Thread: How properly inherit from template?

We certainly seem to have hijacked this thread "most excellently" considering we seem to agree on everything. ^_^

6tr6tr seems to be taking it in quite well though. He/she probably agrees with us

I find it ironic that STL would not be made OO since it was designed specifically for C++ and C++ is an object-oriented language.
I see now why the classes are so lacking in the OO area.
All the more reason to make a C#-ish framework!

I fail to see how it is not OO. Maybe not 100%, but OO is heavily utilized in C++ most times.

I fail to see how it is not OO. Maybe not 100%, but OO is heavily utilized in C++ most times.

Well, the point of "multi-paradigm" is that it includes OO, but with (first class?) support for other programming paradigms.

I dare say C++ wouldn't be the same without classes. Classes are basics to C++. It's combined with other methods, as well perhaps, but things like RAII is a pretty big backbone to C++ which makes it so powerful.
And yet those who designed the library didn't really take advantage of all that power. I find that right out stupid, no matter how they argue it.
I feel that they ruined the standard library. It could have been a lot more than it is, but it wasn't. Instead we're stuck with some half-baked implementation.

Anyway, those are just my thoughts on the whole. They don't necessarily reflect the whole truth.
The standard library contains some good functions, like vector or map, but beyond that I really don't use it. It's too separated and non-OO. Methods were broken out in favour of encapsulation (which is wrong; you can keep encapsulation by still making methods part of the object by calling common interfaces or public access methods instead of touching the internals), plus classes are lacking common methods for actions and algorithms should be avoided, because they complicate the code. There should be appropriate member functions to do all that stuff. At least for simple things such as turning a string all into lower case.

It's a lot of stuff I really don't agree with.

Originally Posted by phantomotap

Direct support for anonymous message passing--invoking a method on a type that may not actually support that method--and multiple parametric polymorphisms would be a favorite.

Even Smalltalk and Eiffel don't support multiple dispatch.
Anonymous message passing is a feature of dynamic languages, rather than object-oriented languages. Java, C# and Eiffel (all statically typed OO languages) do not support it, except the hard way through reflection.

Originally Posted by Elysia

Anyway, those are just my thoughts on the whole. They don't necessarily reflect the whole truth.
The standard library contains some good functions, like vector or map, but beyond that I really don't use it. It's too separated and non-OO. Methods were broken out in favour of encapsulation (which is wrong; you can keep encapsulation by still making methods part of the object by calling common interfaces or public access methods instead of touching the internals), plus classes are lacking common methods for actions and algorithms should be avoided, because they complicate the code. There should be appropriate member functions to do all that stuff. At least for simple things such as turning a string all into lower case.

It's a lot of stuff I really don't agree with.

Ouch. I though the algorithms library was the most OOP part of standard libraries - container objects interacting with contained object interacting with predicate objects etc. If you use it to the full, the calls might look a bit more verbose and a bit less readable than ideal, but I don't see how the problem comes from the algorithms being free functions (the most complicated part is the predicates). And do you find it bad that you can also sort arrays, not just vectors?

Would you say that given the two following options the second is poor programming?

Code:

string s;
s.to_lower(); //hypothetical member function
to_lower(s); //boost/algorithms/string.hpp

Exactly how is the second way more complicated?

I wouldn't mind having the second one in the standard libraries, though.