Vortrags-Videos zu C++0x
-
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/
-
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?
-
Denke schon, ja.
-
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){...}
-
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.
-
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
-
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" ;-)).
-
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.
-
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.
-
Hallo,
auf der Seite von Andrei Alexandrescu gibt es unter
Code-> SafeFormat eine interessante AlternativeGruß
Sorry falscher Beutrag