|
Boost : |
Subject: Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
From: dherring_at_[hidden]
Date: 2008-09-04 13:51:15
On Thu, 4 Sep 2008, Sebastian Redl wrote:
> David Abrahams wrote:
>> on Thu Sep 04 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>>> 2008/9/4 Sebastian Redl <sebastian.redl_at_[hidden]>:
>>>> Jurko Gospodneti? wrote:
>>>>
>>>>> First some collected background information related to Microsoft's
>>>>> checked & debugging iterator support to get a clearer image of what we are
>>>>> modeling. And could someone please collect a similar summary for other
>>>>> compilers/libraries?
>>>>>
>>>> Just a quick note: GCC's scheme works thus:
>>>>
>>>> 1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
>>>> 2) These containers lie in the std::__debug namespace. To actually use them,
...
>>>> It is therefore an explicit choice by the programmer to use those
>>>> containers, for every individual usage. No switching in the build system is
>>>> necessary or even possible.
...
> You're right, sorry. There's a strong using statement importing the
> entire debug namespace in debug mode.
Would it be possible to do something like this in boost?
For header-only libraries, the right preprocessor macros would control
which iterators to use -- nothing needs to change. (?)
For other libraries, bjam would compile the sources multiple times, using
preprocessor macros to put checked iterators and other variants in
boost::__variant_xyz namespaces and linking them all together into a
single library. Then the macros selected by the user's code would control
which symbols are used out of this library.
Such a system would have the benefit that users could link against other
libraries which use boost without having to arrange that they all use the
same build variant.
Properly initializing/using singletons in the presence of multiple
variants could be difficult...
- Daniel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk