C++: Alternative to STL and Boost?

C++ is a multi-paradigm language and STL and Boost are built towards the functional paradigm of the language. STL is composed of containers (to hold data), iterators (to access data) and algorithms (functions to manipulate data). Algorithm functions are applied on containers by using iterators. As a side-effect, these methods are not part of the container classes, but are completely separate. (This avoids redundancy for the library writers, but is painful for library users.)

Are there C++ alternatives to STL/Boost which offer such containers in a more traditional object-oriented flavour? I am looking for strings, vectors, linked lists, map, trees, hash tables and such. Containers should be easy to inherit and extend. In comparison开发者_如何学C, extending classes from STL/Boost is a very bad idea and this is by design of their designers.

PS: Please do not use the reply space below to pontificate the advantages of STL/Boost. I am well aware of them! :-)

Many (most!) older libraries for C++ used containers that bore a much closer resemblance to those used in such things as Java and C#.

A few example of such libraries include COOL, ET++, the NIH Class Library, and Rogue Wave Tools.h++.

Two points:

1. At most, these are a source if inspiration. I'm pretty sure it's been at least 10 years (and often more like 20) since any of them has been updated. There's virtually no chance that any of them will even compile with any reasonably current compiler.
2. I want to go on record as pointing out that I'm providing links to these only in answer to a very specific question. I most assuredly do not recommend that you use any of the above code, nor do I recommend that you even use them as inspiration.

To be sure I'm clear here, at least IMO:

• The allegations in your question are utterly false.
• What you're trying to do is completely insane!
• You're wasting your time.
• Writing code this way is a really, really bad idea. Just say no!
• If you insist on doing this, you will become a pariah.
  1. Even non-programmers who don't quite understand why, will begin to hate you intensely.
  2. Your dog will use your shoes and bed as his toilet.

You're on your own. You have been warned!

Closed captioning for the humor impaired: of course some of that is meant to be humorous -- it is a really, really lousy idea though

This avoids redundancy for the library writers, but is painful for library users.

I don't agree with this premise at all. And even if I did, it's a huge over-generalization that doesn't apply to every library user. But this is a subjective statement anyway, so I'll ignore it.

Are there C++ alternatives to STL/Boost which offer such containers in a more traditional object-oriented flavour?

...

Containers should have methods that allow one to manipulate on them directly. (For example, calling vector.sort() instead of sort(vector.begin(),vector.end()).

Sure. Just make your own containers that have the standard containers as data members and delegate calls to them and to algorithms as needed via member functions. It's rather trivial to implement:

template<typename T>
class MyVector
{
public:
    void sort()
    {
        std::sort(vec.begin(), vec.end());
    }

    // ...
private:
    std::vector<T> vec;
};

There's nothing in C++ that prevents you from doing something like this, ironically thanks to the multi-paradigm nature of C++ that you seem to not agree with.

You can probably use private inheritance and using declarations if you much rather not write out wrapper functions.

STL/Boost make it a pain to derive from their containers and extend them.

That's because you're not supposed to derive from them. The proper way is to use composition, like the code snippet I presented above.

You're heading the wrong way. If you want to program in Java then program in Java. If you program in C++ then program as C++ programmers do. Always swim with the current, never against it.

STL and Boost are as object-oriented as you can get.

1. For all theoretical purposes, member function and a free function overloaded on the first argument are the same thing. They behave very similarly in practice, including for inheritance, so in C++ you should really consider free functions taking (possibly const) reference as first arguments to be methods of their first argument.

   Advantage of free functions is they can be defined for existing class allowing you to add an interface to existing class. Which is why STL and especially boost uses them so much. Main advantage of member functions is they can be virtual (but virtual methods should be private anyway!)

2. You don't want to extend collections by derivation. Generally, you don't want to extend anything by derivation unless it is an abstract base class specifically designed for it. See this question about advantages of composition over inheritance.

Take a look at Qt's approach, I have always been a fan of it.

updated the link.

Why don't use graph instead of STL containers and attach what you need on nodes or edges. They can mimic any STL containers (Am I wrong?). You can easily iterate over nodes or edges (DFS, BFS) and along the way you can do what you like to do with data attached on nodes and edges. Easy mix of algorithm and iterator, isn't it?

What Dilawar stated is actually the solution for all your container needs.

Use Boost::graph or a similar implementation. You can use it [that is what I do] as a object management system.

As for the criticism of STL, it's just a matter of taste and not technical objections. These exist, but not at this level.

Coming a little late to this party AND I know the OP is specifically asking to not "pontificate" as they already know about the STL, however ...

There is an old Dr. Dobbs interview with Alex Stepanov, a pioneer in generic programming and a primary contributor to the STL. It is very instructive a several ways, especially to address the question of why more standard OO techniques are not used in the STL. One paragraph stands out:

Even now C++ inheritance is not of much use for generic programming. Let's discuss why. Many people have attempted to use inheritance to implement data structures and container classes. As we know now, there were few if any successful attempts. C++ inheritance, and the programming style associated with it are dramatically limited. It is impossible to implement a design which includes as trivial a thing as equality using it. If you start with a base class X at the root of your hierarchy and define a virtual equality operator on this class which takes an argument of the type X, then derive class Y from class X. What is the interface of the equality? It has equality which compares Y with X. Using animals as an example (OO people love animals), define mammal and derive giraffe from mammal. Then define a member function mate, where animal mates with animal and returns an animal. Then you derive giraffe from animal and, of course, it has a function mate where giraffe mates with animal and returns an animal. It's definitely not what you want. While mating may not be very important for C++ programmers, equality is. I do not know a single algorithm where equality of some kind is not used.

For those preferring a Java answer to this same conundrum, Josh Bloch takes pains to make the same points in Effective Java, Item 8: Obey the general contact when overriding.

It's a good chapter, with a nice example about trying to preserve the equals contract while at the same time extending a simple Point class with and added color: a ColorPoint class. He goes on to demonstrate that there is a fundamental limitation of OOP: there is no way to extend an instantiable class AND add a value component while preserving the equals contract.

Granted, the Bloch statement is more succinctly stated, but they both (correctly) draw the same conclusions. The main difference is that Java is (was) a "pure OO" language - everything must reside in a class, even those things such as algorithms, which are not naturally objects.

And I think Bloch may be sensitive to this problem because he has seen it fail spectacularly in the Java library: Stack inheriting from Vector is one example of a notable design problem in Java.

Slightly later in the interview, Stepanov goes on to say:

I had participated in several discussions early on at Bell Labs about designing templates and argued rather violently with Bjarne that he should make C++ templates as close to Ada generics as possible. I think that I argued so violently that he decided against that. I realized the importance of having template functions in C++ and not just template classes, as some people believed. I thought, however, that template functions should work like Ada generics, that is, that they should be explicitly instantiated. Bjarne did not listen to me and he designed a template function mechanism where templates are instantiated implicitly using an overloading mechanism. This particular technique became crucial for my work because I discovered that it allowed me to do many things that were not possible in Ada. I view this particular design by Bjarne as a marvelous piece of work and I'm very happy that he didn't follow my advice.