> How do I turn it off, i.e. that I am not using namespace std anymore?
[SNIP]
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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> 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?
Regards, Thomas Kunert
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> "Esa" <x...@y.z> wrote in message news:f0gV6.1$22.962@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. :-)
>: 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).
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). --
In article <3B275B62.A96F...@physik.tu-dresden.de>, Thomas Kunert <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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>, Steve Clamage <clam...@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++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>, > Steve Clamage <clam...@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.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>, Steve
Clamage <clam...@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:
> 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, brang...@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++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> In article <Pine.SOL.3.96.1010612125722.12156D-100000@taumet>, Steve > Clamage <clam...@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:
> 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!).
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> 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?
[SNIP]
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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> 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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
To answer the original subject question: It's spelled "}". :-) That is, use scope to control the... well... scope of using-declarations and using-directives.
>Steve Clamage <clam...@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:
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 <riesb...@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.
>> 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.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
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.
"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 :-).
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
> 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 <riesb...@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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
"John J. Rusnak" 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.
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
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
I write code for biologists, distributed as source, and biologists have 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.
In article <3B2BF710.D411E...@mindspring.com>, John J. Rusnak <john.rus...@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.
> 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.
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.
[ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ]
|
