C++0x doch ohne Concepts

Laut einem Artikel von Danny Kalev sei am 13.7.2009 beim Kommitee-Treffen in Frankfurt entschieden worden, Concepts wieder aus dem Entwurf zu schmeißen.

Mehr fällt mir dazu im Augenblick auch nicht ein.

Gruß,
SP

audacia

volkard

Interessant.

Badestrand

Fällt damit nicht auch die foreach-Schleife weg? Ich meine mal gehört zu haben, dass sie auf Concepts beruht.

Nexus

Sebastian Pizer schrieb:

Mehr fällt mir dazu im Augenblick auch nicht ein.

Ist vielleicht nicht das Schlechteste. Viele befürchten ja, dass ein so riesiges Sprachfeature, das auf einen Schlag hinzugefügt wird, zu Problemen führen könnte. Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Naja, ich kann das natürlich auch nicht genau beurteilen, aber mir ist es lieber, wenn ich noch ein wenig warte, und dafür eine sauberere und durchdachtere Implementierung habe. Zumal Concepts nicht unbedingt das Feature ist, nach dem ich mich schon seit Ewigkeiten sehne...

volkard

Badestrand schrieb:

Fällt damit nicht auch die foreach-Schleife weg? Ich meine mal gehört zu haben, dass sie auf Concepts beruht.

du hast doch noch auto und decltype.
das allein genügt.
#define foreach(cont) for(decltype(cont)::iterator i=cont.begin(),e=cont.end;i!=e;++i)
oder
#define foreach(cont) for(auto i=cont.begin(),e=cont.end;i!=e;++i)

Dravere

Tja, schade. Wobei ich die Argumente durchaus verstehen kann. Immerhin muss man nun nicht mehr 2 Bücher für einen C++ Lernkurs einplanen, sondern nur noch 1 - 1,5 Bücher
Vielleicht wäre es echt eine Idee, die Sache deutlich zu schrumpfen und es viel mehr als Hilfe für Templates zu bauen und nicht als komplettes, zusätzliches, neues und ergänzendes Sprachfeature.

Ich würde es zum Beispiel sehr schätzen, wenn ein Konzept von einem Funktionstemplate oder Klassentemplate automatisch erstellt würde. Irgendsowas muss der Parser und Kompiler im Hintergrund sowieso bereits haben. Und darauf dann nur noch eine Art von concept_map für das entsprechende umbiegen. Das wäre einfacher für den Programmierer und bereits etwas sehr tolles.

Grüssli

Nexus schrieb:

Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Das sind ja auch gute Gründe.

Nexus schrieb:

Zumal Concepts nicht unbedingt das Feature ist, nach dem ich mich schon seit Ewigkeiten sehne...

Naja, "modular type checking for templates" -- wie es Doug Gregor in seinem Vortrag nannte -- wäre schon nett gewesen. Nicht nur, um die ätzenden Fehlermeldungen loszuwerden, sondern auch als Ersatz für all die Template-Tricks (SFINAE,...).

Welches sind denn Eure Top 3 C++0x Sprach-Features? Von dem, was noch übrig ist, würde ich sagen: Rvalue-Referenzen, Variadische Template und Typinferenz (auto, decltype).

Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

volkard schrieb:

du hast doch noch auto und decltype.

Ja, damit würde es gehen. Ich würde aber immernoch den "Umweg" über eine Traits-Klasse (als Concept/Concept Map-Ersatz) machen. Also in etwa so:

for ([i]#1[/i] : [i]#2[/i]) {
  [i]#3[/i]
}

==[ersetzen durch]==>

{
  auto && _range = [i]#2[/i];
  typedef typename remove_reference<decltype(_range)>::type __RangeType;
  typedef range_traits<__RangeType> __RangeTraits;
  for (auto _beg = __RangeTraits::begin(_range),
            _end = __RangeTraits::end(_range);
       _beg != _end; ++_beg)
  {
    [i]#1[/i] = *_beg;
    [i]#3[/i]
  }
}

volkard

Sebastian Pizer schrieb:

Welches sind denn Eure Top 3 C++0x Sprach-Features? Von dem, was noch übrig ist, würde ich sagen: Rvalue-Referenzen, Variadische Template und Typinferenz (auto, decltype).
Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

Genau. Diese vier sind es.
Und: Compilezeitaufrufbare Funktionen.

Sebastian Pizer schrieb:

==[ersetzen durch]==>

Das ist "Jede Sprache, die was taugt, tendiert dazu, Lisp zu sein".
Ja, ich hätte gerne Zugriff auf den Parsebaum und würde ihn frei ummodeln können. Aber ich habe zugleich auch Angst davor.

Dravere

Sebastian Pizer schrieb:

Welches sind denn Eure Top 3 C++0x Sprach-Features?

Alles?

Also von neuen Sprachfeatures:
1. auto, decltype -> vielleicht in diesem Zusammenhang auch die neue Funktionsdeklaration.
2. variadic templates
3. Lambda Funktionen

Bibliothekfeatures:
1. Bind/Functions (wobei das natürlich schon im tr1 dabei ist)
2. Threads
3. Futures (oder gehört das zu Threads?)

Aber der ganze Rest ist natürlich auch toll. Gibt glaub ich kein neues Feature, auf welches ich mich nicht freue.

Grüssli

volkard schrieb:

Sebastian Pizer schrieb:

==[ersetzen durch]==>

Das ist "Jede Sprache, die was taugt, tendiert dazu, Lisp zu sein".
Ja, ich hätte gerne Zugriff auf den Parsebaum und würde ihn frei ummodeln können. Aber ich habe zugleich auch Angst davor.

Hä? Die Idee von dem for-range loop war schon immer, dem Compiler vorzuschreiben, dass er eine solche (oder äquivalente) Ersetzung durchführen soll, sofern der Typ von _range kein Array oder keine Initializer-List ist. Ich habe lediglich das Concept Range<X> durch die Traits-Klasse range_traits<X> ersetzt.

Gruß,
SP

volkard

Sebastian Pizer schrieb:

Hä?

Ups, bin über das Ziel hinausgeschossen.
Ich wünsche mir seit Jahren, daß man das "==[ersetzen durch]==>" selber definieren kann. Ich habe eh ganz andere Wünsche als mein Nächster. Die best practices kann man ja dann standardisieren.
Jede Einführung von mehr Compilermagie-Klassen lehne ich dagegen ab. std::string aus std::exception aus new bringt mich regelmäßig zum weinen.

audacia

Sebastian Pizer schrieb:

Nexus schrieb:

Man hat nicht besonders viel Erfahrung damit (soweit ich weiss, nur ein paar Prototypen wie ConceptGCC), und könnte einiges riskieren.

Das sind ja auch gute Gründe.

Die wesentlichen, IMHO. Genau derselbe Fehler wie bei export.

Sebastian Pizer schrieb:

Welches sind denn Eure Top 3 C++0x Sprach-Features?

Lambda-Funktionen, Typinferenz, Variadic Templates.

hustbaer

volkard schrieb:

std::string aus std::exception aus new bringt mich regelmäßig zum weinen.

Äääääh? Wo bekommst du nen std::string aus ner std::exceptions???
what() gibt nicht ohne Grund nen char const* zurück...

pumuckl

Sebastian Pizer schrieb:

Wovon ich nicht so richtig überzeugt bin ist "thread_local" als Speicherklasse.

Naja, wie es ausschaut haben die ThreadLocal in Java (und anderen Sprachen?) genügend beeindruckt ums auch in C++ zu übernehmen

Artchi

Ich bin überrascht, das doch noch was (größeres) raus fliegt. Interessant und hilfreich wären sie ja auf jeden Fall gewesen. Aber es ist kein Beinbruch.

Was ich mir auf jeden Fall wünsche sind neue Bibliotheken. Sprachfeatures haben wir eigentlich genug. Man kann immer wieder was verbessern, ich finde z.B. Lambdas und das auto-Keyword super.

Aber freuen würde ich mich wenn endlich mal die Std-Lib erweitert wird. Und nein, nicht um GUI o.ä. Sondern um Filesystem, Date and Time und Netzwerk. Das was man auf jedem System (Desktop, Server und Embedded) am ehesten benötigt. Die Thread-Lib in C++0x ist schon mal ein sehr guter Anfang. Ich hoffe das bald C++0x endlich verabschiedet wird und es ruck zuck an TR2 geht!

drakon

Artchi schrieb:

Aber freuen würde ich mich wenn endlich mal die Std-Lib erweitert wird. Und nein, nicht um GUI o.ä. Sondern um Filesystem, Date and Time und Netzwerk. Das was man auf jedem System (Desktop, Server und Embedded) am ehesten benötigt. Die Thread-Lib in C++0x ist schon mal ein sehr guter Anfang. Ich hoffe das bald C++0x endlich verabschiedet wird und es ruck zuck an TR2 geht!

Das sehe ich gleich. Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt. Wohingegen man bei einem Filesystem (rein Sprachbezogen) aufgeschmissen ist. Man muss auf externe Bibliotheken zugreifen (oder nat. alles selbst schreiben). Aber wie du schon sagst ist Thread alleine schon sehr nett. Vor allem als Basis von Netzwerken.

audacia

drakon schrieb:

Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt.

Gerade bei Lambda-Funktionen finde ich das Argument unangebracht. Workarounds wie boost.lambda sind oftmals eher eine Last denn eine Hilfe; das Scope-Capturing läßt sich nunmal nicht mit Bibliotheksfeatures simulieren. Ähnliches gilt für BOOST_TYPEOF.

Bibliothekserweiterungen sind schön und gut, aber real viel zu spät - mittlerweile verwendet ohnehin jeder seinen ganz persönlichen Workaround. Viel wichtiger finde ich die Erweiterung der Sprachmöglichkeiten, also Dinge, die man nicht über externe Bibliotheken nachrüsten kann.

drakon

audacia schrieb:

drakon schrieb:

Obwohl lambda und co. ganz toll sind, "braucht" man sie nicht wirklich, da man das es (meist) Lösungen mit dem aktuellen Standard gibt.

Gerade bei Lambda-Funktionen finde ich das Argument unangebracht. Workarounds wie boost.lambda sind oftmals eher eine Last denn eine Hilfe; das Scope-Capturing läßt sich nunmal nicht mit Bibliotheksfeatures simulieren.

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

audacia

drakon schrieb:

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Diese Argumentation führt zwangsläufig zu C zurück. Oder ziehst du eine willkürliche Grenze?

drakon

audacia schrieb:

drakon schrieb:

Ja, aber ich meinte, dass man es nicht wirklich braucht. Man hat dann halt eine etwas unleserliche Syntax und mehr arbeit, wenn man halt einen Funktor schreiben muss, aber grundsätzlich geht das, was man erreichen will. Keine Frage es ist umständlicher und Mehrarbeit, aber es geht.

Diese Argumentation führt zwangsläufig zu C zurück. Oder ziehst du eine willkürliche Grenze?

Das führt noch weiter zurück. - Nein, nicht willkürlich, aber irgendwo muss eine Balance her. Mir persönlich brächte es mehr, wenn ich eine anständige Lib für Netzwerk an die Hand gelegt bekäme, als eine Lib, die es mir ermöglicht lambda Funktionen zu schreiben. Die Grenze ist natürlich subjektiv und hängt auch ab, in welchem Bereich man vor hat die Features zu nutzen..

Stell dir das umgekehrte vor. Du hast eine Sprache, die dir etliche Sprachfeatures bietet, jedoch nicht einmal eine Bibliothek für String Verarbeitung bietet. Auch nicht so toll, oder?