Concepts for C++
Wieder mal ist ein Semester zu Ende, und ich habe auch wieder ein Seminar belegt und ein zugehöriges Paper geschrieben. Hier das Abstract:
C++ templates are a powerful language construct that enable generic programming techniques without impacting runtime performance. A problem when using templates is the lack of an explicit contract between the user and the definition of a template. This leads to difficult to understand error messages and inhibits separate checking of template code.
Concepts are part of the next C++ standard and mitigate these problems. Concepts express explicit requirements to template argument types, thus allowing separate checking. Other benefits include syntactical adaption of existing types, making code more reusable.
This paper introduces concepts and shows how existing code can be refactored to use concepts, making the code easier to understand.
7 comments on “Concepts for C++”
Leave a comment
You must be connected to write a comment.


Ich habe das ganze Paper schnell in 5min überflogen, also hängt mich nicht auf, wenn ich was nicht ganz verstanden habe. Soeweit ich das sehe, kann mit den C++ concepts voreausgesetzt werden das T eine bestimmte Methode hat? Du hast ja ein Vergleich zu Java und C# gemacht. Vielleicht sollte man kurz erwähnen, dass es in C# auch das keyword “where” gibt. Will man mit Generics also zwei Objekte vergleichen können, könnte die Generics Klasse/Methode auch wie folgt deklariert werden:
public class XY where T : IComparable
{
}
womit T IComparable Unterstützung hat….
Wäre statt auf Methodenebene halt auf Klassen/Interface Ebene, was oft nicht schlechter ist:)
Ich bin jedenfalls froh, mich weniger mit C++ Templates herumschlagen zu müssen. C# Generics finde ich recht gut und ab C# 4.0 mit contravariance in Interfaces und Delegates (hoffe ich habe das richtig in Erinnerung)
Gruss
Rolf
Sali Rolf!
Ja du hast das richtig erfasst. In deinem Beispiel, was ist, wenn die Klasse das Interface nicht implementiert? Mit Concepts ist das kein Problem, du kannst auch fehlende Funktionen nachimplementieren.
Könnte den C# Teil natürlich schon noch ausbauen, aber was ich ja gesagt habe ist, dass C# wie Java eben auch auf Interfaces baut.
Dann programmierst du unterdessen kein C++ sondern C#?
T muss IComparable implementieren, sonst gibt es einen Compilerfehler. Das mit dem Nachimplementieren in C++ schnall ich nicht ganz…?
Das letzte Projekt war nur in C#, das neue ist gemischt. VoIP Teil in C++, der Rest in C#.
Wenn T eben nicht IComparable implementiert, dann kann ich es in einer Concept Map nachimplementieren, ohne dass ich T selbst anpassen muss. Und das kann ja durchaus vorkommen, wenn T aus einer Library kommt und mit einer anderen Library zusammenarbeiten soll.
Ausserdem funktioniert where in C# nur umständlich mit operatoren, glaube ich mal gelesen zu haben.
Ok, das mit dem 3rd Party Nachimplementieren ist ein guter Punkt. Evt., wenn nicht sealed, würde ich halt davon ableiten und damit das Interface nachimplementieren, aber machmal ist das keine Option. Kann man mit C++ Concepts auch mehrere Methoden voraussetzen?
Das mit den Operatoren kann sein, war für mich aber bis jetzt nie ein Problem. Brauchte aber auch nicht viel Mathe
Wenn C# ihre Extension Methods endlich mal so ausbaut, dass man nicht nur Methoden, sondern auch properties, static methods/properties und interfaces im nachhinein dazuimplementieren könnte, wäre sowas auch kein Problem mehr. Ruby kann das recht elegant (auch ein Interface in einer bestehenden Klasse nachimplementieren?)
Klar, du kannst beliebige member functions, free functions, Konstruktoren, etc. voraussetzen. Die ganze Standard-Library wird auch umgebaut werden um Concepts zu benutzen. Der User merkt vielleicht gar nicht viel davon, ausser dass die Fehlermeldungen mit Templates nun endlich lesbar sind
Ruby und C# zu vergleichen ist aber nicht sehr fair
dynamische Typisierung macht vieles sehr viel einfacher, man kann sich aber auch schnell in den Fuss schiessen, wenn man nicht aufpasst.
DIe Roadmap von C# sieht auch immer mehr dynamische Möglichkeiten vor (z.B. dynamic methods in C# 4.0), aber wer weiss, ob sowas dann nicht kontraproduktiv ist und die Sprache “zur Sau” macht, so quasi, wie das mit C zu C++ über die Jahre hinweg passiert ist. In C# 1 gab es keine Generics und ich habe drüber geflucht, dass es erst zur Laufzeit so viele Cast-Exceptions gab. Mit Dynamic Methods könnte sowas wieder passieren… Da muss den Entwicklern wieder auf die Finger geklopft werden, falls sie diese Möglichkeit missbrauchen