Vortrags-Videos zu C++0x

audacia

Mr. N schrieb:

Das sind keine Closures! Zumindest nicht im eigentlichen Sinne.

Dann scheinen wir uns mißverstanden zu haben. Was ich mit Closures meinte, habe ich oben beschrieben.

Artchi schrieb:

LOL! Sehr witzig! Genau das gleiche hatte man sich wohl 1998 gedacht, als man den Compiler-Herstellern "export" zumuten wollte. Weil es ja toll ist.

Aber so läuft der Hase heute nicht mehr! Zum Glück! Heute sitzen nunmal die Compiler- und Library-Hersteller mit im Komitee und bedenken dieses mal im Voraus die Implementierungskosten und somit die eventuelle Komplexität.

Und da soll eine völlig neue Notation für den Rückgabetyp einfacher zu implementieren sein als das verzögerte Evaluieren des vorangestellten Rückgabetyps? Würde mich doch etwas wundern.

Zudem ist export IMHO kein angemessener Vergleich. Daß export das konventionelle Compiler-Linker-Modell vor erhebliche Schwierigkeiten stellt, wird klar, wenn man sich ein wenig näher damit beschäftigt. Daß aber die Forderung, ein Typ dürfe erst nach den nachfolgenden Ausdruck ausgewertet werden, einen Compiler vor erhebliche Schwierigkeiten stellt, kann ich mir nicht vorstellen. Kann der Rückgabetyp innerhalb der Funktionssignatur benötigt werden (dann wäre aber auch die neue Notation hinfällig)? Ist es problematisch, den Gültigkeitsbereich der Funktionsparameter auf den Rückgabetyp auszuweiten - kann davon überhaupt ein anderer Gebrauch gemacht werden als mit decltype?

Bashar schrieb:

Speicherblöcke umherzuschieben gehört nicht unbedingt zu den Muss-Eigenschaften eines GCs.

Mag sein, aber schränkt das nicht die Möglichkeiten eines GCs erheblich ein? Was macht dann ein GC für C++ anderes als ein auto_ptr, abgesehen davon, daß er den Speicher nicht beim Destruktoraufruf, sondern erst bei der Garbage-Collection freigibt? Und sorgen Mechanismen wie das Untersuchen des Speichers nach Daten, die wie Zeiger aussehen, nicht dafür, daß der GC sowohl unnötig Laufzeit verschwendet als auch eine nicht ganz unbeträchtliche Fehlerrate aufweist?

Bashar

audacia schrieb:

Bashar schrieb:

Speicherblöcke umherzuschieben gehört nicht unbedingt zu den Muss-Eigenschaften eines GCs.

Mag sein, aber schränkt das nicht die Möglichkeiten eines GCs erheblich ein? Was macht dann ein GC für C++ anderes als ein auto_ptr, abgesehen davon, daß er den Speicher nicht beim Destruktoraufruf, sondern erst bei der Garbage-Collection freigibt?

Ein GC gibt keine Speicherblöcke frei, sondern merkt sicht welche er behalten muss und vergißt den Rest.

Und sorgen Mechanismen wie das Untersuchen des Speichers nach Daten, die wie Zeiger aussehen, nicht dafür, daß der GC sowohl unnötig Laufzeit verschwendet als auch eine nicht ganz unbeträchtliche Fehlerrate aufweist?

Ja. Man kann nunmal in C++ an einem Objekt im Speicher nicht immer erkennen, welche Komponenten Zeiger sind, die weiter verfolgt werden müssen, und welche nicht. Deshalb gibt es konservative GCs, die alles das behalten, auf das möglicherweise ein Zeiger zeigt. Natürlich gibt es da eine Fehlerrate, aber solange man keine Schweinereien wie XORen von Adressen macht, liegen die Fehler nur darin, dass er zuviel behält, was er eigentlich wegschmeißen könnte, nie andersrum.
Ansonsten siehe hier: http://www.memorymanagement.org/

Mr. N

Bashar schrieb:

solange man keine Schweinereien wie XORen von Adressen macht, liegen die Fehler nur darin, dass er zuviel behält, was er eigentlich wegschmeißen könnte, nie andersrum

Heißt das, man kann in den hinteren, wegen Alignment genullten Bits auch keine Flags mehr kodieren?

Bashar

Denke schon, ja.

otze

mal ne frage zu diesem decltype:

weis jemand, ob sowas in der art auch funktionieren wird?

tempalte<class U, class V>
void foo(U u, V v, decltype(u+v) w){...}

camper

Es soll wohl so wie gccs typeof funktionieren. Dann darfst du decltype überall dort verwenden, wo ein typedef name zulässig ist, also auch wie in deinem Beispiel.

tntnet

otze schrieb:

mal ne frage zu diesem decltype:

weis jemand, ob sowas in der art auch funktionieren wird?
tempalte<class U, class V>
void foo(U u, V v, decltype(u+v) w){...}

Nein - tempalte ist im Standard nicht spezifiziert

Konrad Rudolph

Mr. N schrieb:

boost::function wiederum braucht wohl etwa die Zeit von 5 Funktionsaufrufen. Das ist nun wirklich vertretbar. Man sollte es natürlich nicht in inneren Schleifen aufrufen, aber das sollte man auch nicht mit Delegates...

Genau dort werde Delegates aber üblicherweise gebraucht. Wenn man sich z.B. mal .NET anschaut, dann werden sie ja z.B. eingesetzt, um die ganzen höheren Listenfunktionen zu implementieren, also so Späße wie 'find_if' n C++. Das ist natürlich für C++ nicht relevant, da man hier Funktionsobjekte verwenden kann (und die sind ja, wie bereits bemerkt, "überaus effizient" ;-)).

Mr. N

Konrad Rudolph schrieb:

Mr. N schrieb:

boost::function wiederum braucht wohl etwa die Zeit von 5 Funktionsaufrufen. Das ist nun wirklich vertretbar. Man sollte es natürlich nicht in inneren Schleifen aufrufen, aber das sollte man auch nicht mit Delegates...

Genau dort werde Delegates aber üblicherweise gebraucht. Wenn man sich z.B. mal .NET anschaut, dann werden sie ja z.B. eingesetzt, um die ganzen höheren Listenfunktionen zu implementieren, also so Späße wie 'find_if' n C++. Das ist natürlich für C++ nicht relevant, da man hier Funktionsobjekte verwenden kann (und die sind ja, wie bereits bemerkt, "überaus effizient" ;-)).

find_if braucht ja nichtmal boost::function. Das ist sogar inline-effizient.

Konrad Rudolph

Mr. N schrieb:

find_if braucht ja nichtmal boost::function. Das ist sogar inline-effizient.

Ja, das ist mir klar, das meine ich ja. Aber in C# braucht man dafür eben einen Delegate … und von Effizienz kann hier eben keine Rede sein.

headhunter33

Hallo,

auf der Seite von Andrei Alexandrescu gibt es unter
Code-> SafeFormat eine interessante Alternative

Gruß

Sorry falscher Beutrag