Re: [boost] hex/unhex()?

Subject: Re: [boost] hex/unhex()?
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-06-19 10:22:54

On Mon, Jun 11, 2012 at 4:06 PM, Olaf van der Spek <ml_at_[hidden]> wrote:
> On Sun, Jun 3, 2012 at 7:20 PM, Marshall Clow <mclow.lists_at_[hidden]> wrote:
>>>> They don't have to be equal.
>>>>        std::string s;
>>>>        hex ( <range>, std::back_inserter (s));
>>>
>>> But that's not as convenient as the normal function which returns the string.
>>
>> Indeed.
>
> Could you return a reference to the string to support chaining?
>
>> My goal is not to provide every possible convenience function; the goal is to provide a functionality that can be used in a wide variety of circumstances.
>
> I think reference/view types like range<char*> and string_ref deserve
> direct support.
> This applies to all string functions, not just hex and unhex.
>
> Isn't it possible to have two template parameters Out and In where In
> is deduced and Out defaults to In?
>
>>> It's also missing reserve().
>>
>> reserve is not appropriate in this case; since in general, the size of the input range cannot be determined easily.
>
> Lots of ranges have a known size. You could restrict support to such ranges.
>
>> For a null terminated string, you would have to traverse the input twice; once to determine the length, and the other to do the conversion.
>> That might be advantageous (or not); but consider in the case where the input range is a pair of input iterators.
>
> In that case the size can't be determined beforehand.
>
>>> Should hex output be upper case or lower case? c++0x suggests lower case. :p
>>
>> MySQL (and inertia) suggest upper case; note that unhex will accept both.
>
> I think a parameter should be provided to choose between the two.
>
> Not providing a variant that doesn't throw on bad input is problematic
> too (IMO). A non-throwing variant should be available. A throwing
> variant can then be build on top of it.
>
> BTW, shouldn't hex be in the string directory?

^

-- 
Olaf