Subject: Re: [boost] Boost.Convert. Take 2.
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-02-11 02:24:55
2014-02-10 22:22 GMT+01:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>
> Andrzej, thank you for your input. It's much appreciated. Please find my
> replies below.
> On 02/11/2014 05:12 AM, Andrzej Krzemienski wrote:
> Also, I am likely to select an incorrect function overload, if I pass the
>> result to the function template.
> 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
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.
> Second thing that bothers me is that for the result type to be able to
>> offer all these checks an otherwise unnecessary runtime overhead is
>> imposed. 'result' stores both optional<T> and a flag indicating how to
>> with the lack of value. since, in order to write into T you need to
>> default-construct it anyway (or move construct it), it looks it should be
>> enough to have 'result' contain a non-optional T and more sophisticated
>> flag that also stores the information about having a real T.
> 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
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
> 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,
>> 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();