Fwd: Re: [libstdc++-v3] Remove std::construct and std::destroy

[Stephen M. Webb <stephen at bregmasoft dot com>]

On Tue, 03 Jul 2001, Benjamin Kosnik wrote:
> Note this discussion is only relevant for the trunk, not branch.
> 
> Ok, to sum up this thread, I think it's ok to move deprecated/old bits to 
> backward headers, but not remove them entirely from the library. In 
> addition, deprecated features and constructs should not be used 
> internally in the library.
> 
> Stephen, does this make it clear what the course of action should be?

Yes and no. 

My construct/destroy patch did exactly what was described, as will the patch
I have in the pipe (removing value_type() and distance_type()).  The HP names
continue to be available through the backward headers.  The do not appear in
namespace std any more, but the SGI web pages document them as being in the
global namespace, so that should be okay.

I figure it's okay to remove any internal library names, since user code that
relies on such names is already broken.

Here's the no part.

What should be done with parts of the library that match the SGI web pages but
don't match the standard, and relegating the original SGI implementation to
backwards headers is not really a viable solution?  For example, the rotate()
algorithm returns void in the standard, and a forward iterator in the SGI
implementation.  While the return value can be ignored, the SGI version doesn't
conform (and returning the result wastes all those CPU cycles).  Making the
library conform might break some existing programs that rely on this behaviour.
The only reasonable solution is to provide a compile-time switch to invoke the
SGI behaviour, but that will make the code ugly and less readable

So, in summary,  nonstandard names can be removed from std, and should remain
available through the backward headers.  Behaviour should be according to the
standard, but alternate (documented SGI) behaviour should be available through a
compile time switch.

So if a compile time switch is there to conjure nonstandard SGI behaviour,
should it not also conjure the HP names?

I didn't know I was opening a can of worms with this.  I'm glad I didn't
mention the knife.

-- 

Stephen M. Webb
stephen at bregmasoft dot com