Ich hab mir eben Gedanken darüber gemacht, dass es doch eigentlich praktisch wäre, wenn man in C++ eine Möglichkeit hätte, Compiletime-Schnittstellen definieren zu können. Also Klassendefinitionen, die keine Polymorphie modellieren, sondern nur sicherstellen, dass eine Klasse, die man davon ableitet Schnittstellen-kompatibel mit einer gewissen Definition ist (alle deren public-Symbole anbietet), so dass einem bei verschiedenen Implementierungen derselben Sache geholfen wird, kompatibel zu bleiben. Das wär natürlich praktisch für templates (aber da ist ja schon was im Gange mit den Constraints?) und für Cross-Plattform oder Cross-API Biblitheken. Könnte man die angedachten Constraints auch irgendwie dafür nutzen?

Viele Grüße,
Deci

greetz KN4CK3R

static_interface some_interface {
   int a( bool b );
   void c( float d);
};

class impl1 : some_interface {
   int a( bool b );
   void c( float d);
};

class impl2 : some_interface {
};   // whoah, kompiliert nicht, weil impl2 nicht drop-in-kompatibel zu some_interface ist!

Also eigentlich soll soetwas wie typedef-kompatibilität gesichert werden. Wo immer impl1 verwendet wird, könnte per typedef auch impl2 verwendet werden und der Compiler warnt den Entwickler, wenn er gegen die Kompatibilität verstößt.

template <typename T>
bool static_interface()
{
  T t; // Defaultkonstruktor                                                             
  int a = t.a((bool)true); (void)a; // int a(bool)                                       
  t.c((float)0);  // void c(float)                                                       
  return true;
}
bool _i_m_p_l_1_ = static_interface<impl1>(); // ok
bool _i_m_p_l_2_ = static_interface<impl2>(); // Fehler

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

concept some_interface<T> {    // T unnötig?
   int a( bool b );
   void c( float d);
};

class impl1 {
   int a( bool b );
   void c( float d);
};

concept_map some_interface<impl1> {}  // OK

class impl2 {
};   

concept_map some_interface<impl2> {} // Nicht OK

Irgendwie erscheint mir das geistig "quer" (weil die Interface-Garantie nicht teil der Implementierung ist), da verstehe ich etwas noch nicht.

concept some_interface<typename T>
{
  int T::a(bool);
  void T::c(float);  
}

Das Bekloppte daran ist nur, dass diese Constraints wie Funktionsdeklarationen aussehen, aber in Wirklichkeit für Ausdrücke stehen, die "funktionieren müssen", wenn T wirklich ein some_interface ist. Also, man muss in diesem fall eine Methode a aufrufen können, wo man ein bool reinstecken kann (auch wenn es z.b. implizit zu etwas anderes konvertiert wird) und etwas zurück gibt, was man wieder nach int konvertieren kann.

In dem Concepts-Design war es aber nicht vorgesehen, dass man explizit sagen kann, dass eine Klasse einem Konzept entsprechen soll und daraufhin überprüft werden soll. Ich sehe auch nicht den Vorteil. Da wo Concepts dann wirklich zum Tragen kommen, sind die requires-Klauseln gewesen, mit denen du dann "modular type checking" bekommt. Die Templates können daraufhin auf ihre "Korrektheit" überprüft werden, bevor sie überhaupt instantiiert. Und der Anwender eines solchen Templates bekommt auch eine Fehlermeldung, wenn er bestimmte Bedingungen nicht erfüllt. Man kann also die Schuld jemandem zuweisen, dem Template-Autor oder dem Template-Nutzer.

template<typename T>
  requires some_interface<T>
void foo(T & obj)
{
  obj.a(23);
  obj.c(3.14f);
}

Abkürzungs-Syntax:

template<some_interface T>
void foo(T & obj)
{
  obj.a(23);
  obj.c(3.14f);
}

Die Constraints beschränkten sich auch nicht auf Elementfunktionen, sondern umfassten auch "assoziierte Typen" sowie freie Funktionen. Beispiel:

concept Swappable<typename T>
{
  void swap(T&,T&);
}

oder auch

concept PointerLike<typename T>
  : DefaultConstrucbible<T>
  , MoveConstructible<T>
  , MoveAssignable<T>
{
  typename reference_type;   // assoziierter Typ

  reference_type operator*(T);    // Dereferenzierung
}

Und Concepts beschränkten sich auch nicht auf einen Parameter. Man konnte darin z.B. auch Beziehungen zwischen mehreren Typen ausdrücken:

concept Assignable<T,U>
{
  T& T::operator=(U);
}

Ich bin mal gespannt, was das noch gibt. Bin aber auch froh, dass das wieder aus dem C++0x Entwurf rausgeflogen ist. Das haben ja nichtmal 3% des Kommittees verstanden. Ich habe das 2-3 Jahre lang verfolgt, die Papers gelesen und versucht zu verstehen. Was für ein komplizierter Scheiß das war ... Es hat auch nicht besonders toll mit dem einen oder anderen C++11-Feature interagiert -- z.B. mit Rvalue-Referenzen.

Irgendwie erscheint mir das geistig "quer" (weil die Interface-Garantie nicht teil der Implementierung ist), da verstehe ich etwas noch nicht.

Muss sie das explizit angeben? Ich finde dieses Compile-Time-Duck-Typing gar nicht schlecht. Zumindest muss es "auto-Konzepte" geben. Keiner will an jeden Typen extra dranschreiben müssen, dass er kopierbar, zuweisbar, default-konstruirbar ist u.s.w. Das verrät einem die Schnittstelle ja schon. "auto concepts" sind dann solche, die sich automatisch auf alles übertragen, was "strukturell" passt. Im vorherigen Posting hätte ich z.b. mindestens bei bei Swappable und Assignable ein "auto" davor setzen müssen, weil ich nicht für jeden Typen extra per concept_map sagen will, dass man ein swap aufrufen kann oder eine Zuweisung durchführen kann. Das ergibt sich ja schon aus der Schnittstelle.

Man unterscheidet da zwischen Bedingungen, die rein "strukturell" sind und semantischen Bedingungen. Wenn ich ein swap für ein T aufrufen kann, dann reicht mir das. Das ist der strukturelle Teil. Der semantische Teil eines solchen Constraints würde dann sagen "wenn man dieses swap ausführt, wird auch tatsächlich der Inhalt/die Werte der beiden Objekte getauscht". Das lässt sich nicht in Code aufschreiben und deswegen gab es auch die Möglichkeit Konzepte so zu definieren, dass man doch explizit sagen muss, welche Typen alle dieses Konzept modellieren.

Ein Haken bei der ganzen Concepts-Geschichte war, dass man viel zu viel Code schreiben musste. Ich will kein "modular typechecking" haben, wenn ich dafür viel viel mehr Code schreiben muss.

Ach, eins, was Concepts ermöglichen sollte, was wir aber noch nicht genannt haben, war "concept-based overloading", also:

template<ForwardIterator Iter>
void advance(Iter & iter, Iter::difference_type step)
{
  assert(step>=0);
  while (step>0) {
    ++iter;
    --step;
  }
}

template<BidirectionalIterator Iter>
void advance(Iter & iter, Iter::difference_type step)
{
  while (step>0) {
    ++iter;
    --step;
  }
  while (step<0) {
    --iter;
    ++step;
  }
}

template<RandomAccessIterator Iter>
void advance(Iter & iter, Iter::difference_type step)
{
  iter += step;
}

Das macht man im Moment per "tag dispatching", aber dieses concept-based overloading wär natürlich ein netter Ersatz dafür.

Also alles in allem ... die Ziele von Concepts waren hoch gesteckt. Kurzfassung: Ein Typsystem für Typen.