boost::algorithm::trim_copy() behaves like "strdup" in normal C, does it allocate a new string ?
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 ? 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.
Hi, "trim_copy", like other string algos, returns by value, it can't leak. The returned object is a different object allocated on the stack, it will destroyed when it goes out of stack. regards, Julien
On Fri, Mar 09, 2012 at 07:14:24PM +0100, g.fanini@gmail.com 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@acc.umu.se
On Sat, Mar 10, 2012 at 12:19 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Fri, Mar 09, 2012 at 07:14:24PM +0100, g.fanini@gmail.com 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.
Hmm, wouldn't a by-value parameter allow one to avoid the copy?
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... -- Olaf
On Sat, Mar 10, 2012 at 01:58:22PM +0100, Olaf van der Spek wrote:
On Sat, Mar 10, 2012 at 12:19 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Fri, Mar 09, 2012 at 07:14:24PM +0100, g.fanini@gmail.com 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.
Hmm, wouldn't a by-value parameter allow one to avoid the copy?
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. 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.
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. -- Lars Viklund | zao@acc.umu.se
On Sat, Mar 10, 2012 at 2:33 PM, Lars Viklund <zao@acc.umu.se> 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 though.
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. A: http://www.boost.org/doc/libs/1_49_0/doc/html/accumulators.html B: http://www.boost.org/doc/accumulators
On 10 March 2012 16:47, Olaf van der Spek <ml@vdspek.org> wrote:
There's still no unversioned link available for the latest docs.
IMO, links should be like B, not A.
A: http://www.boost.org/doc/libs/1_49_0/doc/html/accumulators.html B: http://www.boost.org/doc/accumulators
On Sat, Mar 10, 2012 at 7:12 PM, Daniel James <dnljms@gmail.com> wrote:
On 10 March 2012 16:47, Olaf van der Spek <ml@vdspek.org> wrote:
There's still no unversioned link available for the latest docs.
IMO, links should be like B, not A.
A: http://www.boost.org/doc/libs/1_49_0/doc/html/accumulators.html B: http://www.boost.org/doc/accumulators
That's a forwarder. If a user copies a link from the address bar, it will be A, not B. Hence, not really relevant. -- Olaf
On 10 March 2012 13:58, Olaf van der Spek <ml@vdspek.org> wrote:
On Sat, Mar 10, 2012 at 12:19 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Fri, Mar 09, 2012 at 07:14:24PM +0100, g.fanini@gmail.com 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.
Hmm, wouldn't a by-value parameter allow one to avoid the copy?
Have a look at http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/.
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...
-- Olaf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jeroen
I found the leaks were elsewhere, nothing to do with trim_copy, it seem to me from you explanations that this sort of invocation : std::string s; trim_copy(s); is equivalent to doing : string(s); i.e. it is allocated on the stack and is automatically deallocated when going out of scope <g.fanini@gmail.com> ha scritto nel messaggio news:0D047ED74D81417AA3AB1834F4ED4254@onetech2...
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 ? 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Daniel James -
g.fanini＠gmail.com -
gf
-
Jeroen Habraken -
Julien Nitard -
Lars Viklund -
Olaf van der Spek