🚀 go-pugleaf

In <3vq030$8v1@lyman.pppl.gov>, Etay Bogner <ebogner@ird.scitex.com> writes:
>I think that declaring those operators that you don't want to be genereted by the 
>operator templates as private, without definitions would do the job.

You misunderstand...these classes declare all of these as public operators.  The
only restriction is that you CANNOT, for example, define (a <= b) == !(a > b).

Basically, the only problem with STL is that it defines these operators in just
this way to avoid making the user actually define the operators.  But, even if
I did not have the partial order restriction, I often find it is preferrable to
define these myself for greater efficiency.

Now, explicitly defined operators for a class works o.k., but if they are defined
as templates (but NOT the same as the STL definitions) then there is a template
conflict with the STL definitions.  And the only solution is to...

   a) redesign my class library, in the process eliminating many useful classes,

   b) live with the STL definitions -- which are WRONG and therefore will cause
       code to work incorrectly,

   c) simply not use the STL classes -- which is, itself, very useful,

   d) fix STL so that it does not make mathematically invalid assumptions
       "across the board", or

   e) partially disable STL -- however, since the C++ Draft Standard
       says that headers may not be actual host system source files, it
      may not be possible to edit those headers to remove the offending
      definitions, so this approach must be done through a mechanism
      defined in the standard itself.

Michael Lee Finney