Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-05 10:56:19

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "Markus Schöpflin" <markus.schoepflin_at_g...>
> > 1. Should it be based on a more general mechanism for replacing the
> built-in standard library?
> Probably yes but I don't know if it's worth the effort.

OK, maybe you're right. There will be (are) other stdlib replacements
but we can generalize later.

> > 2. Shall we arrange things so that you can build both with and
> without
> > stlport, and such that each build goes in a separate subvariant
> directory?
> Yes, and this works already, just say
> TOOLS = msvc msvc-stlport ;
> et voilà, you end up with both variants.

Fabulous! I hope we can get this to work without having to define a
new toolset for every compiler, since STLport is mostly orthogonal to
choice of toolset.

> > Hmm, I'm not sure there are ever any STLPort revisions that
> preserve link
> > compatibility.
> There will be a 4.5.1 which hopefully preserves link compatibility.

Is that just your hope, or is it based on some real evidence? I ask
because I have contributed lots of code to STLport, and I'm not aware
of Boris ever holding up a feature because of link compatibility
concerns. In fact, since most code is in headers, there's almost
nothing you can do that won't potentially break the ODR.

> > For the most part, stl_user_config is no longer supported, IIRC. I
> think the
> > only thing worth supporting (and even this is arguable, since it
> doesn't
> > really work well) is STLP_NO_IOSTREAMS. But maybe I've overlooked
> something?
> Really? doesn't mention
> this and the fact that those macros are well documented makes me
> belief differently.

I suggest you ask Boris. I am speaking from memory of a conversation
he and I had a few years ago.


Boost list run by bdawes at, gregod at, cpdaniel at, john at