In article <kitk.345.00095021@mudshark.sunquest.com>, kitk@mudshark.sunquest.com (Kit Kauffmann) writes:
> In article <2kgvnf$bnm@news.icaen.uiowa.edu> nvkumar@icaen.uiowa.edu (Neel Vasant Kumar) writes:

> >I guess, I am throwing my hat into the ring for saying that ANSI/ISO
> >committee should *not* standardize the string class.  My guess is that soon
> >*nobody* would be using the word "string" in their programs.  A string class
> >is something that should be left upto the programmer, *even* if ANSI/ISO is
> >trying to internationalize the string class.  ...

> As someone currently enjoying the rather dubious pleasures of having to use
> two string classes ... I ... throw my hat into the "other ring".

> I still don't fully remember the semantics of either class, because I'm
> continually hopping back and forth.  ...

A very fair objection.  I once had to be skilled in no less than seven
editors, two at one job (one from HP, one that made the HP machine usable)
one at another (on RSTS-E), three for school (on CDC NOS, TOPS-20, and
one machine that I've mercifully forgotten), plus vi/ex and ed on UNIX
(they are so closely related I count them as one).  I would never do that
willingly.

> I think it _very_unfortunate for both class designers and class users that
> C++ did not start out with a string class which measured up to the high
> standard of the ios family.  ...

I think it very unfortunately that _standard_ C++ will not have such a string
class.  It won't.

> Regardless of who provides it, i18n could and should be invisible to the
> uninterested programmer, and available to those who need it.

The proposed string class will do very little to help internationalization.

 ...
> A basic string class which any library can depend on seems essential to me,
> both for i18n and to get away from the mutiple string class scenario.

The only thing the standard class will do is reduce the incidence of lost
memory.  It will not raise the level of character manipulation by any
significant amount because it models abstractions whose level is way too low.
It will provide no help for input parsing.  All the help with wide characters
and multibyte characters will come from the  stream  classes.  The string
class will strings as arrays of a character type rather than as arbitrary
amounts of text.  One will not be able to write (for example)

  s( "aa*b" ) = "Some a's and a b"
or
  s( "abc" ) = "Alphabet Circus"
or
  s( 4, 3 ) = "Aphabet Circus"
or
  s( "abc" ) = "def"
or even
  s( 0, 0 ) = "Insert at beginning ..."
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

mat@mole-end.matawan.nj.us wrote:
: In article <kitk.345.00095021@mudshark.sunquest.com>, kitk@mudshark.sunquest.com (Kit Kauffmann) writes:
: > In article <2kgvnf$bnm@news.icaen.uiowa.edu> nvkumar@icaen.uiowa.edu (Neel Vasant Kumar) writes:
:
: > >I guess, I am throwing my hat into the ring for saying that ANSI/ISO
: > >committee should *not* standardize the string class.  My guess is that soon
: > >*nobody* would be using the word "string" in their programs.  A string class
: > >is something that should be left upto the programmer, *even* if ANSI/ISO is
: > >trying to internationalize the string class.  ...

: > As someone currently enjoying the rather dubious pleasures of having to use
: > two string classes ... I ... throw my hat into the "other ring".
:
: > I still don't fully remember the semantics of either class, because I'm
: > continually hopping back and forth.  ...

: A very fair objection.  I once had to be skilled in no less than seven
: editors, two at one job (one from HP, one that made the HP machine usable)
: one at another (on RSTS-E), three for school (on CDC NOS, TOPS-20, and
: one machine that I've mercifully forgotten), plus vi/ex and ed on UNIX
: (they are so closely related I count them as one).  I would never do that
: willingly.

: > I think it _very_unfortunate for both class designers and class users that
: > C++ did not start out with a string class which measured up to the high
: > standard of the ios family.  ...

: I think it very unfortunately that _standard_ C++ will not have such a string
: class.  It won't.

I thought it *was* going to have one [eventually, when the standard gets ratified :-)]!

: > Regardless of who provides it, i18n could and should be invisible to the
: > uninterested programmer, and available to those who need it.

: The proposed string class will do very little to help internationalization.
:
:  ...
: > A basic string class which any library can depend on seems essential to me,
: > both for i18n and to get away from the mutiple string class scenario.

: The only thing the standard class will do is reduce the incidence of lost
: memory.  It will not raise the level of character manipulation by any
: significant amount because it models abstractions whose level is way too low.
: It will provide no help for input parsing.  All the help with wide characters
: and multibyte characters will come from the  stream  classes.  The string
: class will strings as arrays of a character type rather than as arbitrary
: amounts of text.  One will not be able to write (for example)

:   s( "aa*b" ) = "Some a's and a b"
: or
:   s( "abc" ) = "Alphabet Circus"
: or
:   s( 4, 3 ) = "Aphabet Circus"
: or
:   s( "abc" ) = "def"
: or even
:   s( 0, 0 ) = "Insert at beginning ..."
: --
:  (This man's opinions are his own.)
:  From mole-end    Mark Terribile
:  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
:  (Training and consulting in C, C++, UNIX, etc.)

Any body got a spec and could post it? The class definition would be helpful
if a full spec is not available electronically.

--
-- davep@pcproj.datastream.co.uk -- dave postill -- datastream international ltd