In article <3qimou$qlv@tools.near.net> barmar@nic.near.net (Barry
Margolin) writes:

|> In article <D9GK7t.8AD@lut.fi> hevi@dior.it.lut.fi (Petri Heinil{) writes:
|> >In article <D9G6vx.78q@info.physics.utoronto.ca>, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
|> >> Namespaces are especially useful when using more than one third
|> >> party library.
|> ...
|> >Indeed, newer linker can. For example in SunOS 5 with linker
|> >environment variable LD_LIBRARY_PATH can order the resolving
|> >the calls and -z muldefs allow multiple definitions. I don't
|> >know how it's with DLL's on windows, but same kind of system
|> >should be easily produced.

|> That works when you want one library to override the other.  But suppose
|> you want to use *both* libA::AReallyCoolFunc() and libB::AReallyGreatClass
|> in the same program.  Or worse, what if you want do something like:

|>  result = libA::AReallyCoolFunc() + libB::AReallyCoolFunc();

|> The most common example of this kind of conflict is whan multiple vendors
|> name the root of their class hierarchy "Object".  In that case you're
|> likely to need to define objects of class libA::Object and libB::Object.

Multiple vendors who were dumb enough to define a class called object
before namespaces are probably dumb enough to not put it in a
namespace once they have it.

Remember that in the past, there was a (widely used) vendor with a
class called String (rather than, say RWString or BCString), and
another supplier (even more widely circulated) with

 #define String char*

in their header file.

Namespaces (nor any other feature, for that matter) are not a cure for
stupidity on the part of the implementor.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article 990@info.physics.utoronto.ca, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
>According to Steve Clamage <clamage@Eng.Sun.COM>:
>> But the namespace must affect the "real" name of the object. Suppose a
>> compilation unit consists of only this:
>>  namespace XXX { int i; }
>> Any other namespace may have an object or function called "i", so the
>> compiler must identify this object as "the i from XXX". In this compilation
>> unit there is no way to know what other units may eventually (ever) be
>> linked into the same program. The usual way to handle the situation is
>> to include the namespace in the name mangling.
>
>Does that mean that I must always use XXX::i to reference i, even
>if it is the only i in scope?

You really need to read some documentation about namespaces. They are
discussed in D&E, and of course in the draft standard. D&E is much
easier to read and understand, although some namespace details have
been modified since its publication.

You can bring a name into another scope with a using-directive
or a using-declaration. You then do not necessarily need to use the
fully-qualified version of the name in that other scope.

The detailed name-binding rules are rather complicated, but the simple
cases are easy to understand and use. Here are some simple examples:

namespace XXX {
 int i;
 double d;
}

void f1()
{
 int k = XXX::i; // ok
 double x = d; // error, 'd' unknown
}

void f2()
{
 using namespace XXX; // all XXX names brought into current scope
 int k = i; // ok, XXX::i
 double x = d; // ok, XXX::d
}

void f3()
{
 using X::i; // only X::i brought into current scope
 int k = i; // ok, XXX::i
 double x = d; // error, 'd' unknown
}

---
Steve Clamage, stephen.clamage@eng.sun.com

According to Claus T|ndering <ct@login.dknet.dk>:
>
> Would someone please explain to me the practical uses of
> the "namespace" construct introduced in the ISO C++ standard
> draft?
>
> When and why would I want to use a "namespace" declaration?


Namespaces are especially useful when using more than one third
party library.

If library A and library B both define

class AReallyGreatClass;

or

void AReallyCoolFunc();

then the linker can't know which one you want to use when
you call it in the code, and it complains about multiple
definitions.

With namespaces, each library vendor can define their own
namespace, which makes their class or function name unique.
You could then call it like this:

libA::AReallyCoolFunc();

or

libB::AReallyGreatClass b;

where libA and libB are the vendor defined namespaces.


Of course you could do the same with your own functions.
Say you want to define your own iostream class, but don't
want to use or hide the standard one.  All standard func's
and classes are defined in the namespace Std (I think that's
how it's been spelled).  If you define your iostream class
in the namespace MySpace, you can now do this:

Std::ostream stdout;
MySpace::ostream myout;

Not bad, eh?


Hope this helps.


Pete

In article <D9G6vx.78q@info.physics.utoronto.ca>, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
> Namespaces are especially useful when using more than one third
> party library.
>
> If library A and library B both define
>
> class AReallyGreatClass;
>
> or
>
> void AReallyCoolFunc();
>
> then the linker can't know which one you want to use when
> you call it in the code, and it complains about multiple
> definitions.

Indeed, newer linker can. For example in SunOS 5 with linker
environment variable LD_LIBRARY_PATH can order the resolving
the calls and -z muldefs allow multiple definitions. I don't
know how it's with DLL's on windows, but same kind of system
should be easily produced.

Changing resolving order dynamically is very useful feature,
when changing implementations for some service. For example
the look of push button or other user interface elements
can be well selected in this way.

And question from that: can the namespaces change dynamically ?

--
<A HREF="http://www.lut.fi/~hevi/">Petri.Heinila@lut.fi</A>

According to Petri Heinil{ <hevi@dior.it.lut.fi>:
> In article <D9G6vx.78q@info.physics.utoronto.ca>, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
> > Namespaces are especially useful when using more than one third
> > party library.
> >
> > If library A and library B both define
> >
> > class AReallyGreatClass;
> >
> > or
> >
> > void AReallyCoolFunc();
> >
> > then the linker can't know which one you want to use when
> > you call it in the code, and it complains about multiple
> > definitions.
>
> Indeed, newer linker can. For example in SunOS 5 with linker
> environment variable LD_LIBRARY_PATH can order the resolving
> the calls and -z muldefs allow multiple definitions.

I didn't know that.  However, since that is a specific linker's
capability, it is proprietary.  Namespaces are part of the language
definition, and therefore are (will be soon?) portable.


> And question from that: can the namespaces change dynamically ?

I'm not sure, but I don't think so.  As far as I know, namespaces are
used for _compile_ time name resolution, so they don't actually change
the name of the called function (which I think would be required to
create some kind of dynamic namespacing).  If they did change the
name, then you would have to use the namespace resolution, even
when there is no conflict.



Pete

In article <D9GK7t.8AD@lut.fi> hevi@dior.it.lut.fi (Petri Heinil{) writes:
>In article <D9G6vx.78q@info.physics.utoronto.ca>, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
>> Namespaces are especially useful when using more than one third
>> party library.
...
>Indeed, newer linker can. For example in SunOS 5 with linker
>environment variable LD_LIBRARY_PATH can order the resolving
>the calls and -z muldefs allow multiple definitions. I don't
>know how it's with DLL's on windows, but same kind of system
>should be easily produced.

That works when you want one library to override the other.  But suppose
you want to use *both* libA::AReallyCoolFunc() and libB::AReallyGreatClass
in the same program.  Or worse, what if you want do something like:

 result = libA::AReallyCoolFunc() + libB::AReallyCoolFunc();

The most common example of this kind of conflict is whan multiple vendors
name the root of their class hierarchy "Object".  In that case you're
likely to need to define objects of class libA::Object and libB::Object.

Note also, that object declarations aren't handled by the linker, they're
resolved at compile time.  The linker only handles external references.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@{bbnplanet.com,near.net,nic.near.net,netcom.com}
Phone (617) 873-3126 - Fax (617) 873-5124

In article 23D@info.physics.utoronto.ca, peter@chinook.physics.utoronto.ca (Peter Berdeklis) writes:
>>
>> Indeed, newer linker can. For example in SunOS 5 with linker
>> environment variable LD_LIBRARY_PATH can order the resolving
>> the calls and -z muldefs allow multiple definitions.
>
>I didn't know that.  However, since that is a specific linker's
>capability, it is proprietary.

Quite apart from that, we would still have the following problems: Suppose
Library X and Library Y each declare different a class called "Time".

1. You cannot include "X.h" and "Y.h" in the same module, since you
would then have two different classes in the same scope with the
same name. That is not allowed.

2. If you construct a Time object from X in file1.cc, and a Time object
from Y in file2.cc, they are created with different constructors. But each
constructor is called "Time::Time()". How do we tell them apart? If you
tell the linker to search X.lib first, we construct both with the X version,
which is wrong for the object in file2.

>> And question from that: can the namespaces change dynamically ?
>
>I'm not sure, but I don't think so.  As far as I know, namespaces are
>used for _compile_ time name resolution, so they don't actually change
>the name of the called function (which I think would be required to
>create some kind of dynamic namespacing).  If they did change the
>name, then you would have to use the namespace resolution, even
>when there is no conflict.

A namespace is a compile-time concept. You can add names to a namespace
at different points in your source code (same compilation unit or different
compilation units). There is no concept of namespace at run time.

But the namespace must affect the "real" name of the object. Suppose a
compilation unit consists of only this:
 namespace XXX { int i; }
Any other namespace may have an object or function called "i", so the
compiler must identify this object as "the i from XXX". In this compilation
unit there is no way to know what other units may eventually (ever) be
linked into the same program. The usual way to handle the situation is
to include the namespace in the name mangling.

---
Steve Clamage, stephen.clamage@eng.sun.com

(Notice how I resisted using "man" and "UNCLE", or "girl" and "Ipanema"
for the variable and namespace.)

According to Steve Clamage <clamage@Eng.Sun.COM>:
> But the namespace must affect the "real" name of the object. Suppose a
> compilation unit consists of only this:
>  namespace XXX { int i; }
> Any other namespace may have an object or function called "i", so the
> compiler must identify this object as "the i from XXX". In this compilation
> unit there is no way to know what other units may eventually (ever) be
> linked into the same program. The usual way to handle the situation is
> to include the namespace in the name mangling.


Does that mean that I must always use XXX::i to reference i, even
if it is the only i in scope?


Pete

Would someone please explain to me the practical uses of
the "namespace" construct introduced in the ISO C++ standard
draft?

When and why would I want to use a "namespace" declaration?

---
Claus Tondering
Lyngby, Denmark
ct@login.dknet.dk