STL string - converting to low case

[roberts.noah]

Right. So according to that definition too, for_each is not a modifying
algorithm.

According to some arbitrary definition for_each may be classified as a
non-modifying algorithm (but for practical purposes it is and one of
its primary uses is to modify every element in a sequence. Running to
the standard, which picks such an arbitrary definition because
standards have to, to back the assertion that it shouldn't be used for
such purposes is silly. The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.

 

[roberts.noah]

Not with most implementations but according to the standard, someone
might implement for_each to not work in writable mode, in which case
there would be a need to.

Would require a casting of a template type to a const version of that
type. VERY unlikely and would turn up very quickly. This is a
non-issue.

By the way you still haven't answered my post above on how you would
implement case-insensitive lookup using char_traits.

I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you.

 

[Earl Purple]

I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you.

It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.

 

[roberts.noah]

It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.

I gave you a direct source. The very same source I first learned the
technique from in fact. You can get this source for free on the
Internet.

I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.

This is as far as I go.

 

[Richard Herring]

According to some arbitrary definition for_each may be classified as a
non-modifying algorithm (but for practical purposes it is and one of
its primary uses is to modify every element in a sequence. Running to
the standard, which picks such an arbitrary definition because
standards have to,

This particular standard is full of footnotes and other clarifying text
where such a decision could be justified if it truly was arbitrary, but
on this issue it's silent.

to back the assertion that it shouldn't be used for
such purposes is silly.

(No sillier than claiming that "every book" backs the opposite view.)

If I had made any such assertion, it would indeed be silly. All I said
was that since for_each is classified as non-modifying, using an
explicitly modifying algorithm, std::transform, would more clearly
express the original poster's intent.

The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.

Possibly. Since in the original example assignment still occurs when
using for_each, the hypothetical performance improvement of bypassing it
doesn't arise here.

 

[roberts.noah]

In message <[email protected]>,
(e-mail address removed) writes
Possibly. Since in the original example assignment still occurs when
using for_each, the hypothetical performance improvement of bypassing it
doesn't arise here.

I stated such in my original reply...maybe you should read it again.

 

[Earl Purple]

I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.

This is as far as I go.

It's because you don't know. And I do know because I have implemented a
specialised version of char_traits. And I know that char_traits has a
compare() function but that is equivalent to memcmp() and has no
knowledge of lower and upper-case at all.

If there were such a function it would be in locale but even there it
doesn't actually exist.

 

[roberts.noah]

It's because you don't know. And I do know because I have implemented a
specialised version of char_traits.

Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.

Goodbye now...have fun with that attitude.

 

[Earl Purple]

Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.

Goodbye now...have fun with that attitude.

Well I don't know how to do it with char_traits, I think it is
impossible. It is possible to do wtih locale but not directly, i.e. you
have to use a tolower or toupper member of locale, because I am not
aware of any general string conversion or case-insensitive comparison
method in locale.

I do think there should be a case-sensitive comparison in C++ and I
think locale would be the correct library in which to implement it.

 

[roberts.noah]

Well I don't know how to do it with char_traits, I think it is
impossible.

Well, like I said, you now know of and have ready access to the very
source I got the technique from. I believe it is also explained in
Josuttis but I may be mistaken. You can read it, learn it, and make up
your own mind whether to use it.

 

[int2str]

I gave you a direct source.

I can't see that. What am I missing?

You brought up a very interesting topic (using char_traits for case
insensitive string comparisons). It would have been nice if you would
have elaborated more on the topic (for all our benefit).

Failing to see your source, here's what I came up with on Herb Sutter's
page:
http://www.gotw.ca/gotw/029.htm

<synopsis>
The article by Herb Sutter outlines how to generate your own string
class that does everything stl::string does, but compares strings
independend of their case. He does so by creating a new ci_char_traits
class and defining a new string type:
typedef basic_string<char, ci_char_traits> ci_string;
</synopsis>

The use of char_traits for this is very intruiging. Especially given
the fact that char_traits usuaally have been in the "black magic" camp
of the STL for me so far.

Cheers,
Andre

 

[roberts.noah]

I can't see that. What am I missing?

The rest of my post.

Thinking in C++ v2.

 

[Earl Purple]

<synopsis>
The article by Herb Sutter outlines how to generate your own string
class that does everything stl::string does, but compares strings
independend of their case. He does so by creating a new ci_char_traits
class and defining a new string type:
typedef basic_string<char, ci_char_traits> ci_string;
</synopsis>

If you did that you'd have to implement the compare function but doing
that will still require a toupper or tolower call.

Is it really worth rewriting the whole of char_traits just to do that?
You may as well just write a comparison functor (so you can use it as a
predicate in std::map).

 

[Diego Martins]

Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits

Or you may be nice and explain to Earl and to us how to implement it

This is the purpose of newsgroups

 

[Aaron Graham]

Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits

Or you may be nice and explain to Earl and to us how to implement it

This is the purpose of newsgroups

You can do case insensitive comparisons with strings if you use/create
the strings with the correct char_traits. Stroustrup talks about this
in his book "The C++ Programming Language" 3rd edition. I don't
remember the exact pages, but I'm pretty sure it's in the "Strings"
chapter.

You basically create a "ci_string" class like so:
typedef basic_string<char, ct> ci_string;

....where "ct" is your own char_traits class. The char_traits class has
a "eq" function that returns true if two chars are "equivalent". (It
also has many other functions as well.)

I don't really like this approach because you're defining a new kind of
"case insensitive string" that are essentially incompatible with all
"normal" strings, and are thus useless for lots of operations that you
would normally like to do with them (like many iostream operations).

Aaron

 

[roberts.noah]

Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits

I don't understand that statement.

Or you may be nice and explain to Earl and to us how to implement it

I did better. I gave a source. Why give a half ass explaination when
an expert source is readily available? God, for free even...

You people that are bitching about this are just lazy. Go download and
read "Thinking in C++ V2" if you are truely interested. I really don't
think you are and so you probably won't and will continue complaining...

 

[roberts.noah]

I don't really like this approach because you're defining a new kind of
"case insensitive string" that are essentially incompatible with all
"normal" strings, and are thus useless for lots of operations that you
would normally like to do with them (like many iostream operations).

Yeah, all your streams and such have to use those traits in order to
read directly and you can't assign to or copy directly into 'normal'
strings. It can be a useful technique though in some cases.

 

[Diego Martins]

Which cases?