Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 18 Jul 2005 11:51:49 -0600

> I agree that's less than ideal,
> 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.

 From my perspective, about the only thing that c_str() has going for it is
easy of use.

Everyone appears to like UTF-8. Should we decide that UTF-8 is the only
approach to wide characters in EPICS (Marty and Andrew's interfaces seem to
presume this) then the obvious alternative to c_str() is "getChar ( size_t
count, char *pDestination )". This interface will allow 'legacy' libraries
to work if there is a small support code that creates a scratch pad buffer
that get reallocated should it not be big enough. 

A similar, but optimized, solution to this problem is designed into the
"StringSegment" interface. In that interface the numeric to string
conversion is the responsibility of the string storage implementer. If the
string storage is contiguous, then there is no change to the legacy
approach. If the string storage is non-contiguous, then it will be very rare
that a number in the string crosses a boundary between storage blocks. If
so, then legacy libraries can be used by the implementer without copying. If
not, then only a modest copy, and a modest scratchpad, would be required to
get the numeric string segment into a contiguous block where it can be
directly manipulated by legacy libraries.

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Monday, July 18, 2005 10:21 AM
> To: EPICS Core Talk
> Subject: Re: [Fwd: RE: Standard String]
> 
> 
> On Jul 18, 2005, at 11:07, Jeff Hill wrote:
> > The c_str function does not allow an
> > implementation that is stored in non-contiguous fixed sized blocks (or
> > else
> > c_str calls malloc, or else c_str isn't thread safe, ...).
> 
> I agree that's less than ideal,
> 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.
> 
> -Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System