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

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

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

>
>
>  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();

Regards,
&rzej