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
- References:
- RE: String Interfaces Jeff Hill
- Navigate by Date:
- Prev:
Re: ICE and TIPC Marty Kraimer
- Next:
Re: String Interfaces Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: String Interfaces Jeff Hill
- Next:
Re: String Interfaces Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|