How to say: NOT using namespace std
Esa
using namespace std;
How do I turn it off, i.e. that I am not using namespace std anymore?
/Esa
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Fehér@ronto.lmf.ericsson.se
>
> I have defined in my code in the global scope:
>
> using namespace std;
>
> How do I turn it off, i.e. that I am not using namespace std anymore?
There is no way. Don't use using namespace std; - it is evil. Name
specifically those functions/types/classes/etc you want to use. Also
try to name them with using _inside_ you function bodies. Outside use
std:: (like for return values). Don't pollute the global namespace if
you don't have to.
A
Jon Bell
>I have defined in my code in the global scope:
>
>using namespace std;
>
>How do I turn it off, i.e. that I am not using namespace std anymore?
Simply remove that statement. Then if you want to use any names from std,
you must either (a) prefix them with 'std::', for example:
std::cout << "Hello, world!" << std::endl;
or (b) name them in 'using' declarations:
using std::cout;
using std::endl;
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Radoslav Getov
: I have defined in my code in the global scope:
:
: using namespace std;
:
: How do I turn it off, i.e. that I am not using namespace std anymore?
Impossible, but there is a workaround and advice: *never* use 'using
namespace' (IMHO 'using' shouldn't exist at all).
Radoslav Getov
Thomas Kunert
>
>
> Impossible, but there is a workaround and advice: *never* use 'using
> namespace' (IMHO 'using' shouldn't exist at all).
>
using namespace std;
at the beginning of each source file that uses features from the
standard library. Of course, you might have problems if you have classes
in other namespaces with the same name like standard library classes,
but do people really do that?
Regards,
Thomas Kunert
Thomas Kunert
>
> I have defined in my code in the global scope:
>
> using namespace std;
>
> How do I turn it off, i.e. that I am not using namespace std anymore?
>
Just curious,
but why would you want to do that?
Thanks,
Thomas Kunert
Steve Clamage
> "Esa" <x@y.z> wrote in message news:f0gV6.1$22....@news.get2net.dk...
> : I have defined in my code in the global scope:
> :
> : using namespace std;
> :
> : How do I turn it off, i.e. that I am not using namespace std anymore?
> :
>
> Impossible, but there is a workaround and advice: *never* use 'using
> namespace' (IMHO 'using' shouldn't exist at all).
A using-directive might be OK if you restrict its scope. For
example, you might create auxiliary namespaces for use in
a primary namespace. Inside the primary namespace,
using namespace auxiliary;
is probably fine.
But I agree that you never should put
using namespace std;
in global scope, or probably anywhere. It is too big a hammer,
introducing names you probably do not expect.
Unfortunately, many example programs in many textbooks
employ such a using-declaration. I don't know why. I would
steer clear of such books, as they probably contain other
bad advice.
Even in a toy program it is a simple matter to add a using-
directive for just the names you intend to use:
#include <iostream>
using std::cout;
using std::endl;
int main()
{
cout << "Hello, world!" << endl;
}
If you forget one, the compiler will remind you. :-)
---
Steve Clamage, stephen...@sun.com
Thomas A. Horsley
>:
>
>Impossible, but there is a workaround and advice: *never* use 'using
>namespace' (IMHO 'using' shouldn't exist at all).
In principle, I agree you should never use "using", but the last time
I tried to write code that would port to a lot of different platforms,
I found that the variations in what was and wasn't actually specified
correctly in namespace "std" were huge. The only way to write code that
would compile on all of them was "using namespace std" and leaving
off the std:: everywhere. That way if it was in "std" it worked, and
if it wasn't in "std" it worked :-).
Possibly people are much more standard conforming these days and getting
rid of using might work (I hope so).
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
email: Tom.H...@worldnet.att.net icbm: Delray Beach, FL |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+
Francis Glassborow
<kun...@physik.tu-dresden.de> writes
>Radoslav Getov wrote:
>>
>>
>> Impossible, but there is a workaround and advice: *never* use 'using
>> namespace' (IMHO 'using' shouldn't exist at all).
>>
>What's wrong with it? In most cases it seems quite comfortable to write
>
>using namespace std;
>
>at the beginning of each source file that uses features from the
>standard library. Of course, you might have problems if you have classes
>in other namespaces with the same name like standard library classes,
>but do people really do that?
Yes, but in addition solutions should apply to other libraries and
'using directives are far too heavy.
I would very much like to be able to write (particularly in header
files) using namespace xyz at the beginning and ~using namespace xyz at
the end. But I would also like to be able to write:
using namespace xyz;
~using xyz::feature;
Now my question is 'how much more complicated does this make compiler
writing?
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Francis Glassborow
<kun...@physik.tu-dresden.de> writes
>>
>>
>> using namespace std;
>>
>> How do I turn it off, i.e. that I am not using namespace std anymore?
>>
>
>Just curious,
>but why would you want to do that?
Not least, so that I can use libraries where the implementors have
messed things up with using directives that I do not want to leak into
my code.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Jon Bell
Steve Clamage <cla...@eng.sun.com> wrote:
>
>But I agree that you never should put
> using namespace std;
>in global scope, or probably anywhere. It is too big a hammer,
>introducing names you probably do not expect.
>
>Unfortunately, many example programs in many textbooks
>employ such a using-declaration. I don't know why.
In many cases, the authors probably did it as a cheap way to make their
code from an earlier edition compatible with the standard. It's surely
rather time-consuming to add 'std::'s to a lot of pre-existing code, and
then check to make sure each program still compiles.
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
quux111
> In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>,
> Steve Clamage <cla...@eng.sun.com> wrote:
>>
>>But I agree that you never should put
>> using namespace std;
>>in global scope, or probably anywhere. It is too big a hammer,
>>introducing names you probably do not expect.
>>
>>Unfortunately, many example programs in many textbooks
>>employ such a using-declaration. I don't know why.
>
> In many cases, the authors probably did it as a cheap way to make their
> code from an earlier edition compatible with the standard. It's surely
> rather time-consuming to add 'std::'s to a lot of pre-existing code, and
> then check to make sure each program still compiles.
>
Putting std:: in front of simple pieces of code is needlessly messy,
especially when a given code fragment uses only std:: elements. It's a
fair practice if you write tutorial code -- I do it all the time in my
documentation, but never in production code.
I do agree that "using namespace blah;" is bad practice *in most cases* and
should be avoided.
Chris Riesbeck
Clamage <cla...@eng.sun.com> wrote:
>Unfortunately, many example programs in many textbooks
>employ such a using-declaration. I don't know why. I would
>steer clear of such books, as they probably contain other
>bad advice.
>
>Even in a toy program it is a simple matter to add a using-
>directive for just the names you intend to use:
>
>#include <iostream>
>using std::cout;
>using std::endl;
Even for those textbook authors who care (many don't)
there's the problem of supporting the older compilers many
school labs still use.
The above breaks in Borland C++ 5.0 (which is not even
close to how far back some schools go) because <iostream>
was not put in std.
Dave Harris
> I have defined in my code in the global scope:
>
> using namespace std;
>
> How do I turn it off, i.e. that I am not using namespace std anymore?
You can use a specific prefix on individual names. Eg ::for_each() will
tell the compile you want the global for_each() rather than
std::for_each().
Otherwise, it's best not to use the using directive at the global scope.
An alternative is to introduce a smaller scope. Eg:
#include <algorithm>
namespace local {
using namespace std;
// Code that wants std stuff.
}
// Code that doesn't want std stuff.
In practice you may be able to use a function's scope instead of inventing
a new namespace, or you might be able to put all the std stuff into a
separate compilation unit. Generally I would expect that the use of std
would fit some natural, logical organisation of the physical source code.
Another alternative is to select just the stuff you need from std. Eg:
#include <algorithm>
using std::for_each;
This gives the benefit of the shorter name for for_each, without polluting
the namespace with unboundedly many other names.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Robert O'Dowd
>
> In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>, Steve
> Clamage <cla...@eng.sun.com> wrote:
>
> >Unfortunately, many example programs in many textbooks
> >employ such a using-declaration. I don't know why. I would
> >steer clear of such books, as they probably contain other
> >bad advice.
> >
> >Even in a toy program it is a simple matter to add a using-
> >directive for just the names you intend to use:
> >
> >#include <iostream>
> >using std::cout;
> >using std::endl;
>
> Even for those textbook authors who care (many don't)
> there's the problem of supporting the older compilers many
> school labs still use.
>
> The above breaks in Borland C++ 5.0 (which is not even
> close to how far back some schools go) because <iostream>
> was not put in std.
>
The problem with that argument is: where do you stop?
It get's worse than that if you look at older compilers.
IIRC, Borland C++ version 3.1 didn't even support namespaces
and (hence?) there was no "using" directive. It also only
had an iostream.h, rather than an iostream. [That compiler
also predates the bool type or exceptions, which are used
in most modern C++ texts somewhere :-) ].
If you must target older compilers, you really need
to use the preprocessor, and test for particular versions
of compilers. Sprinkling that sort of code throughout
examples in C++ texts would make any book unreadable,
and unnecessarily confusing to the target audience who
will often have a reasonably modern compiler and library.
However, a short section that says "If you have an old
compiler that can't compile examples in this book, then use
this approach ...." would probably be helpful. It is also
imperfect: at what point do we accept that someone writing
about modern C++ is allowed to assume a reasonably up
to date compiler? There comes a point where someone who
uses an old compiler needs to accept they need to work out
how to use it (i.e. read their compiler documentation!).
Attila Feher
[SNIP]
> Yes, but in addition solutions should apply to other libraries and
> 'using directives are far too heavy.
>
> I would very much like to be able to write (particularly in header
> files) using namespace xyz at the beginning and ~using namespace xyz at
> the end. But I would also like to be able to write:
>
> using namespace xyz;
> ~using xyz::feature;
>
> Now my question is 'how much more complicated does this make compiler
> writing?
I suggets you do write it only to function bodies etc. where is it
"scoped". In the declarations take the time to fully qualify your
references, like:
std::string Class::cnvStr( const std::string & s, const std::string
&cnvlist) {
using std::string;
using std::whatever;
// ...
}
A
Attila Feher
[SNIP]
> >#include <iostream>
> >using std::cout;
> >using std::endl;
>
> Even for those textbook authors who care (many don't)
> there's the problem of supporting the older compilers many
> school labs still use.
>
> The above breaks in Borland C++ 5.0 (which is not even
> close to how far back some schools go) because <iostream>
> was not put in std.
While this may be true I ask just one question: what the heck those
schools teach? I mean would you go to a "car-repair" school teaching
model out of production for 10 years? For what reason those schools
waste the students time to learn something they will never meet in real
life?
There is the free BCC5.5 command line compiler with VIDE (I personally
use the WScite editor, not the IDE's) and tada: you have a free, very
near standard C++ environment to teach people. I think that it is very
irresponsible for any school to teach using old, unsupported language.
A
Herb Sutter
scope to control the... well... scope of using-declarations and
using-directives.
>Steve Clamage <cla...@eng.sun.com> wrote:
>>Unfortunately, many example programs in many textbooks
>>employ such a using-declaration. I don't know why. I would
>>steer clear of such books, as they probably contain other
>>bad advice.
>>
>>Even in a toy program it is a simple matter to add a using-
>>directive for just the names you intend to use:
>>
>>#include <iostream>
>>using std::cout;
>>using std::endl;
I used to recommend this, including in GotW. My suggestion was:
- in a header, never write namespace using-declarations or -directives
- in a .cpp, write using-declarations as needed, but after all #includes
- short-term compromise for migration of a large code base under time
pressure: go ahead and write a controlled using-directive that comes
after all #includes in every .cpp file, then please go back later and
replace it with all the using-declarations
But I've reformed. In my final draft of More Exceptional C++, I've relaxed
it to:
- in a header, never write namespace using-declarations or -directives
- in a .cpp, write using-declarations or -directives to taste at file
and/or function scope, but after all #includes
- short-term compromise for migration of a large code base: go ahead
and write a controlled using-directive that comes after all
#includes in every .cpp file, and if you feel like it go back and
take it out later in individual .cpp files where it makes sense
I reformed for three major reasons:
1. Using-declarations and -directives exist for the convenience of
programmers, not vice versa. Do what makes sense (if you have no name
collisions, why not just use all names?), as long as it affects only your
own translation unit and not anybody else's headers or translation units.
Hence the first two bullets.
2. Since toy programs are mentioned: Even many of my own toy programs in
MXC++ would have their line counts go up 30-40% if I wrote all those
annoying individual using-declarations. That's just not the point of "using"
-- namespaces were intended to a) prevent name collisions, but also to b)
make code clearer, not needlessly more verbose. I have lots of short
fragments that use four or five standard names in a few lines. A
using-directive, and even explicit qualification, is less typing (and more
readable) than a list of using-declarations.
3. I've found that my own coding style has changed to what I now recommend.
The original advice was based on my porting a large project, and although I
thought we would go back and write using-declarations, in practice we never
felt any need to do so. I learned Reason #1 from that experience. I can't
recommend someone else do something that I no longer feel the need to do, so
I changed my advice to reflect what I do in practice.
Chris Riesbeck <ries...@cs.northwestern.edu> writes:
>Even for those textbook authors who care (many don't)
>there's the problem of supporting the older compilers many
>school labs still use.
I like to think of myself as caring, and you'll see the above
using-directive-sanctioning advice in print this summer. I hope that doesn't
cause anyone to not read the book. I think it's valuable to share
experience, especially when I used to believe that using-directives were
evil power tools. I now believe that power tools are not evil in themselves
and perfectly useful for quality carpentry or quality code, though of course
they shouldn't be handled carelessly.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar, the definitive C++ event of 2001:
http://www.gotw.ca/cpp_seminar
Chris Riesbeck
<Attila...@lmf.ericsson.se> wrote:
>Chris Riesbeck wrote:
>[SNIP]
>>
>> there's the problem of supporting the older compilers many
>> school labs still use.
>
>While this may be true I ask just one question: what the heck those
>schools teach? I mean would you go to a "car-repair" school teaching
>model out of production for 10 years? For what reason those schools
>waste the students time to learn something they will never meet in real
>life?
They (meaning high schools and many colleges here)
think they're teaching what programming is, not what C++ is.
>There is the free BCC5.5 command line compiler with VIDE (I personally
>use the WScite editor, not the IDE's) and tada: you have a free, very
>near standard C++ environment to teach people. I think that it is very
>irresponsible for any school to teach using old, unsupported language.
There are most costs than the cost of the compiler. There's
the time and resources needed to install and maintain not
only the compiler, but all the example code. There's the cost
of memory and disk upgrades. There's the cost of updating
the text and screen shots of the setup and compile instructions.
And don't forget that doing all this work is not usually
part of the job specification of a teacher.
And the original posting was not about the schools that do this,
rightly or wrongly, but about the textbook authors, who have
to write books that publishers can sell as many copies as possible
of.
John J. Rusnak
the compiler(s) you are using are not standards compliant. (Is there
actually a C++ compiler that comes close to the standard in existence out
there?) If a compiler doesn't meet the standard, either file a defect
report with the compiler vendor to get it fixed or stop using the compiler.
"Thomas A. Horsley" wrote:
> In principle, I agree you should never use "using", but the last time
> I tried to write code that would port to a lot of different platforms,
> I found that the variations in what was and wasn't actually specified
> correctly in namespace "std" were huge. The only way to write code that
> would compile on all of them was "using namespace std" and leaving
> off the std:: everywhere. That way if it was in "std" it worked, and
> if it wasn't in "std" it worked :-).
David Abrahams
"Herb Sutter" <hsu...@acm.org> wrote in message
news:73ukitgf71d0eflbc...@4ax.com...
> 1. Using-declarations and -directives exist for the convenience of
> programmers, not vice versa. Do what makes sense (if you have no name
> collisions, why not just use all names?), as long as it affects only your
> own translation unit and not anybody else's headers or translation units.
I think you should also add: "and as long as you will be around and willing
to maintain the code forever so that when a collision appears in the
namespace you're using, you can track down the problem and sort out the
original intention of the code."
> Hence the first two bullets.
>
> 2. Since toy programs are mentioned: Even many of my own toy programs in
> MXC++ would have their line counts go up 30-40% if I wrote all those
> annoying individual using-declarations. That's just not the point of
"using"
> -- namespaces were intended to a) prevent name collisions, but also to b)
> make code clearer, not needlessly more verbose. I have lots of short
> fragments that use four or five standard names in a few lines. A
> using-directive, and even explicit qualification, is less typing (and more
> readable) than a list of using-declarations.
Weird. I've always found the opposite. When reading code explicit
qualification almost always helps, by allowing me to instantly recognize the
provenance of a name.
> 3. I've found that my own coding style has changed to what I now
recommend.
> The original advice was based on my porting a large project, and although
I
> thought we would go back and write using-declarations, in practice we
never
> felt any need to do so.
Well, of course: it seems obvious to me that the real problems with
using-directives won't show up until much later in a project's lifecycle,
when the namespaces you're "using" evolve. Programmers in other languages
with similar constructs (e.g. Python) have learned the analogous lesson, the
hard way.
> I learned Reason #1 from that experience. I can't
> recommend someone else do something that I no longer feel the need to do,
so
> I changed my advice to reflect what I do in practice.
>
>
> Chris Riesbeck <ries...@cs.northwestern.edu> writes:
> >Even for those textbook authors who care (many don't)
> >there's the problem of supporting the older compilers many
> >school labs still use.
>
> I like to think of myself as caring, and you'll see the above
> using-directive-sanctioning advice in print this summer. I hope that
doesn't
> cause anyone to not read the book. I think it's valuable to share
> experience, especially when I used to believe that using-directives were
> evil power tools. I now believe that power tools are not evil in
themselves
> and perfectly useful for quality carpentry or quality code, though of
course
> they shouldn't be handled carelessly.
Absolutely. In this case, however, I don't think the tools supply much
useful power. They're not like some complicated template metaprogramming
construct that may not be easily understood by novice programmers. They do
save some typing and thought about naming and code formatting, but I think
the tempation to go fast at the expense of the long-term health of a project
is one that should be resisted. With a little care, explicitly-qualified
code can be quite easy to read (and write, even)!
-Dave
James Kanze
> Is the C++ standard that ill-defined? I believe the problem here is
> that the compiler(s) you are using are not standards compliant. (Is
> there actually a C++ compiler that comes close to the standard in
> existence out there?) If a compiler doesn't meet the standard,
> either file a defect report with the compiler vendor to get it fixed
> or stop using the compiler.
The problem is definitely one of using non-compliant compilers. On the
other hand, if you refuse to use non-compliant compilers, you can't
compile C++ at all. Realistically, different compilers are at
different stages, and you have to live with it.
For me, the solution is to define the macros GB_std and GB_iostd in a
header, and to use them to qualify all standard functions. (I need
two, because for portability reasons, I generally have to use the
classic iostreams, instead of the standard ones. And the classic
iostreams aren't in std, whereas the rest of the library probably is.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Mary K. Kuhner
all kinds of strange and cranky compilers. Even with what we have
in the lab, I find that some code will break on compiler A if I use
"std::foo" and break on compiler B if I use "foo". In these cases
"using namespace std" is the only solution I know of short of
massive preprocessor hacking, and it has the advantage that I
don't have to be able to diagnose which compiler my biologist might
be using.
You can't replace it with "using std::foo" because this will kill
you on the compiler where foo is not in std.
I will be a very happy coder when standard-conformant compilers
get a little more common. I'd like to be able to use auto_ptr,
but my current stable of compilers has two auto_ptr
implementations broken in two different ways that cannot be
reconciled. I think I will have to resort to borrowing a good
implementation and renaming it my_auto_ptr. Yucch.
Mary Kuhner mkku...@genetics.washington.edu
Mary K. Kuhner
John J. Rusnak <john....@mindspring.com> wrote:
>Is the C++ standard that ill-defined? I believe the problem here is that
>the compiler(s) you are using are not standards compliant. (Is there
>actually a C++ compiler that comes close to the standard in existence out
>there?) If a compiler doesn't meet the standard, either file a defect
>report with the compiler vendor to get it fixed or stop using the compiler.
This is only relevant if you control all compilation of your code;
if you distribute source, you cannot control what compilers are
used, and it is often desirable to have it compile (correctly!) on
as many compilers as possible.
(But I had to give up on VC++. It just wasn't happening.)
In general, people working in different fields face very different
constraints, and a rule (like "never use 'using namespace std') that
makes perfect sense in one environment may be inappropriate in
another.
Mary Kuhner mkku...@genetics.washington.edu
Mark Wilden
> programmers, not vice versa. Do what makes sense (if you have no name
> collisions, why not just use all names?), as long as it affects only your
> own translation unit and not anybody else's headers or translation units.
Finally, a voice of reason.
Folks are so afraid of "polluting the global namespace" (that
oh-so-cool-sounding phrase) that they forget what namespaces are for.
Herb Sutter
>Weird. I've always found the opposite. When reading code explicit
>qualification almost always helps, by allowing me to instantly recognize the
>provenance of a name.
I do sometimes run across people who like explicit qualifications sprinkled
everywhere (I didn't know you were one). To me it's clutter. YMMV, hence the
advice "season to taste."
>> The original advice was based on my porting a large project, and although I
>> thought we would go back and write using-declarations, in practice we never
>> felt any need to do so.
>
>Well, of course: it seems obvious to me that the real problems with
>using-directives won't show up until much later in a project's lifecycle,
>when the namespaces you're "using" evolve.
I did wait to accumulate experience before changing my advice. It's been
several years now -- several major and many minor project releases later,
and several major and minor compiler/library upgrades later. The chimera
still hasn't manifested.
Again, YMMV. This happened to be my experience on a nontrivial and living
(i.e., changing and adapting) commercial software project, but it's only my
experience.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar, the definitive C++ event of 2001:
http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ben Coltrin
news:<9gge2k$qcf$1...@bob.news.rcn.net>...
> I think you should also add: "and as long as you will be around and willing
> to maintain the code forever so that when a collision appears in the
> namespace you're using, you can track down the problem and sort out the
> original intention of the code."
you're saying that because you might want to declare some variable
cout, that the original programmer should have put std:: garbage in
front of all his cout statements? When the collision appears, it will
be because of new code that is added, and that new code is what should
be changed. Programming for the future is important, but be
realistic.
> Weird. I've always found the opposite. When reading code explicit
> qualification almost always helps, by allowing me to instantly recognize the
> provenance of a name.
You really only need the using directives when different libraries
collide with your own code. I think that names tell what they do, and
if by not recognizing the function from the name, the library name
won't probably help either.
> Well, of course: it seems obvious to me that the real problems with
> using-directives won't show up until much later in a project's lifecycle,
> when the namespaces you're "using" evolve. Programmers in other languages
> with similar constructs (e.g. Python) have learned the analogous lesson, the
> hard way.
But the point Herb was making was that you don't have a global
include, and you don't put the using before the includes in the .cpp
files. That way if (or when) you have a naming conflict, it is local
to a .cpp file and no more. Naming conflicts will never go away.
Namespaces are just a means to when you have the problem, you can fix
it easier than having to rename a lot of things.
> Absolutely. In this case, however, I don't think the tools supply much
> useful power. They're not like some complicated template metaprogramming
> construct that may not be easily understood by novice programmers. They do
> save some typing and thought about naming and code formatting, but I think
> the tempation to go fast at the expense of the long-term health of a project
> is one that should be resisted. With a little care, explicitly-qualified
> code can be quite easy to read (and write, even)!
The point with namespaces is to make programming easier.
Explicitly-qualified code is redundant and messy. Always writing
std::cout << "So you can one day write " << cout; is silly. The real
point behind namespaces is to resolve naming conflicts when they
occur. I think the prevention of always having to use scope
resolution operators and worrying about multiple using directives is
harder than the cure of just using them when needed.
-Ben
James Kanze
> "David Abrahams" <david.a...@rcn.com> wrote in message
> news:<9gge2k$qcf$1...@bob.news.rcn.net>...
> > I think you should also add: "and as long as you will be around
> > and willing to maintain the code forever so that when a collision
> > appears in the namespace you're using, you can track down the
> > problem and sort out the original intention of the code."
> Maintain your code forever so that when a collision appears? So
> you're saying that because you might want to declare some variable
> cout, that the original programmer should have put std:: garbage in
> front of all his cout statements? When the collision appears, it
> will be because of new code that is added, and that new code is what
> should be changed. Programming for the future is important, but be
> realistic.
What he is actually saying is that the name of the object in standard
C++ is std::cout. C++ offers some possibilities for contracting this,
but given that the variable has a very large scope, I rather expect a
long name.
Note that in some cases, the qualifier will be needed; the word "cout"
is a perfectly valid word, at least in France, where I have programmed
the most, and is likely to occur as the name of a member variable in
certain classes. And I certainly don't like the idea that sometimes
standard out is spelled cout, and othertimes std::cout. Consistency
has its value, and the only spelling that can be used consistently is
std::cout.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Dave Harris
> I did wait to accumulate experience before changing my advice. It's been
> several years now -- several major and many minor project releases
> later, and several major and minor compiler/library upgrades later.
> The chimera still hasn't manifested.
I imagine some problems, due to new names being added to the std
namespace, won't manifest themselves until a new version of the C++
Standard is produced.
> - in a header, never write namespace using-declarations or -directives
Agreed.
> - in a .cpp, write using-declarations or -directives to taste at file
> and/or function scope, but after all #includes
The size of the scopes matters. The chances of a name collision are
something like M*N, where M is the number of names in the included
namespace and N is the number of names used in the scope doing the
including. Thus using-declarations are usually OK (small M) and both
declarations and directives are usually OK at function scope (small N,
assuming short functions).
I would balk at a using-directive for std (large M) at the top of a
longish source file (large N), even after all #includes. Short source
files would be OK. Of course it's hard to know where to draw the line.
I would tend to give std special treatment because it is so large, and
because I expect new names to be added to it every 10 years or so. I
wouldn't be so bothered about a namespace I control myself.
> - short-term compromise for migration of a large code base: go ahead
> and write a controlled using-directive that comes after all
> #includes in every .cpp file, and if you feel like it go back and
> take it out later in individual .cpp files where it makes sense
I mostly agree with this. I am a bit concerned about "bit-decay", when old
programs no longer compile. Still, maybe the code will be junk by then for
other reasons :-)
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
news:3B31A9D3...@dresdner-bank.com...
>
> Note that in some cases, the qualifier will be needed; the word "cout"
> is a perfectly valid word, at least in France, where I have programmed
> the most, and is likely to occur as the name of a member variable in
> certain classes.
I don't know how French speakers would feel about using the word "cout" for
anything other than std::cout, but I do know how (I think) most English
speakers would feel about using "vector" for anything other than
std::vector. It would be annoying and confusing (and unnecessary).
> And I certainly don't like the idea that sometimes
> standard out is spelled cout, and othertimes std::cout. Consistency
> has its value, and the only spelling that can be used consistently is
> std::cout.
Well, you know what Emerson said about a foolish consistency, and while I
wouldn't call this one exactly foolish, I do not personally see the benefit
in it.
Consistency is useful to help us remember things. For example, I
consistently name my methods verb-noun (like lots of people). That way, I
never have to remember whether it's AddCustomer or CustomerAdd (either would
be legitimate on its own).
But I don't see any such advantage accruing from using std::cout everywhere.
What exactly does this consistency buy you?
Roland Pibinger
>I have defined in my code in the global scope:
>
>using namespace std;
>
>How do I turn it off, i.e. that I am not using namespace std anymore?
>
You can delimit the namespace directive by putting it in your own
namespace, e.g.
namespace MyApp
{
using namespace std;
//...
}
Best wishes,
Roland Pibinger
David Abrahams
>
> > "David Abrahams" <david.a...@rcn.com> wrote in message
> > news:<9gge2k$qcf$1...@bob.news.rcn.net>...
>
> > > I think you should also add: "and as long as you will be around
> > > and willing to maintain the code forever so that when a collision
> > > appears in the namespace you're using, you can track down the
> > > problem and sort out the original intention of the code."
>
> > Maintain your code forever so that when a collision appears? So
> > you're saying that because you might want to declare some variable
> > cout, that the original programmer should have put std:: garbage in
> > front of all his cout statements? When the collision appears, it
> > will be because of new code that is added, and that new code is what
> > should be changed. Programming for the future is important, but be
> > realistic.
>
> What he is actually saying is that the name of the object in standard
> C++ is std::cout. C++ offers some possibilities for contracting this,
> but given that the variable has a very large scope, I rather expect a
> long name.
Actually I was talking about what happens when std:: or some other 3rd-party
namespace you don't have absolute control over acquires a new name that
collides with one of yours.
-Dave
Herb Sutter
>Actually I was talking about what happens when std:: or some other 3rd-party
>namespace you don't have absolute control over acquires a new name that
>collides with one of yours.
I understand the theoretical problem, but:
a) so you just fix the name collision; and
b) how often has this happened to you in practice?
The more experience I get with namespaces, the more I feel that they're a
solution to a problem that does exist but is nowhere near as serious as most
people feared. I feel that namespaces are principally useful as a simple way
to _resolve_ the rare name collision, and usually not worth the effort to
try to _prevent_ the rare name collision.
In other words, explicit qualification is valuable for disambiguation, but I
certainly have spent more time writing (never mind debating) "using" than I
have saved by using it (pun intended).
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar, the definitive C++ event of 2001:
http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dennis Yelle
>
> "David Abrahams" <abra...@altrabroadband.com> writes:
> >Actually I was talking about what happens when std:: or some other 3rd-party
> >namespace you don't have absolute control over acquires a new name that
> >collides with one of yours.
>
> I understand the theoretical problem, but:
>
> a) so you just fix the name collision; and
>
> b) how often has this happened to you in practice?
>
> The more experience I get with namespaces, the more I feel that they're a
> solution to a problem that does exist but is nowhere near as serious as most
> people feared. I feel that namespaces are principally useful as a simple way
> to _resolve_ the rare name collision, and usually not worth the effort to
> try to _prevent_ the rare name collision.
>
> In other words, explicit qualification is valuable for disambiguation, but I
> certainly have spent more time writing (never mind debating) "using" than I
> have saved by using it (pun intended).
>
> Herb
I actually agree with you on this, Herb, but I wanted to share
with you something that happened to me the other day.
I was writing a quick-and-dirty program and I used
a global variable called "count". I would not have done this
in a large program, but this program was a single file and
less than 200 lines total. Anyway, I discovered that this
doesn't work:
#include <algorithm>
using namespace std;
int count;
int main()
{
count = 7;
return 0;
}
===================
So, yes, I agree with you, but these things do happen.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://www.eskimo.com/~dy1951/
David Abrahams
> "David Abrahams" <abra...@altrabroadband.com> writes:
> >Actually I was talking about what happens when std:: or some other
3rd-party
> >namespace you don't have absolute control over acquires a new name that
> >collides with one of yours.
>
> I understand the theoretical problem, but:
>
> a) so you just fix the name collision; and
Okay, so you just updated your libraries. The code has been around for
years. Now your code is getting compiler errors. How do you "just fix" them?
In other words, how can you tell from looking at the use of an unqualified
name which (qualified) name was actually intended? Worse, if there were
implicit conversions or templates involved, it is possible that your code
will silently begin to call a different function than the intended one
because the other is a better match.
> b) how often has this happened to you in practice?
Never; I have always avoided the use of unqualified names ;-)
Also, I haven't lived with any standard or 3rd-party libraries through a
major change of content.
> The more experience I get with namespaces, the more I feel that they're a
> solution to a problem that does exist but is nowhere near as serious as
most
> people feared. I feel that namespaces are principally useful as a simple
way
> to _resolve_ the rare name collision, and usually not worth the effort to
> try to _prevent_ the rare name collision.
So, it is best to put everything in the global namespace until it collides
with something?
Hmm, I couldn't disagree more. I think we can learn lots from Python here, a
language which is well-known for being easy-to-use. Tim Peters, a member of
the core team of Python language developers, has written "The Python Way", a
set of principles that could easily apply to most software engineering
issues:
1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.
14. Although that way may not be obvious at first unless you're Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- let's do more of those!
Note in particular items 2 and 19. In Python, you even have to explicitly
qualify access to data members, but somehow Python developers never seem to
complain about explicit qualification. Even though Python provides the
equivalent of using-directives (from module import * actually works better
than using directives because there are no name lookup issues), experienced
Python developers have learned to avoid it because of name collisions. The
syntaxes are not so different between C++ and Python (you save one character
in Python by using "." instead of "::"); why do we C++ programmers winge so?
> In other words, explicit qualification is valuable for disambiguation, but
I
> certainly have spent more time writing (never mind debating) "using" than
I
> have saved by using it (pun intended).
This doesn't make much sense to me. The alternative to "using" is explicit
qualification. If "using" isn't saving you time, why bother with it?
-Dave
Herb Sutter
>
>"Herb Sutter" <hsu...@acm.org> wrote in message
>news:7pgbjtsol9i20dhha...@4ax.com...
>>
>> "David Abrahams" <abra...@altrabroadband.com> writes:
>> >Actually I was talking about what happens when std:: or some other 3rd-party
>> >namespace you don't have absolute control over acquires a new name that
>> >collides with one of yours.
>>
>> I understand the theoretical problem, but:
>>
>> a) so you just fix the name collision; and
>
>Okay, so you just updated your libraries. The code has been around for
>years. Now your code is getting compiler errors. How do you "just fix" them?
>In other words, how can you tell from looking at the use of an unqualified
>name which (qualified) name was actually intended?
If you just updated a library and now there's a name conflict because of a
new name in that library, obviously the code meant the other name...?
>Worse, if there were
>implicit conversions or templates involved, it is possible that your code
>will silently begin to call a different function than the intended one
>because the other is a better match.
Theoretically possible, but I'm back to "how often does this happen in
practice?" Has anyone a real-world case in point? Is this a clear and
present danger, or a chimera? There are other cases in C++ already much more
likely than this to cause silent change of meaning.
>> The more experience I get with namespaces, the more I feel that they're a
>> solution to a problem that does exist but is nowhere near as serious as most
>> people feared. I feel that namespaces are principally useful as a simple way
>> to _resolve_ the rare name collision, and usually not worth the effort to
>> try to _prevent_ the rare name collision.
>
>So, it is best to put everything in the global namespace until it collides
>with something?
No, the question was about writing "using" to get at code in namespaces, not
about putting code into separate namespaces in the first place. These are
distinct issues:
1. Should you put library/project code in its own namespace? Yes, do that.
Otherwise the user can never resolve ambiguities with VendorA::sort() vs.
MyProject::sort() vs. std::sort() using explicit qualification (or "using").
2. Should you use explicit qualification vs. using-declarations vs.
using-directives? Do what's simplest; if that's a using-directive, don't be
ashamed, darn the torpedoes and hecklers and go for it.
It's for case #2 that I opined "namespaces are principally useful as a
simple way to _resolve_ the rare name collision [by explicit qualification],
and usually not worth the effort to try to _prevent_ the rare name
collision" by going overboard with paranoia and excessive carefulness,
wasting a lot of time with explicit qualification all over the place, or
writing a painstaking bunch of using-declarations, in an effort to _prevent_
a rare and only potential problem that may never occur in that source
module.
>Note in particular items 2 and 19.
>2. Explicit is better than implicit.
>19. Namespaces are one honking great idea -- let's do more of those!
Yes. When it comes to code littered with explicit qualifications, though, I
also give weight to the other points:
>1. Beautiful is better than ugly.
>3. Simple is better than complex.
>6. Sparse is better than dense.
>7. Readability counts.
>9. Although practicality beats purity.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar, the definitive C++ event of 2001:
http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> "James Kanze" <James...@dresdner-bank.com> wrote in message
> news:3B31A9D3...@dresdner-bank.com...
> > Note that in some cases, the qualifier will be needed; the word
> > "cout" is a perfectly valid word, at least in France, where I have
> > programmed the most, and is likely to occur as the name of a
> > member variable in certain classes.
> I don't know how French speakers would feel about using the word
> "cout" for anything other than std::cout, but I do know how (I
> think) most English speakers would feel about using "vector" for
> anything other than std::vector. It would be annoying and confusing
> (and unnecessary).
I don't think that the two are comparable. The std::vector implements
a vector, and it would be annoying and confusing to have two different
vectors in a program. Not just because of the name clash. In the
case of cout in a French program, we have something like the case of
CardDeck::draw and VisibleObject::draw -- I doubt that English
speakers have problems with this, because the two words, although
spelled the same, are in fact completely different.
Presumably, once universal character names are widely supported, the
problem for cout will disappear, because the correct spelling of the
French word is coût. But I wouldn't hold my breath -- it's not
sufficient for compilers to support it; the entire development
environment must conform, because no one is going to write (nor want
to read) co\u00fbt.
> > And I certainly don't like the idea that sometimes standard out is
> > spelled cout, and othertimes std::cout. Consistency has its
> > value, and the only spelling that can be used consistently is
> > std::cout.
> Well, you know what Emerson said about a foolish consistency, and
> while I wouldn't call this one exactly foolish, I do not personally
> see the benefit in it.
> Consistency is useful to help us remember things. For example, I
> consistently name my methods verb-noun (like lots of people). That
> way, I never have to remember whether it's AddCustomer or
> CustomerAdd (either would be legitimate on its own).
> But I don't see any such advantage accruing from using std::cout
> everywhere. What exactly does this consistency buy you?
Readability. When I see std::cout, I know exactly what is being
referred to. When I see simply cout, it is not as 100% certain.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Mark Wilden
> > But I don't see any such advantage accruing from using std::cout
> > everywhere. What exactly does this consistency buy you?
>
> Readability. When I see std::cout, I know exactly what is being
> referred to. When I see simply cout, it is not as 100% certain.
Isn't it 99% certain, though? Especially in a shop with code reviews, it's
hard for me to imagine justifying cout as a variable name.
Balog Pal (mh)
news:3B361221...@jps.net...
> I was writing a quick-and-dirty program and I used
> a global variable called "count".
Sure mistake. ;-) A whole set of them.
'quick-and-dirty' is a common excuse, but actually a wrong one. I found
following the same common-sense guidelines no matter is no-one supposedly is
watching is a good thing, and doing otherwise almost consistently bites. So
all possible benefit of quickness goes down the sink. Also, if you ever
encounter a real comparision, having someone made the same correctly, it'll
show next to nothing real gain anyway.
Using nonconst globals is bad (in the common environments used today
commonly). And adding all-lowercase names at global scope is a call for
disaster is you also use std.
The "solution" is pretty simple, give your identifiers well-describing names
('count' is definitely <CENSORED by mod:> unless it's a local in a short
function, a param, or a class member in a correct class.) And having that
describing name, use uppercase or _ word separators. Then collisions with
std is really unlikely.
>I would not have done this
> in a large program, but this program was a single file and
> less than 200 lines total.
Today. Next day you add another 100 lines, then some more, someone cuts it
in
a library, etc, and all your stuff "you'd not do for real" leak to a real
environment. And will bite much more seriously than a simple failure to
compile.
Paul
Andrei Alexandrescu
[talking in favor of using-directives]
Look, here's a guy who said, hey, he's naked! Because the ban against the
using-directive is an instance of emperor's clothes to me.
***
I've never have trouble with using-directives in projects of various sizes,
and I've given up the hysteria of bloating my code with namespace prefixes a
time ago, but in silence and shame. I was a proscribed living in the woods,
and I was living my life in terror of public opprobrium and oppression.
But I wasn't alone.
A small underground community was born, and I slowly made contact with them.
We used special signs and passwords to recognize each other. On December 18,
1999, at 19:00 PST, assuming huge risks, in a private email that sneaked
through Carnivore, Scott Meyers sent me a code snippet that contained the
following line at global scope:
using namespace std; // so sue me
The Revolution was started.
I'd meet my comrades secretly in the office kitchen or cafeteria. Our secret
sign was a coffee stain of a special shape onto our shirts - the shape of an
U. We secretly talked and built upon a dream - the dream of a future when
"using namespace std;" would be legit and accepted by everyone. And so with
/any/ namespace, not std alone! We were sharing the rush of the excitement!
Our mantra was: "Using namespace. Forever!"
Now, the Revolution is here. Join it!
***
Ideally, you should put using-directives of /all/ namespaces they use and
have the compiler tap you on the shoulder /only/ for the few ambiguities
that arise. Those (and only those) would be disambiguated by hand, and not
the other way around.
For the sake of a few potential ambiguities in a large project, you should
be able to work on those rather than have all of your source code be
affected by them.
Andrei
--
Check out THE C++ Seminar: 3 Days with 5 Experts
Ben Coltrin
> I don't think that the two are comparable. The std::vector implements
> a vector, and it would be annoying and confusing to have two different
It would be equally annoying and confusing to have two different
couts.
> > But I don't see any such advantage accruing from using std::cout
> > everywhere. What exactly does this consistency buy you?
>
> Readability. When I see std::cout, I know exactly what is being
> referred to. When I see simply cout, it is not as 100% certain.
Well you should be 100% certain. Anyone using something as simple as
the standard output device's name for something else is looking for
trouble.
Let me quote Bjarne Stroustrup from his book "The Design and Evolution
of C++" on pg. 406 (item 17.4.1), "On the other hand, explicit
qualification of names that everybody knows (or at least ought to
know) and of frequently used names can become a real nuisance. For
example, writing stdio::printf, math::sqrt, and iostream::cout is not
going to help anyone acquainted with C++. The added visual clutter
easily becomes a source of errors. This argues strongly for a
mechanism like using-declarations or using-directives. Of these, a
using-declaration is the more discriminating and by far the less
dangerous."
Andrei Alexandrescu
> using namespace std;
>
> int count;
>
> int main()
> {
> count = 7;
> return 0;
> }
> ===================
>
> So, yes, I agree with you, but these things do happen.
Yeah, and there is a solution - it's spelled "::". So what?
Without namespaces you have a way out of this problem. Without them, you
wouldn't have had. Such is the utility of namespaces.
That doesn't mean we need to make ourselves slaves of full qualification
just to say "Aha! I told you!" when we get an easy to fix compile-time
error.
Andrei
--
Check out THE C++ Seminar: 3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar
Andrei Alexandrescu
> So, it is best to put everything in the global namespace until it collides
> with something?
I guess he didn't mean that. Putting something in a namespace X and then
saying 'using namespace X;' is very different from just putting that thing
an the global namespace. Unfortunately, I've known programmers who were
brainwashed by the literature badly enough so they honestly believed there's
no difference between the two. It's time we end this hoax.
Andrei
--
Check out THE C++ Seminar: 3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar
Jonathan Thornburg
> referred to. When I see simply cout, it is not as 100% certain.
In article <tjf0a7p...@news.supernews.com>,
Mark Wilden <ma...@mwilden.com> wrote:
>Isn't it 99% certain, though? Especially in a shop with code reviews, it's
>hard for me to imagine justifying cout as a variable name.
But clog() for a complex logarithm function is quite plausible.
Indeed, I personally introduced a C library containing such a function
(used within another C library which was in turn called from ourC++ code)
into our not-using-namespaces-for-historical-reasons C++ code last year.
I got some, ahh, "interesting" error messages when including both
<iostream.h> and the header file prototyping the clog() function
extern "C" our_complex clog(our_complex z);
The short-term solution was to hack the C code to use a different
function name. But the long-term solution was/is to use namespaces,
and I'm much more careful in new code nowdays...
--
-- Jonathan Thornburg <jth...@thp.univie.ac.at>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"It's every man for himself, said the elephant as he danced on the
anthill!" -- T. C. "Tommy" Douglas's description of ((you guess))
Attila Feher
[SNIP]
> Isn't it 99% certain, though? Especially in a shop with code reviews, it's
> hard for me to imagine justifying cout as a variable name.
For things like that an old friend of mine (did numerous big and complex
projects in Hungary as a leader) said: before you do xxx (like cout for
variable name) you approach your team leader with two things in hand:
very good reasons and a sickpack of the best beer. :-))) And for things
exactly like this he said that the beer will certainly lost - or drinked
together while he explains: why _not_. :-)))
Same may be true for non-exception safe code, reinventing any parts of
the standard library, doing multiply inheritance (esp. virtual one),
changing an API (I'd like to see a small and not hard co. to employ that
more often :-), making any member var public etc.
A
David Abrahams
> "David Abrahams" <david.a...@rcn.com> writes:
> >Okay, so you just updated your libraries. The code has been around for
> >years. Now your code is getting compiler errors. How do you "just fix"
them?
> >In other words, how can you tell from looking at the use of an
unqualified
> >name which (qualified) name was actually intended?
>
> If you just updated a library and now there's a name conflict because of a
> new name in that library, obviously the code meant the other name...?
Which other name? Remember, the call was not explicitly qualified, and your
code is full of using-declarations.
> >Worse, if there were
> >implicit conversions or templates involved, it is possible that your code
> >will silently begin to call a different function than the intended one
> >because the other is a better match.
>
> Theoretically possible, but I'm back to "how often does this happen in
> practice?" Has anyone a real-world case in point?
I don't, for the reasons I cited before. But name collisions do happen, and
when they do they waste much more time than you'd expect. A great many of us
on the boost list were surprised recently to find that certain names which
are technically available to us as users are being defined as macros by
certain system headers. We avoid macros for the same reasons we use
namespaces.
> No, the question was about writing "using" to get at code in namespaces,
not
> about putting code into separate namespaces in the first place. These are
> distinct issues:
>
> 1. Should you put library/project code in its own namespace? Yes, do that.
> Otherwise the user can never resolve ambiguities with VendorA::sort() vs.
> MyProject::sort() vs. std::sort() using explicit qualification (or
"using").
>
> 2. Should you use explicit qualification vs. using-declarations vs.
> using-directives? Do what's simplest; if that's a using-directive, don't
be
> ashamed, darn the torpedoes and hecklers and go for it.
>
> It's for case #2 that I opined "namespaces are principally useful as a
> simple way to _resolve_ the rare name collision [by explicit
qualification],
> and usually not worth the effort to try to _prevent_ the rare name
> collision" by going overboard with paranoia and excessive carefulness,
> wasting a lot of time with explicit qualification all over the place, or
> writing a painstaking bunch of using-declarations, in an effort to
_prevent_
> a rare and only potential problem that may never occur in that source
> module.
Here's another question closer to the subject line: what is the cost to the
user if he wants to /remove/ a using declaration? That could be very
difficult, it seems to me.
> Yes. When it comes to code littered with explicit qualifications, though,
I
> also give weight to the other points:
>
> >1. Beautiful is better than ugly.
> >3. Simple is better than complex.
> >7. Readability counts.
Funny, you read these differently than I do. Explicit qualification is much
simpler and more readable than a bunch of implicitly looked-up names, IMO.
> >6. Sparse is better than dense.
Rx: simpler expressions, spacebar, newline ;-)
> >9. Although practicality beats purity.
No argument there! If it doesn't work, who cares?
-Dave
Pete Becker
>
> Ideally, you should put using-directives of /all/ namespaces they use and
> have the compiler tap you on the shoulder /only/ for the few ambiguities
> that arise. Those (and only those) would be disambiguated by hand, and not
> the other way around.
>
Using directives can lead to logic errors that don't show up as
ambiguities:
namespace n0
{
#ifdef NEW_VERSION
void f(int);
#endif
}
using namespace n0;
namespace n1
{
void f(double);
}
using namespace n1;
int main()
{
f(1);
return 0;
}
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Pete Becker
>
> "David Abrahams" <david.a...@rcn.com> writes:
> >
> >Worse, if there were
> >implicit conversions or templates involved, it is possible that your code
> >will silently begin to call a different function than the intended one
> >because the other is a better match.
>
> Theoretically possible, but I'm back to "how often does this happen in
> practice?"
>
And how harmful is it if it occurs. A quiet change in meaning can be
disastrous, especially if it goes undetected until you're just about
ready to release. Do you want to risk not making your ship date?
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
news:9hccla$gcr$1...@mach.thp.univie.ac.at...
>
> The short-term solution was to hack the C code to use a different
> function name. But the long-term solution was/is to use namespaces,
> and I'm much more careful in new code nowdays...
Exactly. The solution is _always_ to use namespaces. No one's questioning
that. That way, you have an easy fix if there's a collision. But if there's
not a collision, you don't need to cruft up your code. I think Bjarne got
this one absolutely right.
James Kanze
> "James Kanze" <James...@dresdner-bank.com> wrote in message
> news:3B36E6A7...@dresdner-bank.com...
> > > But I don't see any such advantage accruing from using std::cout
> > > everywhere. What exactly does this consistency buy you?
> > Readability. When I see std::cout, I know exactly what is being
> > referred to. When I see simply cout, it is not as 100% certain.
> Isn't it 99% certain, though? Especially in a shop with code
> reviews, it's hard for me to imagine justifying cout as a variable
> name.
That's because you can't imagine working in a French speaking
environment:-). (Coût is the French word for cost. And I can very
well imagine it as a name for a member variable.) What about count?
Which is likely not to cause problems until someone includes
<algorithm>.
In general, I reserve the shortest names for local variables. And it
doesn't bother me at all that a global variable have a long name, like
std::cout.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> James Kanze <James...@dresdner-bank.com> wrote in message
> news:<3B36E6A7...@dresdner-bank.com>...
> > I don't think that the two are comparable. The std::vector
> > implements a vector, and it would be annoying and confusing to
> > have two different vectors in a program. Not just because of the
> > name clash...
> It would be equally annoying and confusing to have two different
> couts.
Except that one is read c out, and the other coût. They are two
perfectly distinct concepts, and if either is misnamed, it is
definitly cout (which logically would be standard_out).
Are you going to ban count, as well (defined in <algorithm>)? In most
application code, I'd expect <algorithm> to be included more often
than <iostream>, and std::count to be used several orders of magnitude
more frequently than std::cout. (Come to think of it, I can't
remember any real application which used std::cout more than once or
twice.)
> > > But I don't see any such advantage accruing from using std::cout
> > > everywhere. What exactly does this consistency buy you?
> > Readability. When I see std::cout, I know exactly what is being
> > referred to. When I see simply cout, it is not as 100% certain.
> Well you should be 100% certain. Anyone using something as simple
> as the standard output device's name for something else is looking
> for trouble.
Or simply thinking about the application, and not the development
environment.
> Let me quote Bjarne Stroustrup from his book "The Design and Evolution
> of C++" on pg. 406 (item 17.4.1), "On the other hand, explicit
> qualification of names that everybody knows (or at least ought to
> know) and of frequently used names can become a real nuisance. For
> example, writing stdio::printf, math::sqrt, and iostream::cout is not
> going to help anyone acquainted with C++. The added visual clutter
> easily becomes a source of errors. This argues strongly for a
> mechanism like using-declarations or using-directives. Of these, a
> using-declaration is the more discriminating and by far the less
> dangerous."
I'll just have to disagree. The general rule is that the length of a
name should be inversely proportional to the size of its scope.
Global names should be longest.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> "James Kanze" <James...@dresdner-bank.com> wrote in message
> news:3B36E6A7...@dresdner-bank.com...
> > When I see std::cout, I know exactly what is being referred to.
> > When I see simply cout, it is not as 100% certain.
> In article <tjf0a7p...@news.supernews.com>,
> Mark Wilden <ma...@mwilden.com> wrote:
> >Isn't it 99% certain, though? Especially in a shop with code
> >reviews, it's hard for me to imagine justifying cout as a variable
> >name.
> But clog() for a complex logarithm function is quite plausible.
It is, in fact, defined in the standard C library. C99, so the
standards committee hasn't addressed the problem of how to integrate
it into C++ yet:-).
> Indeed, I personally introduced a C library containing such a function
> (used within another C library which was in turn called from ourC++ code)
> into our not-using-namespaces-for-historical-reasons C++ code last year.
> I got some, ahh, "interesting" error messages when including both
> <iostream.h> and the header file prototyping the clog() function
> extern "C" our_complex clog(our_complex z);
You're not alone. The C standards committee did exactly the same
thing.
> The short-term solution was to hack the C code to use a different
> function name. But the long-term solution was/is to use namespaces,
> and I'm much more careful in new code nowdays...
The C++ standards committee wanted the C committee to adopt your short
term solution, I think. Doubtlessly, in the next revision of the C++
standard, some work-around will be found, probably using namespaces.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Herb Sutter
>That's because you can't imagine working in a French speaking
>environment:-). (Coût is the French word for cost. And I can very
>well imagine it as a name for a member variable.)
That's fine. If you do that, and only later include <iostream>, it's easy
enough to write "this->" or change the name, isn't it? Resolving collisions
isn't hard, and the resolution only needs to be done once because it "takes"
permanently and stays fixed.
>What about count? Which is likely not to cause problems until someone
>includes <algorithm>.
What about it? If there is a collision, don't I just toss in "::" (without
changing my using-directives), and I'm done?
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
Herb Sutter
>Herb Sutter wrote:
>> Theoretically possible, but I'm back to "how often does this happen in
>> practice?"
>
>And how harmful is it if it occurs. A quiet change in meaning can be
>disastrous, especially if it goes undetected until you're just about
>ready to release. Do you want to risk not making your ship date?
Pardon me for being a broken record, but I'm back to "how often does this
happen in practice?" Nobody has yet answered that question, which is the key
to this chimera.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
Herb Sutter
>> >Okay, so you just updated your libraries. The code has been around for
>> >years. Now your code is getting compiler errors. How do you "just fix" them?
>> >In other words, how can you tell from looking at the use of an unqualified
>> >name which (qualified) name was actually intended?
>>
>> If you just updated a library and now there's a name conflict because of a
>> new name in that library, obviously the code meant the other name...?
>
>Which other name? Remember, the call was not explicitly qualified, and your
>code is full of using-declarations.
I really don't understand your objection. Maybe I'm dense.
Time 1: My code works, unambiguously. I know which foo() is being called.
(If I don't, why am I allowed to touch the code?)
Time 2: I upgrade a library, which now declares a foo() and because I'm
"using namespace ThatLib;" now the compiler says my call to foo() is
ambiguous.
Time 2 + epsilon: I qualify foo() to say I want the foo() that has always
been there, not the one in ThatLib::. Clearly I know what foo() that was/is,
else I wouldn't be maintaining the code.
Done. How could it be easier?
>> Theoretically possible, but I'm back to "how often does this happen in
>> practice?" Has anyone a real-world case in point?
>
>I don't, for the reasons I cited before. But name collisions do happen, and
>when they do they waste much more time than you'd expect.
>A great many of us
>on the boost list were surprised recently to find that certain names which
>are technically available to us as users are being defined as macros by
>certain system headers. We avoid macros for the same reasons we use
>namespaces.
But that's a straw man on two counts, isn't it?
First, macros are much nastier and don't respect scope at all, so they're
just not comparable.
Second, you make it sound like I'm against namespaces; I'm not, they're
great and I encourage them, but what I am against is mindless explicit
qualification for the pointless disambiguations of ambiguities that rarely
if ever will happen in practice. (NOTE: Reminder, I am very much against
using declarations or directives in header files or before #includes.)
Now, if someone loves all those explicit qualifications and chooses to write
them of his own free will, that's great, no skin off my nose, more power to
him -- but I feel it would be wrong for me as an author to tell him he
should or must do it that way, when in practice I've never seen a net
benefit in the wilds of my production code, or even in my example code.
Sure, I have seen a lot of argument and justification for over a half decade
and even used to buy into it, but I've just never seen a net benefit. And
I'm not alone. After a while, the arguments of "avoiding the chimera of name
collisions" ring hollow after they just don't happen every day. Sure they
exist, but they're only real but occasional cockroaches, not the claimed
(but unreal) big chimera.
It's just not that big a deal. Namespaces are great, but the rule to "avoid
using 'using'" tries to solve a problem that just isn't the big hairy mess
that it's often been breathlessly made out to be.
>Here's another question closer to the subject line: what is the cost to the
>user if he wants to /remove/ a using declaration? That could be very
>difficult, it seems to me.
FWIW, I'm trying to avoid "seems" because I used to buy into explicit
qualification because of "seems" reasons. Instead of guessing what problems
there might be and how scary things could get, I now try to base all my
advice on what I've seen works best in practice, in the real world and in my
own production and example code.
Let's imagine that you actually do what to do this. In my experience, having
it be desirable to remove a using directive is a "rare to never" event, but
let's just say for the sake of argument that it's come up. Why is removing
it any more difficult than omitting it in the first place would have been?
Indeed, it's probably a lot less work: First of all, if I need to get rid of
a file-scope using-directive, it's probably because of one collision and
I'll just either move that function up above the using-directive, or I'll
just keep writing using-directives in all the other functions and explicitly
qualify only the one I need to -- a lot less work. Second, let's say I even
have to go whole hog and there's some as-yet-unguessed reason I may have to
jettison the using-directive from the whole source file (I'll believe it
when I see it, but let's just say)... then you've still got a lot less work
than writing all the qualifications up front and as you go, because you're
writing only the net using declarations or explicit qualifications required
by the final code, not the stuff that might have lived and died in earlier
versions of the code. And, best of all, by writing a using-directive
initially I've deferred the work until I _know_ it needs to be done, which
usually turns out to be never.
There's an XP principle at work here too: "Write the simplest thing that
could possibly work." I think that's a great idea, and it's really growing
on me. In the past I've been as guilty as anyone of overengineering and of
putting in features or code "just in case," and I've learned that I've been
silly to think that way. I admit it.
There's an optimization principle at work here too: "The first rule of
optimization: Don't do it. The second rule of optimization: Don't do it
yet." In brief, the rationale is 'why spend time until you know it's needed
and will even matter?' That applies verbatim to any extra coding work,
including explicit qualifications.
There's an interesting parallel here with the advice (that I first heard
from Kevlin Henney) to "write less code and more software." There's an
application of that principle here.
Notice a recurring theme? Simpler is better. We keep rediscovering that.
Speaking of which:
>Funny, you read these differently than I do. Explicit qualification is much
>simpler and more readable than a bunch of implicitly looked-up names, IMO.
If that's your feeling, that's perfectly valid. Go for it. That's entirely
up to you. The only thing that would be wrong would be to try to force "what
works for you" or "what you prefer" on everyone else, that's all. Some
people I've talked to at conferences agree with you. Most people I've talked
to feel that, except where there's a real collision that needs to be
qualified, it's redundant clutter, and so do I because by definition an
unneeded qualification _is_ as good as whitespace. And whitespace is faster
to read.
>> >6. Sparse is better than dense.
>
>Rx: simpler expressions, spacebar, newline ;-)
Absolutely. Get rid of those darned redundant pesky std:: qualifications
that make my code wider, make me wrap lines, and that (adding insult to
injury) don't even mean anything more than a spacebar would have! When told
they should do something, I think readers have every right to ask: "Why?"
For example: "If it adds no semantic meaning, why am I being told I have to
write it? What's the benefit to me?" And our answer should cite benefits
from avoiding major and recurring real problems often observed in practice,
not on just-in-case potential problems that have turned out to be dream
monsters and bugbears.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
Mark Wilden
>
> > Isn't it 99% certain, though? Especially in a shop with code
> > reviews, it's hard for me to imagine justifying cout as a variable
> > name.
>
> That's because you can't imagine working in a French speaking
> environment:-). (Coût is the French word for cost. And I can very
> well imagine it as a name for a member variable.)
Regardless, I think it would be a poor choice of identifier (without the
circumflex). It depends on the context, of course.
One issue that gets overlooked, I think, is that it's unlikely that the
French cout would clash with the IOStreams cout, because the latter is a
global variable, which you would assume to be rare in our own code.
> What about count?
> Which is likely not to cause problems until someone includes
> <algorithm>.
It would only cause problems if you had a global named "count," right? So
don't do that. :)
> In general, I reserve the shortest names for local variables. And it
> doesn't bother me at all that a global variable have a long name, like
> std::cout.
It was std::string that griped me (and yes, I know I could declare it into
my space). I use strings more than ints sometimes, and it seemed to me to be
extra typing and less screen real estate for no good reason.
Pete Becker
>
> Pete Becker <peteb...@acm.org> writes:
>
> >Herb Sutter wrote:
> >> Theoretically possible, but I'm back to "how often does this happen in
> >> practice?"
> >
> >And how harmful is it if it occurs. A quiet change in meaning can be
> >disastrous, especially if it goes undetected until you're just about
> >ready to release. Do you want to risk not making your ship date?
>
> Pardon me for being a broken record, but I'm back to "how often does this
> happen in practice?" Nobody has yet answered that question, which is the key
> to this chimera.
>
Can you guarantee that it will never happen? If not, then you have to do
risk analysis. And remember, we're talking about a field where Murphy's
law works overtime.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> Pardon me for being a broken record, but I'm back to "how often does this
> happen in practice?" Nobody has yet answered that question, which is the
key
> to this chimera.
Nobody ever answered the question when I asked it, either (as I've been
doing, off and on, for the last year or so). The answer was usually along
the lines of "I've never seen it happen, but why take a chance?". Mind you,
there were plenty of _theoretical_ possibilities suggested...
However, there was one thread on clc where the poster was unable to identify
the compile-time error that resulted from using a symbol in std under "using
namespace std;". It's the first real-world case I've heard of where the
directive actually caused anyone any problems. The poster was a newbie and
someone on the group figured the problem out.
Pete Becker
>
> James Kanze <James...@dresdner-bank.com> writes:
> >That's because you can't imagine working in a French speaking
> >environment:-). (Coût is the French word for cost. And I can very
> >well imagine it as a name for a member variable.)
>
> That's fine. If you do that, and only later include <iostream>, it's easy
> enough to write "this->" or change the name, isn't it? Resolving collisions
> isn't hard, and the resolution only needs to be done once because it "takes"
> permanently and stays fixed.
All that is true, but first you have to identify the collision. You keep
wanting to solve the easy problems. Do the hard ones instead:
namespace n0
{
#if NEW_VERSION
void f(int);
}
using namespace n0;
namespace n1
{
void f(double);
}
using namespace n1;
int main()
{
f(1);
return 0;
}
Now, if you notice that something went wrong you have to figure out what
it was. And that sort of debugging can kill your release schedule.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> "David Abrahams" <abra...@altrabroadband.com> writes:
> >> >Okay, so you just updated your libraries. The code has been around for
> >> >years. Now your code is getting compiler errors. How do you "just fix"
them?
> >> >In other words, how can you tell from looking at the use of an
unqualified
> >> >name which (qualified) name was actually intended?
> >>
> >> If you just updated a library and now there's a name conflict because
of a
> >> new name in that library, obviously the code meant the other name...?
> >
> >Which other name? Remember, the call was not explicitly qualified, and
your
> >code is full of using-declarations.
>
> I really don't understand your objection. Maybe I'm dense.
>
> Time 1: My code works, unambiguously. I know which foo() is being called.
> (If I don't, why am I allowed to touch the code?)
>
> Time 2: I upgrade a library, which now declares a foo() and because I'm
> "using namespace ThatLib;" now the compiler says my call to foo() is
> ambiguous.
>
> Time 2 + epsilon: I qualify foo() to say I want the foo() that has always
> been there, not the one in ThatLib::. Clearly I know what foo() that
was/is,
> else I wouldn't be maintaining the code.
Maybe you're the poor guy who was responsible for making the library
upgrade. You're expected to know the (implicit) intention of all previous
programmers?
Name lookup can get pretty hairy in C++: just look at some of your recent
GotW articles. When you throw in the fact that visibility can change due to
indirect #include dependencies, don't you really want to know (and say)
exactly what should happen whenever possible? I sure do.
It seems to me that you're saying "write this over here to make the name(s)
available, then use the name over there and assume that the compiler picks
up the name you intend. If there's a problem later, let the compiler tell
you about it." Well, if you're recommending using-directives for that
purpose you may have some surprising results. For example, name lookup in
templates doesn't proceed through using-directives, so you may actually be
picking up a name (the same one, or a different one) from some
using-/declaration/ elsewhere. Even if you restrict yourself to using
declarations, there are oddities. For example IIRC, argument-dependent
lookup doesn't proceed through using declarations. Also, a change in a
function's visibility can cause a different function to be silently called.
> >> Theoretically possible, but I'm back to "how often does this happen in
> >> practice?" Has anyone a real-world case in point?
> >
> >I don't, for the reasons I cited before. But name collisions do happen,
and
> >when they do they waste much more time than you'd expect.
>
>
> >A great many of us
> >on the boost list were surprised recently to find that certain names
which
> >are technically available to us as users are being defined as macros by
> >certain system headers. We avoid macros for the same reasons we use
> >namespaces.
>
> But that's a straw man on two counts, isn't it?
Not intentionally.
> First, macros are much nastier and don't respect scope at all, so they're
> just not comparable.
Since I have used careful practices with regard to names that can be
qualified, it's the best I can come up with. If you throw everything
together with using-directives, nothing respects scope either (unless you're
in a template in which case you have to explicitly qualify anyway).
> Second, you make it sound like I'm against namespaces; I'm not, they're
It sounded like you were for a while there, but I don't think so anymore.
> great and I encourage them, but what I am against is mindless explicit
^^^^^^^^
> qualification for the pointless disambiguations of ambiguities that rarely
> if ever will happen in practice. (NOTE: Reminder, I am very much against
> using declarations or directives in header files or before #includes.)
I don't think we should do anything mindlessly. This is a little bit loaded,
don't you think?
You must have different rules for writing code in header files (explicit
qualification) and source files (using-directives). Doesn't that complicate
things somewhat? In my code, the interfaces are read ten times for every
time the implementation is read. How much benefit do you really get from the
using-declarations?
> Now, if someone loves all those explicit qualifications and chooses to
write
> them of his own free will, that's great, no skin off my nose, more power
to
> him -- but I feel it would be wrong for me as an author to tell him he
> should or must do it that way, when in practice I've never seen a net
> benefit in the wilds of my production code, or even in my example code.
Have you ever seen a benefit from using "const"?
> Sure, I have seen a lot of argument and justification for over a half
decade
> and even used to buy into it, but I've just never seen a net benefit.
Yes: this is one of those things that only shows up when it's absent and you
get bitten. And while I believe this danger is real, there are better
reasons for explicit qualification...
> And
> I'm not alone. After a while, the arguments of "avoiding the chimera of
name
> collisions" ring hollow after they just don't happen every day. Sure they
> exist, but they're only real but occasional cockroaches, not the claimed
> (but unreal) big chimera.
>
> It's just not that big a deal. Namespaces are great, but the rule to
"avoid
> using 'using'" tries to solve a problem that just isn't the big hairy mess
> that it's often been breathlessly made out to be.
^^^^^^^^^^^^
A little loaded again, eh?
> >Here's another question closer to the subject line: what is the cost to
the
> >user if he wants to /remove/ a using declaration? That could be very
> >difficult, it seems to me.
>
> FWIW, I'm trying to avoid "seems" because I used to buy into explicit
> qualification because of "seems" reasons. Instead of guessing what
problems
> there might be and how scary things could get, I now try to base all my
> advice on what I've seen works best in practice, in the real world and in
my
> own production and example code.
Likewise. I've repeatedly found that using-directives have unexpected
results in store for me. I'm not sure how much of this is due to broken
compilers, but practically speaking, who cares?
> Let's imagine that you actually do what to do this. In my experience,
having
> it be desirable to remove a using directive is a "rare to never" event,
but
> let's just say for the sake of argument that it's come up. Why is removing
> it any more difficult than omitting it in the first place would have been?
> Indeed, it's probably a lot less work: First of all, if I need to get rid
of
> a file-scope using-directive, it's probably because of one collision and
> I'll just either move that function up above the using-directive, or I'll
> just keep writing using-directives in all the other functions and
explicitly
> qualify only the one I need to
...and the function signatures
> There's an XP principle at work here too: "Write the simplest thing that
> could possibly work." I think that's a great idea
Me, too. But only assuming that you're sure about what the thing you wrote
will do. The thing that bothers me about using-declarations and unqualified
use of names is that I'm not sure, anymore, about what I'm getting. Nor am I
sure what it might turn into next week.
> and it's really growing
> on me. In the past I've been as guilty as anyone of overengineering and of
> putting in features or code "just in case," and I've learned that I've
been
> silly to think that way. I admit it.
For me, simplest="requires the least thought to understand". I write const
because it keeps the reader from having to think about whether a value is
changing. I explicitly qualify because it keeps the reader from having to
wonder about the meaning of a name. I write "the basic guarantee" because it
captures a simple concept that allows the reader to reason about
exception-safety without considering the probably-useless modified state of
target objects.
So, here are my most important reasons for explicit qualification:
simplicity, readability, and understandability. I know that these are your
reasons for avoiding it. Funny world, eh?
> There's an optimization principle at work here too: "The first rule of
> optimization: Don't do it. The second rule of optimization: Don't do it
> yet." In brief, the rationale is 'why spend time until you know it's
needed
> and will even matter?'
Well, you miss the other part of the rationale: optimization usually makes
the code more complex, less readable, less understandable.
> That applies verbatim to any extra coding work,
> including explicit qualifications.
So, how do you decide what's extra? <facetious>Maybe we should toss const.
And comments. And naming conventions. And code reviews</facetious>.
I guess if you believe that qualification harms readability, none of the
above will make any sense to you ;-)
> There's an interesting parallel here with the advice (that I first heard
> from Kevlin Henney) to "write less code and more software." There's an
> application of that principle here.
>
> Notice a recurring theme? Simpler is better. We keep rediscovering that.
Yep. The rules of C++ are complicated. They are more complicated in the
presence of 'using'.
This is really a question of "social responsibility". When a maintainer
comes upon my code, I'd like for him/her to know exactly what it means
immediately, without looking around the source file for previous
using-directives ("I spent ten minutes before realizing this is the improved
boost::string, not std::string!"). Keeping track of the chain of enclosing
namespaces and the enclosing class is, I think, quite enough burden for the
person who comes after me. Also, I'd like not to cause others to have to
muck about in code I write just because some #include dependency changed
which made new names visible.
> If that's your feeling, that's perfectly valid. Go for it. That's entirely
> up to you. The only thing that would be wrong would be to try to force
"what
> works for you" or "what you prefer" on everyone else, that's all. Some
> people I've talked to at conferences agree with you. Most people I've
talked
> to feel that, except where there's a real collision that needs to be
> qualified, it's redundant clutter, and so do I because by definition an
> unneeded qualification _is_ as good as whitespace. And whitespace is
faster
> to read.
But not to understand. Whitespace has no communicative value.
Furthermore, you can't tell me that the qualification will be unneeded
tomorrow, and there's no way in general for an arbitrary person to resolve
(or sometimes even detect) the problem when the qualification becomes
neccessary.
>
> >> >6. Sparse is better than dense.
> >
> >Rx: simpler expressions, spacebar, newline ;-)
>
> Absolutely. Get rid of those darned redundant pesky std:: qualifications
> that make my code wider, make me wrap lines, and that (adding insult to
> injury) don't even mean anything more than a spacebar would have! When
told
> they should do something, I think readers have every right to ask: "Why?"
> For example: "If it adds no semantic meaning, why am I being told I have
to
> write it? What's the benefit to me?"
But the basis of the question is flawed. std:: obviously has semantic
meaning, at least in the presence of other entities using the same names.
Surely you don't propose that we all must avoid
find
binary_search
lower_bound
vector
string
map
???
> And our answer should cite benefits
> from avoiding major and recurring real problems often observed in
practice,
> not on just-in-case potential problems that have turned out to be dream
> monsters and bugbears.
Good engineering practice often doesn't matter until quite a few years into
a project lifecycle. How long has it been since you gave up explicit
qualification?
-Dave
Mark Wilden
news:3B3CE020...@acm.org...
>
> namespace n0
> {
> #if NEW_VERSION
> void f(int);
> }
> using namespace n0;
>
> namespace n1
> {
> void f(double);
> }
> using namespace n1;
>
> int main()
> {
> f(1);
> return 0;
> }
>
> Now, if you notice that something went wrong
If your tests don't tell you when you've called a completely different and
unrelated function (it's even in a different namespace, it's so different!),
then your tests are not even close to being accurate. Tests aren't perfect,
but if they can't catch something like that, they're completely worthless.
> you have to figure out what it was.
That could be tougher (in this case), agreed.
BTW, do people write a lot of global functions (like f()) these days? It
would be interesting (and more real world) to show an example of a runtime
error where global functions weren't involved.
Mark Wilden
> And remember, we're talking about a field where Murphy's
> law works overtime.
Murphy's Law is a superstition, of course. It's not real. :)
Herb Sutter
>Here's another question closer to the subject line: what is the cost to the
>user if he wants to /remove/ a using declaration? That could be very
>difficult, it seems to me.
In addition to my previous response, it occurs to me now that I can't think
of a case where I have a working module with a using-directive, and then
would want to remove it. Can you give an example? (Note I'm making the
question even harder for me -- removing a using-directive, not just a
using-declaration.)
Say I have a working module with a using-directive, and it works. What could
change that would break it? The only thing I can think of is that a library
I use adds a name which now causes a conflict, but then the answer is to
simply qualify that name -- without touching the using-directive.
But let's say it's a really extreme case: If my module uses LibA and LibB
with using-directives and then LibB adds a name that I use so frequently
that half of my source lines become ambiguous (e.g., operator<< or
operator+), I may want to replace "using namespace LibB;" with a bunch of
using-declarations (that don't include the offending new name) just because
that would be more convenient than lots of explicit qualifications. Okay, I
can just barely imagine that. I don't believe it happens in the wild, but
let's say that it did: Even then, such a new name in LibB, if it's a
function, is likely to cause ambiguity whether I'm "using namespace LibB;"
or not because Koenig lookup will pull it into the mix anyway more often
than not. So the using-directive wouldn't be the real/only culprit, and
removing the using-directive probably won't solve most of the ambiguities
anyway. So now I'm back to "why would I want to remove a using-directive?"
again.
Hmm. Interesting food for thought...
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
> news:3B3CE020...@acm.org...
> >
> > namespace n0
> > {
> > #if NEW_VERSION
> > void f(int);
> > }
> > using namespace n0;
> >
> > namespace n1
> > {
> > void f(double);
> > }
> > using namespace n1;
> >
> > int main()
> > {
> > f(1);
> > return 0;
> > }
> >
> > Now, if you notice that something went wrong
>
> If your tests don't tell you when you've called a completely different and
> unrelated function (it's even in a different namespace, it's so different!),
> then your tests are not even close to being accurate. Tests aren't perfect,
> but if they can't catch something like that, they're completely worthless.
A good test suite exercises about 60% of the code under test. Getting
beyond about 70% gets very expensive, and is rarely cost-effective. If
that call is in the untested part of the code the error will not be
detected.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<hsu...@acm.org> writes
>In addition to my previous response, it occurs to me now that I can't think
>of a case where I have a working module with a using-directive, and then
>would want to remove it. Can you give an example? (Note I'm making the
>question even harder for me -- removing a using-directive, not just a
>using-declaration.)
Now, in general I am more interested in using declarations. I would like
to be able to pull in all of an interface except for... Which is why I
want a form of using directive that works for classes, but I would like
an option to use all but...
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
David Abrahams
"Mark Wilden" <ma...@mwilden.com> wrote in message
news:tjq4pgq...@news.supernews.com...
> If your tests don't tell you when you've called a completely different and
> unrelated function (it's even in a different namespace, it's so
different!),
> then your tests are not even close to being accurate. Tests aren't
perfect,
> but if they can't catch something like that, they're completely worthless.
I learned something long ago (when I was just starting C++) from Scott
Meyers' books. He said something like this: "if you can catch a problem at
compile-time, do that. Otherwise, if you can catch it at link-time, do that.
Otherwise, catch it at runtime as a last resort."
Some people like to program in languages without static type checking, and
while I agree that the flexibility can be wonderful (I enjoy a little Python
now and again myself), in my experience it has a cost in maintainability and
especially in the ability to grow a large system. Each time you give up a
compile-time check, you pay a little something. Python is also very easy and
fast to read and write, in part due to the lack of type declarations. AFAIK,
the Python designers have been looking for ways to allow optional type
declarations, though. The reasons?
* Type declarations make code more readable by documenting what's going on
* They allow code to be checked when it's parsed as opposed to when it's
run
* In a dynamic language, they allow otherwise-unavailable optimizations in
a hypothetical compiler
The first two apply equally to explicit qualification.
> > you have to figure out what it was.
>
> That could be tougher (in this case), agreed.
>
> BTW, do people write a lot of global functions (like f()) these days?
Well, namespace scope functions anyway. Preferring free functions to member
functions is a trend in modern C++.
> It would be interesting (and more real world) to show an example of a
runtime
> error where global functions weren't involved.
Why do you think it would be "more real world"?
Peter Dimov
> "David Abrahams" <abra...@altrabroadband.com> writes:
[...]
> >Funny, you read these differently than I do. Explicit qualification is much
> >simpler and more readable than a bunch of implicitly looked-up names, IMO.
>
> If that's your feeling, that's perfectly valid. Go for it. That's entirely
> up to you. The only thing that would be wrong would be to try to force "what
> works for you" or "what you prefer" on everyone else, that's all. Some
Absolutely right. But: an existing using directive (worst case: in a
header file) forces users into 'your' model, whereas the lack of an
using directive doesn't force the "no using directives" model; the
user is free to add an using directive later, preferably in a local
scope.
> people I've talked to at conferences agree with you. Most people I've talked
> to feel that, except where there's a real collision that needs to be
> qualified, it's redundant clutter, and so do I because by definition an
> unneeded qualification _is_ as good as whitespace. And whitespace is faster
> to read.
Actually, I believe that you are wrong here. 'std::string' is faster
to read (in code) than just 'string'. The reason is that the brain
pattern-matches a word using its general shape, length and surrounding
context _before_ matching individual letters. Especially if you are
short-sighted, and I am. :-)
--
Peter Dimov
Multi Media Ltd.
Herb Sutter
>> great and I encourage them, but what I am against is mindless explicit
> ^^^^^^^^
>> qualification for the pointless disambiguations of ambiguities that rarely
>> if ever will happen in practice. (NOTE: Reminder, I am very much against
>> using declarations or directives in header files or before #includes.)
>
>I don't think we should do anything mindlessly. This is a little bit loaded,
>don't you think?
True, perhaps "automatic" would have been better; I meant that in the sense
of not giving thought to something before doing it, not having thought
through reasons. In particular, I had in mind legions of programmers in the
trenches wasting their fingers to nubs with explicit qualification, and
writing what to me is less readable code, just because the book they read
told them they should.
I have a challenge, then: What do the authors do? Specifically, consider the
first-tier C++ books that are well-received and frequently cited (e.g.,
Stroustrup, Meyers, Josuttis, Langer, to cite some published late enough to
be expected to do something sensible with namespaces), and ask:
1. In the text, what do the authors recommend?
2. In the code examples, how often are explicit qualification,
using-declarations, and using-directives used in the code examples? And for
any case where there's none of the above present, including no qualification
on some or all names, I think it's fair to count that case implicitly in the
using-directive camp.
(One hopes that the answers to #1 and #2 will be consistent for any given
book.)
The main reason I wrote the namespaces article[*] for DDJ last year was to
state what I do, and what I have found to work, in practice. Now, the main
reason I refined that advice for More Exceptional C++ was to bring it in
line with the additional information I've accumulated over the two years
since that article was written in 1999 (yes, DDJ sat on it for a year; oh
well) and what I've found myself doing routinely, both in production code
and in example code. Throw into the mix that overwhelmingly the major
authors do the same in their example code...
[*] "Migrating to Namespaces" (Dr. Dobb's Journal, 25(10), October 2000).
Online at http://www.gotw.ca/publications/migrating_to_namespaces.htm. This
has been refined and the advice updated for its appearance in More
Exceptional C++ later this year; see below.
>You must have different rules for writing code in header files (explicit
>qualification) and source files (using-directives).
Absolutely. In my first post to this thread, I wrote:
me>In my final draft of More Exceptional C++, I've relaxed it to:
me>
me> - in a header, never write namespace using-declarations or -directives
me>
me> - in a .cpp, write using-declarations or -directives to taste at file
me> and/or function scope, but after all #includes
me>
me> - short-term compromise for migration of a large code base: go ahead
me> and write a controlled using-directive that comes after all
me> #includes in every .cpp file, and if you feel like it go back and
me> take it out later in individual .cpp files where it makes sense
>Doesn't that complicate things somewhat?
We've been living with it fine, but YMMV.
>In my code, the interfaces are read ten times for every time the
>implementation is read. How much benefit do you really get from the
>using-declarations?
I'd guess that in my code the implementation usually has 10-20 times the
number of nonblank lines that the interface has, and I'd guess that if you
count the amount of eyeball time each line gets, both by users and by
maintainers, the implementation gets more eyeball time (both because there
are more lines to get eyeball hits, and because the eyeball hits are longer
for implementation lines). That's an unscientific off-the-cuff guesstimate
based on what I do, though. Certainly for code that's been stable for years
the balance will shift more to what you express above.
>> Now, if someone loves all those explicit qualifications and chooses to write
>> them of his own free will, that's great, no skin off my nose, more power to
>> him -- but I feel it would be wrong for me as an author to tell him he
>> should or must do it that way, when in practice I've never seen a net
>> benefit in the wilds of my production code, or even in my example code.
>
>Have you ever seen a benefit from using "const"?
Yes. And I recommend it. And I write it myself in production and example
code, and so do all the major authors.
I'd love to be shown the authors who recommend preferring explicit
qualification everywhere, and who follow that advice in their production and
example code (fortunately the latter is available for spot-checking, if not
the former). Or does today's book advice -- top-tier books and otherwise --
boil down to a choice between:
a) silence (not recommending anything particularly wholeheartedly); and
b) "do as I say but not as I do" (recommending one thing, but doing another,
possibly with an embarrassed note in the preface excusing it on the grounds
of keeping the example code more clear -- hmmm...)?
Note that I include myself here. I don't want to be a "(b) hypocrite," and
Exceptional C++ pretty much fell into the "(a) silence" category by just not
covering that topic (page 135 briefly mentions the choice between explicit
qualification or a using-declaration in an example, but doesn't recommend
anything). In More Exceptional C++, I was incorporating material that did
give advice, and I struggled with whether to:
a) keep the advice that favored explicit qualification and change all my
code in MXC++ to suit (with a private promise to change my production coding
habits in the future so as to avoid guilty feelings); or
b) update the advice and keep my example and production code as-is.
To be fair, I gave (a) a shot and went far enough along that path to see
just how extensive and painful the code rework was going to be, and I
convinced myself by several examples that it just wasn't adding anything of
value to offset the pain. I certainly convinced myself that no way was I
going to voluntarily do this in an existing production code base, nor in new
code.
>> It's just not that big a deal. Namespaces are great, but the rule to "avoid
>> using 'using'" tries to solve a problem that just isn't the big hairy mess
>> that it's often been breathlessly made out to be.
> ^^^^^^^^^^^^
>A little loaded again, eh?
True, sorry. I had in mind stuff I heard said and saw written back in time
closer to when namespaces were being proposed and adopted, and I think
"breathless" is appropriate for some of those statements. The silver bullet
was sold by describing a big hairy monster -- a monster which definitely
existed and motivated namespaces so that qualification was available for
disambiguation, but _not_ a monster motivating explicit qualification
everywhere by default as a coding style.
>Me, too. But only assuming that you're sure about what the thing you wrote
>will do. The thing that bothers me about using-declarations and unqualified
>use of names is that I'm not sure, anymore, about what I'm getting. Nor am I
>sure what it might turn into next week.
Let me focus on the "unqualified use of names" part of your comment. Then,
after looking at my first challenge above about "what do the authors do,"
let's take another challenge, this time in the library field: What does the
committee tell standard library implementers that they must do? Use
explicitly qualified names always, or not?
The answer as of today, according to LWG issues 225 and 229, is "leaning
toward requiring explicit qualification by default with a list of cases that
are exceptions and shouldn't be qualified, but really we're not quite sure
yet because there are reasons maybe we shouldn't." Of course, IIRC you and I
took different stances on this in Copenhagen two months ago, so continuing
that debate here is probably not productive. All I want to show by this is
that it's unclear among the experts defining the standard what even the
standard library should be required to do, and that what is clear among the
experts is that there definitely are cases where explicit qualification
would be undesirable or wrong (for reasons sometimes quite different from
the more pedestrian ones we've been debating here, but it's a data point).
For those keeping score at home, see:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html
>For me, simplest="requires the least thought to understand". I write const
>because it keeps the reader from having to think about whether a value is
>changing. I explicitly qualify because it keeps the reader from having to
>wonder about the meaning of a name.
Maybe it's a style thing. 99 times out of 100, it's been clutter for me.
>I guess if you believe that qualification harms readability, none of the
>above will make any sense to you ;-)
Bingo. :-)
>Surely you don't propose that we all must avoid
>
> find
> binary_search
> lower_bound
> vector
> string
> map
>
>???
(C'mon, you've got to admit "Surely you don't propose [...] ???" is
"breathless." :-) )
This is actually not obvious, and it's a key part of the Copenhagen
discussions about 225 and 229. Whether those names are (or should be)
effectively assigned reserved meanings in all namespaces present and future
is still an open debate. Even though most of us want them not to be, some
otherwise attractice solutions would effectively exert strong pressure in
that direction, so the answer to your question depends on what's decided.
This is one of the key concerns affecting people's positions on those two
LWG issues. IIRC, didn't you and I end up on different sides on the fence on
this one?
>Good engineering practice often doesn't matter until quite a few years into
>a project lifecycle. How long has it been since you gave up explicit
>qualification?
Slight correction: I never actually gave it up in my production code,
because since we started using a platform with the standard library in
std::, the following two statements have always been true: a) I have always
used explicit qualification in header files; and b) I have never used
explicit qualification in .cpp files (except possibly for a few
disambiguations, but I can't recall specifically any cases where that
actually came up). So I can't say I ever gave up explicit qualification.
I migrated that code base in either June 1998 or June 1999 (sorry, can't
recall which), using the approach documented in my above-cited DDJ article.
Later, over time, we found that we never felt the need to drop the
using-directive after all (although I did originally recommend dropping it,
because at the time I anticipated we'd be wanting to do that). Incidentally,
I don't specifically recall any cases where we even had to explicitly
qualify something in the .cpp modules to resolve a name collisions, but
there may have been a few. YMMV.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Chris Newton
> On December 18, 1999, at 19:00 PST, assuming huge risks,
> in a private email that sneaked through Carnivore, Scott
> Meyers sent me a code snippet that contained the following
> line at global scope:
>
> using namespace std; // so sue me
>
> The Revolution was started.
With all due respect, it's hardly a revolution. The fact that a few big
names in C++ have been a vocal minority objecting to "using namespace
std;" until recently doesn't mean the remaining 99.99% of the C++
developers in the world haven't been doing it all along. It's practical,
and real world people like practical things.
I consider it routine for small programs (a few hundred lines in a small
number of files), including illustrative code. I dislike verbose code;
it reduces readability. This is one of Java's great failings -- it takes
almost an hour just to write the code for "Hello, world". I'm glad C++
doesn't force that on me.
Much the same goes for other areas of the language, BTW. I still prefer
<climits> to <limits> for a lot of basic use. Which would you rather
explain to a beginner,
std::cin.ignore(std::numeric_limits<std::streamsize>::max, '\n');
or
cin.ignore(INT_MAX, '\n');
? Which would you rather see in code you've got to change? I thought so.
By the way, the "typo" in the above was quite deliberate. I trust
everyone advocating absurdly verbose coding spotted it.
Of course, using declarations are much safer than using directives.
They're more refined, but more importantly, they provide a checklist of
possible problems if naming appears to be messed up after any change. I
continue to dislike writing using namespace std; at the top of any
serious work, particularly if it's likely to be more than those few
hundred lines, and certainly if more than one person is going to be
working on it at once. Using declarations are more appropriate here
IMHO.
So, if I don't like writing std::cout everywhere, why do I like
namespaces at all? The kind of project I work on does graphically
illustrate why namespaces must be available in a language, even if they
are generally a formality. The code base is now over a million lines,
developed by probably 20 or more people over a period of 6 or 7 years on
two different sites.
I think we now have four completely different matrix calculation
classes, used in totally different places in the program, with different
functionality. Yes, ideally, they would have been part of a pre-planned
and well thought-out maths library, but not everyone programming the
project was a mathematician and/or prescient enough to arrange that.
The catch is that each of those Matrix classes is called... CMatrix.
Some are templates, some aren't. They have different associated
hierarchies and so on, and many multiply-used names. They are used in
different DLLs, essentially as part of different projects, so we
generally get away without naming conflicts. However, anyone who wants
to use a matrix class in new code has to be very careful to select the
correct one for inclusion/linking, as used elsewhere in the bit of
project they're working on, to avoid conflicts. Since the project
predates namespaces, resolving any conflicts that did arise would be
very awkward.
There are several other subsystems in the project where the same naming
issue arises, for example, where we have one class that we use to drive
some hardware, and another (identically named) class we use to emulate
that hardware for test purposes. The only reason we get away with it is
because we're heavily split into different DLLs, and so far, we've been
lucky enough that no two of the clashing names were needed in the same
DLL. Many in the lifetime of the project have questioned the decision to
use DLLs, but if we were to write all of our code into one big project
now, the number of name clashes would be frightening.
That's a real world example for you, with a few more to spare. I can't
see how any large scale project with a similar development environment
wouldn't suffer the same risks without some sort of packaging to avoid
conflicts, and namespaces provide the most natural packaging now they're
standardised.
Regards,
Chris
Pete Becker
>
> I have a challenge, then: What do the authors do?
Better: what do the people who deliver quality sofware on schedule
within cost do.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> "David Abrahams" <david.a...@rcn.com> writes:
> >> great and I encourage them, but what I am against is mindless explicit
> > ^^^^^^^^
> >> qualification for the pointless disambiguations of ambiguities that
rarely
> >> if ever will happen in practice. (NOTE: Reminder, I am very much
against
> >> using declarations or directives in header files or before #includes.)
> >
> >I don't think we should do anything mindlessly. This is a little bit
loaded,
> >don't you think?
>
> True, perhaps "automatic" would have been better; I meant that in the
sense
> of not giving thought to something before doing it, not having thought
> through reasons. In particular, I had in mind legions of programmers in
the
> trenches wasting their fingers to nubs with explicit qualification, and
> writing what to me is less readable code, just because the book they read
> told them they should.
I think this discussion would be well-served by less hyperbole.
> I have a challenge, then: What do the authors do? Specifically, consider
the
> first-tier C++ books that are well-received and frequently cited (e.g.,
> Stroustrup, Meyers, Josuttis, Langer, to cite some published late enough
to
> be expected to do something sensible with namespaces), and ask:
>
> 1. In the text, what do the authors recommend?
>
> 2. In the code examples, how often are explicit qualification,
> using-declarations, and using-directives used in the code examples? And
for
> any case where there's none of the above present, including no
qualification
> on some or all names, I think it's fair to count that case implicitly in
the
> using-directive camp.
Silly challenge; you already know the answers I'm sure. Authors have
traditionally done beginning users a disservice by ignoring important
details (e.g. error-handling). I don't think statistics about what authors
have done proves much. Lots of books leave out the qualification /and/ the
using-directives.
I think you could use the Josuttis book as an example. Everyone reads it and
recommends it. Nobody complains that it's unreadable. IIRC Nico used
explicit qualification to refer to types, and Koenig lookup to avoid
qualifying functions where appropriate.
> >Have you ever seen a benefit from using "const"?
>
> Yes. And I recommend it. And I write it myself in production and example
> code, and so do all the major authors.
How did the benefit show up? I mean, how did you "see it"?
> Let me focus on the "unqualified use of names" part of your comment. Then,
> after looking at my first challenge above about "what do the authors do,"
> let's take another challenge, this time in the library field: What does
the
> committee tell standard library implementers that they must do? Use
> explicitly qualified names always, or not?
>
> The answer as of today, according to LWG issues 225 and 229, is "leaning
> toward requiring explicit qualification by default with a list of cases
that
> are exceptions and shouldn't be qualified,
I don't think we're leaning at all. All votes were entirely inconclusive
IIRC.
> but really we're not quite sure
> yet because there are reasons maybe we shouldn't." Of course, IIRC you and
I
> took different stances on this in Copenhagen two months ago, so continuing
> that debate here is probably not productive.
Well, my stance has shifted somewhat. I now understand that there are times
when unqualified calls are neccessary. I still think it's neccessary to be
explicit about which namespace's semantics are being overloaded. I have a
way to do that within the core language definition, but this is not the
place for it...
> All I want to show by this is
> that it's unclear among the experts defining the standard what even the
> standard library should be required to do, and that what is clear among
the
> experts is that there definitely are cases where explicit qualification
> would be undesirable or wrong (for reasons sometimes quite different from
> the more pedestrian ones we've been debating here, but it's a data point).
Agreed. A problem with using-declarations is that they expand the names
available for selection by overloading, sometimes unpredictably.
> >For me, simplest="requires the least thought to understand". I write
const
> >because it keeps the reader from having to think about whether a value is
> >changing. I explicitly qualify because it keeps the reader from having to
> >wonder about the meaning of a name.
>
> Maybe it's a style thing. 99 times out of 100, it's been clutter for me.
I just want to suggest again that there's an element of social
responsibility here: are you writing so it's easier for the author, or so
that it's easier on the readers/maintainers?
> >Surely you don't propose that we all must avoid
> >
> > find
> > binary_search
> > lower_bound
> > vector
> > string
> > map
> >
> >???
>
> (C'mon, you've got to admit "Surely you don't propose [...] ???" is
> "breathless." :-) )
I was breathing at the time. It was a serious question. Maybe I used too
many question marks?
> This is actually not obvious, and it's a key part of the Copenhagen
> discussions about 225 and 229. Whether those names are (or should be)
> effectively assigned reserved meanings in all namespaces present and
future
> is still an open debate.
Not at all. TThe type template names vector, string, and map are not under
discussion in that context. In a world of using-directives, however, these
names must be reserved for std:: only or maintenance problems will result.
> Even though most of us want them not to be, some
> otherwise attractice solutions would effectively exert strong pressure in
> that direction, so the answer to your question depends on what's decided.
> This is one of the key concerns affecting people's positions on those two
> LWG issues. IIRC, didn't you and I end up on different sides on the fence
on
> this one?
Yes. I wonder how you react to my new position, though.
> >Good engineering practice often doesn't matter until quite a few years
into
> >a project lifecycle. How long has it been since you gave up explicit
> >qualification?
>
> Slight correction: I never actually gave it up in my production code,
> because since we started using a platform with the standard library in
> std::, the following two statements have always been true: a) I have
always
> used explicit qualification in header files; and b) I have never used
> explicit qualification in .cpp files (except possibly for a few
> disambiguations, but I can't recall specifically any cases where that
> actually came up). So I can't say I ever gave up explicit qualification.
OK.
> I migrated that code base in either June 1998 or June 1999 (sorry, can't
> recall which), using the approach documented in my above-cited DDJ
article.
> Later, over time, we found that we never felt the need to drop the
> using-directive after all (although I did originally recommend dropping
it,
> because at the time I anticipated we'd be wanting to do that).
Incidentally,
> I don't specifically recall any cases where we even had to explicitly
> qualify something in the .cpp modules to resolve a name collisions, but
> there may have been a few. YMMV.
I think if you're going to recommend the use of using directives, it at
least behooves you to encourage people to think about the future of their
projects: how many namespaces are likely to be involved, what changes they
are willing to make when #include dependencies change, who is responsible
for maintaining a source file after it's initially written, etc. It is easy
to imagine projects where using-directives will never cause a problem. It is
equally easy for me to imagine projects where they will cause lots.
-Dave
Francis Glassborow
<hsu...@acm.org> writes
>I migrated that code base in either June 1998 or June 1999 (sorry, can't
>recall which), using the approach documented in my above-cited DDJ article.
>Later, over time, we found that we never felt the need to drop the
>using-directive after all (although I did originally recommend dropping it,
>because at the time I anticipated we'd be wanting to do that). Incidentally,
>I don't specifically recall any cases where we even had to explicitly
>qualify something in the .cpp modules to resolve a name collisions, but
>there may have been a few. YMMV.
Thanks for your considered response which I have snipped because anyone
can go back and read the original. I just want to add $0.02.
I am perfectly happy suggesting that programmers do whatever they are
comfortable with in their own code. By that I mean code that will not
directly impact on anyone else's via any form of file inclusion. Indeed
I have always felt that within the limited local context the focus
should be on writing code that is easily read. Overly long names, too
many comments and explicit qualifications all add to the fog that can
obscure the essential code. However my rules change completely when
concerned with files that will be #included. Then there is a much wider
context which needs to be considered.
For example, I always encourage programmers to use fully descriptive
parameter names in function declarations, however in function
definitions, I encourage the use of short names because at that level
the shape of the code matters, long source code lines become clumsy and
so hide defects. It is like the difference between
'Canada::Cpp::Sutter::Herb' and simply Herb. When we talk to each other
anything more than 'Herb' is silly but when I talk about you to others
who may not know of you it is 'Herb Sutter, a Canadian C++ expert ...'
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> And how harmful is it if it occurs. A quiet change in meaning can be
> disastrous, especially if it goes undetected until you're just about
> ready to release. Do you want to risk not making your ship date?
I haven't seen a bug caused by the using directive that a good test wouldn't
catch. After all, we're not talking about a simple logic error here (which
might be hard to test for). We're talking about (in your prior example)
calling a _completely different and unrelated function_!
If a developer can ship such code, then he has far greater problems that
namespaces can solve.
Herb Sutter
>Herb Sutter wrote:
>>
>> I have a challenge, then: What do the authors do?
>
>Better: what do the people who deliver quality sofware on schedule
>within cost do.
I can't measure that, as I can't see their source code. And those opinions
are already being expressed here; we've each expressed our own data points
and feelings. I deliver quality software on schedule within cost, and
routinely use "using namespace std;" at global scope in .cpp files (after
all #includes). Have done for years. But that's just my data point.
Authors are respected as the leading world experts on this language and how
to use it well. Their books give advice that is likely to be accepted as
gospel, and have inspectable code. That's measurable and verifiable. So
what's the result when we measure and verify?
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Herb Sutter
"David Abrahams" <david.a...@rcn.com> writes:
>> I have a challenge, then: What do the authors do?
>Silly challenge; you already know the answers I'm sure.
No to both. :-)
It's not silly, because the authors are regarded as the leading experts in
this field, their advice is liable to be taken as gospel by many, and their
code examples are supposed to be exemplary.
I don't know the answers yet, because although I suspect them from what I
remember reading, I've not yet taken a minute to go look.
>Authors have
>traditionally done beginning users a disservice by ignoring important
>details (e.g. error-handling). I don't think statistics about what authors
>have done proves much. Lots of books leave out the qualification /and/ the
>using-directives.
If that last bit is true, and if these are the leading experts in the field
dispensing advice and exemplary example code, what does that tell us?
>> The answer as of today, according to LWG issues 225 and 229, is "leaning
>> toward requiring explicit qualification by default with a list of cases that
>> are exceptions and shouldn't be qualified,
>
>I don't think we're leaning at all. All votes were entirely inconclusive
>IIRC.
That's my recollection, but I was trying to be generous because the proposed
resolution currently in the issues list tends more to your view than to
mine.
>I just want to suggest again that there's an element of social
>responsibility here: are you writing so it's easier for the author, or so
>that it's easier on the readers/maintainers?
Yes.
>Not at all. TThe type template names vector, string, and map are not under
>discussion in that context.
Okay, granted. It's true of the non-type names.
>I think if you're going to recommend the use of using directives,
Actually that's not what I do -- I just endorse them as a viable
alternative, and say "season to taste." Do what's appropriate, don't feel
shackled into global explicit qualification just because someone said so
(and don't feel you have to use using-directives because I said so, for I
don't say so). Perhaps I chould add a sentence as to how to determine the
level of seasoning:
>it at
>least behooves you to encourage people to think about the future of their
>projects: how many namespaces are likely to be involved, what changes they
>are willing to make when #include dependencies change, who is responsible
>for maintaining a source file after it's initially written, etc.
Herb
---
Herb Sutter (http://www.gotw.ca)
Secretary, ISO WG21 / ANSI J16 (C++) standards committee
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
* Check out THE C++ Seminar: http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> A good test suite exercises about 60% of the code under test. Getting
> beyond about 70% gets very expensive, and is rarely cost-effective. If
> that call is in the untested part of the code the error will not be
> detected.
I don't know where these numbers come from. Do you have a source?
I also don't know what is meant by "exercise." Are you referring to
coverage? If so, my code is 100% covered by tests.
I can't conceive of a test suite that would not catch calling a completely
different function. That's not a test suite, in my book--it's worthless.
Mark Wilden
news:9hlb11$kod$1...@bob.news.rcn.net...
>
> I learned something long ago (when I was just starting C++) from Scott
> Meyers' books. He said something like this: "if you can catch a problem at
> compile-time, do that. Otherwise, if you can catch it at link-time, do
that.
> Otherwise, catch it at runtime as a last resort."
Yes, that's why I use C++. I also like to catch problems as early as
possible (even though it means more overhead, i.e., compilation time).
This subject is about detecting an extremely rare condition. There are two
approaches offered: 1) don't use the directive, and do more typing and waste
more screen space, 2) write your bloody tests correctly so this becomes a
non-issue. :)
If you think you can get away without testing in a language like C++, good
luck! :) If you know you have to write tests, even with C++, then you'll
catch this (extremely rare) situation (which was mistyping "sets" as
"setw").
> > BTW, do people write a lot of global functions (like f()) these days?
> Well, namespace scope functions anyway. Preferring free functions to
member
> functions is a trend in modern C++.
I'm not very impressed by trends and fashions. I don't see global ("free"??)
functions increasing, either in books, in newsgroup messages, or among my
colleagues. I know Meyers has advocating using friend functions instead of
members for some purposes, but I don't accept that we are now preferring
global functions to classes!
> > It would be interesting (and more real world) to show an example of a
> runtime
> > error where global functions weren't involved.
>
> Why do you think it would be "more real world"?
Do you tend to write a lot of global functions, compared to classes? That
will provide the answer to your question. :)
Pete Becker
>
> Pete Becker <peteb...@acm.org> writes:
>
> >Herb Sutter wrote:
> >>
> >> I have a challenge, then: What do the authors do?
> >
> >Better: what do the people who deliver quality sofware on schedule
> >within cost do.
>
> I can't measure that, as I can't see their source code.
So we'll all look for our car keys under the light pole, even though we
lost them in the bushes, because that's where the light is.
> Authors are respected as the leading world experts on this language and how
> to use it well.
No. The goal of a good author is always to describe the language
clearly. Best usage may or may not be a goal. The fact that many authors
started using 'using namespace std;' several years ago reflects the
state of libraries at the time, not a considered opinion on how to make
the best use of C++.
> Their books give advice that is likely to be accepted as
> gospel, and have inspectable code. That's measurable and verifiable. So
> what's the result when we measure and verify?
If you measure the wrong thing it doesn't matter what the result is.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> If that last bit is true, and if these are the leading experts in the field
> dispensing advice and exemplary example code, what does that tell us?
>
Nothing, since the second assumption is false. There is no inherent
connection between being an author and being a leading expert in the
field. There are many bad books written about C++.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
> news:3B3E260F...@acm.org...
> >
> > A good test suite exercises about 60% of the code under test. Getting
> > beyond about 70% gets very expensive, and is rarely cost-effective. If
> > that call is in the untested part of the code the error will not be
> > detected.
>
> I don't know where these numbers come from. Do you have a source?
It's well known among professional testers, based on statistics from
test instrumentation. Indeed, one of the primary efforts of professional
testers is to get coverage up from the usual 40% or so that a naive
suite will hit.
>
> I also don't know what is meant by "exercise." Are you referring to
> coverage? If so, my code is 100% covered by tests.
How do you know that? Have you run a coverage analyser against your
tests?
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<ma...@mwilden.com> writes
>I know Meyers has advocating using friend functions instead of
>members for some purposes, but I don't accept that we are now preferring
>global functions to classes!
I don't think that is what he was advocating in that article.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
> > >
> It's well known among professional testers, based on statistics from
> test instrumentation.
Since you're not a professional tester, I'd still like to see some
first-hand reference for this statistic. It may well apply to black-box
testing, which is what most professional testers perform. It doesn't apply
to XP's unit testing, where the tests are written by the programmers.
> > I also don't know what is meant by "exercise." Are you referring to
> > coverage? If so, my code is 100% covered by tests.
>
> How do you know that? Have you run a coverage analyser against your
> tests?
Unlike professional testers, I write the code that is tested. I also write
the tests. In fact, I write the test before I write the code. After I've
written the test, I write the function I'm testing. As I'm writing the
function, I make sure that the test exercises every line (a large proportion
of my bugs were from lines that I never executed in "hand-testing").
What percentage of the code you write is unit tested?
David Abrahams
> > > BTW, do people write a lot of global functions (like f()) these days?
> > Well, namespace scope functions anyway. Preferring free functions to
> member
> > functions is a trend in modern C++.
>
> I'm not very impressed by trends and fashions.
You didn't ask me to impress you. You asked what people are doing these
days. People are writing more and more free functions.
> I don't see global ("free"??)
free functions are any functions at namespace scope. Global functions are
only at global scope.
> functions increasing, either in books, in newsgroup messages, or among my
> colleagues. I know Meyers has advocating using friend functions instead of
> members for some purposes, but I don't accept that we are now preferring
> global functions to classes!
Some of us prefer free functions that operate on classes, even. It's a
wonderful, magical world!
> > > It would be interesting (and more real world) to show an example of a
> > runtime
> > > error where global functions weren't involved.
> >
> > Why do you think it would be "more real world"?
>
> Do you tend to write a lot of global functions, compared to classes? That
> will provide the answer to your question. :)
It depends on the problem domain. If I need to write generic code that can
work on built-in types, free functions will always be an obvious choice.
There tend to be lots of free functions in numeric code (e.g. sin(),
log()...), partly for this reason. The standard library is full of free
functions (the algorithms).
-Dave
David Abrahams
> >I think if you're going to recommend the use of using directives,
>
> Actually that's not what I do -- I just endorse them as a viable
> alternative, and say "season to taste." Do what's appropriate, don't feel
> shackled into global explicit qualification just because someone said so
> (and don't feel you have to use using-directives because I said so, for I
> don't say so). Perhaps I chould add a sentence as to how to determine the
> level of seasoning:
>
> >it at
> >least behooves you to encourage people to think about the future of their
> >projects: how many namespaces are likely to be involved, what changes
they
> >are willing to make when #include dependencies change, who is responsible
> >for maintaining a source file after it's initially written, etc.
Well, you should do the same with any language feature: lay out the
potential consequences, and get people to think about the choices they make.
That gives people the tools they need to make informed choices. Just be sure
that what you tell people is accurate. Telling people that (and I
paraphrase) "using full qualification has no semantic consequences and is
simply a waste of typing" would be inaccurate.
-Dave
Pete Becker
>
> I can't conceive of a test suite that would not catch calling a completely
> different function. That's not a test suite, in my book--it's worthless.
>
Most developers who moonlight as testers would probably agree with you.
Professional testers know better. To get an inkling of a tester's
mindset, think about what the other function could do that would not be
detected by your tests as they currently exist. Then figure out what's
needed to close that loophole. Then decide whether it's worth the cost.
Testing is rarely about finding gross errors. It's about subtle errors,
because those are the ones that aren't self-evident.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrei Alexandrescu
> >Have you ever seen a benefit from using "const"?
>
> Yes. And I recommend it. And I write it myself in production and example
> code, and so do all the major authors.
I consider bringing const into the discussion is out of place anyway. What
does it have to do with anything (except a misdirected irony).
> I'd love to be shown the authors who recommend preferring explicit
> qualification everywhere, and who follow that advice in their production
and
> example code (fortunately the latter is available for spot-checking, if
not
> the former). Or does today's book advice -- top-tier books and
otherwise --
> boil down to a choice between:
For what it's worth, MC++D does not recommend a specific approach. All
examples are written without explicit qualification, and this is mentioned
in the preface: "All the elements of the library live in the namespace Loki.
The namespace is not mentioned in the coding examples because it would have
unnecessarily increased indentation and the size of the examples."
By the way, it might be of little relevance here... I've got hundreds of
feedback emails on MC++D and Loki. Guess it's over one thousand now. And I
answer them all... :o/ Precisely one question is namespace-related - see the
thread "the very successfull loki" (sic) on this newsgroup. In that message,
I am asked why I used "using namespace Loki" in my few cpp files. So I have
a past as a proscribed :o).
> Note that I include myself here. I don't want to be a "(b) hypocrite," and
> Exceptional C++ pretty much fell into the "(a) silence" category by just
not
> covering that topic (page 135 briefly mentions the choice between explicit
> qualification or a using-declaration in an example, but doesn't recommend
> anything).
Winston Churchill is known to have said: I would rather be right than
consistent.
> >Good engineering practice often doesn't matter until quite a few years
into
> >a project lifecycle. How long has it been since you gave up explicit
> >qualification?
>
> Slight correction: I never actually gave it up in my production code,
> because since we started using a platform with the standard library in
> std::, the following two statements have always been true: a) I have
always
> used explicit qualification in header files; and b) I have never used
> explicit qualification in .cpp files (except possibly for a few
> disambiguations, but I can't recall specifically any cases where that
> actually came up). So I can't say I ever gave up explicit qualification.
I also used using-directives for years now; just didn't have the courage to
state it in public. I did that in a number of mid and large-sized projects
and never had a problem with it.
From what I understand, David Abrahams does not have any experience with the
using directives because he never used them. All he says are imaginary
problems that might possibly appear. But that's not real experience. For
what it's worth, I do have that experience both in development and
maintenance mode and it's been quite a pleasant one. YMMV, or if use the
metric system, YKMV.
Andrei
--
Check out THE C++ Seminar: 3 Days with 5 Experts
Andrei Alexandrescu
> Silly challenge; you already know the answers I'm sure. Authors have
> traditionally done beginning users a disservice by ignoring important
> details (e.g. error-handling).
How come. Error handling in good written C++ software is nonlocal. Modern
C++ Design has only one example (page 229) where error handling is ignored;
all other code is correct - and does not use explicit qualification.
> I don't think statistics about what authors
> have done proves much. Lots of books leave out the qualification /and/ the
> using-directives.
True. They assume (and implicitly suggest) that one is employing
using-directives.
> > >Have you ever seen a benefit from using "const"?
> >
> > Yes. And I recommend it. And I write it myself in production and example
> > code, and so do all the major authors.
>
> How did the benefit show up? I mean, how did you "see it"?
I suggest we leave const out of this, it's counterprodictive.
> I just want to suggest again that there's an element of social
> responsibility here: are you writing so it's easier for the author, or so
> that it's easier on the readers/maintainers?
Again, I've been maintaining code laden with using directives without
problems. That code uses modern C++ features, including namespaces,
extensively.
Andrei
--
Check out THE C++ Seminar: 3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> You asked what people are doing these
> days. People are writing more and more free functions.
As I said, I haven't seen this trend. Your source?
> > Do you tend to write a lot of global functions, compared to classes?
That
> > will provide the answer to your question. :)
>
> It depends on the problem domain. If I need to write generic code that can
> work on built-in types, free functions will always be an obvious choice.
> There tend to be lots of free functions in numeric code (e.g. sin(),
> log()...), partly for this reason. The standard library is full of free
> functions (the algorithms).
I didn't ask whether you use "free" functions or not (I don't, myself), but
whether you write a lot of them compared to classes. That's important, I
think, because I think namespace problems are (somewhat) more likely the
more "free" functions you tend to use.
Mark Wilden
>
> Most developers who moonlight as testers would probably agree with you.
Your implication is that developers who actually test their code are mere
"moonlighters." Extreme Programming (which I know you are disdainful of)
disagrees. It (and I) think that testing is part and parcel of programming,
and that a programmer who writes tests is not moonlighting, but doing his
job. Conversely, a programmer who does not write tests...
But when I said:
> I can't conceive of a test suite that would not catch calling a completely
> different function. That's not a test suite, in my book--it's worthless.
you implied that "professional testers" would disagree. Frankly, I don't see
the basis for that. It sounds like a big huge potato bug to me (to
accidentally call a completely different and unrelated function). Are you
_quite_ sure that your "professional testers" would not catch this?
Especially considering how easy it would be for a mere moonlighter, like
myself?
> To get an inkling of a tester's
> mindset, think about what the other function could do that would not be
> detected by your tests as they currently exist. Then figure out what's
> needed to close that loophole. Then decide whether it's worth the cost.
That sounds to me like a bulletin from the Department of the Bleeding
Obvious. How else does one write tests??
> Testing is rarely about finding gross errors. It's about subtle errors,
> because those are the ones that aren't self-evident.
Testing is about finding as many errors as is practical. Most errors are not
subtle (at least in my coding). Hence, most testing is about finding
non-subtle errors.
LR
Andrei Alexandrescu wrote:
>
> "Herb Sutter" <hsu...@acm.org> wrote in message
> news:o3gsitgea7om7g3qi...@4ax.com...
> [talking in favor of using-directives]
[snip]
> Scott Meyers sent me a code snippet that contained the
> following line at global scope:
> using namespace std; // so sue me
Maybe he knew that it was a bad thing to do?
[snip]
> The Revolution was started.
[snip]
Think of me as an anti-revolutionary.
With all due respect to Messrs. Alexandrescu, Sutter and Meyers, I think
that this is one of the worst ideas that I've ever heard.
May I respectfully suggest that you feel this way, because you have not
yet been burned by such a practice.
I believe that "using namespace std;" is and will remain a terrible
idea. *Especially* in books, where it's use misleads the unwary.
I like the way things like "std::cout" look too. I think that it makes
the code easier to read.
It will help you avoid having to hunt down some surprising problems that
won't otherwise get flagged as errors during compile time. Trying to
solve problems like this is never as much fun as you think it's going to
be when you first start.
This simply reinforces my opinions that, as programmers we can learn
from engineers, but, software engineering is an oxymoron.
Here is a nice quote from "Engineering in History," Kirby, Withington,
Darling and Kilgour, 0-486-26412-2, p. 242: "Fontana and Stephonson had
it in common; both were engineers with imagination and took every
precaution they could imagine."
LR.
Anyone can walk a tightrope, but how many can make it to the other end?
David Abrahams
"Andrei Alexandrescu" <andre...@hotmail.com> wrote in message
news:9htth6$fqme5$1...@ID-14036.news.dfncis.de...
>
> From what I understand, David Abrahams does not have any experience with
the
> using directives because he never used them.
On the contrary, a few times that I have used them have produced surprising
results, so I stopped.
> All he says are imaginary problems that might possibly appear.
I'm not sure that's a fair characterization. Everyone has to use some tools
when deciding whether and how to use a language feature. The experience of
others is one kind of tool, but I think reasoning and projection of possible
consequences is another valid approach. I don't think I need to experience
my program terminating to understand that exception-specifications are
usually a bad choice for my applications.
Finally, as I've stressed in previous postings, I mainly qualify explicitly
to improve readability and maintainability, which means that it's a value
judgement on my part that it's effective in that way. Others may have the
opposite judgement - fair enough - but it's not that I'm citing an imaginary
problem with other approaches. I see my approach as having real benefits.
> But that's not real experience. For
> what it's worth, I do have that experience both in development and
> maintenance mode and it's been quite a pleasant one. YMMV, or if use the
> metric system, YKMV.
Mmm, well that's good to know. I daresay my brief dalliance with using
declarations does not carry as much weight of experience as your years of
use.
-Dave
David Abrahams
> > > >Have you ever seen a benefit from using "const"?
> > >
> > > Yes. And I recommend it. And I write it myself in production and
example
> > > code, and so do all the major authors.
> >
> > How did the benefit show up? I mean, how did you "see it"?
>
> I suggest we leave const out of this, it's counterprodictive.
I'm not sure why you say that. It is at least analogous. The use of const,
as with explicit qualification:
1. documents an intention
2. makes the compiler behave more strictly
I agree that these are beneficial, but the benefits are hard to see unless
you run into a bug that const/explicit qualification might have prevented.
-Dave
David Abrahams
"Andrei Alexandrescu" <andre...@hotmail.com> wrote in message
news:9htu9p$fqvhf$1...@ID-14036.news.dfncis.de...
> > I just want to suggest again that there's an element of social
> > responsibility here: are you writing so it's easier for the author, or
so
> > that it's easier on the readers/maintainers?
>
> Again, I've been maintaining code laden with using directives without
> problems. That code uses modern C++ features, including namespaces,
> extensively.
Oh, I realize it's no problem when you're maintaining your own code. I'm
talking about what happens when somebody else has to handle your code.
That's the difference between personal grooming and social responsibility
;-)
-Dave
Mark Wilden
news:9i06og$k5v$1...@earth.superlink.net...
>
> > Scott Meyers sent me a code snippet that contained the
> > following line at global scope:
> > using namespace std; // so sue me
>
> Maybe he knew that it was a bad thing to do?
Then why did he do it? He's not exactly stupid, after all. Could it be that
the comment referred to the fact that so many other people think it's a bad
thing to do, but Scott disagrees?
> May I respectfully suggest that you feel this way, because you have not
> yet been burned by such a practice.
Exactly! And we haven't heard of anyone else being "burned." So...maybe it's
not as dangerous in the real world as some would suggest? And I use the word
"suggest" advisedly. There are a lot of suggestions that you can get
"burned," but precious little (read: none) evidence.
Since namespaces are (at least primarily) a convenience feature, such
empirical observations are valid. Personally, I expect to continue using the
directive until I run into problems or hear of (real) problems it's caused
for someone else. I've been using the directive (and arguing for it) for the
last three years, or so, and I'm still waiting...
> I like the way things like "std::cout" look too. I think that it makes
> the code easier to read.
Then of course you must use std::cout, and no one is suggesting you don't.
The question is whether what you find easy to read is sufficient argument
for everyone else also to avoid the directive.
> It will help you avoid having to hunt down some surprising problems that
> won't otherwise get flagged as errors during compile time. Trying to
> solve problems like this is never as much fun as you think it's going to
> be when you first start.
It sounds like you have indeed had some experience with the pitfalls of the
directive. Could you expand on this?
LR
Mark Wilden wrote:
>
> "LR" <lr...@superlink.net> wrote in message
> news:9i06og$k5v$1...@earth.superlink.net...
> >
> > > Scott Meyers sent me a code snippet that contained the
> > > following line at global scope:
> > > using namespace std; // so sue me
> >
> > Maybe he knew that it was a bad thing to do?
>
> Then why did he do it? He's not exactly stupid, after all.
I did not, nor would I, imply that Mr. Meyers is stupid. If he were, I
think that he wouldn't have put the "// so sue me" after the line. I
suspect that he put in "using namespace std;" as a convenience in a
snippet. I suspect he knows that it's not considered to be, and IMO
isn't good practice, and so he put the line in tongue in cheek.
> Could it be that
> the comment referred to the fact that so many other people think it's a bad
> thing to do, but Scott disagrees?
Of course that's possible, but only he can clarify that.
>
> > May I respectfully suggest that you feel this way, because you have not
> > yet been burned by such a practice.
>
> Exactly! And we haven't heard of anyone else being "burned." So...maybe it's
> not as dangerous in the real world as some would suggest? And I use the word
> "suggest" advisedly. There are a lot of suggestions that you can get
> "burned," but precious little (read: none) evidence.
I have been. Not terribly. But I do know that I want to avoid sticking
my hand in the fire a second time. Yes, as you'll read below, it was my
own stupid fault. But I make mistakes all the time. I am imperfect. If
the compiler will protect me, I will make the small effort to let it
help me.
>
> [snip] Personally, I expect to continue using the
> directive until I run into problems or hear of (real) problems it's caused
> for someone else. [snip]
Or if some of the people on this NG get their way, you can be regulated
to use it. Or if you do run into a problem, then maybe a lawyer will
find this discusion at deja and ask you about it.
I guess that if you code perfectly, all the time, every time, you don't
have to worry about things like this. But I do.
I saw someone mention the use of const as an analogy to this, which I
think was another good example. But my example would be std::cout vs.
printf. Which will be more likely to tell you about errors at compile
time? Which would you rather use?
> > I like the way things like "std::cout" look too. I think that it makes
> > the code easier to read.
>
> Then of course you must use std::cout, and no one is suggesting you don't.
> The question is whether what you find easy to read is sufficient argument
> for everyone else also to avoid the directive.
Ok, I agree, please tell me what cost would make you willing to stop
taking the risk of "using namespace std;".
> It sounds like you have indeed had some experience with the pitfalls of the
> directive. Could you expand on this?
I have, and as I noted, it was a lot less fun than you'd think. I admit
once again that I made a mistake in leaving out a header, but in medium
to large projects such mistakes probably occur more often than we'd
like. I'm not saying that it's an everyday occurrence, or even more than
once a decade occurance. But that it does happen.
And no fair telling me that "fill" isn't a name that I should use for a
function. It is the most natural name for what I wanted to do in the
problem domain. And yes, if I had it to do all over again, I'd put all
of my functions in a namespace too. But this code was originally
written before namespace was available as a feature in the compiler I
use.
So this is just a snippet, more or less. Please think about this
happening in a project that isn't just a few lines long, but a few tens
of thousands, or hundred of thousands, or millions of lines long.
Even if the code executes every time you run, you may not find this
error right away.
Anyway, here's my example. You can try it by defining CASEn when you
compile to select the individual cases. No, I don't think that using
#ifdef in this way is good practice. So sue me.
------------------------- fill.h
#ifndef FILL_H_
#define FILL_H_
void fill(double *p1, double *p2, const double &d);
#endif
------------------------------- my program(s)
#ifdef CASE1
#include <algorithm>
// no worries.
// calls fill in fill.h
#include "fill.h"
using namespace std;
int main() {
const double x = 1.0;
double t[3] = { 34.5,2.7,8.2, };
fill(t,t+3,x);
return 0;
}
#endif
#ifdef CASE2
#include <algorithm>
// oops, I forgot my include
// this will call std::fill.
// I hope it's what we want,
// because aren't going to find
// out about it until much too
// late.
using namespace std;
int main() {
const double x = 1.0;
double t[3] = { 34.5,2.7,8.2, };
fill(t,t+3,x);
return 0;
}
#endif
#ifdef CASE3
#include <algorithm>
// oops, I forgot my include
// this will yield a compile
// error, and we are saved.
int main() {
const double x = 1.0;
double t[3] = { 34.5,2.7,8.2, };
fill(t,t+3,x);
return 0;
}
#endif
LR.
Mark Wilden
news:9i225u$8bn$1...@bob.news.rcn.net...
>
> On the contrary, a few times that I have used them have produced
surprising
> results, so I stopped.
Could you elaborate? I'm really hungry for some real-world evidence of
problems with the directive. Given enough stories of problems, I might even
stop using it myself.
Mark Wilden
>
> > > > using namespace std; // so sue me
> > Then why did he do it? He's not exactly stupid, after all.
>
> I did not, nor would I, imply that Mr. Meyers is stupid. If he were, I
> think that he wouldn't have put the "// so sue me" after the line. I
> suspect that he put in "using namespace std;" as a convenience in a
> snippet.
Exactly. The using directive is for convenience, nothing more.
> I suspect he knows that it's not considered to be, and IMO
> isn't good practice, and so he put the line in tongue in cheek.
If someone like Meyers writes a line of code, I think our first assumption
should be that he did it because he thought it was the right thing to do. Of
course he's aware that certain people don't like it, and he's telling them
to bite him.
But clearly, if he thought it was bad, he wouldn't do it, especially in a
teaching book. "So sue me" isn't anywhere close to "Never do this." :)
> If the compiler will protect me, I will make the small effort to let it
> help me.
Other things being equal, I'd do the same.
> > [snip] Personally, I expect to continue using the
> > directive until I run into problems or hear of (real) problems it's
caused
> > for someone else. [snip]
>
> Or if some of the people on this NG get their way, you can be regulated
> to use it. Or if you do run into a problem, then maybe a lawyer will
> find this discusion at deja and ask you about it.
You lost me.
> I guess that if you code perfectly, all the time, every time, you don't
> have to worry about things like this. But I do.
As an imperfect being myself, I have _plenty_ to worry about, thanks. :) But
it clearly does not require perfect coding to successfully use the
directive.
> I saw someone mention the use of const as an analogy to this, which I
> think was another good example.
It's not the same thing, IMO. const affects runtime. It would only be the
most contrived set of circumstances that could cause the using directive to
affect runtime. const has other advantages; compiler-checked documentation
being perhaps the most important.
> But my example would be std::cout vs.
> printf. Which will be more likely to tell you about errors at compile
> time? Which would you rather use?
The using directive causes compile errors when it's incorrectly used (i.e.,
when there's a name clash).
> > Then of course you must use std::cout, and no one is suggesting you
don't.
> > The question is whether what you find easy to read is sufficient
argument
> > for everyone else also to avoid the directive.
>
> Ok, I agree, please tell me what cost would make you willing to stop
> taking the risk of "using namespace std;".
At this point in my career, having successfully written thousands of lines
of code under "using namespace std;", it's hard for me to say. But I'll know
it when I see it. :)
> I have, and as I noted, it was a lot less fun than you'd think. I admit
> once again that I made a mistake in leaving out a header, but in medium
> to large projects such mistakes probably occur more often than we'd
> like. I'm not saying that it's an everyday occurrence, or even more than
> once a decade occurance. But that it does happen.
OK, I'll buy that. But am I to type (and read) std:: all over the place just
because of a once in a decade occurance?
> And no fair telling me that "fill" isn't a name that I should use for a
> function.
:) That was my first thought, I admit. One thing that's probably helped me
avoid that once in a decade situation is that I don't code many global
functions, and I use proper case for functions. I also wrap my code in a
namespace.
> // I hope it's what we want,
> // because aren't going to find
> // out about it until much too
> // late.
> using namespace std;
> int main() {
> const double x = 1.0;
> double t[3] = { 34.5,2.7,8.2, };
> fill(t,t+3,x);
> Even if the code executes every time you run, you may not find this
> error right away.
It's difficult for me to conceive of a situation where you could call an
entirely different function, in another library, written by someone else,
spec'ed by yet another person, and not see a problem when you run your
tests.
Granted, compile-time checks are better than testing (that's why we use C++
instead of Smalltalk). And in general, I'll make the effort to put the
burden on the latter instead of the former. Except when the payoff seems so
low.
Francis Glassborow
<ma...@mwilden.com> writes
>It's difficult for me to conceive of a situation where you could call an
>entirely different function, in another library, written by someone else,
>spec'ed by yet another person, and not see a problem when you run your
>tests.
The problem isn't when the code is entirely different, when it is
vicious is when it is almost the same.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
LR
Mark Wilden wrote:
>
> "LR" <lr...@superlink.net> wrote in message
> news:9i4jot$1gft$1...@earth.superlink.net...
> >
> > > > > using namespace std; // so sue me
[snip]
> If someone like Meyers writes a line of code, I think our first assumption
I prefer not to assume too much, but when I see somebody write "so sue
me," in this context, if you don't mind, I'll make an assumtion thats
different from yours.
But again, only he can clarify this.
[snip]
> But clearly, if he thought it was bad, he wouldn't do it, especially in a
> teaching book.
I don't think that the original quote comes from a teaching book, but
from a communication between Mr. Meyers and Mr. Alexandrescu.
IMO putting it in a teaching book with out documenting the dangers is
*especially* bad.
[snip]
> > If the compiler will protect me, I will make the small effort to let it
> > help me.
>
> Other things being equal, I'd do the same.
But other things, for example, the downside risk, aren't always equal.
[snip]
> As an imperfect being myself, I have _plenty_ to worry about, thanks. :) But
> it clearly does not require perfect coding to successfully use the
> directive.
Just that you don't make a mistake that the compiler doesn't warn you
about.
[snip]
> It's not the same thing, IMO. const affects runtime. It would only be the
> most contrived set of circumstances that could cause the using directive to
> affect runtime.[snip]
The example I provided, which wasn't contrived, affected runtime.
>
> > But my example would be std::cout vs.
> > printf. Which will be more likely to tell you about errors at compile
> > time? Which would you rather use?
>
> The using directive causes compile errors when it's incorrectly used (i.e.,
> when there's a name clash).
You've lost me here, but on the assumption I understood what you meant
to say, again, I submit my example.
> > Ok, I agree, please tell me what cost would make you willing to stop
> > taking the risk of "using namespace std;".
>
> At this point in my career, having successfully written thousands of lines
> of code under "using namespace std;", it's hard for me to say. But I'll know
> it when I see it. :)
No, you see, that's the really fun part of "using namespace std;" You
may not see the error until it's caused some real damage.
>
> > I have, and as I noted, it was a lot less fun than you'd think. I admit
> > once again that I made a mistake in leaving out a header, but in medium
> > to large projects such mistakes probably occur more often than we'd
> > like. I'm not saying that it's an everyday occurrence, or even more than
> > once a decade occurance. But that it does happen.
>
> OK, I'll buy that. But am I to type (and read) std:: all over the place just
> because of a once in a decade occurance?
I make the mistake once a decade. The code runs every day.
>
> > And no fair telling me that "fill" isn't a name that I should use for a
> > function.
>
> :) That was my first thought, I admit. One thing that's probably helped me
> avoid that once in a decade situation is that I don't code many global
> functions, and I use proper case for functions. I also wrap my code in a
> namespace.
Like I said, this was developed before the compiler that I used
supported the feature. I applaud your wrapping functions in a namespace.
>
> > // I hope it's what we want,
> > // because aren't going to find
> > // out about it until much too
> > // late.
> > using namespace std;
> > int main() {
> > const double x = 1.0;
> > double t[3] = { 34.5,2.7,8.2, };
> > fill(t,t+3,x);
> > Even if the code executes every time you run, you may not find this
> > error right away.
>
> It's difficult for me to conceive of a situation where you could call an
> entirely different function, in another library, written by someone else,
> spec'ed by yet another person, and not see a problem when you run your
> tests.
Sorry, but it happened. And since people are probably blithely "using
namespace std;" my guess would have to be that it's happening all the
time.
> Granted, compile-time checks are better than testing (that's why we use C++
> instead of Smalltalk). And in general, I'll make the effort to put the
> burden on the latter instead of the former. Except when the payoff seems so
> low.
I'd rather be safe than sorry, and I think that testing is already
difficult enough, so I made a different cost benefit analysis. But that
will have to be your choice, I hope that you don't live to regret it.
LR.
Some people learn by having things explained to them, some people learn
from the examples set by others, but some have to grab the third rail to
see for themselves.
Ian Knowles
[snip]
>'Canada::Cpp::Sutter::Herb' and simply Herb. When we talk to each other
>anything more than 'Herb' is silly but when I talk about you to others
>who may not know of you it is 'Herb Sutter, a Canadian C++ expert ...'
Hmm...
Okay, assuming we have namespaces "UK::Cpp::Glassborow" and
"Canada::Cpp::Sutter" and the following function exists somewhere in
the namespace "Australia::Cpp::Knowles"...
#include "sutter_herb"
#include "glassborow_francis"
using namespace Canada::Cpp::Sutter;
using namespace UK::Cpp::Glassborow;
// a few hundred lines of source away...
// Function to provide feedback concerning a namespace_policy...
Policy_feedback namespace_policy_feedback( Policy policy )
{
Herb herb;
Francis francis;
Policy_feedback final_feedback;
Policy_feedback herb_feedback, francis_feedback;
while( true )
{
herb_feedback = herb.call_to_discuss_policy( policy );
francis_feedback = francis.call_to_discuss_policy( policy );
if( no_unresolved_issues(
herb_feedback, francis_feedback ) )
{
final_feedback = combine_feedback(
herb_feedback, francis_feedback );
return final_feedback;
}
}
}
Now assume that a recently appointed developer to "Cost Effective
Consulting" has been given the task to try and "lower the cost" of a
certain Australia::Consultant::Cpp::Knowles::Ian's "namespace policy
feedback" function as this function is now being requested rather
frequently and is beginning to erode the company's profit margin.
I don't think that it's entirely unreasonable to think that the
developer might decide to delve into the details of
"no_unresolved_issues" (and perhaps later the "combine_feedback")
functions seeing no obvious problem with the looping construct itself.
It is possible that the new developer might check the namespaces that
Herb and Francis live in, however, seeing there are no compile-time
issues and they are keen to impress this initial "background work"
might well be skipped, however, if the variable declarations were
fully qualified:
....
{
Canada::Cpp::Sutter::Herb herb;
UK::Cpp::Glassborow::Francis francis;
....
the financial implications of "call_to_discuss_policy" might be
immediately observed, and with the following quick change:
....
// herb_feedback = herb.call_to_discuss_policy( policy );
// francis_feedback = francis.call_to_discuss_policy( policy );
herb_feedback = herb.email_to_discuss_policy( policy );
francis_feedback = francis.email_to_discuss_policy( policy );
....
the new developer saves "Cost Effective Consulting" a lot of money (as
well as securing an early pay rise).
Of course, I must admit a major flaw with this example is the false
assumption that Australia::Consultant::Cpp::Knowles::Ian has the
necessary information to use the "call_to_discuss_policy" function at
all :>
Regards,
Ian Knowles (remove the .nospam to reply)