Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-24 09:20:26

On Mon, Jan 24, 2011 at 9:51 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>> On Mon, Jan 24, 2011 at 7:50 PM, Artyom <artyomtnk_at_[hidden]> wrote:
>> >> From: Dave Abrahams <dave_at_[hidden]>
>>
>> >> Who says we need a  c_str()?
>> >
>> > Almost everybody who uses any kind of API that does not has
>> > direct uses of this string and this is as almost every API
>> > around...
>>
>> Right, but what's keeping that person from creating an std::string
>> from this hypothetical `boost::string` if they really need a c_str()?
>
> Do you mean besides poorer performance and greater complexity of use?
>

Sure, but a conversion operator implemented by the hypothetical
boost::string should suffice no? For interfaces that take an
std::string, that'd be all you need really. For those that need a
c_str(), then I guess it's the price you pay for a crazy efficient
string that you can use in the innards of your application and just
pay for the cost of when you just need a c_str(). :D

Of course I'm half-joking there, but I think that's a reasonable price
to pay I think much like how everyone is just dealing with the fact
that you absolutely have to at some point just linearize your data
structures into a void* for it to be sent through network APIs that
take a void* and a size. Maybe people want to have zero-copy APIs but
even Linux doesn't provide that API just yet at least to the
user-space applications so I don't see why having just an extra string
copy to an std::string would be a big deal.

-- 
Dean Michael Berris
about.me/deanberris