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: Jeff Hill <[email protected]>
To: [email protected]
Cc: 'Eric Norum' <[email protected]>, 'Ralph Lange' <[email protected]>, 'Matej Sekoranja' <[email protected]>, 'Marty Kraimer' <[email protected]>, 'Andrew Johnson' <[email protected]>, 'Ken Evans' <[email protected]>, 'Bob Dalesio' <[email protected]>, "'Kasemir, Kay'" <[email protected]>
Date: Tue, 01 Mar 2005 09:30:08 -0700

> Just because many implementations of std::string implement 
> c_str in this 
> way doesn't mean it /must/ be implemented this way. An
alternative 
> implementation of std::string, based on fixed-sized
non-contiguous 
> blocks of memory, would need to allocate a new standard
c-string 
> (contiguous), copy the data to it, and pass that as the result
of 
> c_str.
>
> Of course, such an implementation of c_str is a lot less
efficient

This c_str() function appears to be in mainstream use. 

Therefore, my conclusion has been that it will be very unlikely
that an implemtation will exist with storage for non-contiguous
fixed sized blocks and also storage for a continuous block that
is a copy of what is in the non-contiguous blocks. This would of
course double memory requirments and negate any benefits derived
from bothering with non-contiguous fixed sized blocks in the
first place.

> /Any/ implementation of strings based on non-contiguous blocks 
> will encounter the same problem, if it wants to provide a
routine 
> to interface with routines that expect a contiguous
null-terminated 
> C string.

Yes, and therefore an interface allowing non-contiguous
implementations can not include such a function. A better
alternative would be a function that copies the string to a user
supplied contiguous buffer. 

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

PS: When working on data access I also considered the idea of
interfacing to different string implementations using a string
class plug in for the standard stream buffer interface. However,
I noticed that when a standard stream is created most
implementations internally call malloc to set up the locale and
other stuff. Considering that data access based interfaces to
stings must be created and destroyed bracketing high throughput
CA requests, then this call to malloc could cause significant
efficency issues. I could of course keep a standard stream in a
cache, and retarget it to a new string with each request, but
this appeared to be a real mess. Eventually I decided that use of
the standard stream buffer interface for interfacing with
different string implementations should not be required.

Note however that the pure virtual string interface in data
access exists to provide us options. We may use almost any string
implementation we would like. This includes standard library
strings and standard library streams should they be found to be
suitable for a particular application.

Jeff


> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]] 
> Sent: Tuesday, March 01, 2005 3:41 AM
> To: Jeff Hill
> Cc: 'Eric Norum'; 'Ralph Lange'; 'Matej Sekoranja'; 'Marty 
> Kraimer'; 'Andrew Johnson'; 'Ken Evans'; 'Bob Dalesio';
'Kasemir, Kay'
> Subject: Re: memory management
> 
> 
> On Tuesday 01 March 2005 02:10, Jeff Hill wrote:
> > > Jeff, could you please explain why the interface of
> > > std::string is not
> > > compatible with such implementations?
> >
> > One of the OO convential wisdoms is to never implement an
> > interface that passes off handles to an internal data
structure.
> > See Item 29 in "Effective C++ 2nd edition", Scott Meyers. To
my
> > continued amazement there is in std::basic_string a function
> > called c_str() which all implementations I have looked at so
far
> > implement by providing a pointer to the raw internal storage
for
> > the string. Here is the latest GNU source code. This
> > implementation appears to prevent strings stored in
> > non-contiguous, fixed sized blocks.
> >
> > const value_type *c_str( ) const;
> >
> >       // String operations:
> >       /**
> >        *  @brief  Return const pointer to null-terminated
> > contents.
> >        *
> >        *  This is a handle to internal data.  Do not modify
or
> > dire things may
> >        *  happen.
> >       */
> >       const _CharT*
> >       c_str() const { return _M_data(); }
> 
> Just because many implementations of std::string implement 
> c_str in this 
> way doesn't mean it /must/ be implemented this way. An
alternative 
> implementation of std::string, based on fixed-sized
non-contiguous 
> blocks of memory, would need to allocate a new standard
c-string 
> (contiguous), copy the data to it, and pass that as the result
of 
> c_str.
> 
> Of course, such an implementation of c_str is a lot less 
> efficient, but 
> I think this lies in the nature of things. /Any/ implementation
of 
> strings based on non-contiguous blocks will encounter the 
> same problem, 
> if it wants to provide a routine to interface with routines 
> that expect 
> a contiguous null-terminated C string.
> 
> Ben
> 



Replies:
Re: memory management Benjamin Franksen
References:
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 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 
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 ·