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.

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.

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.

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.

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.

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.

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.

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.