Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are several design patterns like Adaptor, Iterator implemented in STL.

Does that mean STL is implemented with OO concepts?
What is the relationship between OO and template parts of C++?

I learned that virtual member function which justifys the OO is contradict with template, is this correct?

share|improve this question
The designer of the STL is famously anti-OO. – stonemetal Aug 7 '12 at 18:09

First, the "STL" is not an official term, it is the name of the library proposed for inclusing in the C++ Standard Library when there was no containers. It provides essentially container and algorithms templates.

Now, these container and algorithms templates are...templates so they produce types as needed. They don't rely on inheritance from the point of view of the user.

However, the standard library specify essentially the interface of the library, not the implementation. A lot of STL implementations will use a bit of object orientation in their implementation but as a user you will not see it if you don't dive in your implementations source code (that have to be exposed as it is essentially template code).

I learned that virtual member function which justifys the OO is contradict with template, is this correct?

No, they are orthogonal concepts that provide very different sets of advantages and cons. In fact in C++, one of the key advantage to use such a language is that you have both available and using one don't cancel using the other. It is even a very big advantage. For example one of the most interesting idiom in C++ is CRTP that use both templates and inheritance. The idea is that the inheritance part allows you to extend several types with a common behaviour and data, as a base class; while the template part make sure to generate specific base classes for each child, making impossible to have a pointer to all the classes using the CRTP class as base. This is extremely useful and don't allow messing with inheritance where there shouldn't be.

I've also implemented very generic event dispatching systems that didn't know either event types or listener types but combined internally dynamic and static code that together allowed to generate the right internal types corresponding to the right runtime types.

And that's the point: you don't always need "object orientation". In fact, most of the time you don't need it at all, you need to define some types and use them directly as different part of some kind of abstract engine (composition). You don't always need generic code, aka templates. You need it sometimes to generalize a function to apply to several unrelated types. When they are related you can use their base class instead and not need templates.

They have different advantages and completely different costs so they are good to combine to solve complex problems.

STL is a good example of a problem where most of it is about providding types (containers) and functions (algorithms) that are related to a given type instead of a hierarchy of runtime objects. In the standard library, streams are made in a way that is typical to object orientation: it is a hierarchy of stream classes that does different things in a way that allow defining a sub stream class that combine different behaviours/capacities. There, object orientation is useful, even if some people would prefer it to be more like the STL (I'm not a specialist on the subject).

So, just think of them as very different tools, as a screwdriver and a hammer. C++ don't let you think with only one tool in mind.

share|improve this answer

Actually, the STL introduced the Generic Programming paradigm to the mainstream.

When I was taught about the Object-oriented Programming paradigm (by some professor) 15 years ago, I was taught the three crucial pillars are encapsulation, inheritance, and polymorphism (today the latter should probably be qualified as runtime polymorphism), while Wikipedia currently lists data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance as defining OOP characteristics. Of course, the STL uses some of them, like encapsulation, but then it also uses functions, which are a characteristic of the Structured Programming paradigm. Yet nobody would argue that the STL is Structured Programming.

Note that one of C++' strongest features is the fact that it supports many programming paradigms (Structured, Object-oriented, Generic, Functional Programming, and others) and that it shines brightest where you mix and mingle them.

share|improve this answer

To quote Alexander Stepanov from his STLPort interview:

STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. [...] I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong.

That said, an individual implementation could be done using inheritance and polymorphism in places. Just for example, I've seen an implementation in which iterator was derived from const_iterator to support implicit conversion from iterator to const_iterator. Derivation is not however, characteristic of, or required by, the design.

Bottom line: while you can/could use object oriented code to implement some parts of the STL, the design of the STL itself is (emphatically) not object oriented.

share|improve this answer

It depends on who you ask for a definition of OOP, because OOP is a notoriously ill-defined term and there is no good consensus over what constitutes OOP and what doesn’t.

From a Java person’s perspective, the answer is probably “no” since thee algorithms and containers library of C++ doesn’t deal in run-time polymorphism, doesn’t use class inheritance and because the syntax doesn’t look OOP-y.

On the other hand, ask a funcional programming person and the answer may be “yes”.

Here’s how Wikipedia defines OOP:

Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP, at least as an option.

All of those are realised, or aided, in C++’ standard library, and in particular in the part dealing with containers and algorithms. In particular, the algorithms strengthen encapsulation and abstraction (and thus modularity) and are polymorphous through the use of templates.

share|improve this answer
Except that you should use inheritance with those containers, which is one of OOP's main features. – sbi Aug 7 '12 at 12:25
@sbi I consider inheritance a red herring. What OOP is actually about is abstraction and code-reuse, which are facilitated by inheritance. The STL provides both. But just to satisfy the Wikipedia definition to the letter, the STL containers are actually implemented via inheritance (though that’s of course an implementation detail). – Konrad Rudolph Aug 7 '12 at 12:28
Inheritance was a main feature- back before templates. Now I don't think there's anything more core about using inheritance to implement an abstraction than using templates to implement that abstraction. – DeadMG Aug 7 '12 at 15:53
If one speaks of inheritance in general terms, and not in the way it is defined in the C++ language syntax, then one may argue that vector<int> is inherited from the abstract base class vector. Through functors and operator overloading, it achieves polymorphism specific to the int type. – user29079 Aug 10 '12 at 11:17
@Lundin True, but that’s simply abstraction of an interface. Which is what inheritance does as well, which is why I think inheritance should be de-emphasised. – Konrad Rudolph Aug 10 '12 at 12:11

No, I'd say the STL is not particularly OO, if anything it maps more to a functional programming style. In particular:

  • std::algorithms are free functions not methods
  • they often take function objects so :. are higher order functions
  • they operate on any container
  • std::transform is map, the X_if functions are filters, std::accumulate is fold/reduce

likewise you can sort of argue that the containers themselves are monads

  • template instantiation is a type construction
  • the sequences at least have unit constructors e.g. vector<string>(1,"Foo")
  • fmap is std::transform
  • bind and/or join are implementable (though not provided out of the box)
  • any reasonable implementation of bind/join would meet the monad laws

For your other questions, the OO parts and template parts of C++ are seperate, and virtual functions do not preclude having templates. In the case of the STL the design just does not choose to use virtual functions.

share|improve this answer
Free functions vs methods is largely a syntactic distinction, and just because they are functional doesn’t mean that they aren’t object-oriented, on the contrary. – Konrad Rudolph Aug 7 '12 at 11:59
In addition, the algorithms may be functional, but there's no reason to believe that std::vector<int> is not object-orientated. – DeadMG Aug 7 '12 at 12:10

In my opinion STL is more about algorithms over iterable containers than OO.

It defines a common interface (the iterator) to be implemented in order to use the algoritms.

C/C++ iterators are called enumerator/enumeratable in Java and C#

Maybe STL is more aspect-oriented than OO.

share|improve this answer

I learned that virtual member function which justifys the OO

Where on earth did you hear that?

The crucial tenets of object orientation is encapsulation and abstraction. virtual functions are just one means by which that is achieved. They're not necessary at all for actual object orientation. Indeed, a template is a perfectly suitable means. It may not be inheritance, but it is still a kind of polymorphism. And some classes require neither.

The Standard library's containers are absolutely object-orientated. They encapsulate all unnecessary details from the interface and abstract the implementation to the maximum that is reasonably possible.

share|improve this answer
When I was taught "OO" 15 years ago, I was taught the three crucial pillars are encapsulation, inheritance, and polymorphism. – sbi Aug 7 '12 at 12:06
Inheritance and polymorphism are just one means to the end goals: encapsulation and abstraction. Not to mention that whilst templates don't use inheritance, they are polymorphic. – DeadMG Aug 7 '12 at 12:06
Well, it’s commonly taught, as sbi said. I agree with you that it’s largely a red herring though. – Konrad Rudolph Aug 7 '12 at 12:19

OOP implementation, by itself, means nothing until you don't define what you mean by "object". If Objects are values (not entities, like the most of the so-called OOP languages but C++ assumes), then STL is OOP otherwise no.

Assume this code fragment:

Person a("joe");
Person b = a;

Are a and b two representations of a same living person or just two living pesons with a same name?

What is the object? a, b or the living person(s) they represent?

Also, C++ inheritance is a technical aggregation mechanism that's different from Object inheritance (that is an abstraction). The two can coincide if you impose a certain discipline (like Objects are all accessible trough indirection, and are all replaceable - that means all relevant methods are virtual) otherwise they can target different objectives (C++ inheritance is nothing more than an "implicit composition")

Templates also can (via specialization) offer "substitution" mechanism, based on static types rather than dynamic types (based on virtual functions) and in this sense -if a same discipline is used at compile-time- provide a compile-time OOP.

In essence non of the C++ aggregation and dispatching schemes is by itself OOP or justify OOP. They can do other things as well. OOP is an abstract methodology to describe and relate object together. Those relation can be mapped to inheritance and virtual dispatch if object types depends on the run-time execution, or can be mapped to template specialization and implicit conversions if the object types can be defined during compilation. Inheritance can be just a one of the way to provide implicit conversion between references and pointers.

share|improve this answer
Inheritance is always also an aggregation mechanism, not just in C++. – Konrad Rudolph Aug 7 '12 at 12:00
I gotta downvote here. Even ignoring virtual methods, composition has serious differences to inheritance. – DeadMG Aug 7 '12 at 12:10
@KonradRudolph: true, but the question is about C++. – Emilio Garavaglia Aug 7 '12 at 16:57
@DeadMG: please note that the meaning of the term "composition" outside the OOP terminology has a precise meaning also in plain English. And inheritance (apart virtual method) is nothing more than "compose with an unnamed member". I undertand perfectly that OOP integralists don't like these facts, but C++ is not only a OOP langauge and inheritance as well as class composition are not just servicing OOP "is a" and "has a" relationships. ... – Emilio Garavaglia Aug 7 '12 at 17:14
... There is a difference between OOP terminology and C++ terminology. Back in the days when C++ had no other paradigm support than inheritance and virtual methods (no tempates and no lambdas) the two terminology could have been deliberately confused and used one in the place of another, but nowadays reducing OOP inheritance to just implement the OOP substitution principle is deliberately castrate the language. – Emilio Garavaglia Aug 7 '12 at 17:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.