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