In article <6TXw7.251$GF2.15528@tengri.easynet.fr>, Francis ANDRE says...
>
>
>Hi DG
>
>Does the C++ standard or Request for enhancement list plan to add:
>using namespace;
>
>This will be helpful in avoiding name scope clashes when using a "new" std
>namespace  and "old" global namespace.

No, that won't be done. (as you suggest it).
The point is that any namesclash should be resolved by explicit qualification.
That is, be clear in what namespace you want; :: or std::

>For exemple
>
>#include <fstream>
>#include <vector>
>using namespace    std:
>class    foo    {
>public:
>        vector<int>        bar1;
>        vector<int>        bar2;
>friend    ostream&    operator << (ostream& os, const foo&);
>};
>....
>....
>#include <strstream.h>
>....
>....
>
>
>At this point, the compiler emits an error claiming that "streambuf" and
>"ostream"  referenced in the definition of strstream is ambigous because the
>declaration of "class streambuf;" conflicts with "typedef
>basic_streambuf <char, char_traits<char> >" from <fstream>.

Well, you should have used using std::vector, and whoever wrote <strstream.h>
should have used ::streambuf.

>By inserting a reset command like -- using namespace; -- of the used
>namespace before the including of <strstream.h>,
>one can avoid this kind of problem.

By using <sstream> one can avoid more problems.

>I know that one cannot intermix <iostream> and <iostream.h> but when an
>application is using one library with <iostream.h> and another one with
> <iostream> comming from 2 differents providers, this is a real painful
> problem!!!

Well, yeah, that's true sometimes, with certain namemangling schemes etc.
But since libraries are really a problem outside the C++ language, it is
a problem best solved by each compiler vendor. After all, they know what's
really in their <iostream>. The standard writers don't know that.

>In my opinion, the -- using namespace;-- could be a easy solution both for
>compiler and integrator to cope with the problem.

>Cheers
>Francis ANDRE

In general I dislike language solutions to problems with a limited
number compilers, or to problems with legacy code. Handling legacy
issues is IMO the domain of compiler vendors, a QOI issue. Perhaps
a #pragma mix_io_streams is a solution ?

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]