Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 01 Mar 2005 11:40:52 +0100

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System