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

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.

queer_boy

gesagt getan,

marcus war schnell und es sieht schon viel besser aus.

queer_boy

so, ich hab jetzt noch die quellen eingefügt und ein bisschen was umgeschrieben.
vor dem [R] status also nochmal die bitte, sich das ganze auf inhaltliche richtigkeit durchzulesen (soweit halt möglich)
letzte woche war semester-ende, deshalb konnte ich mich nicht so auf die artikel konzentrieren ^^'

/ps. den [R]-artikel dann als neuen thread posten?