Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Convert library, last day
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-04 13:11:25

On 5/4/2011 4:23 AM, John Bytheway wrote:
> On 03/05/11 21:28, Matthew Chambers wrote:
> <snip>
>> I use an optional header that defines lexical_cast string->numeric
>> specializations using strto[ld]. Is this at risk for ODR violations? I
>> use it widely but I'm not at all careful about making sure it's included
>> everywhere. Yet I haven't had any ODR violations on GCC or MSVC. Unless
>> that's pure luck, I'd like to know how the optional specializations are
>> ODR violations.
[...snip simple and effective explanation...]
> $ g++ -o odr main.cpp f.cpp g.cpp
> $ ./odr
> <i at 0x7fff0d49ef8c>
> <i at 0x7fff0d49ef8c>
> $ g++ -o odr main.cpp g.cpp f.cpp
> $ ./odr
> int(0)
> int(0)
> It does different things according the the order in which I pass the
> source files on the command line. This is because the two (different)
> definitions of print<int> are being merged into one.
> There may or may not be a second ODR violation because of the two
> different definitions of print_helper<int>. My standard-ese is
> insufficient to figure out whether this is a violation or not.
> But even this first problem could clearly arise if e.g. library A which
> uses Boost.Convert in a template function to perform a conversion which
> is specialised by library B which depends on library A. This is very
> difficult to detect and avoid.

You make me cry sir. I'll file this under "ways that C++ assists your process to commit suicide".
Cross-referenced with "ways that C++ causes programmer neuroses."

I agree that boost shouldn't provide optional template specializations. So in a single binary, only
one definition for lexical_cast<int, string> is allowed? Through "luck" it seems my optimized
specializations have been overriding the stringstream ones, but it makes me cringe now. Maybe it
even causes some mysterious crashes I've had in my C++/CLI bindings.


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