Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 28 Jul 2005 10:46:39 -0500

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System