Redirected to comp.lang.c++ (for consistency with "Worth of operators").

In article <KANZE.94Aug2194919@slsvhdt.us-es.sel.de>,
James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> wrote:
>[...]
>In addition, neither of them really do the job one would expect.
>Namespaces don't begin to solve the problem of the library vendor who
>has "#define list" in his header files.  (Quality library vendors like
>Rogue Wave and Booch have already solved this problem, without
>namespaces.)  A real solution would require modules.  But that would,
>in turn, delay the standard more than could be tolerated.
>[...]
>On the other hand, both proposals *do* go far enough to create real
>problems in the core language (type system, name lookup, etc.), and
>thus, to create a significant delay in the standard.
>
>My own position is that we should probably have saved these proposals
>for a future version of the standard (when there would have been more
>time to do them right), and gotten the current version out quicker
>without them.

Whoa there, the problem library vendors have with ``#define list'' in
their header is just that -- having #define list in their header.
There might be other good reasons for a real module system (eg, global
construction order), but please don't use preprocessor macros as an
example, lest library vendors start thinking they should be liberally
using them.

I just realized that you probably mean that "list" is the macro used
in a #ifndef guard.  Yes, macros are necessary for header guards and
namespaces don't cover the preprocessor.  But, I wouldn't consider
this failing a flaw in *namespaces* beause I don't think macros (other
than #ifndef guards) are something to be encouraged in general C++
programming.  A module system replacing #include would be great, but
changing namespaces just because of the widespread #include hack is
not.  The solution to the #ifndef guard problem is easy -- use the
macro VENDOR_LIST_H.  While you're at it, make sure your library
headers are in a separate directory so that users have to do #include
<vendor/list.h>.  Macro name clashes won't cause much trouble compared
to header file name clashes ;-).

You said some library vendors have already solved the name space
problem.  Do you mean they prefix all their global names with a
three-letter prefix?  Well, as D&E 17.2.1 discusses, they are quite
ugly and unpleasant to use (for both the library writer and user), and
three-letter abbreviations have a tendancy to clash.  I personally
think namespaces are a major advantage to large software projects, in
spite of, or maybe because of ;-), their lack of support for macros.

D&E also presents a very interesting technique for managing library
releases by putting older versions in a separate name space, giving
library users more flexibility to decide when to update their source
code and how much of it to update.  Note: I have no idea how well this
technique would work in practice.

Jamshid Afshar
jamshid@ses.com