|
Boost : |
Subject: Re: [boost] boost::algorithm::trim_copy() behaves like "strdup" in normal C, does it allocate a new string ?
From: Lars Viklund (zao_at_[hidden])
Date: 2012-03-10 06:19:13
On Fri, Mar 09, 2012 at 07:14:24PM +0100, g.fanini_at_[hidden] wrote:
> Could I ask for a clarification whether boost::algorithm::trim_copy()
> behaves like "strdup" in normal C, i.e. does it allocate a new string ? or
> does it modify the passed string without allocating a new string ?
As the parameter is const, it cannot cast the const away to mutate it
unless it knows things about the argument at the call site, which it
cannot know.
> It is not entirely clear from the documentation :
> http://www.boost.org/doc/libs/1_34_0/doc/html/boost/algorithm/trim_copy.html Because the argument passed has the modifier "const" I am led to believe it would leave the passed string unchanged, and return a newly allocated string. Possibly would you consider kindly updating the documentation reflecting the returned string is newly allocated.I am asking this becauseI am trying to work with preexisting boost code which uses boost::algorithm::trim_copy() profusely and I have severe leakage problems.Thank you for any information.
It makes a new sequence of the same type that the argument has.
Assuming that the type of the argument is a correctly implemented
sequence, there are no leaks.
As the function is not callable with either char const* nor
char const[], there is no possiblity to deal with raw strings in any way
at all.
If you pass in a std::string, you get a regular std::string out. If you
pass in a custom sequence type, you get a new such type returned. There
is no dynamic allocation unless your sequence type does this internally.
Also, you're using very ancient documentation there, are you really on
1.34 or just using the wrong documentation?
Any leaks you have are most probably from some other source. The only
way trim_copy can "leak" is if your sequence type is broken.
-- Lars Viklund | zao_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk