C++2009-Papers vom Kona-Meeting

[Werner Salomon]

Konrad Rudolph schrieb:

Ähm, inwiefern unterstützt denn Boost die Konvertierung von Unicode-Transformationsformaten?

Guckst Du hier. Aber ist irgendwie nicht 'offiziell', Artchi sprach ja auch von 'im Netz suchen'.

LordJaxom schrieb:

CodeOriginator schrieb:

Ich denke, mit dem Jahr 2009 kommt zwar der neue Standard, es wird sich jedoch in den ersten 1-2 Jahren nichts signifikantes an der Situation ändern. Schließlich brauchen die Compilerhersteller auch ihre Zeit, um nachzuziehen.

Da würde ich inzwischen nichtmal mehr von ausgehen. Mindestens GNU und Comeau implementieren bereits heute Teile von C++0x

Außerdem gibst parallel zu den Compilerherstellern auch Aktivitäten bei boost, die eine Nutzung des TR1 bereits heute ermöglichen.

Gruß
Werner

[Artchi]

TR1 gibts bereits vollständing von Dinkumware. D.h. theoretisch könnte heute schon Borland und MS den TR1 ihren Compilern beilegen (beide benutzen Dinkumwares Std-Lib!). Aber anscheinend müssen sie das extra bezahlen, weshalb sie noch nicht beiligen. Auch GNU G++ hat da meines Wissens vieles von TR1 fertig.

D.h. was die Std-Lib für C++2009 angeht, ist vieles schon fertig.

Bleiben noch die Spracherweiterungen: diese werden sich in Grenzen halten, auch wenn es wirklich erstaunliche Neuerungen gibt. Aber die Anzahl hält sich in Grenzen. Vorallem sind viele Spracherweiterungen bereits experimentell in GCC und anderen Compilern implementiert. D.h. auch das Komitee hat aus den Fehlern vom letzten Standard gelernt, und will nicht einfach Features zulassen, die noch nicht ausprobiert wurden (wie damals mit dem export für Templates!).

Klar, wenn 2009 das ganze (hoffentlich) abgesegnet wird, wird die ISO ein Jahr für das Release benötigen (lässt sich nicht umgehen dieser Prozess) und dann werden so langsam die ersten Compiler-Umgebungen auftauchen, die das meiste vom Standard drin haben werden.

[Artchi]

Nur mal als Beispiel: wer die Concepts aus C++0x ausprobieren will, kann das heute schon mit dem ConceptGCC machen - ein GCC mit Concept-Fähigkeit. Wenn der C++0x rauskommt, werden die GCC-Jungs vielleicht nur noch leichte Änderungen machen müssen. Und schon ist ein leistungsfähiges Sprachfeature pünktlich im GCC verfügbar... naja, so zumindest die Vorstellung.

http://www.generic-programming.org/software/ConceptGCC/

[Konrad Rudolph]

Werner Salomon schrieb:

Konrad Rudolph schrieb:

Ähm, inwiefern unterstützt denn Boost die Konvertierung von Unicode-Transformationsformaten?

Guckst Du hier. Aber ist irgendwie nicht 'offiziell', Artchi sprach ja auch von 'im Netz suchen'.

Ach herrje, das ist ja reinstes Chaos! Allein schon die Bennenung (UCS-4 hat nix mit Unicode zu tun). Aber ich schaue mir das mal an, vielen Dank. Eventuell lässt sich ja damit was reißen.

[Hutzli]

Konrad Rudolph schrieb:

Ach herrje, das ist ja reinstes Chaos! Allein schon die Bennenung (UCS-4 hat nix mit Unicode zu tun).

Das ist jetzt aber doch etwas übers Ziel hinaus.

Guckst Du: http://www.unicode.org/versions/Unicode4.0.0/appC.pdf

As a consequence, UCS-4 can now be taken effectively as an alias for the Unicode encoding form UTF-32, except that UTF-32 has the extra requirement that additional Unicode semantics be observed for all characters.

jm2c

Hutzli

[Konrad Rudolph]

Hutzli schrieb:

Konrad Rudolph schrieb:

Ach herrje, das ist ja reinstes Chaos! Allein schon die Bennenung (UCS-4 hat nix mit Unicode zu tun).

Das ist jetzt aber doch etwas übers Ziel hinaus.

As a consequence, UCS-4 can now be taken effectively as an alias for the Unicode encoding form UTF-32, except that UTF-32 has the extra requirement that additional Unicode semantics be observed for all characters.

Ja, das bedeutet aber nur soviel, dass es eben faktisch dasselbe ist, weil die Standards in Abstimmung entwickelt wurden. Es heißt *nicht*, dass man Namenskonventionen über den Haufen werfen sollte, schon gar nicht beim Schreiben von Bibliotheken.

[Hutzli]

Konrad Rudolph schrieb:

Hutzli schrieb:

Konrad Rudolph schrieb:

Ach herrje, das ist ja reinstes Chaos! Allein schon die Bennenung (UCS-4 hat nix mit Unicode zu tun).

Das ist jetzt aber doch etwas übers Ziel hinaus.

As a consequence, UCS-4 can now be taken effectively as an alias for the Unicode encoding form UTF-32, except that UTF-32 has the extra requirement that additional Unicode semantics be observed for all characters.

Ja, das bedeutet aber nur soviel, dass es eben faktisch dasselbe ist, weil die Standards in Abstimmung entwickelt wurden. Es heißt *nicht*, dass man Namenskonventionen über den Haufen werfen sollte, schon gar nicht beim Schreiben von Bibliotheken.

Da stimme ich Dir zu, nur "hat nix Unicode zu tun" sieht für den unbedarften Leser ja dann doch etwas dramatischer aus. Inhaltlich sind UCS-4 und Unicode eben nicht komplett verschieden. Daher wollte ich dieses extrem etwas ins rechte Licht rücken. Wenn selbst das Unicode-Gremium UCS-4 als Alias erklärt, ist die Namenswahl sicherlich "unglücklich" aber nicht "reinstes CHaos".

[Artchi]

Ehem, wer sagt denn überhaupt, das boosts codecvt in UTF-32 konvertiert? Vielleicht konvertiert es wirklich in UCS-4?! Denn von UTF-32 habe ich nichts gelesen...

[Konrad Rudolph]

Artchi schrieb:

Ehem, wer sagt denn überhaupt, das boosts codecvt in UTF-32 konvertiert? Vielleicht konvertiert es wirklich in UCS-4?! Denn von UTF-32 habe ich nichts gelesen...

Meinetwegen. Dann werden da eben nicht nur Begriffe, sondern sogar verschiedene Standards durcheinandergeschmissen. Macht es nicht besser.

[Th]

Ich habe mir mal die Mühe gemacht und das Paper Seite für Seite überflogen und folgende Erweiterungen festgestellt (sicherlich nicht komplett):

Neue Schlüsselwörter (d.h. der C/C++ Parser muß dann angepaßt werden -):

alignas		// Setzen des Alignments eines Typs
alignof		// Ermittlung des Alignments eines Typs
char16_t		// Neuer Datentyp
char32_t		// Neuer Datentyp
constexpr		// Definition eines konstanten Ausdrucks (als Funktion)
decltype		// zum Ermitteln des Datentyps einer Variablen/Funktion
nullptr		// Alternative zu 0 (für Zeiger)
static_assert	// zur Erzeugung von Compiler-Fehlern (mit entspr. Meldung)

Neuer Datentyp:

(unsigned/signed) long long (int)

Neue String-Literale:

u"..."	// char16_t Strings
U"..."	// char32_t Strings
u8"..."	// UTF-8 Strings
R"..."	// Raw-Strings
u8R"..."
uR"..."
UR"..."
LR"..."

Neue Deklaratoren:

auto		// Platzhalter für einen Datentyp z.B. "auto y = 0.0;"
&&		// RValue-Referenz (im Gegensatz zu LValue-Referenz &)
= default		// für Spezial-Memberfunktionen (CopyCtr, Assignment, ...)
= delete		// für Member-Funktionen (explizites Nichterzeugen)

Aufruf von anderen Konstruktoren (zur Vermeidung einer Init-Funktion):

class C
	{
	  C(int x) { }  // Basis-Konstruktor
	  C(): C(42) { } // Aufruf von Konstruktor mit Typ 'int'
	};

aber Rekursion ist nicht erlaubt!

& u. && für Deklaration bei (überladenen) Memberfunktionen:

class X
	{
	  void f() &;  // für nicht-temporäre Objekte
	  void f() &&; // für temporäre Objekte
	};

Templates:

> für geschachtelte Templates: vector<map<string, int>>

Variadic Templates (Templates mit beliebiger Anzahl von Parametern)

template <class ... Types> class Tuple;

	Tuple<> t0; // Types contains no arguments
	Tuple<int> t1; // Types contains one argument: int
	Tuple<int, float> t2; // Types contains two arguments: int and float

gilt auch für Template-Funktionen:

template<class ... Types> void f(Types ... args);

	f(); // args contains no arguments
	f(1); // args contains one argument: int
	f(2, 1.0); // args contains two arguments: int and double

C++ Standard Library:

Neue Headers:
<array> Array-Template
<regex> Reguläre Ausdrücke
<random> Zufallszahlen-Generatoren
<system_error> System-Fehlercodes
<tuple> Tupel-Klasse
<type_traits> Typ-Eigenschaften
<unordered_map> Unsortierte Map (Hash-Map)
<unordered_set> Unsortiertes Set (Hash-Set)

Neue Datentypen:

max_align_t	// Datentyp für maximales Alignment
nullptr_t		// Datentyp für nullptr

<cstdlib>:

extern "C" int at_quick_exit(void (*f)(void));
extern "C++" int at_quick_exit(void (*f)(void));

<functional>:

template <class T> struct bit_and;
template <class T> struct bit_or;
template <class T> struct bit_xor;

template<class Fn, class... Types>
  unspecified bind(Fn, Types...);

Platzhalter _1, _2, _3, ..., _N (implementationsabhängig)

template <class T> struct hash;

template<class R, class... ArgTypes>
  class function<R(ArgTypes...)>

template <class Fn, class... ArgTypes>
  class result_of<Fn(ArgTypes...)>

template <class T> class reference_wrapper

<memory>:

template <class T, class D = default_delete<T>>
  class unique_ptr	// auto_ptr ist "deprecated"

template<class T> class shared_ptr

<string>:
Überladung von std::string nach Zahlen Konvertierung (und zurück)
- int stoi(const string&, ...)
- string to_string(long long val);
- ...

<codecvt> (Code Conversation Facets):
codecvt_utf8
codecvt_utf16
codecvt_utf8_utf16

<array>:

template <class T, size_t N> struct array;

<unordered_map>:
template <class Key,
	  class T,
	  class Hash = hash<Key>,
	  class Pred = std::equal_to<Key>,
	  class Alloc = std::allocator<std::pair<const Key, T> > >
	class unordered_map;

template <class Key,
	  class T,
	  class Hash = hash<Key>,
	  class Pred = std::equal_to<Key>,
	  class Alloc = std::allocator<std::pair<const Key, T> > >
	class unordered_multimap;

<unordered_set>:
template <class Value,
	  class Hash = hash<Value>,
	  class Pred = std::equal_to<Value>,
	  class Alloc = std::allocator<Value>>
	class unordered_set;

template <class Value,
	  class Hash = hash<Value>,
	  class Pred = std::equal_to<Value>,
	  class Alloc = std::allocator<Value>>
	class unordered_multiset;

<iterators>:

template <class Iterator> class move_iterator;

<random>:
Über 30 Zufallszahlen-Generatoren (mersenne_twister_engine, uniform_int_distribution, ...)

<regex>:

template <class charT, class traits = regex_traits<charT> >
  class basic_regex;
typedef basic_regex<char> regex;
typedef basic_regex<wchar_t> wregex;

<cstdatomic>: Atomare Operationen

Platzhalter für Thread-Support

Mißbilligungen (deprecated):
- binder1st, bind1st, binder2nd, and bind2nd (stattdessen Benutzung von bind(...))
- auto_ptr (stattdessen Benutzung von unique_ptr)

[darthdespotism]

Die String - Literale erinnern nur zufällig an Python oder?