🚀 go-pugleaf

In <DD1oF2.AA1@research.att.com>, ark@research.att.com (Andrew Koenig) writes:
>In article <409bjt$59c@mujibur.inmind.com> mfinney@inmind.com writes:
>
>> 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.
>
>Why do you think so?

Like most people, I use parts of the standard library fairly heavily -- especially
the string manipulation functions, iostreams -- and hopefully soon STL.  This
means that virtually all of my source code contains one or more library headers
and the usual practice there, to match existing code, will be to have a
"using namespace std" present.  However, my own class library is extremely
extensive and is ALSO used very heavily.  Again, constant qualification will be
very annoying so that namespace will also be included.  Of course, normally
there are no conflicts between the namespaces, so there is no problem.

However, if STL is used (or is dragged in by another header, which is just fine
with me) then the definitions of these operators will cause a conflict.  I have
global template definitions of operators ==, != , <. <=, > and >= which map to,
respectively, x.isEqual(y), x.isNotEqual(y), etc..  Each class is free to implement
the underlying methods as inline functions and, where appropriate, make the
same type of short-cuts that STL makes.  In polymorphic classes, these are
usually virtual methods as well.  However, classes such as PartialOrder does
NOT (and should not) make such short-cuts because they are not mathematically
valid.  Since STL also defines these as global templates to avoid the necessity of
the user defining the operators, the STL definition conflicts with my definition.

So, if I am going to use the standard library and my library, both in the global
namespace -- which is the normal usage, the STL usage causes problems.

Michael Lee Finney