Re: String Interfaces

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

Jeff Hill wrote:
> > Jeff: Would you accept something like this method in a string interface
> > class?
> >
> > protected:
> >     virtual bool getSegment(size_t offset,
> >                  const char * & segment, size_t & len) const = 0;
> My reservation about this is # 29 in Effective C++ 2nd edition - avoid
> returning handles to internal data. I think that these concerns are
> magnified in systems that have a) dynamically created and deleted strings,
> b) dynamically modifiable string values, c) dynamically modifiable string
> storage sizes, and d) have multiple threads accessing shared strings.
Can I request that you re-read the final paragraph of that EffC++ item.

In this case there *is* a compelling reason to allow other string 
implementations to get a pointer to your segment data; because it's 
impossible for two different segmented string types to work together 
efficiently (even assignment would have to be done character by 
character) otherwise.
Your concerns about multiple threads are irrelevent since if the string 
is not already properly protected by an external mutex it can be changed 
in between two character-by-character reads, which is probably breaking 
some other promise you made to the user of the string when you handed it 
out.
You're already presenting us with another API that requires us to give 
out handles to internal data: A propertyCatalog::traverse() function has 
to trust that the propertyViewer/propertyManipulator isn't going to take 
and store the address of the reference it has to give out.

> > If not, please describe how you would write an efficient comparison
> > operator between two different segmented string implementations.
Note the words I used: "two different segmented string implementations."

> If not then we drop back to a slower generic version that
> requires copying into a scratchpad, but since that situation will occur only
> when crossing between subsystems or when transitioning from an old string
> implementation to a new one then perhaps the overhead would be acceptable.
I disagree that this is acceptable, because I see it as being very 
common to have multiple implementations.  I can see requirements for at 
the very least two if not three or four inside of iocCore, and that's 
before considering your needs inside of CA.
> PS: I would also like to see strings accessed through a pure virtual
> interface class so that multiple implementations are possible. This is,
> among other apple pie reasons, because DA is interfacing with the world, and
> the world will use many different string implementations including
> std::string.
If you give me my request, I'll give you that one.

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.