Subject: Re: [boost] boost::algorithm::trim_copy() behaves like "strdup" in normal C, does it allocate a new string ?
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-03-10 11:47:18
On Sat, Mar 10, 2012 at 2:33 PM, Lars Viklund <zao_at_[hidden]> wrote:
> What copy? The current signature is most probably one of the most
> optimal ones, considering that NRVO is a very common optimization to
> elide the copy of the returned value.
> The only benefit you would gain from changing the parameter to be
> by-value is that you could work in-place, but as the Sequence concept
> used doesn't include shrinking from either side, you still need to make
> copy into a fresh return value in order to have something to return.
Right, but it'd save a memory alloc/dealloc.
Sometimes it might even be better to return a 'reference' (like ptr
pair) to even avoid the copy. Might be hard to implement practically
> Or was the 'by-value' a typo for passing by reference to non-const,
> working in-place? If so, you still have the problem of not being able to
> express a truncation in the Sequence concept.
No, it wasn't.
>> > Also, you're using very ancient documentation there, are you really on
>> > 1.34 or just using the wrong documentation?
>> It's still the first hit on google...
> While unfortunate, one should still aim to use documentation that
> matches the version you're attempting to use.
> Ret-conning a note into old documentation indicating that it's not
> current might be beneficial, but considering that there's many
> documentation systems involved in Boost docs, it might not be
> universally feasible.
> There's some limited redirects out there for some doc revisions, but I'm unsure of the exact semantics.
There's still no unversioned link available for the latest docs.
IMO, links should be like B, not A.