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: [Fwd: RE: Standard String]
From: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>, "'Kay-Uwe Kasemir'" <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Mon, 18 Jul 2005 12:25:09 -0600
> 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  <20052006  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  <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 ·