Quote:Original post by Nypyren
I was trying to get people to wonder why there is not a tolower method on the std::string CLASS itself. std::string is a class, in a language touted for object oriented features, not for functional features. I apologize for not being painfully direct in my posts.
So to you, OOP equals putting *everything* inside the same class?
The ultimate OOP design would be to have one master class that contains every bit of functionality you might need to operate on its data (which obvious is everything)
Sure, that's an extreme example, but consider, why should something like tolower() be a member function? Yes, it's a common operation, but I don't recall reading any OOP gurus say "all common operations shall be made members of the class they operate on". If that was followed strictly, we would quickly end up with the one master class described above.
Quote:Obviously native "int foo[]" arrays don't have their own iterators in C++, either, because they are not a class. The iterators you use for them are external, providing access to native types, and as such there is nothing preventing you from also creating container objects that reference an underlying native type in the same manner.
They do have iterators. External or not, they work like iterators, so they are iterators.
But please show how you'd implement a tolower() member function on a char* [wink]
That's one reason why it makes some sense to have it as a free function. It's not tied to any particular representation of the string, they just have to have iterators you can work on. Allowing me to reuse the tolower() function on my own custom string class sounds object-oriented to me. Modularity, loose coupling, code reuse and all that.
Why should I restrict my tolower() function to only work on *my* strings, when the exact same code could work on *any* string type, even native ones like char*'s?
