Nathan Myers wrote:
>
> In article <3485f189.97655353@news.motu.com> Dave Abraham[sic] wrote:
> >Recently I've been posting some questions to comp.lang.c++.moderated
> >about using namespaces safely and effectively, and the dearth of
> >satisfactory answers leads me to wonder whether the language feature
> >can actually fulfill its promise. The biggest problem as I see it is
> >that without significant care (for which there is no help from the
> >compiler), using directives import a different set of names from a
> >namespace in different translation units. This is true even if we
> >follow Stroustrup's advice and limit using directives to function
> >scope:
> > ...
> >void foo()
> >{
> >  using namespace M; // M declared in A.h -- OK.
> >  using namespace L; // L declared in something from Q.h
> >  B b;  // Which definition of B is this?
> >        // Depends on what Q.h #includes.
> >}
>
> If we "follow Stroustrup's advice" we will use using-directives
> mainly as a transition aid.  Is "M::B" such an intrusive name?
> Short namespace aliases provide all the convenience you need,
> and more safety.

Nathan,

I refer you to 8.2.3, where he says "In a function (only), a using-directive
can be safely used as a notational convenience"

And 8.3.3.1 where he gives code examples that follow this practice

And 8.4/8, which says "Use _using_ _namespace_ only for transition or within a
local scope"

More to the point, if I'm delivering a library, I don't have a lot of control
over how my clients use it. I'd like to protect them as much as possible from
such problems.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <3485f189.97655353@news.motu.com> Dave Abraham wrote:
>Recently I've been posting some questions to comp.lang.c++.moderated
>about using namespaces safely and effectively, and the dearth of
>satisfactory answers leads me to wonder whether the language feature
>can actually fulfill its promise. The biggest problem as I see it is
>that without significant care (for which there is no help from the
>compiler), using directives import a different set of names from a
>namespace in different translation units. This is true even if we
>follow Stroustrup's advice and limit using directives to function
>scope:
> ...
>void foo()
>{
>  using namespace M; // M declared in A.h -- OK.
>  using namespace L; // L declared in something from Q.h
>  B b;  // Which definition of B is this?
>        // Depends on what Q.h #includes.
>}

If we "follow Stroustrup's advice" we will use using-directives
mainly as a transition aid.  Is "M::B" such an intrusive name?
Short namespace aliases provide all the convenience you need,
and more safety.

Nathan Myers
ncm@nospam.cantrip.org
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nat Pryce <np2@doc.ic.ac.uk> writes:

>Fergus Henderson wrote:
>> So, in C+=2, we should keep translation units, and names for them.
>> We should get rid of #include, so the names will be translation unit
>> names, not header file names, but the names are needed so that we
>> can make the dependencies explicit.  The replacement for `#include'
>> would be a new keyword, call it say `import'.  If you write
>>
>>         import foo;
>>
>> then this would import (make visible) all the declarations for
>> entities defined in `foo'.  One major distinction between this
>> and `#include' is that import would not be transitive; you
>> would get only the declarations for the entities defined in `foo',
>> not for those which are simply used in `foo'.
>
>But this can still cause the same problem!  The cause of the problem
>is not #include but the "using namespace ..." statement.

Hmm.  Yes, you're right.  `using' is transitive too,
so it has similar problems.  Oh well :-(

A possible solution is to avoid using `using'.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Abrahams wrote:
>
> Fergus Henderson wrote:
> >
[...]
> > Stroustrup did in fact propose adding something roughly along these lines,
> > but it was at a fairly late stage in the standardization process...
> > since C++ already has namespaces, this was seen as too much,
> > too late in the process, for too little benefit.
>
> Probably a good thing: I don't know if it would help all that much unless it
> were integrated somehow with namespaces. Do you want to be able to separately
> compile different parts of your component (all in one namespace)? If so, then
> we have a similar problem where the meaning of a name in the presence of a
> using-directive is dependent on the set of imported translation units. The
> lack of transitive imports helps a little, but it still seems unnatural and
> error-prone. A possible improvement:
>
> 1. Translation units get bound together into packages
> 2. A namespace can only be opened within a single package
> 3. Importing a translation unit is prohibited
> 4. Importing a package is allowed.

This package idea is IMHO a good idea. It could also help to solve
another problem: static object initialization.

Used packages would have to be mentioned explicitly; therefore the
dependencies would be well defined and known to the compiler. Thus it
can be ensured that initialization of statics inside a package occurs
before the package is used. IMHO circular dependencies of packages
should not generally be allowed (that is, the dependency graph of
packages is a tree; inside of packages of course all the C++ features
are allowed; that is, circular dependencies between file inside a
package are possible). A "backdoor" could be an "import uninitialized"
directive, which imports another package, but doesn't ensure it is
properly initialized until the main() function of the program is
executed (that is, you can't rely on it being initialized during
initialization of your package).

To be compatible with current C++, there would have to be a main
package which doesn't have to be declared; Everything that doesn't go
into other packages goes into the main package (that is, all current
programs would use the main package only). The main() function of the
program always has to be in the main package.  It would be nice to
allow main() functions in other packages as well; those would be called
at the end of package initialization. When a package main executes,
it's own static data and the imported, but not imported uninitialized
packages are guaranteed to be initialized (that is, the main()
functions of all imported, but not imported uninitialized packages have
been run, and all constructors of own static data of the current
package have been called. If imported uninitialized packages have been
initialized yet is undefined; they must however be initialized on entry
to program main().  Files belonging to a package other than the main
package would have to contain a line "package name" or similar before
any C++ declaration.

The standard stuff could be in a special package "standard", which is
automatically imported to any package without a special import
statement, this way ensuring current programs compile without change.

BTW, even if you'd have such a package structure, it would still be
nice to have a replacement for #include, which doesn't allow macros
from the including file to be active in the included file. Also to be
able to give parameters to them would be nice as well. This new feature
would be used _inside_ a package as replacement for #include.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Recently I've been posting some questions to comp.lang.c++.moderated
about using namespaces safely and effectively, and the dearth of
satisfactory answers leads me to wonder whether the language feature
can actually fulfill its promise. The biggest problem as I see it is
that without significant care (for which there is no help from the
compiler), using directives import a different set of names from a
namespace in different translation units. This is true even if we
follow Stroustrup's advice and limit using directives to function
scope:

//A.h
namespace M
{
  class A {...};
}

//B.h
namespace M
{
  class B {...};
}

// BB.h
namespace L
{
  class B {...};
}

//Q.cpp
#include "Q.h"
#include "A.h"

void foo()
{
  using namespace M; // M declared in A.h -- OK.
  using namespace L; // L declared in something from Q.h
  B b;  // Which definition of B is this?
        // Depends on what Q.h #includes.
}

In this example, the effects of declaring B could change wildly based
on subtle header file dependencies in Q.h. I'd still like to see an
answer for this problem (and others - see my other posts) if anyone
has one. The real culprit here, however, is not the design of
namespaces but the existence of multiple translation units.

The only reason we have multiple translation units is, IMO,
historical. Imagine there was only one big translation unit, and all
definitions went into a "big database soup". The above problems would
disappear. Also any issues about which header files you have to
include - this is a big one for people trying to write cross-platform
software using the standard library (which headers do you technically
need to include to get particular definitions, and how do you know
that you've included all of them?). In fact, #include could disappear
altogether, eliminating another problem: header file name collisions.

Any such compiler would have to be smart enough to only recompile the
relevant parts of the program when declarations changed, but that
technology has been available in research circles for years. I hear
that IBM has recently announced an incremental compiler that works
this way. I'd like to see the standard evolve in a way that encourages
such systems. In particular, everything that introduces a semantic
dependency on order of declarations and usage should be deprecated or
stricken.

-Dave
(Please change 'spam' to 'abrahams' in the return address, which has been altered to foil junk mail senders.)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Abrahams wrote:
>
>
> In this example, the effects of declaring B could change wildly based
> on subtle header file dependencies in Q.h. I'd still like to see an
> answer for this problem (and others - see my other posts) if anyone
> has one. The real culprit here, however, is not the design of
> namespaces but the existence of multiple translation units.

In fact it has nothing whatsoever to do with namespaces:

// A.h
void f(int);

// B.h
void f(double);

// test.cpp
#include "B.h"

int main()
{
f(1); // calls f(double)
}

If you #include "A.h" as well, f(1) calls f(int). This problem is not
new, nor has it led to significant complaints in the past.
 The real question is do people run into problems here in practice?
There are lots of ways you can screw yourself up if you're careless, but
most of them are in the category of "don't do that".
 -- Pete
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

spam@motu.com (David Abrahams) writes:

>Recently I've been posting some questions to comp.lang.c++.moderated
>about using namespaces safely and effectively, and the dearth of
>satisfactory answers leads me to wonder whether the language feature
>can actually fulfill its promise. The biggest problem as I see it is
>that without significant care (for which there is no help from the
>compiler), using directives import a different set of names from a
>namespace in different translation units. This is true even if we
>follow Stroustrup's advice and limit using directives to function
>scope:
[...]
>#include "Q.h"
>#include "A.h"
>
>void foo()
>{
>  using namespace M; // M declared in A.h -- OK.
>  using namespace L; // L declared in something from Q.h
>  B b;  // Which definition of B is this?
>        // Depends on what Q.h #includes.
>}
>
>In this example, the effects of declaring B could change wildly based
>on subtle header file dependencies in Q.h.

IMHO, the problem here is not the existence of multiple translation
units, and it is not namespaces or `using'.  The problem is `#include'.

>The only reason we have multiple translation units is, IMO,
>historical. Imagine there was only one big translation unit, and all
>definitions went into a "big database soup".  The above problems would
>disappear. Also any issues about which header files you have to
>include - this is a big one for people trying to write cross-platform
>software using the standard library (which headers do you technically
>need to include to get particular definitions, and how do you know
>that you've included all of them?). In fact, #include could disappear
>altogether, eliminating another problem: header file name collisions.

Separate compilation is a feature, not a bug.
Your proposal would make separate compilation very difficult.

Also explicit dependencies are a feature.
Your proposal would make dependencies implicit.
There would have several major negative consequences.
One is that simply adding a new declaration in a new file `foo.c'
might break some code in `bar.c', even though `bar.c' didn't
mention `foo.c' at all.  Another is that it would be harder
for programmers to figure out what the real dependencies are.

So, in C+=2, we should keep translation units, and names for them.
We should get rid of #include, so the names will be translation unit
names, not header file names, but the names are needed so that we
can make the dependencies explicit.  The replacement for `#include'
would be a new keyword, call it say `import'.  If you write

 import foo;

then this would import (make visible) all the declarations for
entities defined in `foo'.  One major distinction between this
and `#include' is that import would not be transitive; you
would get only the declarations for the entities defined in `foo',
not for those which are simply used in `foo'.

Stroustrup did in fact propose adding something roughly along these lines,
but it was at a fairly late stage in the standardization process...
since C++ already has namespaces, this was seen as too much,
too late in the process, for too little benefit.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Pete Becker wrote:
>
> David Abrahams wrote:
> >
> >
> > In this example, the effects of declaring B could change wildly based
> > on subtle header file dependencies in Q.h. I'd still like to see an
> > answer for this problem (and others - see my other posts) if anyone
> > has one. The real culprit here, however, is not the design of
> > namespaces but the existence of multiple translation units.
>
> In fact it has nothing whatsoever to do with namespaces:

If I thought the problem was with namespaces, I would have titled the post
"namespaces must die"!

> // A.h
> void f(int);
>
> // B.h
> void f(double);
>
> // test.cpp
> #include "B.h"
>
> int main()
> {
> f(1);   // calls f(double)
> }
>
> If you #include "A.h" as well, f(1) calls f(int). This problem is not
> new nor has it led to significant complaints in the past.

That's a good point - separate translation units were a danger long before I
had namespaces. In a sense, namespaces make the problem much worse. Before I
had namespace support I would never have dreamed of writing a type name (class
or typedef) called "Time". The chance of a name collision in the future was
simply too great. This would lead to descriptive, but frequently overly
verbose names that included some description of the problem domain. I work for
a music software company; here a few different approaches to representing time
that we might need:

// A time within a measure
typedef rational<long> MusicNotationTime;
// A time in seconds
typedef double RealTime;
// A motion-picture frame synchronization time
struct { int hh, mm, ss, ff, hh; } SMPTETime;

Because we all know about the dangers of name collisions in a world without
namespaces, examples like yours above with a function called "f" (or something
similarly short) seldom appear in real code written by experienced programmers.

Now, if I'm writing the music notation package with namespaces, an
organization like this makes a lot more sense:

namespace MusicNotation { typedef rational<long> Time; ... }

Now I can deal simply with Time within the MusicNotation namespace. My code
becomes more readable and my clients are protected from name collisions...
unless they see the wrong set of declarations.

>         The real question is do people run into problems here in practice?

Good question. From the lack of practical responses to my post on
comp.lang.c++.moderated, I'm beginning to wonder whether people have made much
use of namespaces. Of course, there are other possible explanations.

> There are lots of ways you can screw yourself up if you're careless, but
> most of them are in the category of "don't do that".

Yes, but for most of those we have invented some easily-managed coding
practices which help to save us from ourselves. My best solution for this
problem in the presence of namespaces is not only hard to manage, but
introduces undesirable recompilation dependencies - another side-effect of
separate translation units.

When I consider the amount of effort I expend avoiding recompilation
dependencies just as a matter of course every day, it sends a little shiver
down my spine. If the standard encouraged a single-translation-unit,
incremental rebuild model, it would eventually make writing C++ much more
natural and less error-prone.

-Dave
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
> spam@motu.com (David Abrahams) writes:
> [...]
> >#include "Q.h"
> >#include "A.h"
> >
> >void foo()
> >{
> >  using namespace M; // M declared in A.h -- OK.
> >  using namespace L; // L declared in something from Q.h
> >  B b;  // Which definition of B is this?
> >        // Depends on what Q.h #includes.
> >}
> >
> >In this example, the effects of declaring B could change wildly based
> >on subtle header file dependencies in Q.h.
>
> IMHO, the problem here is not the existence of multiple translation
> units, and it is not namespaces or `using'.  The problem is `#include'.
[...snip...]
> So, in C+=2, we should keep translation units, and names for them.
> We should get rid of #include, so the names will be translation unit
> names, not header file names, but the names are needed so that we
> can make the dependencies explicit.  The replacement for `#include'
> would be a new keyword, call it say `import'.  If you write
>
>         import foo;
>
> then this would import (make visible) all the declarations for
> entities defined in `foo'.  One major distinction between this
> and `#include' is that import would not be transitive; you
> would get only the declarations for the entities defined in `foo',
> not for those which are simply used in `foo'.

But this can still cause the same problem!  The cause of the problem
is not #include but the "using namespace ..." statement.  For example,
the same problem would occur if there was no #include but the
namespaces were implemented as:

namespace M {
 class B { ... };
}

namespace N {
 class B { ... };
}

namespace O {
 using namespace M;
 using namespace N;

 B b; // Which b?
}

The fault in the code above is that it does not explicitly state the
dependencies between the namespaces -- writing vague code like this
is asking for trouble in the long run because namespace O is not
insulated from changes to the implementation of namespaces M and N.

E.g:  suppose that initially, namespace N was defined as:

namespace N {
 class A { ... };
}

Then namespace O would be fine.  However, the next release of namespace
N might be altered to be:

namespace N {
 class B { ... }; // Implementation details
 class A { ... };
}

And now namespace O is broken.

However, the dependencies between namespaces are less brittle if
defined explicitly, such as:

namespace O {
 using M::B;
 using N::A;

 B b;
}

Cheers,
 Nat.



--
+------------------------------------------+---------------------+
| Name:   Nat Pryce MEng ACGI              | Dept. of Computing, |
| Email:  np2@doc.ic.ac.uk                 | Imperial College,   |
| Tel:    +44 (0)171 594 8394              | 180 Queen's Gate,   |
| Fax:    +44 (0)171 581 8024              | London SW7 2BZ,     |
| WWW:    http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom      |
+------------------------------------------+---------------------+
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
>
> spam@motu.com (David Abrahams) writes:
>
> >Recently I've been posting some questions to comp.lang.c++.moderated
> >about using namespaces safely and effectively, and the dearth of
> >satisfactory answers leads me to wonder whether the language feature
> >can actually fulfill its promise. The biggest problem as I see it is
> >that without significant care (for which there is no help from the
> >compiler), using directives import a different set of names from a
> >namespace in different translation units. This is true even if we
> >follow Stroustrup's advice and limit using directives to function
> >scope:
> [...]
> >#include "Q.h"
> >#include "A.h"
> >
> >void foo()
> >{
> >  using namespace M; // M declared in A.h -- OK.
> >  using namespace L; // L declared in something from Q.h
> >  B b;  // Which definition of B is this?
> >        // Depends on what Q.h #includes.
> >}
> >
> >In this example, the effects of declaring B could change wildly based
> >on subtle header file dependencies in Q.h.
>
> IMHO, the problem here is not the existence of multiple translation
> units, and it is not namespaces or `using'.  The problem is `#include'.
>
> >The only reason we have multiple translation units is, IMO,
> >historical. Imagine there was only one big translation unit, and all
> >definitions went into a "big database soup".  The above problems would
> >disappear. Also any issues about which header files you have to
> >include - this is a big one for people trying to write cross-platform
> >software using the standard library (which headers do you technically
> >need to include to get particular definitions, and how do you know
> >that you've included all of them?). In fact, #include could disappear
> >altogether, eliminating another problem: header file name collisions.
>
> Separate compilation is a feature, not a bug.
> Your proposal would make separate compilation very difficult.

You're right; I forgot about that. I'd be happy to amend my proposal to allow
separate compilation. In the case of separate compilation, people would get no
less protection than they do right now - perhaps more, depending on the
availability of definitions in their "database soup".

> Also explicit dependencies are a feature.

Explicit dependencies between what? Files?  You're suggesting that #include
should be replaced, but that's the mechanism for  explicit dependencies
between files, so I assume you mean something else. Please explain.

> Your proposal would make dependencies implicit.
> There would have several major negative consequences.
> One is that simply adding a new declaration in a new file `foo.c'
> might break some code in `bar.c', even though `bar.c' didn't
> mention `foo.c' at all.

It's already possible (easy) to break the one-definition-rule that way, with
no diagnostic required from the compiler. At least in my proposal, there would
be some enforcement of the ODR.

>  Another is that it would be harder
> for programmers to figure out what the real dependencies are.

I'm not so sure. First of all, I wonder how important it is to know what the
real dependencies are. Practically speaking, I have never been tempted to look
through the list of #included files to find out what a file depends on. Even
if we decide it's important, that list is extremely poor documentation of
those dependencies. Often enough, something that `foo.c' depends on isn't in
its list of #includes because it just happens to be included by something that
is. Tracing through the transitive closure of #includes isn't much help either
because you usually end up seeing far more than actually neccessary to compile
the file in question.

> So, in C+=2, we should keep translation units, and names for them.
> We should get rid of #include, so the names will be translation unit
> names, not header file names, but the names are needed so that we
> can make the dependencies explicit.  The replacement for `#include'
> would be a new keyword, call it say `import'.  If you write
>
>         import foo;
>
> then this would import (make visible) all the declarations for
> entities defined in `foo'.

What is `foo'? A source file? A translation unit? I'll assume the latter.

> One major distinction between this
> and `#include' is that import would not be transitive; you
> would get only the declarations for the entities defined in `foo',
> not for those which are simply used in `foo'.
>
> Stroustrup did in fact propose adding something roughly along these lines,
> but it was at a fairly late stage in the standardization process...
> since C++ already has namespaces, this was seen as too much,
> too late in the process, for too little benefit.

Probably a good thing: I don't know if it would help all that much unless it
were integrated somehow with namespaces. Do you want to be able to separately
compile different parts of your component (all in one namespace)? If so, then
we have a similar problem where the meaning of a name in the presence of a
using-directive is dependent on the set of imported translation units. The
lack of transitive imports helps a little, but it still seems unnatural and
error-prone. A possible improvement:

1. Translation units get bound together into packages
2. A namespace can only be opened within a single package
3. Importing a translation unit is prohibited
4. Importing a package is allowed.

-Dave
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Abrahams wrote:
>
> You're right; I forgot about that. I'd be happy to amend my proposal to allow
> separate compilation.

Just a clarification for onlookers who may be confused: there's no
formal proposal to amend. David is speaking informally about an idea he
has for what C++ should look like in the future. The C++ standard is
finished, and if all goes as we expect it to, it will be ratified, in
its current form and with its current contents, by ISO in 1998. It is
not subject to revision for five years, except for clarifications and
corrections of errors. There is no formal body that is officially
looking at new ideas for C++.
 -- Pete
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]