To Upper with STL String ?
quote:Original post by quant
Was that difficult?
In quite a few ways, yes. Which is why it should have been offered in the library in the first place.
quote:Original post by quantI 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".
Was that difficult?
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 Puzzler183People in Norway generally speak "bokmål" or "nynorsk", right Arild?
And what language do you speak?
quote:Original post by Anonymous Posterquote:Original post by Puzzler183People in Norway generally speak "bokmål" or "nynorsk", right Arild?
And what language do you speak?
Those are the written forms of Norwegian, mostly. The announcers and news anchors of the public broadcaster, NRK, usually speak "pure" bokmål or nynorsk, but other than that, it''s just a mish-mash of various dialects. Wikipedia has some stuff on it: http://en.wikipedia.org/wiki/Norwegian_language#Bokmål_and_Nynorsk
quote:
Does C# even have a standard library?
I''m fairly sure it''s stipulated somewhere that C# is tied to the BCL.
quote:Original post by Anonymous PosterC#, or rather .NET has its "Base Class Library". In terms of feature parity it contains much more than the C++ STL.
Does C# even have a standard library?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/cpref_start.asp?frame=true
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconthenetframeworkclasslibrary.asp
Comon now... STL not having the toupper method that you think it should have is not definitive proof that STL as a whole is flawed...
If transform bothers you, use this:
for (string::iterator i = test.begin(); i != test.end(); i++)
*i = toupper(*i);
If a simple for loop still bothers you, do what quant said, stick it in a function and never let it bother you again.
IMO, one of C++''s strengths is that there is always more than one way to solve the problem.
I can see that this is going to turn into another holy war over a question that has already been answered.
quote:Original post by EvilSteve
Comon now... STL not having the toupper method that you think it should have is not definitive proof that STL as a whole is flawed...
You are totally missing the point. Yes, you are right, he library not having a toupper function is not, alone, the proof that the standard library is flawed. *However*, this particular flaw is representative of the general braindamage that caused the standard library as a whole to be inherently flawed.
quote:
If transform bothers you, use this:
for (string::iterator i = test.begin(); i != test.end(); i++)
*i = toupper(*i);
That''s no better. What the programmer want to achieve is, from hi perspective, a simple atomic operation, and here you come shoving an ugly loop in his face? WTF?
quote:
If a simple for loop still bothers you, do what quant said, stick it in a function and never let it bother you again.
Which is exactly what the C++ committee should have done in the first place.
quote:
IMO, one of C++''s strengths is that there is always more than one way to solve the problem.
One of the strengths of *GOOD* API designs are that, even in the presence of alternatives suited to more advanced use, there is *ALWAYS* *one* intuitive and obvious way to do it. Here, the C++ committee failed miserably.
Also, the above philosophy was one of the major causes behind that other miserable failure in language design, namely Perl.
quote:
I can see that this is going to turn into another holy war over a question that has already been answered.
And so? The "holy war" is in itself a lot more interesting than the original question.
Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated.Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren''t special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you''re Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it''s a bad idea.If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let''s do more of those! >>>
Perhaps instead of trolling and flaming the C++ standard commitee, you should start your own. You seem to think you can do a better job.
You can also use the .NET librarys in C++, if you have a problem with the STL, use them instead.
You can also use the .NET librarys in C++, if you have a problem with the STL, use them instead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
