> The C++ standard states two requirements for c_str():
> "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 after any subsequent call to
> a non-const member function" Thus the implementation
> may release the contiguous buffer it allocated the next
> time the user attempts to alter the string.
The c_str() interface does not allow for enforced locking (it hands off a
handle to internal data). Therefore, should a segmented storage version of
std::string be designed, thread safety would require a large temporary
scratchpad buffer for each thread in the system that touches std::string
(accessed using thread private storage system calls of course).
> It is possible to design a full implementation of C++ std::string
> that uses segmented memory.
I was aware of this, and the above subtleties, but I don't know if anyone
has actually created an open source std::string that does allow segmented
memory. I also don't know how easy it would be to slice out the default
std::string and replace it with an alternative implementation (std::string
is used by many things in the standard library).
CA has an additional requirement. It must create an implementation of a
string interface and assign segments of its non-contiguous protocol buffers
as the storage. The problem with most implementations of std::string is that
as soon as we copy in a string it calls "new". I am trying to avoid calling
"new" every single time that we execute a request (we don't today). Requests
can occur with a very high frequency, and the overhead for "new" would
definitely be a large (overwhelming) percentage of the overhead for
dispatching a request.
Jeff
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, July 18, 2005 11:55 AM
> To: Kay-Uwe Kasemir
> Cc: EPICS Core Talk
> Subject: Re: [Fwd: RE: Standard String]
>
> Kay-Uwe Kasemir wrote:
> >
> > but I still don't see a way around contiguous char * strings,
> > because that's what most 'legacy' libraries want.
> >
> > You can add that as a layer around the next EPICS String class
> > and copy char by char from the non-contig. String into a char *,
> > but std::string and MFC::CString instead bite the bullet
> > and provide a c_str() type of method.
>
> In our EpicsString design, we solved this requirement by including a
> buffer type that stores contiguous zero-terminated data (the other
> buffer types don't have to guarantee a zero terminator). If you need to
> pass a string to an external library then you can create one of these
> and copy the string to it, or just use that buffer type in the first
> place if it's your string and you're not concerned about reallocating
> memory if it ever needs to be extended.
>
> It is possible to design a full implementation of C++ std::string that
> uses segmented memory. The assumption is that c_str() would rarely be
> used, but when it is the implementation just allocates a contiguous
> buffer and copies the segmented string into it. The C++ standard states
> two requirements for c_str(): "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 after any subsequent call to a non-const member
> function" Thus the implementation may release the contiguous buffer it
> allocated the next time the user attempts to alter the string.
>
> I am not advocating that we use this approach in our string class, just
> illustrating that the C++ standards writers saw that they had to provide
> a char* accessor method for interfacing to legacy systems.
>
> - Andrew
> --
> Podiabombastic: The tendency to shoot oneself in the foot.
- References:
- Re: [Fwd: RE: Standard String] Andrew Johnson
- Navigate by Date:
- Prev:
Re: [Fwd: RE: Standard String] Andrew Johnson
- Next:
RE: Standard String 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
- Navigate by Thread:
- Prev:
Re: [Fwd: RE: Standard String] Andrew Johnson
- Next:
[Fwd: Re: Standard String] Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|