Kay-Uwe Kasemir wrote:
Being out of ideas, I looked at the NextStep/Apple Cocoa frameworks.
I like how it uses separate classes for static and mutable objects,
and suggest that the basic 'String' is read-only,
a 'MutableString' allows write access,
and there are container classes that create a string from char *,
sprintf-format etc. and present a 'String' or 'MutableString' interface.
Having two separate interfaces for const and mutable strings was
something Eric mentioned a while back. I'm not sure that it's really
necessary in C++ since the compiler already implements the distinction
we need using const qualifiers, but programmers who are new to C++ might
find it easier to understand and I don't see any major performance
issues. Any design done one way should be easily converted to the
other, so I'll go along with this suggestion for now.
However, as far as I can see the major point of contention with strings
seems to be how you access the characters stored in the string.
Jeff was originally only offering one character at a time access in
order to support wide character types, but he has conceded that if we
standardize on UTF-8 everywhere then the wide character requirement goes
away. To quote him:
> The StringSegment interface in data access certainly could be
> revised to allow blocks of characters to be read/written in UTF-8
> format (assuming that all strings are streams of octets).
The chief argument that I see then is whether the string interface
should permit other code to access the character segments directly in
its internal buffer, or whether they would have to be copied out to some
other buffer first.
AIUI Jeff wishes to completely hide the internal string implementation,
such that the only API that supports access to multiple characters at at
time would be one that copies all or a section of the string to an
external char* buffer.
In the blue corner, I think we should permit code that is willing to
work with segmented strings to get at least a const char* pointer to a
section of the string. There's a very good reason for this - it's
needed to implement efficient operations between strings of different
kinds. This access method can be protected so that only other string
implementations can make use of it, but I don't see any way to implement
assignment between or comparison of different string types efficiently
otherwise.
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;
If not, please describe how you would write an efficient comparison
operator between two different segmented string implementations.
I'll be back with more when I get an answer to this.
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
- Replies:
- RE: String Interfaces Jeff Hill
- References:
- FW: Standard String Jeff Hill
- Re: FW: Standard String Benjamin Franksen
- Re: Standard String Kay-Uwe Kasemir
- Re: Standard String Marty Kraimer
- Network Accessable Data Marty Kraimer
- Data Interfaces Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Data Interface (was: ICE & TIPC) Kay-Uwe Kasemir
- Next:
RE: ICE and TIPC Jeff Hill
- 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:
Data Interfaces Kay-Uwe Kasemir
- Next:
RE: String Interfaces Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|