Archived

This topic is now archived and is closed to further replies.

To Upper with STL String ?

This topic is 4948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

#include <string>
#include <algorithm>
#include <cctype>

std::transform(str.begin(), str.end(), str.begin(), (int (*)(int))std::toupper);


The function cast is required to disambiguate between the toupper function in the <locale> header and the one in the <cctype> header.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan


[edited by - Fruny on May 28, 2004 8:02:13 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
It takes a committee to make something so conceptually simple so complicated...


Considering that they had more than just the english alphabet to handle, it's more complicated "conceptually" than you think.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan


[edited by - Fruny on May 28, 2004 8:04:54 PM]

Share this post


Link to post
Share on other sites
I have very mixed feelings about this and other aspects of the STL.

On one hand, you''re right, this is completely non-obvious to someone who hasn''t dealt with the STL a lot. One would expect something more like myString.to_upper();

On the other hand, it is incredibly flexible, because you can use the same basic transform mechanism with other functions (tolower), or your own custom functions, and with different data types (not just strings). And that is incredibly cool... the problem is, until you''re familiar with the STL it is also incredibly non-obvious and difficult to just ''look up'', which wouldn''t be the case if it were a more traditional API system.



Share this post


Link to post
Share on other sites
quote:
Original post by gmcbay
And that is incredibly cool... the problem is, until you''re familiar with the STL it is also incredibly non-obvious and difficult to just ''look up'', which wouldn''t be the case if it were a more traditional API system.


Which is why I don''t recommend C++ as a beginner language.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan

Share this post


Link to post
Share on other sites
quote:
Original post by gmcbay
I have very mixed feelings about this and other aspects of the STL.

On one hand, you''re right, this is completely non-obvious to someone who hasn''t dealt with the STL a lot. One would expect something more like myString.to_upper();

On the other hand, it is incredibly flexible, because you can use the same basic transform mechanism with other functions (tolower), or your own custom functions, and with different data types (not just strings). And that is incredibly cool... the problem is, until you''re familiar with the STL it is also incredibly non-obvious and difficult to just ''look up'', which wouldn''t be the case if it were a more traditional API system.


But the one doesn''t preclude the other. The interface of the C++ string class is *very* ugly - it looks like the result of someone''s "orthogonal design" wet dream, one which completely ignores the basic needs of the common developer. Uppercasing and lowercasing is a *very* common operation, doing custom transforms is not. But does the API take that into consideration?

Share this post


Link to post
Share on other sites
quote:
Original post by Fruny
#include <string>
#include <algorithm>
#include <cctype>

std::transform(str.begin(), str.end(), str.begin(), (int (*)(int))std::toupper);


The function cast is required to disambiguate between the toupper function in the <locale> header and the one in the <cctype> header.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan


[edited by - Fruny on May 28, 2004 8:02:13 PM]


And it''s still not guaranteed to work because (according to the standard) toupper might be given C linkage, but here you''re casting it away so it''s illegal.

Share this post


Link to post
Share on other sites
Uppercase doesn''t even exist in some languages. It''s best not to put something so specific on a general character string implementation. It belongs in locale and deserves to be conceptually separate. People ask questions and code as if ASCII was the only character encoding and that it should be expected to be the default.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Share this post


Link to post
Share on other sites
quote:
Original post by quorn
Uppercase doesn''t even exist in some languages. It''s best not to put something so specific on a general character string implementation. It belongs in locale and deserves to be conceptually separate. People ask questions and code as if ASCII was the only character encoding and that it should be expected to be the default.


You are certainly right. However, a potential (basic_)string::to_upper() could simply delegate the call to its local, so that would not be the point.

What Arild Fines means, is that applying the container-concept to the stl-string is so "amazingly reusable, flexible and compatible" that it completely ignores the users needs. IMHO it moreover is a very non-object-oriented-design. A comparable example in real-life would be drinking milk (the chars) out of glass (the string) using a spoon (transform()), just because a spoon can handle all fluids. No one would (well, maybe someone WOULD) do it. Instead we normally drink the milk directly out of the glass (to_upper).

Regards,
Andre Loker

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Fruny
Considering that they had more than just the english alphabet to handle, it''s more complicated "conceptually" than you think.
Bullshit. It works just fine and is trivial to use in plenty of other languages, such as Java, C# (or rather BCL), VB, Smalltalk...

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Bullshit. It works just fine and is trivial to use in plenty of other languages, such as Java, C# (or rather BCL), VB, Smalltalk...


Did you read any of the posts? Or better yet, do you speak more than one language? How about a language that dosn''t use the English alphabet? I somehow doubt it.

Things like this are found throughout C++. Another good example is the digraphs and trigraphs that allow people to program while lacking certain keys on their keyboard. For example <% and %> are valid in place of { and }.

Share this post


Link to post
Share on other sites
quote:
Original post by Puzzler183
quote:
Original post by Anonymous Poster
Bullshit. It works just fine and is trivial to use in plenty of other languages, such as Java, C# (or rather BCL), VB, Smalltalk...


Did you read any of the posts? Or better yet, do you speak more than one language? How about a language that dosn''t use the English alphabet? I somehow doubt it.


Uh, dude, almost every modern language in the world offer a .toUpper method on their string types, dealing transparently with the l10n issues - WITHOUT stuffing all the ugliness of the implementation down the users throat.

Yes, l10n is hard, but that''s the **LIBRARY IMPLEMENTOR''S** problem, not the user''s. The fact that the C++ committee even managed to botch this one up is a serious failure on their part.

(And yes, as for me, I do speak more than one language, one that incorporates characters not found in the English language.)

Share this post


Link to post
Share on other sites
quote:
Original post by fallenang3l
quote:
Original post by Fruny
#include <string>
#include <algorithm>
#include <cctype>

std::transform(str.begin(), str.end(), str.begin(), (int (*)(int))std::toupper);


The function cast is required to disambiguate between the toupper function in the <locale> header and the one in the <cctype> header.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan


[edited by - Fruny on May 28, 2004 8:02:13 PM]


And it''s still not guaranteed to work because (according to the standard) toupper might be given C linkage, but here you''re casting it away so it''s illegal.





cctype is a C++ header (not part of the C standard, the C version is ctype.h) hence std::toupper doesn''t have C linkage.

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
Did you read any of the posts? Or better yet, do you speak more than one language? How about a language that dosn''t use the English alphabet? I somehow doubt it.


Uh, dude, almost every modern language in the world offer a .toUpper method on their string types, dealing transparently with the l10n issues - WITHOUT stuffing all the ugliness of the implementation down the users throat.

Yes, l10n is hard, but that''s the **LIBRARY IMPLEMENTOR''S** problem, not the user''s. The fact that the C++ committee even managed to botch this one up is a serious failure on their part.

(And yes, as for me, I do speak more than one language, one that incorporates characters not found in the English language.)


I really don''t see what the problem is with the code. Could you point it out to me? And I''m sorry they wrote smart code and languages like basic didn''t; no big shock I guess.

And what language do you speak?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Puzzler183
Did you read any of the posts? Or better yet, do you speak more than one language? How about a language that dosn''t use the English alphabet? I somehow doubt it.

Things like this are found throughout C++. Another good example is the digraphs and trigraphs that allow people to program while lacking certain keys on their keyboard. For example <% and %> are valid in place of { and }.
Swedish is my mother tounge, but I also speak English and have basic knowledge of German and Norwegian. As for programming I consider C++ and C# as mother tounge, and I''m farly confident with Java too.

If you''ve used C# you know that things like uppercasing a string "just works". Simply go to System.String in MSDN docs and you know what to do. If you use C++, possibly with STL, on the other hand it''s a pain. Sure, I realize that it''s harder to do this, but as Arild Fines writes, it''s the library implementor''s thing to deal with and make a good abstraction of. The C++ committee has clearly failed to make this easy.

In my world a good libary should easy and intuative to use, because the library implementor takes care of the tricky parts. This is how Java and .NET class libraries are designed. I cannot say that about STL.

Share this post


Link to post
Share on other sites
quote:
Original post by Puzzler183
I really don''t see what the problem is with the code. Could you point it out to me?


The problem is that it represents a logical disconnect from the operation it is performing. Uppercasing a string is a conceptually very simple operation, as it is reflected by most sane languages, but instead of presenting it like that to the client programmer, like any sane language/library under the sun does, you are forced to deal with some computer scientist pipe dream of orthogonal design; applying an operation to an iterator range.

If I want to uppercase a string, I want to do just that. I don''t have time or interest in fawning over the beauty of some incredibly abstract and generic design.
quote:

And I''m sorry they wrote smart code and languages like basic didn''t; no big shock I guess.


Now you''re just coming off as an ignorant dilettant. How old are you, and what software have you written that I am likely to have used?
quote:

And what language do you speak?


Sheesh.

Share this post


Link to post
Share on other sites
The string class is not part of the STL for one thing, and how hard is it to make a function which does this impossible hard operation?


void toupper(std::string& str){

std::transform(str.begin(), str.end(), str.begin(), (int (*)(int))std::toupper);

}


toupper(mystring);



Was that difficult?


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by quant
Was that difficult?
I completely agree with Arild. Uppercasing a string is logically totally different from transforming iterators and casting function pointer to disambiguate between various toupper functions. I completely fail to see the beauty in this, it''s more what I''d like to call "bad design".

People do want to uppercase strings, thus it''s a failure that the class library itself doesn''t have a function for that. There are reasons why C# and Java have added support for such things - it''s obvious, easy and productive to use.

quote:
Original post by Puzzler183
And what language do you speak?
People in Norway generally speak "bokmål" or "nynorsk", right Arild?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Does C# even have a standard library?

Share this post


Link to post
Share on other sites

This topic is 4948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.