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.