6tr6tr seems to be taking it in quite well though. He/she probably agrees with us :pQuote:
We certainly seem to have hijacked this thread "most excellently" considering we seem to agree on everything. ^_^
Printable View
6tr6tr seems to be taking it in quite well though. He/she probably agrees with us :pQuote:
We certainly seem to have hijacked this thread "most excellently" considering we seem to agree on everything. ^_^
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!
No it isn't, but it does have support for object-oriented techniques. (C++ is billed as a multi-paradigm language.)Quote:
C++ is an object-oriented language.
If it was an "object-oriented language", as Smalltalk or Java, I wouldn't be using it.
Soma
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.Quote:
I fail to see how it is not OO. Maybe not 100%, but OO is heavily utilized in C++ most times.
OO, procedural, and generic, and I'm with soma - I wouldn't use it if everything had to be an object. Blech.
That's just it though, it is utilized; it is not forced. I get to mix and match whatever techniques, including any of the various "OOP" techniques C++ supports, might be most applicable.Quote:
OO is heavily utilized in C++ most times.
Well, with C++ pretty much everything seems like a second class citizen--which I suppose is the best thing about it.Quote:
Well, the point of "multi-paradigm" is that it includes OO, but with (first class?) support for other programming paradigms.
You forgot functional. Sure, there are a lot of bits of a traditional FP that C++ lacks, but C++ lacks just as many traditional "OOP" bits and people have no problem with that association.Quote:
OO, procedural, and generic, and I'm with soma - I wouldn't use it if everything had to be an object. Blech.
Soma
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.
Of course it wouldn't, but that has nothing to do with anything. (It wouldn't be the same if any changes were made, or if decisions had been made differently.)Quote:
I dare say C++ wouldn't be the same without classes.
'RAII' has nothing to do with classes. (It does in C++, but not at the conceptual level.) No 'RAII' mechanism is possible in any number of languages that have classes. A few languages have scoped garbage collection that do not have classes.Quote:
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.
Hardly. A mistake, or oversight, surely, but nothing that "ruins" the library.Quote:
I feel that they ruined the standard library.
The only reason we can say that: we've had a decade to examine the C++ machine. (The standard guys had a relatively short time.) Hindsight is an amazing thing.Quote:
It could have been a lot more than it is, but it wasn't.
A strange comment indeed! O_o (I said ""OOP" bits" not "OOP "bits"". ^_^)Quote:
I'll bite. What OOP "bits" is it missing?
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. (Yes, they can be emulated, but they can be emulated in C, or even assembler, as well so it isn't worth discussing emulation.)
Soma
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.
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.
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?
Exactly how is the second way more complicated?Code:string s;
s.to_lower(); //hypothetical member function
to_lower(s); //boost/algorithms/string.hpp
I wouldn't mind having the second one in the standard libraries, though.