🚀 go-pugleaf

Lassi A. Tuura wrote:
> ... most
> applications will be doing the equivalent of "using namespace std;",
> and the resulting conflicts could become overwhelming.

This is a very odd remark.

The standard names are in the std namespace specifically
to prevent such "overwhelming" conflicts.  In the design of the
standard library, we have considered the std namespace sufficient
encapsulation that we need not be concerned about name conflicts
with user code.  Tuura seems to be predicting that this stratagem 
will fail.

Do those teaching C++ agree that namespace std encapsulation is
a failure?  When you write about C++, are you advising readers
to say "using namespace std;"?

Nathan Myers
myersn@roguewave.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "NM" == Nathan Myers <ncm@netcom.com> writes:
[...]
NM> Do those teaching C++ agree that namespace std encapsulation is a
NM> failure?  When you write about C++, are you advising readers to
NM> say "using namespace std;"?

I wouldn't call it a failure, but I would like to see some ``topical''
comparting so that I might write:
	using namespace ::std::strings;
or
	using namespace ::std::vectors;
etc. (I'm mentioning these two because I expect they often clash with
existing names, unlike say ostream or valarray.)

Although I've never encouraged anyone to use
	using namespace std;
many have asked me if there was a nice way to only cause part of the
namespace std to be considered for name-lookup.

	Daveed

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <l8220qk4oos.fsf@neppari.cs.hut.fi> Lassi.Tuura@hut.fi (Lassi A. Tuura) writes:

> I see two possible paths emerging from the current situation:
>   - programmers put "using namespace std;" in their programs, which
>     will be *very* unfortunate; it will be hard to motivate them
>     not to do so, at least not until the next revision is made to the
>     standard and they have tons of clashes...

Even if programmers do put "using namespace std" in their programs,
that isn't necessary such a disaster.  Remember, you can put a
using-directive anywhere, not just at namespace scope.  So you can put
"using namespace std" in function definitions (and not necessarily all
function definitions), rather than at the beginning of every file.
That will ensure, at any rate, that any problems will be local ones.

I agree that it would be nice to have namespace std partitioned a bit
more finely; I doubt if it will happen, though.  Coming up with a
sensible partitioning might be a fair amount of work.
-- 
  Matt Austern                             He showed his lower teeth.  "We 
  matt@physics.berkeley.edu                all have flaws," he said, "and 
  http://dogbert.lbl.gov/~matt             mine is being wicked."

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

David Vandevoorde <vandevod@cs.rpi.edu> writes:
> >>>>> "NM" == Nathan Myers <ncm@netcom.com> writes:
> [...]
> NM> Do those teaching C++ agree that namespace std encapsulation is a
> NM> failure?  When you write about C++, are you advising readers to
> NM> say "using namespace std;"?

It might be that I have totally misunderstood the concept of
namespaces since I haven't had any compiler to test them on.
I tried to read the relevant parts of the draft, and understood the
stuff as follows.

If I define a namespace like

namespace X {
   class XYZ { /* ... */ };
   extern XYZ xyz;
}

then I cannot cannot access `xyz' without additional scope qualifiers
until I have either "using namespace X;" or "using X::xyz;" in my
program.

Given that the standard namespace `std' is required to be declared
much like this, does the committee indeed assume that programmes would
be doing "using std::<a feature I need>;" instead of "using namespace
std;"?  I would say this is fairly bold assumption, and as such I
don't think the encapsulation will have much hopes for success.

> I wouldn't call it a failure, but I would like to see some ``topical''
> comparting so that I might write:
> 	using namespace ::std::strings;
> or
> 	using namespace ::std::vectors;
> etc. (I'm mentioning these two because I expect they often clash with
> existing names, unlike say ostream or valarray.)

This is exactly what I mean, and would very much like to see.  I am
quite confident that programmers like I will never have serious
clashes with the standard `std' name space.  However, the committee
should acknowledge that there are programmers that have better ways to
spend their time than trying to figure out all the using-declarations
they need.  These programmers are not usually computer scientists but
physicists or economists or you-name-it professionals who are using
the language as a means to achieve their needs: producing the
executable programs; the joy of writing c++ may not be their final
goal.

I see two possible paths emerging from the current situation:
  - programmers put "using namespace std;" in their programs, which
    will be *very* unfortunate; it will be hard to motivate them
    not to do so, at least not until the next revision is made to the
    standard and they have tons of clashes...
  - packages whose only purpose is to encapsulate std namespace
    features to smaller chunks will appear -- possibly (probably?)
    they will come directly with STL implementations.

Therefore, I propose the division David Vandevoorde mentioned should
be performed before the standard is finished.  Of course, this still
does not remove my original plea that the exceptions in the draft
standard should be named more uniformly.

//LaT
-- 
Lassi A. Tuura                           Have you not known?
Lassi.Tuura@hut.fi                       Have you not heard?


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]