Re: [boost] boost::string namespace and string-conversion functions

Subject: Re: [boost] boost::string namespace and string-conversion functions
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-14 06:25:57

Scott,

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[1] 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
> submission".

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 
lexical_cast does)?

> 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
> effort.

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
or
    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

[snip]

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 
weeks.

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).

V.