Re: String Interfaces

[Marty Kraimer <mrk@aps.anl.gov>]

This discussion is only of interest to C++ since a Java implementation 
would do something very different.

Even for C++ lets limit the discussion to what is needed for network 
accessable data. What network transport code needs for strings may be 
very different than what other code requires.  Thus lets only discuss an 
interface for transfering network accessable strings. For example this 
is the interface that dataAccess can use for strings.

Kay  has been asking for non segmented strings. Can this be done and 
still satisfy other requirements? Perhaps yes.

The following interface (defined in psuedo code) has the following 
attributes:

1) Does not expose internal storage.
2) Is a pure interface
3) Allows the user and implementer to use segmented or non-segmented 
storage for the strings


interface StringAccess {
   void setPutSize(int32 size);
   void put(int32 len, octet[] data);
   int32 getSize();
   void get(int32 len,octet[] data);
};


Code doing a put does the following:

1) Call setPutSize to say how many octets it will transfer
2) Call put as many times as it wants. Each put transfers an additional 
segment. The code implementing the interface MUST accept the total 
amount requested.

Code doing a get does the following:

1) Calls getSize tom see how much storage is required.
2) Calls get as many times as it wants. Each get transfers an additional 
segment. The code implementing the interface MUST return the total 
amount requested.

Thus the caller can either work with non segmented ir segmented strings. 
The implementer of the string can also use segmented or non-segmented 
strings but may have to block between segments.


Marty

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.
>
>  
>
> > If not, please describe how you would write an efficient comparison
> > operator between two different segmented string implementations.
> >
> >    
>
> In the String Segment interface we have the following:
>
>    virtual StringDiff compare ( const StringSegment & ) const = 0;
>
> My conclusion was that it would be easy, and relatively efficient enough (we
> need to remind ourselves that nothing is particularly efficient when we use
> strings), to inside of the implementation of striongSegment::compare()
> attempt to downcast the incoming StringSegment typed parameter using
> dynamic_cast to the local type deriving from interface StringSegment. If
> that cast is successful we are comparing two implementations of the same
> type that we have private access to and we can implement a very fast and
> efficient version. 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.
>
> 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.
>
> Jeff
>