RE: [Fwd: RE: Standard String]

["Jeff Hill" <johill@lanl.gov>]

The problem is worse than that. 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, ...).

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:kasemirk@ornl.gov]
> Sent: Monday, July 18, 2005 8:31 AM
> To: EPICS Core Talk
> Subject: Re: [Fwd: RE: Standard String]
> 
> Hi:
> 
> Jeff wrote:
> > 2) I'm not terribly fond of interfaces that hand off handles to
> > internal
> > data. I'm not enamored, for example, with "std::string::c_str()" and
> > "EpicsString::expose".
> 
> In principle, I agree that c_str violates everything you learn
> about using interfaces and hiding the internal data.
> 
> In fully OO languages like Java where a string constant "blah" is
> interchangeable with a String class and all library functions understand
> this, we'd be fine.
> 
> In reality, however, I'm afraid that many C and C++ APIs still require
> text as (const char *), so whatever String class we use needs to
> convert to/from char * as efficiently as possible,
> and c_str does that for 'reading' the String.
> So just like std::string and MFC::CString and probably most of the other
> C++ string classes, I doubt you can avoid char *.
> 
> -Kay