Re: [boost] BOSOT_ENUM proposal rev 4

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.