On 04/25/2016 12:22 PM, Peter Foley wrote:
On Mon, Apr 25, 2016 at 1:05 PM, Josh Stone <jistone@xxxxxxxxxx> wrote:
On 04/23/2016 12:57 PM, Peter Foley wrote:
Don't unconditionally include all of namespace std
I agree it's good practice avoid "using namespace std;" in API headers,
so you don't force that on the library's users.
However, IMO removing std from all the source files is needless churn.
It's perfectly fine for a project to unconditionally use std internally
as many projects do, and as dyninst has for a long time.
Is there a real problem you're trying to solve here?
I figured since I was removing 'using namespace std' from the header
files, I might as well "fix" the source files that were implicitly
depending on those includes at the same time, especially since most of
them had a mix of std::<type> and just plain <type>.
That said, I have no issue with simply adding a bunch of 'using
namespace std' to the C files if that's the consensus on the best way
to go.
I think what we want to maintain, at least for 9.x, is the following
guidelines:
* No "using namespace" in public headers (foo/h/*.h); "using foo::bar"
may be used but prefer typedefs if you want to clean up overly long
namespace chains
* Any of "using namespace foo", "using foo::bar", and "foo::bar" is
acceptable in private headers and source files (foo/src/*.[hC]). "using
foo::bar" or explicit "foo::bar" at point of use is preferred in the
absence of typedefs; typedefs and auto are the preferred options we
should trend towards in new code.
* If you're already touching a type, you may replace it with the most
preferred form (typedefs and auto to hide implementation details).
* If you see something unacceptable, fix it.
This sound good to folks?
Thanks,
Peter
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}