[X] C++09 (Teil 1) - Ein Überblick: Neue Sprachfeatures

queer_boy

Mach ich, (nach dem Mittagessen), die Stelle über Variadic-Templates hab ich jetzt auch nochmal überarbeitet.

CStoll

Ich geb gleich zu, daß ich einige Teile nur überflogen habe. Aber auf den ersten Blick sieht es schon interessant aus.

Aber:

die rohen String-Literale müsstest du eventuell genauer erklären.
ergänzt man mit der Concept-Map eigentlich die Schnittstelle einer Klasse? (Sprich: Könnte ich auch "MyString sum = concatenate(str1,str2);" schreiben?)
was genau bedeutet "PODs sind nicht mehr von der Definition von Aggregattypen abhängig."? Kann etwas ein POD sein, was nicht-POD Datenelemente enthält? Wenn ja, wie wird da die Kompatibilität zu C structs sichergestellt?

(btw, Sachen wie variadic Templates oder automatische Typerkennung klingen auf jeden Fall interessant, bei der neuen Funktionsdefinition bin ich etwas skeptisch (auch wenn sie mich an Pascal (FUNCTION test(...) : int) erinnert - aber das ist eine Sache der Gewohnheit))

Artchi

Vielen Dank für die Arbeit! Endlich mal ne deutsche Übersicht zu den neuen Features. Habe zwar immer englische Texte dazu gelesen, aber so liest es sich deutlich leichter. **zensiert** Ich finde, da sind echt knallharte Neuerungen mit bei, die die anderen Sprachen nicht bekommen würden (wenn dann auch nur alle 10 Jahre).

Egal, ich finde die Übersicht super.

Die Library-Neuerungen kann und sollte man ruhig in einen anderen Artikel packen. Sonst wird es auch schwer zu lesen sein, weil man elend lange scrollen muß.

Artchi schrieb:

Auch bekommen endlich mal die Nörgler ("Boh, sind die langsam und das wird nie was!") zu sehen, das nicht wie bei Java u.a Sprachen mit jeder version Mini-Änderungen kommen.

Kannst du den Scheiss nichtmal in der Redaktion lassen? Echt arm...

Artchi

Ist zensiert.

Artchi schrieb:

Wieso?

Weil du derjenige bist, der sich immer über Flamer und Trolle aufregt, aber selbst einer der größten Flamer bist. Das ist einfach nur zum kotzen.

Artchi schrieb:

Fühlst du dich angesprochen?

Wenn du nicht komplett blind durch das Forum laufen würdest, wüsstest du, dass ich C-Vertreter bin. Und da man bei C dasselbe Standardisierungdingens macht kann ich mich hier wohl kaum angesprochen fühlen.

@ alle anderen. Tut mir leid dass ich das überhaupt kommentiert habe. Ignoriert es am besten

phlox81

Guter Artikel. Allerdings könnte man aus dem Aktuellen Text imho schon gut 2 Artikel machen.

queer_boy

CStoll schrieb:

die rohen String-Literale müsstest du eventuell genauer erklären.

gesagt getan. das hindernis daran war wohl, dass es diejenige neuerung ist, die mich am wenigsten interessiert ^^' (von den angesprochenen)

was genau bedeutet "PODs sind nicht mehr von der Definition von Aggregattypen abhängig."? Kann etwas ein POD sein, was nicht-POD Datenelemente enthält? Wenn ja, wie wird da die Kompatibilität zu C structs sichergestellt?

durch neue definitionen. wenn man im standard "aggregat" hört, bezieht sich das hauptsächlich auf die art, wie es initialisiert werden kann - nämlich wie c-structs mit { 1, 2, 3 }. (das ist erstens wohl sowieso bald überflüssig und geht zweitens ein bisschen an der intention von POD vorbei) - man definiert POD nun über (1) triviale typen und (2) standard-layout-typen. hab das allerdings schon im artikel klarer deutlich gemacht. die definition ist ähnlich geblieben, nur nicht mehr direkt von der definition von aggregat abhängig.

(btw, Sachen wie variadic Templates oder automatische Typerkennung klingen auf jeden Fall interessant, bei der neuen Funktionsdefinition bin ich etwas skeptisch (auch wenn sie mich an Pascal (FUNCTION test(...) : int) erinnert - aber das ist eine Sache der Gewohnheit))

mich erinnert die sehr an (S)ML. dort sieht das beinahe gleich aus [ok, beinahe: (int * int) -> int]

[*]ergänzt man mit der Concept-Map eigentlich die Schnittstelle einer Klasse? (Sprich: Könnte ich auch "MyString sum = concatenate(str1,str2);" schreiben?)

ich halte ja concepts für die größte neuerung im kernbereich der sprache, gefolgt von variadic templates.

stroustrup (auf den geht das proposal afaik zurück) hat eine schöne analogie: eine concept-map ist wie die berühmte rosa brille, mit der die welt so gesehen wird, wie man sie braucht. d.h. wenn ein concept eine bestimmte schnittstelle braucht, sieht es sie entweder direkt über die implizite concept-map, die jedes interface darstellt; oder durch eine selbstdefinierte concept-map, die funktionen umbiegt.

bei der neuen for-schleife habe ich das ein bisschen angeschnitten. diese ist abhängig von einem konzept, dass in <iterator_concept> definiert wird: Range.
das sieht so aus:

concept Range <typename T>
{
    typedef InputIterator iterator;
    iterator begin (T&);
    iterator end (T&);
};

für arrays und container sind jetzt concept-maps angelegt, die so aussehen:

template <Container C> //Container ist selbst ein concept
concept_map Range <C>  //Das ist also eine "Spezialisierung" für alle Container
{
   typedef C::iterator iterator; //Übersetze in die Begriffe von concept Range
   iterator begin (C& c) { return c.begin(); }
   iterator end (C& c) { return c.end(); }
};

die for-schleife ist jetzt selbst so implementiert:

for (Element: range)
{
   //...
}

//wird zu:
typedef decltype(range) range_t;

for (Range<range_t>::iterator i = Range<range_t>::begin(range); i != Range<range_t>::end(range); ++i)
{
   Element = *i;
   //...
}

zumindest von der semantik her. Das Range ist über die concept_map für Container spezialisiert und falls range einen container darstellt, dann wird für Range<range_t>::begin(range) einfach range.begin() aufgerufen (steht ja so in der concept_map)

(in wahrheit ist der code für die expandierte neue for-schleife noch etwas mit rvalue-Referenzen aufgepeppt und optimierter)

queer_boy

phlox81 schrieb:

Guter Artikel. Allerdings könnte man aus dem Aktuellen Text imho schon gut 2 Artikel machen.

das habe ich mir auch schon überlegt. nur wo? die hälfte des artikels liegt ungefähr bei 2.1., allerdings wäre vom inhalt her eine trennung zwische 1/2 und 3 besser.
nur leider verweise ich auch quer durch den artikel (von 1.8 auf 3.2 usw.) - also thematisch ist alles irgendwie voneinander abhängig. von daher würde ich mir schwer tun, ihn zu teilen.

neben der alternative, ihn so zu lassen (es gab auch schon mal artikel in ähnlicher länge), könnte man noch sachen kürzen.

sothis_

queer_boy schrieb:

phlox81 schrieb:

Guter Artikel. Allerdings könnte man aus dem Aktuellen Text imho schon gut 2 Artikel machen.

das habe ich mir auch schon überlegt. nur wo? die hälfte des artikels liegt ungefähr bei 2.1., allerdings wäre vom inhalt her eine trennung zwische 1/2 und 3 besser.
nur leider verweise ich auch quer durch den artikel (von 1.8 auf 3.2 usw.) - also thematisch ist alles irgendwie voneinander abhängig. von daher würde ich mir schwer tun, ihn zu teilen.

neben der alternative, ihn so zu lassen (es gab auch schon mal artikel in ähnlicher länge), könnte man noch sachen kürzen.

da ich nicht die große ahnung von c++ habe, und es mich wohl auch nie interessieren wird habe ich den artikel auch nur überflogen. ich persönlich finde ihn vom umfang her akzeptabel

CStoll

queer_boy schrieb:

CStoll schrieb:

die rohen String-Literale müsstest du eventuell genauer erklären.

gesagt getan. das hindernis daran war wohl, dass es diejenige neuerung ist, die mich am wenigsten interessiert ^^' (von den angesprochenen)

Ja, jetzt wird's klarer - haben die Zeichen zwischen " und [ eigentlich eine Funktion oder werden sie vom Compiler zerstört? (und gibt es eine Möglichkeit, das Endezeichen ] im rohen String zu verwenden (z.B. wenn ich BBCode-Fragmente analog zu deinem HTML-Beispiel unterbringen will)

was genau bedeutet "PODs sind nicht mehr von der Definition von Aggregattypen abhängig."? Kann etwas ein POD sein, was nicht-POD Datenelemente enthält? Wenn ja, wie wird da die Kompatibilität zu C structs sichergestellt?

durch neue definitionen. wenn man im standard "aggregat" hört, bezieht sich das hauptsächlich auf die art, wie es initialisiert werden kann - nämlich wie c-structs mit { 1, 2, 3 }. (das ist erstens wohl sowieso bald überflüssig und geht zweitens ein bisschen an der intention von POD vorbei) - man definiert POD nun über (1) triviale typen und (2) standard-layout-typen. hab das allerdings schon im artikel klarer deutlich gemacht. die definition ist ähnlich geblieben, nur nicht mehr direkt von der definition von aggregat abhängig.

Ja, ist jetzt klarer.

(btw, Sachen wie variadic Templates oder automatische Typerkennung klingen auf jeden Fall interessant, bei der neuen Funktionsdefinition bin ich etwas skeptisch (auch wenn sie mich an Pascal (FUNCTION test(...) : int) erinnert - aber das ist eine Sache der Gewohnheit))

mich erinnert die sehr an (S)ML. dort sieht das beinahe gleich aus [ok, beinahe: (int * int) -> int]

Ja, das kommt davon, womit man angefangen hat Ich habe als erstes mit Pascal gearbeitet und fand bei der Umstellung die C-Reihenfolge etwas ungewohnt (in Pascal wird der Typ nach dem Namen angegeben), inzwischen habe ich mich daran gewöhnt - und die neue Deklarationsform bringt die Reihenfolge wieder durcheinander (oder darf man auch "i -> int;" schreiben, um Variablen zu definieren?).

[*]ergänzt man mit der Concept-Map eigentlich die Schnittstelle einer Klasse? (Sprich: Könnte ich auch "MyString sum = concatenate(str1,str2);" schreiben?)

ich halte ja concepts für die größte neuerung im kernbereich der sprache, gefolgt von variadic templates.

stroustrup (auf den geht das proposal afaik zurück) hat eine schöne analogie: eine concept-map ist wie die berühmte rosa brille, mit der die welt so gesehen wird, wie man sie braucht. d.h. wenn ein concept eine bestimmte schnittstelle braucht, sieht es sie entweder direkt über die implizite concept-map, die jedes interface darstellt; oder durch eine selbstdefinierte concept-map, die funktionen umbiegt.

bei der neuen for-schleife habe ich das ein bisschen angeschnitten. diese ist abhängig von einem konzept, dass in <iterator_concept> definiert wird: Range.
das sieht so aus:
[...]

Hm, nach der Erklärung sieht das für mich nach einer Erweiterung von Typ-Traits (ala std::iterator_traits<> oder std::char_traits<>) aus.

@Aufteilung: Ich würde am ehesten nach Kapitel 2 einen Schnitt machen (btw, bei meiner Serie zur STL hatte ich auch gelegentlich Verweise zwischen den einzelnen Teilen, das ist nicht das Problem ;)).

Artchi

Würde eine Aufteilung auch besser finden. Das Scrollen kann sehr unangenehm sein.

Habe noch einen Wunsch: kann man evtl. zu lange Codezeilen kürzen bzw. einen Umbruch rein machen? Z.B. sind manche Kommentare hinter einer langen Anweisung (typedef u.ä.), den Kommentar könnte man drüber schreiben. Sonst muß man immer so weit nach rechts scrollen, nicht jeder hat einen 1600x1200 Pixel Monitor.

queer_boy

CStoll schrieb:

Ja, jetzt wird's klarer - haben die Zeichen zwischen " und [ eigentlich eine Funktion oder werden sie vom Compiler zerstört? (und gibt es eine Möglichkeit, das Endezeichen ] im rohen String zu verwenden (z.B. wenn ich BBCode-Fragmente analog zu deinem HTML-Beispiel unterbringen will)

klar doch:

R"--[[ubbtag]klar doch:[ubbtag]]--";
//Was nun, wenn ich die Zeichenkette ]--" in meinem String brauche?
//Dann mache ich es einfach anders:
R"**[jetzt kann ich bequem über ]--" schreiben, ohne das etwas passiert]**";

sinn verstanden?
für die strings zwischen " und [ gibt es nur die Größenbegrenzung: maximal 16 Zeichen - eine gewisse Einschränkung beim Inhalt (keine leerzeichen, kein ", kein [ oder ]) und dass diese sequenz am anfang des strings wie auch am ende dieselbe sein muss.
hm diese information, soll ich die jetzt noch einbauen (imo habe ich schon genug dazu gesagt), oder nicht (wahrscheinlich wird sich die diskussion, die wir jetzt hier führen dann wiederholen ^^)

und die neue Deklarationsform bringt die Reihenfolge wieder durcheinander (oder darf man auch "i -> int;" schreiben, um Variablen zu definieren?).

naja, streng genommen eigentlich nicht, immerhin musst du ja ein auto an vorderste stelle tun...

Hm, nach der Erklärung sieht das für mich nach einer Erweiterung von Typ-Traits (ala std::iterator_traits<> oder std::char_traits<>) aus.

ein bisschen mehr als type_traits.

ein weiteres beispiel:

concept Stack <typename X>
{
   typename value_type;

   void push (X&, value_type const&);
   void pop (X&);

   value_type top (X const&);
   bool empty (const X&);
};

//vector als Stack:
template <class T>
concept_map Stack <std::vector<T>>
{
   typedef T value_type;

   void push (std::vector<T>& v, T const& x) { v.push_back(x); }
   void pop (std::vector<T>& v) { v.pop_back(); }
   T top (std::vector<T> const& v) { return v.back(); }
   bool empty (std::vector<T> const& v) { return v.empty(); }
};

//de factor sollte die template-concept-map aber auch mit list und deque 
//funktionieren
//vector, list und deque unterstützen alle das konzept:
concept BackInsertionSequence <typename X> 
{
   typename value_type = X::value_type;
   void X::push_back (value_type const&);
   void X::pop_back ();
   value_type& X::back ();
   const value_type& X::back() const;
   bool X::empty() const;
};

//und damit lässt sich eine concept-map über ein concept definieren:
template <BackInsertionSequence X>
concept_map Stack<X>
{
//wie oben...
};

damit lässt sich quasi ein generisches interface im sinne von std::stack definieren, dass aber - jederzeit erweiterbar - mit x-beliebigen typen, die zunächst gar nicht kompatibel aussehen, funktionieren.
mit template-type-traits wäre das alles ein ziemlicher aufwand.

aber concepts können noch mehr: (und das habe ich in der einführung gar nicht erwähnt) sie unterstützen "axiome"

concept CopyConstructible <typename T>
{
   T::T (T const&);

   axiom CopyEquivalence (T x)
   {
      T(x) == x; //allerdings nur type-checking, nicht semantisch
   }
}

axiome können zu enormen optimierungen führen: wenn ein axiom aussagt, dass zwei ausdrücke gleich sind, kann der compiler sie gegeneinander austauschen:

concept Monoid <typename Op, typename T>
{
   T identity_element (Op);

   axiom Identity (Op T x)
   {
      op (x, identity_element(op)) == x;
      op (identity_element(op), x) == x;
   }
};

template <typename Op, typename T> requires Monoid<Op, T>
T identity (Op const& op, T const& t)
{
    return op(t, identity_element(op)); //erfüllt das axiom Identity
    //damit kann der compiler diesen funktionsaufruf durch:
    return t; //ersetzen.
}

das kann auf jedenfall interessant werden.

/edit 1, 2, 3 und 4: die verwendung von R"[ ]" könnte in diesem forum noch problematisch werden ^^'

CStoll

@rohe Strings - zumindest solltest du dazuschreiben, welche Aufgabe diese erweiterten Trennzeichen haben ("um die Verwendung zu vereinfachen" ist imho etwas mager).
(PS: Ja, mit den letzten Erklärungen habe ich den Sinn verstanden)

und die neue Deklarationsform bringt die Reihenfolge wieder durcheinander (oder darf man auch "i -> int;" schreiben, um Variablen zu definieren?).

naja, streng genommen eigentlich nicht, immerhin musst du ja ein auto an vorderste stelle tun...

Von daher ist es vielleicht ein wenig inkonsequent - Pascal verwendet durchgängig die Schreibweise "name:typ", C++ bislang durchgängig "typ name". Allerdings weiß ich auch nicht, wie man das besser lösen könnte.
(im ARM habe ich afair mal gelesen, daß Template mal als "T template<typename T> func(...)" angedacht waren, wurde zugunsten der leichteren Compilierbarkeit verworfen)

Ben04

Ich bin gegen das Spalten des Artikels. Es passt einfach so wie es jetzt ist gut zusammen. Da jetzt irgendwo zu schneiden wäre meiner Meinung nach nicht so toll.

Wie verhalten sich for Schleifen, wenn der Range während der Ausführung verändert wird?

queer_boy

hm die frage, ob der artikel gespaltet werden soll, erübrigt sich wohl.

seht doch mal an das ende des artikels, einfach abgeschnitten ^^'

(zum glück schreibe ich den text nicht einfach direkt ins forum rein...)

Ben04

Wie meinst du das jetzt? Meinst du das Forum hätte da abgeschnitten? Bist du sicher, dass das kein unglücklicher Bedienungsfehler war?

sothis_

Ben04 schrieb:

Wie meinst du das jetzt? Meinst du das Forum hätte da abgeschnitten? Bist du sicher, dass das kein unglücklicher Bedienungsfehler war?

ich glaube nicht. mir ist ähnliches passiert als ich meinen artikel geschrieben hatte

queer_boy

Ben04 schrieb:

Wie verhalten sich for Schleifen, wenn der Range während der Ausführung verändert wird?

wahrscheinlich nicht wie erwartet. im schlimmsten falle undefiniert.
der draft definiert es so, dass zwei temporäre objekte begin und end zu beginn definiert werden, so dass sich die abfrage dann auf begin != end ohne funktionsaufrufe beschränkt.

queer_boy

Ben04 schrieb:

Wie meinst du das jetzt? Meinst du das Forum hätte da abgeschnitten? Bist du sicher, dass das kein unglücklicher Bedienungsfehler war?

nö. das lustige ist, wenn ich auf "vorschau" klicke, scheint alles da zu sein. nur dann auf absenden - und schwupps ist alles weg. (auch wenn ich gleich auf absenden klicke)