Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 02 Mar 2005 01:54:36 +0100

On Tuesday 01 March 2005 17:30, Jeff Hill wrote:
> 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.

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 teh user code is responsible 
for freeing that memory.

> > /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.

I agree that it would be clearer then whose responsibility it is to 
allocate/free the memory (the user's), instead of spreading it between 
std::string (allocation) and user (de-allocation). OTOH, such an interface 
would be more vulnerable to buffer overflow errors.

The main point, however, is that you cannot solve the underlying problem by 
refusing to provide method c_str. Either the functionality is not really 
needed. In this case it would be sufficient to (strongly) discourage use of 
this method and to point out its inefficiency.

Or, as you seem to suggest, users really /need/ this functionality i.e. 
there /is/ lots of code that expects a classic contiguous C string (for 
instance, because many old-style C string routines are used). In that 
case /any/ implementation based on non-contiguous storage has the same 
problem, regardless of the interface, and regardless of who (user or string 
class) does the work of allocating additional storage and copying the data.

An advantage of providing c_str is that allocation and copying can be avoided 
in cases where the string is short enough to fit into a single (fixed-size) 
block.

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

Why?

> [...]
> 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.

Of course, the smaller your interface, the larger the set of possible 
implementations that can be fit unto it. Or so it would seem.

Unfortunately, however versatile your string interface may be, it imposes an 
imperative style on the implementation: it completely precludes functional 
style (immutable) strings. Such strings are *so* much easier to handle, than 
the traditional mutable ones. Take concatenation as an example. Functional 
style:

	res = concat(s1,s2);

Imperative style:

	res = new string( s1.length() + s2.length() ); // or was it -1 or +1 ???
	res.copy( s1 );
	res.append( s2 );

Note that concatenation is probably _the_ most used standard operation on 
strings (or rather, would be if it were not prohibitively expensive and 
unwieldy in C).

In my experience, overwriting an already existing string is almost never a 
natural solution to the problem at hand, but done only to avoid memory 
allocation or copying.

An implementation based on non-contiguous storage, could take advantage of its 
storage model, and almost completely avoid copying (at the cost of slightly 
increasing the overall memory footprint). For instance, functional 
concatenation can be done in constant time (avoiding all allocation and 
copying). As long as strings are immutable and references are properly 
tracked, an implementation can easily share the storage between different 
strings (except the meta data). I would bet that such an implementation is in 
the end a lot more efficient than any implementation based on mutability, 
such as imposed by the dataAccess string interface.

Just my 2c.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System