Why were concepts (generic programming) conceived when we already had classes and interfaces?

Also on programmers.stackexchange.com:

I understand that STL concepts had to exist, and that it would be silly to call them "classes" or "interfaces" when in fact they're only documented (human) concepts and couldn't be translated into C++ code at the time, but when given the opportunity to extend the language to accomodate concepts, why didn't they simply modify the capabilities of classes and/or introduced interfaces?

Isn't a concept very similar to an interface (100% abstract class with no data)? By looking at it, it seems to me interfaces only lack support for axioms, but maybe axioms could be introduced into C++'s interfaces (considering an hypothetical adoption of interfaces in C++ to take over concepts), 开发者_JAVA技巧couldn't them? I think even auto concepts could easily be added to such a C++ interface (auto interface LessThanComparable, anyone?).

Isn't a concept_map very similar to the Adapter pattern? If all the methods are inline, the adapter essentially doesn't exist beyond compile time; the compiler simply replaces calls to the interface with the inlined versions, calling the target object directly during runtime.

I've heard of something called Static Object-Oriented Programming, which essentially means effectively reusing the concepts of object-orientation in generic programming, thus permitting usage of most of OOP's power without incurring execution overhead. Why wasn't this idea further considered?

I hope this is clear enough. I can rewrite this if you think I was not; just let me know.

There is a big difference between OOP and Generic Programming, Predestination.

In OOP, when you design the class, you had the interfaces you think will be useful. And it's done.

In Generic Programming, on the other hand, as long as the class conforms to a given set of requirements (mainly methods, but also inner constants or types), then it fits the bill and may be used. The Concept proposal is about formalizing this, so that detection may occur directly when checking the method signature, rather than when instantiating the method body. It also makes checking template methods more easily, since some methods can be rejected without any instantiation if the concepts do not match.

The advantage of Concepts is that you do not suffer from Predestination, you can pick a class from Library1, pick a method from Library2, and if it fits, you're gold (if it does not, you may be able to use a concept map). In OO, you are required to write a full-fledged Adapter, every time.

You are right that both seem similar. The difference is mainly about the time of binding (and the fact that Concept still have static dispatch instead of dynamic dispatch like with interfaces). Concepts are more open, thus easier to use.

Classes are a form of named conformance. You indicate that class Foo conforms with interface I by inheriting from I.

Concepts are a form of structural and/or runtime conformance. A class Foo does not need to state up front which concepts it conforms to.

The result is that named conformance reduces the ability to reuse classes in places that were not expected up front, even though they would be usable.

The concepts are in fact not part of C++, they are just concepts! In C++ there is no way to "define a concept". All you have is, templates and classes (STL being all template classes, as the name says: S tandard T emplate L ibrary).

If you mean C++0x and not C++ (in which case I suggest you change the tag), please read here:

http://en.wikipedia.org/wiki/Concepts_(C++)

Some parts I am going to copy-paste for you:

In the pending C++0x revision of the C++ programming language, concepts and the related notion of axioms were a proposed extension to C++'s template system, designed to improve compiler diagnostics and to allow programmers to codify in the program some formal properties of templates that they write. Incorporating these limited formal specifications into the program (in addition to improving code clarity) can guide some compiler optimizations, and can potentially help improve program reliability through the use of formal verification tools to check that the implementation and specification actually match.

In July 2009, the C++0x committee decided to remove concepts from the draft standard, as they are considered "not ready" for C++0x.

The primary motivation of the introduction of concepts is to improve the quality of compiler error messages.

So as you can see, concepts are not there to replace interfaces etc, they are just there to help the compiler optimize better and produce better errors.

While I agree with all the posted answers, they seem to have missed one point which is performance. Unlike interfaces, concepts are checked in compile-time and therefore don't require virtual function calls.