How do objects fit into modern C++ (stl, policy-classes, functional) style?

Question

I'm a bit confused so the question is a bit confusing. TL;dr: how to mix STL and OOP?

From the comment to Best overview to modern C++ paradigms? and http://www.boost.org/community/generic_programming.html there isn't much about objects-oriented programming. (boost guidelines mention object generators).

When planing a program, it seems that STL and objects should fit well together. You think of an algorithm and how to do things, then you think of what are the things you want to work with and what properties/characteristics they have. You express those things in terms of tuples and containers and you apply algorithms to them. From my understanding, that's STL style of thinking.

Now this is where objects come in. They are things that you do stuff with that contain data, algorithms that change that data and interfaces. But that overlaps with idea of stl where you separate data and algorithms.

In OO you combine data and algorithms and in STL you separate it.

Although mathematically and generically STL make more sense (when you can apply the algorithm to anything), it is easier to think conceptually in OO style when you have a lot of different objects and algorithms -- you get a better organization. For example, qt-style advocates using minimal and orthogonal interfaces specific to a class as oppose to general algorithms. I said specific because their objects are different and they ask for minimal interfaces meaning objects won't share the same interfaces.

So the question is: "can you get away with STL in modern C++ or should you use objects? and if you have to use objects then how?"

Other relevant questions at Stack Overflow:

• What is so great about STL?
• C++: Alternative to STL and Boost?

Answer 1

One thing that you should be careful to not forget is that C++ is a multi-paradigm language. It is a language that supports abstractions from low-level imperative code up to high-order functional code, and almost everything in between.

The standard containers (not the STL - that's a mostly unrelated library) are a type of abstraction that sits closer to the functional part of the paradigm spectrum. It provides the most generic interface possible to a category of standard algorithms, in a form that follows a functional style - a style in which algorithms and data structures are described in very high-level but consistent terms.

This is not at odds with the object-oriented paradigm that you are likely accustomed to. Rather, it is both orthogonal and complementary.

The reason modern C++ discussions don't revolve much around object-orientation is simply due to the fact that objects are merely one of the many tools C++ offers to model the computations that underlie user-defined types.

To restate that another way: The focus in modern C++ is in types. Objects happen to be used to model the behavior of some types, and templates and functions model the behavior of other types.

This is not the "STL way of thinking," rather, it is a paradigm that takes full advantage of the functional paradigm in that way in which C++ can support it.

When planning a program, you determine the core behaviors and the superstructure of the data model. Then, you build a computational model that incorporates both the behaviors and the data model. Indeed, you should think first about the data model, then the algorithms to operate upon it.

The standard library provides the most commonly-used linear data structures and algorithms that mutate them. Lists of various kinds happen to be the most convenient and easiest to model of the major data structures, and the functional paradigm teaches us that the most convenient algorithms for those data structures are the ones which the standard library chose to provide. The rest of C++ (classes, inheritance, functions, templates, etc.) provide a powerful way to model those data structures and algorithms efficiently, without sacrificing their genericity.

The way in which you choose to implement your data structures and algorithms doesn't matter to C++: It provides you with all of the tools you need to model computations in whatever form you find convenient. But that expressive breadth comes at the cost of complexity. Some models that you may choose may not be type-safe. C++ allows you to use them, but it also provides models that are type safe and generic.

Your question is, I think, the wrong one.

The question you should ask is not "should I use the standard containers or use objects," but rather, "What class of algorithms and data structures most clearly models my program?"

If you have a need for a simple data structure and the primary operations on that data structure are closely modeled by the standard algorithms library, by all means use it. They are part of the standard library because they are meant to be useful. It happens to be complete, in that it provides all of the high-level abstractions your program will ever need, but it may not always do so in a way that makes your code clear. This is why C++ provides all of its other tools: To give you a way to model your own kinds of abstractions.

Answer 2

I come from a background where most of my OO skills were gained using C#. However, most of my generic programming skills come from C++. I recently wrote a C++ project that recursively searched web sites for certain things (a web spider). I constantly ran into problems whenever I tried to mix OO and the STL.

Objects don't like to expose their internals. Those internals are the data structures (vectors, maps, etc.) that other objects want to interact with. It always felt clumsy to create accessor/mutator methods for these data structures. Consumers of my classes couldn't use the STL to grab and manipulate my data as they saw fit.

It is very easy to use the STL within the confines of a class. You have everything you need. But when you start interacting with other objects, using the STL is difficult without violating encapsulation. One topic I researched heavily was generic iterators (iterators that don't expose the underlying collection type). Even with generic iterators, your consumer needs to know whether the iterator is random access, forward, bi-drectional, etc.

Another approach I adopted later was passing functors to member functions. One object would pass a functor to another object's member function who would then pass it to an STL algorithm. At times I would have to decorate/adapt the functor to not expose implementation details about how data was stored internally. The problem with this approach was that it became difficult to know who "owned" a piece of functionality. Additionally, it meant that these member functions were templates, which limited where I could define their implementations. A lot of the problems I ran into with template member functions will be going away with C++11.

I ended up making classes that I felt were very exposed or whose implementations were spread out across too many other classes. A lot of this came from my desire to avoid writing explicit loops and avoiding inefficiencies. I believe on a professional project I would probably limit my use the STL to within the confines of my classes. I spent way too much time trying to use the STL everywhere I could.

By now it should be obvious that I'm probably not the best person to provide advice. I just wanted to share with you that the two styles are not always easy to combine. Bjarne Stroustrup's book The C++ Programming Language emphasizes how C++ was designed to allow programmers to switch between paradigms as needed. I don't think he intended the language to make it easy to combine them necessarily. Most of his examples regarding OOP touch the STL very little. He creates very distinct layers.

I'd recommend poking around my project to see how I used the STL across object bounds. Like I said, it's not perfect but it will provide some examples which may be useful.