🚀 go-pugleaf

In <407n9d$nb7@lyman.pppl.gov>, Etay Bogner <Etay_Bogner@mail.stil.scitex.com> writes:
>Wouldn't the use of name spaces solve your problem ?
>
>Another overhead is to wait for a compiler which implements namespaces :-).

The main problem is that far too much code will require a "using namespace std;"
along with my class libraries -- and then we get the conflict again.  Alternatively,
either the standard namespace or my namespace or both will have to be explicitly
qualified for ALL uses.  This is a VERY large disadvantage.  You want to be able
to use STL and other features of the C++ library "naturally", so you will almost
always have a "using namespace std;" in effect.

Also, of course, your second point is very true -- I am using the IBM VisualAge++
C++ compiler and they decided to go for other features rather than the latest
draft standard on the latest release due to user requests (only a couple of us
wanted things like RTTI and namespaces as opposed to "direct to som" compiling.
Further, the NT beta of the same compiler will be in process until early next
year, so the odds are that it will be a couple of years before the draft standard
(by then, hopefully the standard) is fully implemented.

I could use other compilers -- but they all have their advantages and
disadvantages.  The Borland OS/2 compiler is a joke -- it hasn't compiled
my code in years without too many compiler bugs to be worth tracking down.
Especially since they almost never release a fix without making it a new 
release.  At least IBM comes out with an accumulative CSD every couple
of months.  There are some others, but most of there are twice as expensive
so I will have to live without RTTI and namespaces.

However, when they ARE implemented, my code will break if the STL
operator templates are not removed.  It could be argued that my code
should be "fixed", but the problem is that the STL code is "wrong" in
that it makes invalid semantic assumptions about those operators.  So
better to speak up now with some slim chance of getting the problem
fixed than be constantly trying to "patch" the compiler header files
(assuming, of course, that they can be edited -- which the standard
does NOT require).

Michael Lee Finney