Re: [boost] Ann: Floating Point Utilities Review starts today

From: Johan Råde (rade_at_[hidden])
Date: 2008-02-28 04:40:53

John Maddock wrote:
>>> 2) I'm not completely sure about the "legacy" flag: shouldn't the
>>> facet just read in everything that it recognises by default?  Or
>>> maybe we should flip the meanings and "legacy" should become
>>> "strict_read" or "nolegacy" or something - I'm not that keen on
>>> those names, but Boosters can usually come up with something snappy
>>> when asked :-)
>> There are cases where the legacy flag could change the meaning of a
>> file.
>> For instance, if you set the legacy flag, and parse the string "1#2",
>> then "1#" will be interpreted as the beginning of "1#INF" or some
>> other Visual Studio nonsense. Once the parser gets to '2', it will
>> realize its mistake,
>> but when you read using stream iterators it is impossible to
>> backtrack,
>> so the parser will set the failbit of the stream.
>>
>> So the legacy flag can be a little dangerous.
>> This should of course be pointed out in the docs.
> 
> Ah, I see, in that case it's probably best to leave as is, and add an 
> "admonishment" to the docs to point this out.

One could have support for reading "qnan", "nanq", "snan" and "nans" as default.
(The scenarios where that could change the meaning of a valid file are extremely contrived.)
And have a flag for enabling reading of the Visual Studio nonsense.

> The problem as you correctly point out is with DLL's: I'm fairly sure that 
> on Unix (or Linux anyway) the shared library loader will resolve duplicate 
> symbols so that just one is active in the program - that way only one 
> instance of iostream_data<dummy> will be active and everything should work 
> OK.  On Windows though you could end up with separate instances of 
> iostream_data<dummy> in each dll, which would be bad news if you expect to 
> pass iostreams between them :-(  The only - somewhat inelegant - solution I 
> can think of is to define a pair of macros to import/export 
> iostream_data<dummy> so users can control it's instantiation.

How do other Boost libraries handle this problem?

--Johan