Experimental Physics and Industrial Control System
|
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
<2005>
2006
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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|