C++1y

314159265358979

http://herbsutter.com/2012/03/08/trip-report-february-2012-c-standards-meeting/

Ethon

5 Jahre für eine große Sprachextension? Wtf?

krümelkacker

Mir fehlt eigentlich nicht viel an Sprachkern-Features. Das meiste von dem, was vorgeschlagen wurde, kommt mir sehr komisch vor. Aber ich bin mal gespannt, was aus Concepts und Modules wird.

rüdiger

Ich finde es gut, dass die Sprachentwicklung nicht wieder einschläft, so wie es nach C++98 war. Module&Concepts hab ich schon in C++11 vermisst. Wie der aktuelle Vorschlag für Concepts aussieht, hat Stroustrup bei GoingNative präsentiert http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/A-Concept-Design-for-C-

Bei Modulen meinten sie in der Fragerunde, dass sie noch keine genaue Vorstellung haben, was ein Modul sein soll und wie das ganze Aussieht. Ich hoffe, dass sie hier auf eine Lösung kommen, die auch von den Compilerherstellern getragen wird.

Artchi

So lange die elenden Headers verschwinden, ist es mir egal was ein Module sein soll. Ich erwarte von den Modules einfach, das ich nur noch *.cpp-Dateien pflegen muß, und gut.

Wenn dann noch zusätzliche Features dazu kommen, soll es mir Recht sein.

rüdiger schrieb:

Bei Modulen meinten sie in der Fragerunde, dass sie noch keine genaue Vorstellung haben, was ein Modul sein soll und wie das ganze Aussieht.

Vielleicht sollten sie einfach mal über den Tellerrand schauen.

Oder gibt es ernsthafte Schwierigkeiten, warum ein Compiler/Linker für C++ nicht mit Modulen zurechtkommen sollte?

knivil

Das kommt auf die Anforderungen an Module an, was sollen sie leisten. Auch in anderen Sprachen tut man sich schwer mit Modulsystemen.

Worauf ich mich freue: Continuations in C++ als Standardbibliothek. Herb Sutter hat davon gesprochen, mal schauen, wie die fuer C++ aussehen werden.

Nexus

ModuleBitte schrieb:

Oder gibt es ernsthafte Schwierigkeiten, warum ein Compiler/Linker für C++ nicht mit Modulen zurechtkommen sollte?

Ich schätze, dass man dafür recht viele der bisherigen Regeln bezüglich Deklaration/Definition, ODR, Linkage etc. über den Haufen werfen müsste. Du kannst das nicht mit anderen Sprachen vergleichen, wo Module schon von Anfang an dabei waren.

Bei Concepts habe ich den grossen Nutzen noch nicht erkannt. Bereits in C++98 kann man sehr viel mit impliziten Konzepten (aka Ducktyping) arbeiten, in Boost passiert das z.B. andauernd. Mit static_assert werden auch die Fehlermeldungen bereits besser. Aber vielleicht sollte ich das Video schauen...

cooky451

Na ja, wofür man halt IMO eine Lösung finden sollte, ist das hier (kann sein, dass Concepts das abdecken)

// Normale Funktion
void do_smth1(foo* f)
{
  f->yay();
}

int main()
{
  bar b;
  do_smth1(&b); // Fehler beim Aufrufen
}

// Template
template <typename T>
void do_smth2(T* f)
{
  f->yay();
}

int main()
{
  bar b;
  do_smth2(&b); // Fehler erst im Template!
}

Man kann da zwar irgendwie Gegensteuern mit enable_if, static_assert, CRTP etc., aber das Gelbe vom Ei ist das nicht.

Nexus

Mich stört an Concepts, dass immer ein wenig schönere Fehlermeldungen* als vorderstes Argument angeführt werden (so habe ich es jedenfalls erlebt). Nur dafür scheint mir die Komplexität nicht gerechtfertigt. Allerdings muss ich mich wie angetönt noch genau mit dem Sprachmittel befassen.

_______
"Fehler erst im Template" ist meiner Meinung nach kein grosses Problem, da man beim 1. Klick gleich auf die Zeile kommt und sieht, dass eine nicht vorhandene yay() -Methode aufgerufen wird, und man beim 2. Klick auch noch den "instanziiert in main() "-Hinweis und die entsprechende Codestelle sieht. Mit static_assert wäre auch eine aussagekräftige Fehlermeldung möglich.

Ethon

Ich finde die Concept-Spezialisierungen echt toll. Dann kann endlich jeder zb. die String-Klasse verwenden die er möchte anstatt dass permanent rumkopiert werden muss. Und da gibts viele weitere Einsatzzwecke.

concept string<typename T>
{
    typename char_type;
    char_type const* c_str();
    std::size_t len();
};

template<typename T>
concept_map string<std::basic_string<T>>
{
    typedef T char_type;

    char_type const* c_str(std::basic_string<T> const& str)
    {
        return str.c_str();
    }

    std::size_t len(std::basic_string<T> const& str)
    {
        return str.size();
    }
};

template<typename T>
concept_map string<T const*>
{
    typedef T char_type;

    char_type const* c_str(char_type const*& str)
    {
        return str;
    }

    std::size_t len(char_type const*& str)
    {
        return std::strlen(str);
    }
};

Das wäre nach meinem Verständnis (durch Wikipedia) ein Concept, um einen c-String und einen STL-String gleich ansprechen zu können.

314159265358979

concept_maps wurden bei der neuen Version rausgeschmissen, afaik.

rüdiger

Das Problem ist ja nicht unbedingt, wenn man das Template direkt selbst instantiiert. Es wird nur sehr verwirrend, wenn man nach mehreren Ebenen (zB 30 Templates) auf ein Problem stößt, dass tief in einer anderen Bibliothek versteckt ist. zB fehlt auf einmal ein operator+(T,int), weil irgend wo erwartet wird, dass man einen Randomaccessibleiterator oder gar einen Randomaccessiblecontainer hätte übergeben sollen. Das kann man auch mit static_assert sehr schwer ausdrücken. Man kann damit ja nicht die Verfügbarkeit des operators prüfen. Über irgend welche hacks kann man zwar sogar prüfen ob ein spezifischer member existiert (siehe Boost.MPL has_xxx). Aber das funktioniert dann wieder nicht bei Non-membern (operator+ ist ja normalerweise kein member).

Alternativ zu Templates gibt es einen "static if"-Vorschlag. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf (Gibt dazu auch einen Vortrag bei GoingNative). Wobei mir das Concepts-Proposal deutlich besser gefallen hat.

Nexus

rüdiger schrieb:

zB fehlt auf einmal ein operator+(T,int), weil irgend wo erwartet wird, dass man einen Randomaccessibleiterator oder gar einen Randomaccessiblecontainer hätte übergeben sollen. Das kann man auch mit static_assert sehr schwer ausdrücken.

Warum? Man kann auf Ebene des Algorithmus mit static_assert sicherstellen, ob die Iteratoren die richtige Kategorie haben. Falls nicht, kommt es gar nicht erst zum +.

Klar setzt sowas eine konsequente Überprüfung von Compilezeit-Bedingungen voraus, aber Gleiches gilt für Concepts.

cooky451

Nexus schrieb:

"Fehler erst im Template" ist meiner Meinung nach kein grosses Problem, da man beim 1. Klick gleich auf die Zeile kommt und sieht, dass eine nicht vorhandene yay() -Methode aufgerufen wird, und man beim 2. Klick auch noch den "instanziiert in main() "-Hinweis und die entsprechende Codestelle sieht. Mit static_assert wäre auch eine aussagekräftige Fehlermeldung möglich.

Nun ja, es stört mich einfach auf 2 Ebenen:
- Es widerspricht meinem Gefühl von Typsicherheit (Polymorphie einbezogen), dass man ein Objekt mit garantierten Fähigkeiten bekommt. Dass das auch so ist (man ein solches Objekt erhält) sollte in den Verantwortungsbereich der aufrufenden und nicht in den der aufgerufenen Ebene fallen.
- Es ist nervig an so etwas immer denken zu müssen, es gibt kein einheitliches Mittel dafür und eigentlich sind das alles irgendwo Hacks.

hustbaer

Ethon schrieb:

Das wäre nach meinem Verständnis (durch Wikipedia) ein Concept, um einen c-String und einen STL-String gleich ansprechen zu können.

Das kann man doch im Prinzip jetzt schon haben, nur halt mit weniger Checks und weniger hübscher Syntax.

template <class T>
struct string_concept
{
    typedef T string;
    typedef typename T::char_type char_type;

    static char_type const* c_str(string const& str)
    {
        return str.c_str();
    }

    static std::size_t len(string const& str)
    {
        return str.len();
    }
};

template <class C, class A>
struct string_concept<std::basic_string<C, A>>
{
    typedef std::basic_string<C, A> string;
    typedef C char_type;

    static char_type const* c_str(string const& str)
    {
        return str.c_str();
    }

    static std::size_t len(string const& str)
    {
        return str.size();
    }
};

template <class C>
struct string_concept<C const*>
{
    typedef C const* string;
    typedef C char_type;

    static char_type const* c_str(string str)
    {
        return str;
    }

    static std::size_t len(string const& str)
    {
        return strlen(str);
    }
};

Nexus

Ich habe jetzt den Vortrag auf GoingNative geschaut. Andrew Sutton stellt um etwa 0:50:00 seine Bibliothek Origin vor, die Concepts in C++11 mittels Static Assert und Template Aliases emuliert. Auf die Frage hin, warum es dann trotzdem Concepts brauche (0:57:38), antwortet Bjarne Stroustrup, dass die Überprüfung schon beim Aufruf und nicht erst bei der Template-Instanziierung stattfindet. Das ginge zwar momentan auch mit enable_if , aber die Fehlermeldungen sind dann weniger schön.

Ein paar Dinge sehen aber interessant aus, z.B. Überladung anhand Concepts (z.B. Iteratorkategorien) und die kompakte Syntax ohne requires . Axiome scheinen auch viel Potenzial zu haben. Wenn es irgendwann möglich sein sollte, dass der Compiler dadurch fehlende Operatoren ergänzen oder sogar semantische Analysen zur Optimierung verwenden könnte, wäre das natürlich sehr nett.

Es gibt aber auch noch Probleme mit Concepts, z.B. bei std::inner_product() , wo die Concept-Version des Algorithmus komplett unleserlich ist und nichts mehr über die Intention aussagt. Vielleicht sollte man nicht auf Biegen und Brechen versuchen, überall Concepts anzuwenden...