Re: [Fwd: RE: Standard String]

[Andrew Johnson <anj@aps.anl.gov>]

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.