Re: [boost] Extensions in Boost.Compatibility

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-12-15 11:38:54

On Thursday 12 December 2002 13:42, Jeremy Maitin-Shepard wrote:
> On Thu, Dec 12, 2002 at 02:54:46PM +0100, Toon Knapen wrote:
> > [snip]
> >
> > My only remaining question is : if the STL (used by the developer)
> > already provides the algorithm (in the std namespace however), would'nt
> > it be better to reuse it. Maybe that algorithm is written in a way to
> > offer the best performance with that compiler ?
>
> I agree there could be performance benefits in using the compiler
> vendor-supplied implementation.  I see several issues with using these
> implementations, however.  First, due to the by-definition
> non-standard nature of extensions, not all compiler vendors implement
> them in exactly the same way, thus making them non-usable. 

Agreed, care must be taken too avoid having incompatibilities between the 
extensions provided by different STL's.  Practically, the most common 
extensions have the same definition in all STL's (e.g. iota). Extensions that 
are still being heavily discussed however (like hash_map), will also heavily 
be discussed before they will be added to boost. So through the discussion 
forum we automatically filter the latter.

> Even in
> the case that a single interface is used by many vendors, by
> immediately assuming that the vendor-supplied implementation should be
> used when such an implementation exists eliminates the possibility of
> imlementating the library with a different interface or more
> functionality.

We're still able to define 'extended' interfaces and provide always a 
implementation for those in boost as with any other function that is not 
provided by the STL being used.

So Herve, what's your position on re-using STL provided algorithms (if they 
are provided). And are you planning to move your work from the boost-sandbox 
to the boost-cvs ?

t