Boost logo

Boost :

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


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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk