Re: [boost] Boost.Convert. Take 2.

Subject: Re: [boost] Boost.Convert. Take 2.
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-02-11 05:52:30

Andrzej Krzemienski <akrzemi1 <at> gmail.com> writes:

> 2014-02-10 22:22 GMT+01:00 Vladimir Batov <Vladimir.Batov <at>
constrainttec.com>
> >
> > Again, if there is enough conviction behind the implicit conversion
> > causing havoc, it's no drama to take it out. Will it solve the problem you
> > mention?
> 
> Yes, my opposition is towards the implicit conversion to T rather than to
> returning a wrapper. In fact, I agree with you that a composed type
> "either T or nothing" is a more natural and more desired interface.

OK. To prevent implicit converter haunting me I simply removed that. So, now
it's always "either T or nothing" return type plain and simple.

> >> ...
> > Well, I have to disagree about "unnecessary checks". If one does not 
> > need
> > checks, then boost::lexical_cast will suffice. As for the current
> > implementation, then I consider it a rough draft and an implementation
> > detail which I am not focusing on right now. Your suggestion might well
> > be
> > the ultimate way to go. I think, we need to get the fundamentals right
> > first.
> 
> I am sorry if I did not express my intent clearly. I do agree that the
> feature "check if we have a value and if not: react" is a desired one. The
> statement about "unnecessary runtime overhead" was referring to
> implementation details, but I accept that it is to early to discuss the
> implementation details.

Indeed, I have no doubt that the current first-cut proof-of-the-concept
implementation is crap (pardon my French). :-) When I look at the stuff that
is in Boost and that I expect to be dead simple... gosh... don't I feel
stupid?! We are not there yet... I do not get if we get there... Currently,
I'd like to focus on user-visible part -- the public API. If we settle on
that, we'll be able to improve implementation as much as we like behind the
interface without anyone noticing. :-)

> >  I would like to suggest two things:
> >>
> >> 1. Would it not be possible to have an overload that does not take the
> >> stream object? It would mean we want to use some default char-based stream
> >> with any locale. The newbies would not have to bother with what it is,
> >> when
> >> they only want to convert an int to a string?
> >>
> >
> > In the code I used/required explicit converter. In actual code the
> > converter is defaulted to the one I listed explicitly. Will it suffice?
> 
> I must admit I do not understand this statement. So, let me ask an
> auxiliary question. Will I be able to use the library like this:
> 
>   string s = convert<string>::from(-5).value();

Apologies, typed my previous reply in a hurry and was far from clear. What I
meant to say was that in the code that I posted on git and showed in my
first email I specified the need for an explicit converter to highlight the
orthogonality of the new design. In the actual production code I have the
converter parameter defaulted to that mentioned stream-based converter. So,
there is no need to always specify the converter. That is

 string s = convert<string>::from(-5).value();
 string s = convert<string>::from(-5, "bummer").value();

will pick that mentioned stream-based converter. Now though I am not sure if
that should be the converter to default to. I've added lexical_cast-based
converter and now wondering if that should be the default converter instead.

V.