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

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)

Ben04

Ich habe auch schon längere Artikel geschrieben und ich hatte da keine Probleme. Das da klingt nach einem neuen Boardbug.

queer_boy

hm, es schneidet immer wieder an der gleichen stelle ab, auch in neuen threads. gleiche stelle heißt immer nach derselben anzahl von zeichen.

CStoll

Hast du mal mitgezählt, nach wievielen Zeichen genau das war? (wenn ich raten müsste - du hast die maximale Beitragsgröße des Forums erreicht)

queer_boy

CStoll schrieb:

Hast du mal mitgezählt, nach wievielen Zeichen genau das war? (wenn ich raten müsste - du hast die maximale Beitragsgröße des Forums erreicht)

das habe ich auch gesagt, bis:

Ben04 schrieb:

Ich habe auch schon längere Artikel geschrieben und ich hatte da keine Probleme. Das da klingt nach einem neuen Boardbug.

aber ich glaube, irgendwann mal vor ein paar jahren etwas zum thema maximale-beitragslänge gehört zu haben. kann aber sein, dass das noch vor phpbb war.

also wie gesagt, aus eins mach zwei

Ben04

Das "längere" bezog sich auf im allgemein eher lang. Ich hab damit nicht länger als einer der beiden neuen Artikel gemeint. (Ich habe nicht gezählt, von daher ist es aber nicht ausgeschlossen.) Wobei es mich zwar wundert, dass die Vorschau geht...

phlox81

Ben04 schrieb:

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?

Naja, aus meiner Sicht wäre es schon sinnvoll über eine maximale Länge von Artikeln nachzudenken. Sonst wird es zu unübersichtlich, auch spricht nichts dagegen eine Artikelserie zu dem Thema zu veröffentlichen.

queer_boy

das problem hier war ja nur: ich wollte von anfang an eine artikel-serie machen, aber der erste artikel sollte einen überblick (keinen zu genauen) über die neuen features geben. wie auch immer, ich splitte jetzt den artikel überblick auch schon in zwei. dann kann ich auch noch (was ich sowieso tun sollte) der standardbibliothek von C++09 mehr aufmerksamkeit widmen. (immerhin bietet die nun multithreading-support!)

also artikel 1 (hier): Core-Language Features
artikel 2 (wird gleich eröffnet): Library Features

Ben04

Da könnte man in der Tat schneiden.

queer_boy

Weil der Vorschlag vielleicht untergegangen ist: Wie realistisch ist es, noch C++0x Code-Tags zu bekommen? Also im Prinzip nur Code-Tags, die die neuen Schlüsselwörter auch highlighten:

static_assert
decltype
concept
concept_map
requires
axiom
late_check
nullptr
(nullptr_t)
...

Ben04

Ich hab mal Marc++us gefragt und folgende Antwort gekriegt:

Hi Ben,

gibt's eine Liste der zusätzlichen Wörter? Dann bitte her damit, dann ist das sofort gemacht.

Danke

Viele Grüße

Marcus

Schick (E-Mail) ihm also einfach eine Liste der Schlüsselwörter welche du in deinem Artikel benutzt hast.