Hi, On Fri, Aug 02, 2013 at 11:30:01PM -0500, Gabriel Dos Reis wrote: > [ Adding Benjamin, Diego, Lawrence ] > > General remarks first: > When we designed the coding standards for GCC, an overriding > philosophy was that we did not want to be prescriptive. Rather, we > explicitly wanted to encourage common sense and trust the judgment > of maintainers to make sound and appropriate judgments. > > More than a year later, I still believe that was the right thing to do > and I would not want us to start being prescriptive. > > > It is a "common wisdom" among C++ programmers that using directives > in header files generally negate the benefits of namespaces, and can > lead to surprises. This is because most of the time, people don't go > scrutinize header files; they include them (based on documentation > of declared signatures) in many translation units.
Perhaps it was a mistake of mine but I never intended to discuss using "using" in header files. I was basically wondering whether we should start a C file with "using namespace gcc" instead of sprinkling the source below with "gcc::" qualifiers. I suppose it probably depends on what we intend to move in that particular namespace (or into another namespace in general but I think that we should probably discuss this only after a great deal of Andrew's re-architecting actually happens and we see the clearer interfaces that will hopefully emerge). > > There is one notable exception to this, which is known as > "namespace composition": > > > http://stackoverflow.com/questions/16871390/why-is-namespace-composition-so-rarely-used > > We should probably amend the coding standards and include that hint, > but I don't feel strongly about it. > > > > > These aren't the GCC coding conventions, but the Google conventions: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Namespaces > > forbid using directives of the form: > > using NAMESPACE; > > but suggest using directives of the form: > > using NAMESPACE::NAME; > > to pick out individual names from a namespace, though *not* in global > > scope in a header (to avoid polluting the global namespace). > > The using declarations are fine, as indicated. > > > > > I like this approach - how about using it for frequently used names in > > a .c/.cc file, keeping the names alphabetizing by "fully qualified > > path", so e.g.: > > > > #include "foo.h" > > ... > > #include "bar.h" > > > > using gcc::context; > > using gcc::pass_manager; > > ...etc, individually grabbing the names we'll be needing > > > > // code follows > > > > and thus avoiding grabbing whole namespaces, whilst keeping the code > > concise. > > Agreed. If that's the general feeling, I'll comply. With only one big gcc namespace, I do not see the point though. Once we'll divide our namespace, it will make sense. (But as I wrote above, I think that it will take and should take some time before we get there.) > > […] > > > Note that as per > > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01365.html > > we'll use "pass_manager" rather than "pipeline", so this would look > > like: > > pass_manager &get_passes () { gcc_assert (passes_); return *passes_; } > > > > We were chatting about C++ references on IRC on Friday, and IIRC there > > was a strong objection to passing *arguments* that are non-const > > references, > > I hope nobody is objecting to std::swap for example. I'm not sure how I could object to std::swap or what good would that be. Apart from being the standard, it is also rather exceptional due to its nature and its name. Despite this special example, I think the rule of not passing arguments as non-const references is a good one, and it seems I am not alone. Where I may differ from others is that I also think that getter functions should (generally) return pointers or const references too, and for similar reasons - the caller may unintentionally modify data that the programmers thought were on the stack but were in fact elsewhere else and "belonged" to someplace else. Nevertheless, I do not want spend too much time arguing about this, it seems I have not persuaded people that it will lead to bugs which will be hard to debug and so let's drop this discussion and hope that I am wrong (though I will swear a lot if I ever I stumble across such a bug). Martin
