$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Martin (adrianm_at_[hidden])
Date: 2005-12-22 07:36:34
> - I don't think it is necessary for bitfield operator>> to handle multiple
> > entries. It can be added on top by the caller if necessary. It should
> > allow
> > numeric input though.
>
> Hmm, I'm really trying to free the user from having to write extra code.
> Would it really hurt anything if the user could specify the delimiters or
> could enable/disable this functionality? It obviously isn't written yet, so
> I could just be lazy and leave it as you suggest.
The problem is that the stream doesn't carry around a separator field. It is
hardcoded to use isspace() characters. To allow the user to specify the
separator you need to add a custom stream manipulator or a locale facet (facet
is preferred since you can then apply it globally but it is much harder to
use). If you go for a stream manipulator your library will not be header only
anymore since you need to allocate storage for xalloc()
I forgot one thing in my last post. Don't forget to add BOOST_WENUM for
wchar_t strings.
A side note: I once started to write a proposal to add a "int_type" separator
field to ios_base but never finished it. It would work like this:
cout >> 1 >> separator >> 2 >> setseparator(';') >> separator >> 3;
output is: 1 2;3
cin >> setseparator(',') >> string1 >> separator >> int1
parses a comma separated file.
The default would be traits::eof which would mean isspace() so existing code
would still work. Only change in the standard library (outside ios_base) would
be operator>> for strings.
Once a separator is in ios_base it would be easy to add streaming of
containers, tuples etc and replace the broken complex type streaming.