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
>> 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
>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk