11

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), 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.

Community
  • 1
  • 1
Gui Prá
  • 5,559
  • 4
  • 34
  • 59
  • Belongs to [programmers.se](http://programmers.stackexchange.com/) ? – iammilind Sep 02 '11 at 06:14
  • 4
    StackOverflow isn't about programming anymore..? Been away for a long time. – Gui Prá Sep 02 '11 at 06:16
  • 1
    @n2liquid: SO seems now more about technical objective questions and subjective discussions about rationale/design etc are usually migrated to SE. Don't really know why :p – Matthieu M. Sep 02 '11 at 06:25
  • That's news to me. At least is SE as popular as SO? I'll hate SO/SE if not >: – Gui Prá Sep 02 '11 at 06:27
  • 8
    @n2liquid: of course it isn't. That's what makes it so stupid. If you have a question related to programming that you want to ask here, go ahead. The worst that can happen is that people will migrate it for reasons they're not really clear about themselves. – jalf Sep 02 '11 at 06:47
  • @jalf: if I could upvote you twice, I definitely would. – Gui Prá Sep 02 '11 at 06:49
  • Why don't you try modifying C++ this way? Likely, you'll end up inventing Agda2. As for the "*OOP power*" - sorry, there is no power. OOP does not worth it. – SK-logic Sep 02 '11 at 07:10
  • @SK-logic actually some guys already did it. Check out http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.8789&rep=rep1&type=pdf. – Gui Prá Sep 02 '11 at 07:13
  • @n2liquid, it is not quite capturing the idea of a "concept". Dependent types are much closer, allowing to express more of what's normally just in your head or in the documentation. – SK-logic Sep 02 '11 at 07:17
  • @SK-logic, true, I remember SCOOP didn't fully capture the idea of concepts. Particularly, it didn't feature auto mapping and axioms. – Gui Prá Sep 02 '11 at 07:19

4 Answers4

6

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.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
  • I understand we use OOP with predestination in mind, but what I propose is a shift in that mentality. When you write a concept, you're specifying requirements (i.e. not what you *think* will be useful, but what *is* useful, in fact necessary, for you). When you write an interface as we know them, you're dealing with predestination, if I got that right, and I agree. But what forbids you from writing an interface with necessity, not abstraction, in mind? – Gui Prá Sep 02 '11 at 06:43
  • Regarding adapters, I disagree. When you didn't have concepts, Library1::Sound and Library2::Sound fit equally, you were gold; no adapters, no nothing. But with concepts, you either need auto concepts or concept_maps. That'd simply be auto interfaces and adapters. What's so different? And dynamic dispatching obviously shouldn't be needed if the implementation class type is a template parameter and you use that type directly. – Gui Prá Sep 02 '11 at 06:45
  • 3
    @n2liquid: the problem with interface is not necessity over abstraction. Suppose you design an interface `interface Comparable { operator<; operator==; }` and I come along and want to call an algorithm that uses `interface LowerThanComparable { operator<; }` then I cannot use objects that derive from your interface because your interface does not derive from mine. This is what I call predestination. I cannot use your objects with my algorithms unless I provided you with my interfaces at one point. Really annoying in modular development. – Matthieu M. Sep 02 '11 at 07:02
  • Aren't you perhaps ignoring the possibility of implementing sort of an "auto interface" akin to an "auto concept"? I'm not sure I follow. And remember, it's not our current interfaces and our current classes, but an adaptation of them for generic programming. – Gui Prá Sep 02 '11 at 07:07
  • @n2liquid: if you're talking about auto interfaces (like in Go or Haskell), then they are essentially similar (and I am sorry I missed the distinction, the OO threw me off I fear). However note that templates are already usable (without concept maps), the goal of Concept here is mainly to provide better diagnosis. – Matthieu M. Sep 02 '11 at 07:22
  • 1
    @n2liquid: You are talking about a potential *auto interface*, what would it be like? I understand that you would not have your types as *conforming to the auto interface*, but rather the algorithm would require an *auto interface* that would then be *matched* against the features of the type that is passed to the algorithm, right? If that is so, then call your *auto interface* a *concept* and you are done. If what you dislike is that there is a new *buzzword*, don't. It is much better to have a new clearly different word than mix different concepts under the same name. – David Rodríguez - dribeas Sep 02 '11 at 07:23
  • 1
    @n2liquid: ... consider questions in SO after the feature was added, with many people talking about *interfaces* and meaning *pure abstract* classes and others talking about *interfaces* and referring to your *auto interfaces*. As you said in the question title, we already have *classes* and *interfaces* and they refer to a different already existing meaning, why abuse the names? We already have the distinction of runtime polymorphism (`virtual`, inheritance) and static polymorphism (`template`), now in the same way that you have runtime *interfaces* you have static *concepts* – David Rodríguez - dribeas Sep 02 '11 at 07:26
  • 1
    @dribeas, yes, you're straight to the point. You can answer that and I'll settle for it. Any further discussion would be why I prefer using pre-existing concepts and that would be totally my own conjecture. The question was objective, and your answer is valid. I'd love to discuss more, but SO isn't the place and I'm satisfied. If you could, though, I'd love to know if the guys behind the C++ standard share the same idea, and if they ever considered reusing classes instead of adding concepts. Thanks. – Gui Prá Sep 02 '11 at 07:37
  • Well you can follow the discussion by reading the proposals in the C++ std [committes mailings](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/). The first is [N1758](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1758.pdf) from 2005, the last ones will be from mid-2009. You can find some of the discussions in the Minutes, mostly in the POST-xxx mailings. – Fabio Fracassi Sep 02 '11 at 07:57
3

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.

MSalters
  • 173,980
  • 10
  • 155
  • 350
1

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.

Shahbaz
  • 46,337
  • 19
  • 116
  • 182
  • @n2liquid did you get the answer to your question? – Shahbaz Sep 20 '11 at 10:05
  • C++0x became C++11 (which is officially *the* C++) in March '11. Wikipedia is not an authoritative, or even a good source of information on C++. "Improving compiler diagnostics" can potentially be quite revolutionary, as testability is a major limitation of template programming, and the messages are often inscrutable to many. – Potatoswatter Apr 28 '12 at 13:45
0

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.

Огњен Шобајић
  • 1,414
  • 15
  • 31