Subject: Re: [boost] boost::string namespace and string-conversion functions
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-14 06:25:57
Thank you for your reply. Much appreciated. I was looking forward to that
and you did not disappointed (on many levels) :-\.
> To answer a rhetorical question with a rhetorical question, does it
> lift someones spirits to hear "Well, 5 people didn't explicitly
> reiterate your concern, so it must not be important"?
OK, you shot back at me with *your* rhetorical question. Can we leave it at
that so that we can get to the technical side of things? Is it OK with you?
> A dozen-email exchange without a response from the thread author does
> not "People largely seem content [so] we are settling on
> boost::string" imply. It would have been easy to use "I'll stick
> with" instead of "we are settling on" to sound less domineering.
Yes, that'd have been easier if English was my native or I could borrow your
head. "domineering"... aren't you reading too much into it? It is easy to
forget that for a tiny minority of people English has not become native yet
and, consequently, they tend to miss subtleties of the language. How 'bout
you write a few words in Russian and we'll discuss it? I am sure you'll make
a generous bunch of grammatical, linguistic, colloquial and cultural
mistakes that I'll use to compile you character profile. It'll be fun.
> It feels like you would like my comments on the thread, so I'll
> provide that. I didn't earlier as my objection was to form rather
> than technical aspects. Apologies if I re-tread ground unnecessarily.
Yes, I indeed found the technical part of your email very informative and I
appreciate you sharing your thoughts on that (the technical part that is).
> - Process
>>From the start, this thread has irked me, as including "review
> request" in the subject seems to flout the normal submission
> process for no apparent reason.
"Flout", "domineering"... Do you think there is anything good still left in
me? I'd probably better leave the group and go out to do my real evil things
in the real evil world. Still, you are irked. So, this contemptuous,
domineering me apologizes.
As for the process, yes, it is unlikely I am following any particular
process as I got to where I am mostly by accident. I was only hoping to get
lexical_cast extended with default values (and no default-constructibility
requirement) as I wanted something "standard" and lexical_cast seemed good
for it and seemed to do almost all I needed. That turned out to be
problematic with the author and the maintainer. So, there was a suggestion I
go ahead and do it myself without looking at lexical_cast.
> You've mentioned having used a
> similar component many times, yet provided no "Preliminary
Yes, I consider nailing the interface an important step but more importantly
I wanted to hear views like yours if there was a point/need of doing it at
all. You obviously got irked I used the "review request" title. I did not
know you were so sensitive to that. I'll use it sparingly from now on.
> You appear to be holding the "Discuss, refine, resubmit.
> Repeat until satisfied" processes after the formal request, instead of
> before. One or the other could be "not as conventional", but both
> seems excessive.
Seems like no matter which way I go it turns out excessive. I seem to be
such an excessive guy all of a sudden. :-)
> - Concept
> My recollection is that lexical_cast was fine (or at least mostly
> acceptable) for conversion to strings, but conversion from strings was
> a much harder problem.
It was not my reading. I considered to/from to be pretty symmetric with,
say, formatting applied both ways, and the default values (people seem to
want it even if I personally did not use/need the to-string default).
> Boost already has a library for that problem:
> Spirit. With Spirit2, in fact, my understanding is that it has a
> consistent way to both directions as well. (Arguably serialization
> does as well, but there any parsing is an implementation detail.)
I am glad you brought it up. Something along these lines was nagging me as I
was using boost::serialization for ultimately conversion to/from XML (i.e.
string) and Hartmut mentioned Spirit capable of doing conversions. So, I was
wondering if that my noise about conversion was not mis-guided. I played
with Spirit (the parser part) only a little bit. I only managed to write a
half-a-page parsing grammar just to happily replace it with a two-liner
regular expression. Never looked back.
Could you show how to convert int-to-string-to-int with Spirit? Can we apply
hex/scientific/etc. formatting? Does it deal with user types (as
> This makes it feel like the problem is already mostly solved, if in
> greater detail than this library actually calls for.
Solved? That sounds very exciting and what I was hoping for. Again, could
you jog a few lines how it's done? It'd be appreciated. It'd give me a
kick-start what to look for in the Spirit documentation.
> That makes me
> think of another similar library, Bimap. Matias could have invented
> and implemented his own way of doing it, which may have provided the
> base functionality more quickly, but instead built on MultiIndex,
> ultimately getting a much more flexible library with less duplicated
I am not eager to waste my time doing something already available. I am
sorry for being obtuse. Can I see a snippet how to do that? Then, I'll drop
causing all that noise.
> The proposed library is essentially a very simple lexer and
> pretty-printer, so it feels like the right way to build it is using
> Spirit2 components in such a way that gradually increasing complexity
> in the conversions provide a path to something that could be extracted
> and used in a full spirit grammar, should requirements eventually
> surpass what the helper library provides. (Orders that progress from
> simple numeric IDs up to, many iterations later, a full DSL.)
That sits very well with me.
> Unfortunately, I don't know enough about spirit2 to provide an outline
> of how this might look.
Oh, bummer. So, no code in the end? Can anyone jump in and show us how to
convert things with Spirit? Is it as inclusive as lexical_cast? I am really
looking for someone to show me the right way. I could not apply Spirit to
conversions I needed from the Spirit docs.
> Perhaps it would be a good idea to step back and decide on the
> boundaries for the functionality first. So far all I can tell is
> "string conversions allowing default values on failure and not needing
> default constructors". Does it allow formatting? Is this just for
> scalars? If it's for more, can I give different formatting for
> different elements of containers or structures? Where's the line
> where it gives up and says "use spirit"? Some major implementation
> issues will effect the interface, such as the choice of piggy-backing
> off operator<< or using a different method, so that's also important.
The way we seemed to be heading (apart from the names) was
string str = aux::string::from(-1, "0") >> std::hex;
int i = aux::string::to(str, -1) >> std::hex;
// Do not care to check the failure
aux::string::value<string> s = aux::string::from(-1) >> std::hex;
aux::string::value<int> i = aux::string::to(str, -1) >> std::hex;
if (s.good()) conversion successful
if (i.good()) conversion successful
Later that'd be extended to locales still following the same interface. Like
string str = aux::string::from(false) >> some-how-stick-locale-here;
> - Names
Yep, I got it -- you do not like "to/from" either. Did I get this right? (I
seem to misinterpret things lately). ;-\
'is' seems not needed with the interface above. So, at least we won't be
arguing about it.
> I think thats enough from me for now,
Yep, I think I've had just about enough of that stress as well. Off to
fishing. I guess I'll read your thoughtful and considerate reply in two
Then, I'll upload my implementation to the Vault to actually take it for a
spin who interested... unless we figure out how Spirit does it for us. I'd
really and honestly like to see it (too thick to figure it out myself).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk