Matt Austern <austern@sgi.com> wrote:
>"Al Stevens" <alstevens@midifitz.com> writes:
>
>> And, as a committee with the charter to define a standard, you would get to
>> say which way (toupper or tolower) it ought to be if you decide to include
>> that feature in std::string. No old code breaks because you aren't changing
>> any behavior of any vendor's stricmp extension or VC++'s
>> CString::CompareNoCase. I think it would have been a handy addition to the
>> class. You probably considered it and have good reasons for leaving it out.
>
>If there were any discussions on case-insensitive basic_string
>compare, they were before I joined the standardization committee.
>
>If someone had proposed adding case-insensitive comparison to
>basic_string<>, though, I would have argued against it.  It doesn't
>make any sense to talk about case-insensitivity except in the context
>of a specific locale.  (In C, toupper and tolower both refer to hidden
>global state.)  For basic_string<> to do case-insensitive comparison,
>it would have to keep track of which std::locale object to use.
>Presumably it would have to use some sort of imbue mechanism, like
>basic_istream and basic_ostream use.
>
>At present basic_string<> has no dependencies on locale, and it has no
>imbue mechanism.  My opinion is that the gain in functionality isn't
>enough to justify the extra complexity and the new dependencies.

An imbue mechanism would not be necessary; a simple function

  bool string_less(string const& s1, string const& s1,
                   const locale& = locale());

(suitably templatized) would suffice.  A similar interface would work
for conversions.  If the compare interface needed to take just two
arguments, a string comparer object:

  class string_comparer {
    string_comparer(const locale&);
    bool operator(string const& s1, string const& s1) const;
  };

(again, suitably templatized) might be preferable.

The problem is not in designing a usable interface.  The real problem
was that conversion to upper and to lower is not well-defined for all
encodings; in particular, the length of the upper-case version of a
string can be different from the lower-case version, so simple
character-by-character operations may not work.  Since users who have
more knowledge about the encoding they are using can define something
like the above themselves, it didn't seem appropriate to have something
in the standard that might be wrong.

The best way to support this kind of comparison is with an appropriate
locale.  The C++ locale object already knows how to compare strings: it
has a member operator() that returns a bool, and uses the collate facet.
All you need to do is construct a locale with a "collate" facet that
implements the right semantics.  Unfortunately the people who create
"official" locale definitions do not seem to have recognized (yet) the
need for this capability, so (for now) you would need to create your
own collate facet for each target language.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Al Stevens" <alstevens@midifitz.com> writes:

> And, as a committee with the charter to define a standard, you would get to
> say which way (toupper or tolower) it ought to be if you decide to include
> that feature in std::string. No old code breaks because you aren't changing
> any behavior of any vendor's stricmp extension or VC++'s
> CString::CompareNoCase. I think it would have been a handy addition to the
> class. You probably considered it and have good reasons for leaving it out.

If there were any discussions on case-insensitive basic_string
compare, they were before I joined the standardization committee.

If someone had proposed adding case-insensitive comparison to
basic_string<>, though, I would have argued against it.  It doesn't
make any sense to talk about case-insensitivity except in the context
of a specific locale.  (In C, toupper and tolower both refer to hidden
global state.)  For basic_string<> to do case-insensitive comparison,
it would have to keep track of which std::locale object to use.
Presumably it would have to use some sort of imbue mechanism, like
basic_istream and basic_ostream use.

At present basic_string<> has no dependencies on locale, and it has no
imbue mechanism.  My opinion is that the gain in functionality isn't
enough to justify the extra complexity and the new dependencies.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <r_TK1.5178$zm6.873849@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
> Pete Becker wrote in message <35F5605C.94F3946C@acm.org>...
> >> Yeah, just one of the vagaries of ascii.
> >
> >Not so much a vagary of ASCII, but a vagary of "case-insensitive". The
> >difference in the two is that (conceptually) one converts the strings =
to
> >uppercase before comparing them, and the other converts to lowercase.
> >Any characters that fall between the ranges of uppercase and lowercase
> >keep their original values, and their relative position depends on whi=
ch
> >case conversion you've done. This issue arises for all character
> >representations in which uppercase characters and lowercase characters
> >are not contiguous, not just ASCII.
>
> And, as a committee with the charter to define a standard, you would ge=
t to
> say which way (toupper or tolower) it ought to be if you decide to incl=
ude
> that feature in std::string. No old code breaks because you aren't chan=
ging
> any behavior of any vendor's stricmp extension or VC++'s
> CString::CompareNoCase. I think it would have been a handy addition to =
the
> class. You probably considered it and have good reasons for leaving it =
out.

They didn't leave it out.  It's in the facet collate, in <locale>.
An appropriate place, too, since how you do a case insensitive compare
IS locale dependant.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote in message <35F5605C.94F3946C@acm.org>...
>> Yeah, just one of the vagaries of ascii.
>
>Not so much a vagary of ASCII, but a vagary of "case-insensitive". The
>difference in the two is that (conceptually) one converts the strings to
>uppercase before comparing them, and the other converts to lowercase.
>Any characters that fall between the ranges of uppercase and lowercase
>keep their original values, and their relative position depends on which
>case conversion you've done. This issue arises for all character
>representations in which uppercase characters and lowercase characters
>are not contiguous, not just ASCII.

And, as a committee with the charter to define a standard, you would get to
say which way (toupper or tolower) it ought to be if you decide to include
that feature in std::string. No old code breaks because you aren't changing
any behavior of any vendor's stricmp extension or VC++'s
CString::CompareNoCase. I think it would have been a handy addition to the
class. You probably considered it and have good reasons for leaving it out.





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens wrote:
>
> >Even is you implement something based on the ascii character set you
> >have a problem with characters which lie between Z and a; do they
> >come before or after the case-insensitive letters. ISTR that Borland
> >and Microsoft deal with this differently.
>
> Yeah, just one of the vagaries of ascii.

Not so much a vagary of ASCII, but a vagary of "case-insensitive". The
difference in the two is that (conceptually) one converts the strings to
uppercase before comparing them, and the other converts to lowercase.
Any characters that fall between the ranges of uppercase and lowercase
keep their original values, and their relative position depends on which
case conversion you've done. This issue arises for all character
representations in which uppercase characters and lowercase characters
are not contiguous, not just ASCII.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Followups set to comp.lang.c++{,.moderated}]

Herb Sutter <herbs@cntc.com> wrote:
>"Al Stevens" <alstevens@midifitz.com> wrote:
>>stricmp (case-insensitive compare--not standard C but in some C compiler
>>libraries as an exension)
>
>Fair enough, this is a common request -- but what do you mean by "case"?
>
>See also GotW #29 at www.peerdirect.com/resources/gotw029.html.
[...]

This view -- that case insensitivity is a property of the string type
(as a trait) rather than of the operation -- bugs me in a few ways.

herbs@cntc.com (Herb Sutter) wrote:

>
>"Al Stevens" <alstevens@midifitz.com> wrote:
>>>What do you want to do the underlying C-style string (assuming it exists
>>>in the first place) that you can do with C but can't do with
>>>std::string? We tried to put equivalent capabilities into the string
>>>class.
>>
>>stricmp (case-insensitive compare--not standard C but in some C compiler
>>libraries as an exension)
>
>Fair enough, this is a common request -- but what do you mean by "case"?

Even is you implement something based on the ascii character set you
have a problem with characters which lie between Z and a; do they
come before or after the case-insensitive letters. ISTR that Borland
and Microsoft deal with this differently.

Norman


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>Even is you implement something based on the ascii character set you
>have a problem with characters which lie between Z and a; do they
>come before or after the case-insensitive letters. ISTR that Borland
>and Microsoft deal with this differently.


Yeah, just one of the vagaries of ascii. It's usually not a problem;
typically I'd like to compare things like filenames and paths for equality
or search database strings for matches without worrying about where they
came from. I'd be happy with case-insensitive == and != operators.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gerhard Menzl wrote in message <35E505E3.4283B298@sea.ericsson.se>...
>What kind of operations do you need to perform that are neither covered
>by std::string nor by C library functions that accept a const char*?

Unformatted input?  CD2 gave getline(istream,string), but it isn't obvious
to me how you say that any delimiter should be ignored.  If
   get(istream,string) or get(istream,string,count)
exist, I missed it/them (quite possible).



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Al Stevens wrote:
>
> >What do you want to do the underlying C-style string (assuming it
exists
> >in the first place) that you can do with C but can't do with
> >std::string? We tried to put equivalent capabilities into the string
> >class.
>
> stricmp (case-insensitive compare--not standard C but in some C
compiler
> libraries as an exension)

Case translation depends on the locale that you're in. Locale objects
know how to handle this sort of thing, and can be used directly for this
sort of comparison.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Al Stevens" <alstevens@midifitz.com> writes:

> >What do you want to do the underlying C-style string (assuming it exists
> >in the first place) that you can do with C but can't do with
> >std::string? We tried to put equivalent capabilities into the string
> >class.
>
> stricmp (case-insensitive compare--not standard C but in some C compiler
> libraries as an exension)

Which locale do you want the string to use when it's doing a
case-insensitive compare?

The cleanest solution, I suppose, would be for case-insensitive
compare to take three arguments (a locale and two strings), or for it
to be a member function of std::ctype<> or of std::locale.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Al Stevens" <alstevens@midifitz.com> wrote:
>>What do you want to do the underlying C-style string (assuming it exists
>>in the first place) that you can do with C but can't do with
>>std::string? We tried to put equivalent capabilities into the string
>>class.
>
>stricmp (case-insensitive compare--not standard C but in some C compiler
>libraries as an exension)

Fair enough, this is a common request -- but what do you mean by "case"?

See also GotW #29 at www.peerdirect.com/resources/gotw029.html. As the
solution introduction states:

 Note 2:  What "case insensitive" actually means depends
 entirely on your application and language.  For
 example, many languages do not have "cases" at all, and
 for languages that do you have to decide whether you
 want accented characters to compare equal to unaccented
 characters, and so on.  This GotW provides guidance on
 how to implement case-insensitivity for standard
 strings in whatever sense applies to your particular
 situation.


---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>What kind of operations do you need to perform that are neither covered
>by std::string nor by C library functions that accept a const char*?

Case-insensitive compare.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>What do you want to do the underlying C-style string (assuming it exists
>in the first place) that you can do with C but can't do with
>std::string? We tried to put equivalent capabilities into the string
>class.

stricmp (case-insensitive compare--not standard C but in some C compiler
libraries as an exension)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 4 Sep 1998 10:33:35 -0400, Al Stevens <alstevens@midifitz.com> wrote:

>>What kind of operations do you need to perform that are neither covered
>>by std::string nor by C library functions that accept a const char*?

>Case-insensitive compare.

Yes they are, in a way.  All you have to do is define a new traits.
The default traits for char does strcmp in its comparison function.
Defining the new traits is not that much of work.

template<class charT, class traits, class Allocator>
class basic_string;


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <IrIG1.1352$cP1.113752@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>>What kind of operations do you need to perform that are neither covered
>>by std::string nor by C library functions that accept a const char*?
>
>Case-insensitive compare.

If some C headers contain

int stricmp(char*,char*);

you have a broken system and should fix the header not the C++ standard
library. You can of course add

extern "C++" {int stricmp(const char*s1,cont char*s2) {
return stricmp(const_cast<char*>s1,const_cast<char*>s2);}

or you could define appropriate character traits (covered by
Guru of the Week#29, http://www.cntc.com/Resources/gotw029.html )
and get the correct behaviour from the standard library.



--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The question wasn't how do you implement something. It was, "What kind of
operations do you need to perform that are neither covered..." Defining a
custom trait does not automatically extend the standard. It isn't a question
of how much work it is, either. The question as I understood it was about
standard features.

Siemel Naran wrote in message ...
>
>On 4 Sep 1998 10:33:35 -0400, Al Stevens <alstevens@midifitz.com> wrote:
>
>>>What kind of operations do you need to perform that are neither covered
>>>by std::string nor by C library functions that accept a const char*?
>
>>Case-insensitive compare.
>
>Yes they are, in a way.  All you have to do is define a new traits.
>The default traits for char does strcmp in its comparison function.
>Defining the new traits is not that much of work.
>
>template<class charT, class traits, class Allocator>
>class basic_string;

[ moderator's note: excessive quoting deleted. Please strip
  unnecessary material from quotes. -sdc ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

With the abundance of C string functions, I think it would be nice to have a
"legal" way to access the C-style string inside the std::string class.
c_str() only returns const, which is while const_cast<>()-able, is certainly
not a good way of accessing the charater string underneath.

What do you think?

Athena.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 26 Aug 1998 15:43:29 GMT, Athena Wong <athena_w@hotmail.com> wrote:

>With the abundance of C string functions, I think it would be nice to
have a
>"legal" way to access the C-style string inside the std::string class.
>c_str() only returns const, which is while const_cast<>()-able, is
certainly
>not a good way of accessing the charater string underneath.
>
>What do you think?

I think they want to deter you from using the <cstring> functions
directly on a string.  The intent is that if you have a string,
you should access and modify it through the string and
string::iterator and string::const_iterator functions.

Don't use a const_cast<char*>.  It will work in some cases, of
course.  But it will also intefere with reference counting.  If
you do "string b=a", both strings probably point to the same
memory location.  Therefore a.c_str()==b.str().  So if you say
     (const_cast<char*>(a.c_str()))[3]='H';
you'll be messing up both strings!  By contrast, if you do the
same thing with iterators, only string 'a' will be changed
(which implies that the implementation of string::iterator is
rather complicated).

The standard does not require that strings be reference counted,
but most implementations do this in any case.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Athena Wong wrote:
>
> With the abundance of C string functions, I think it would be nice to have a
> "legal" way to access the C-style string inside the std::string class.
> c_str() only returns const, which is while const_cast<>()-able, is certainly
> not a good way of accessing the charater string underneath.
>
> What do you think?
>

What do you want to do the underlying C-style string (assuming it exists
in the first place) that you can do with C but can't do with
std::string? We tried to put equivalent capabilities into the string
class.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Athena Wong wrote:

> With the abundance of C string functions, I think it would be nice to have a
> "legal" way to access the C-style string inside the std::string class.
> c_str() only returns const, which is while const_cast<>()-able, is
certainly
> not a good way of accessing the charater string underneath.

> What do you think?

The proper way to get a writable C-style string from a std::string is to
copy it. Trying to modify the internal representation of std::string is
asking for trouble.

What kind of operations do you need to perform that are neither covered
by std::string nor by C library functions that accept a const char*?

Gerhard Menzl


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]