EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: memory management
From: Andrew Johnson <[email protected]>
To: Benjamin Franksen <[email protected]>
Cc: Jeff Hill <[email protected]>, 'Eric Norum' <[email protected]>, 'Ralph Lange' <[email protected]>, 'Matej Sekoranja' <[email protected]>, 'Marty Kraimer' <[email protected]>, 'Ken Evans' <[email protected]>, 'Bob Dalesio' <[email protected]>, "'Kasemir, Kay'" <[email protected]>
Date: Tue, 01 Mar 2005 19:45:09 -0600
Benjamin Franksen wrote:
On Tuesday 01 March 2005 17:30, Jeff Hill wrote:

This c_str() function appears to be in mainstream use.
...
The idea is, of course, that memory for the C string would be allocated as soon as c_str is called, not earlier, and that the user code is responsible for freeing that memory.

The ISO/IEC C++ standard says about the standard c_str() function (section 21.3.6):


const charT* c_str() const;

Returns: A pointer to the initial element of an array of length size()+1 whose first size() elements equal the corresponding elements of the string controlled by *this and whose last element is a null character specified by charT().

Requires: The program shall not alter any of the values stored in the array. Nor shall the program treat the returned value as a valid pointer value after any subsequent call to a non-const member function of the class basic_string that designates the same object as this.


This means that the user code is *not* responsible for freeing the memory, but the string library may do so itself when the next string function is called that could change that string. Sorry if that was obvious, I just wanted to clarify the position.

There *are* implementations of the C++ std::string API that use non-contiguous blocks; the original SGI template library contains an extension called rope<T, Alloc> which implements such a thing - see http://www.sgi.com/tech/stl/Rope.html for details.

I also found this comparison of string libraries which might be interesting - there are lots of possibilities out there already...
http://www.and.org/vstr/comparison.html

BTW: Functions like c_str are also a real problem from a thread
safe interface perspective.

Why?

Jeff's point here is probably that sharing a string between two threads makes it impossible to know how long the c_str() data will be valid for, as the other thread may come in and modify the string before I've had a chance to actually look at it. The string couldn't itself keep an internal semaphore to protect the data because it must remain valid after the c_str() routine has returned, so the threads would have to implement that protection between themselves in higher level user code. Personally I think that should be the case anyway as any semaphore kept inside the string would probably slow down its operations signficantly. However that does make implementing database gets of a record's string fields an interesting prospect...

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro



Replies:
RE: memory management Jeff Hill
string implementations (was: memory management) Benjamin Franksen
References:
RE: memory management Jeff Hill
Re: memory management Benjamin Franksen

Navigate by Date:
Prev: Re: memory management Benjamin Franksen
Next: Re: memory management Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: memory management Benjamin Franksen
Next: RE: memory management Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·