Stellenangebot Autor für: Function objects, Function pointers mit boost::bind, lambda usw. [vergeben]
-
Hallo,
wer hätte Lust, Zeit und das Fachwissen über die im Titel angesprochenen Themen zu schreiben? Der Umfang kann auch variieren, die Freiheiten liegen da beim Autor.
MfG
GPC
-
Ich denke ich könnte darüber was schreiben, würde aber den Schwerpunkt nicht unbedingt auf Dinge aus Boost legen.
-
tommie-lie schrieb:
Ich denke ich könnte darüber was schreiben, würde aber den Schwerpunkt nicht unbedingt auf Dinge aus Boost legen.
die wichtigen konzepte um funktionsobjekte sind da eh erstmal boost-frei. und kompliziert genug. und sauwichtig für modernes c++. man stelle sich nur mal vor, std::sort würde wie qsort einen funktionszeiger fordern. wie lahm das schon wäre. std::sort kann aber ganz nebenbei nen funktionszeiger nehmen, weil funktionsobjekte sich (in dem, was std::sort braucht) wie funktionen verhalten.
wenn die dinge verstanden sind und mit der normalen stl geübt wurden, kann man in nem weiteren artikel gerne boosten.
-
volkard schrieb:
man stelle sich nur mal vor, std::sort würde wie qsort einen funktionszeiger fordern. wie lahm das schon wäre.
Gewagte These. Das liegt weniger in der Natur von Functor alsan den Möglichkeiten, diese zu opitimieren. Mit -O0 verhalten sich alle drei Varianten (qsort(), std::sort() mit Function Pointer und std::sort() mit Functor) reproduzierbar ziemlich ähnlich beim Sortieren einer identischen Datenstruktur (was zwangsläufig ein C-Style Array ist), wobei die Variante mit dem Functor reproduzierbar am langsamsten ist.
Das Aktivieren der Optimierung (selbst -O3) bringt nahezu nichts für qsort(), weil es schlichtweg nicht zu optimieren ist. Mit std::sort() und einem Functor hat der Compiler beste Vorraussetzungen zum Optimieren, womit das Ergebnis mehr als doppelt so schnell wie qsort() ist. Der Preis, den du dafür zahlst, ist ein Binary, das größer ist, als bei qsort().volkard schrieb:
std::sort kann aber ganz nebenbei nen funktionszeiger nehmen, weil funktionsobjekte sich (in dem, was std::sort braucht) wie funktionen verhalten.
Das funktioniert, wenn man Quellcode einbindet, aber nicht, wenn man gegen vorkompilierte Bibliotheken linkt. Ein Functor mag sich im Code genauso verhalten, wie eine Funktion (weil ein Functor so definiert ist), aber er besitzt ein unterschiedliches ABI. Ein Shared Object, das in C geschrieben wurde und das unbedingt einen Funktionspointer haben will, wird sich nicht mit dem Functor anfreunden können, den ich ihm gebe.
-
tommie-lie schrieb:
volkard schrieb:
man stelle sich nur mal vor, std::sort würde wie qsort einen funktionszeiger fordern. wie lahm das schon wäre.
Gewagte These. Das liegt weniger in der Natur von Functor alsan den Möglichkeiten, diese zu opitimieren.
jup.
Mit std::sort() und einem Functor hat der Compiler beste Vorraussetzungen zum Optimieren, womit das Ergebnis mehr als doppelt so schnell wie qsort() ist. Der Preis, den du dafür zahlst, ist ein Binary, das größer ist, als bei qsort().
jup.
wir gehen nur von -O3 aus und nur von PCs. randbetrachtungen gerne am rande.tommie-lie schrieb:
volkard schrieb:
std::sort kann aber ganz nebenbei nen funktionszeiger nehmen, weil funktionsobjekte sich (in dem, was std::sort braucht) wie funktionen verhalten.
Das funktioniert, wenn man Quellcode einbindet, aber nicht, wenn man gegen vorkompilierte Bibliotheken linkt. Ein Functor mag sich im Code genauso verhalten, wie eine Funktion (weil ein Functor so definiert ist), aber er besitzt ein unterschiedliches ABI. Ein Shared Object, das in C geschrieben wurde und das unbedingt einen Funktionspointer haben will, wird sich nicht mit dem Functor anfreunden können, den ich ihm gebe.
missverständnis: ich meinte eher "std::sort kann aber ganz nebenbei nen funktionszeiger nehmen". std::sort frisst dich funktionszeiger gerne. es nimmt ein beliebiges objekt und wenn man drauf den op() aufrufen kann, ist alles fein. std::sort verlangt keine echten klassenobjekte als less. es nimmt alles, was () kann, insbesondere funktionszeiger.
mir ging es nicht um den umgekehrten weg, daß man sachen wie qsort mit vergleichenden klassenobjekten versorgt.vote: ich bin voll dafür, daß du so einen artikel ganz nach deinem gutdünken bastelst. bin sicher, daß der sehr gut wird, mir erscheinst du ein mächtiger ahnunghaber in diesem thema zu sein.
-
volkard schrieb:
wir gehen nur von -O3 aus und nur von PCs. randbetrachtungen gerne am rande.
Dabei mag ich doch die Plattformunabhängigkeit von C++ so gerne
volkard schrieb:
missverständnis: ich meinte eher "std::sort kann aber ganz nebenbei nen funktionszeiger nehmen". std::sort frisst dich funktionszeiger gerne.
Jo, weil's im Quellcode vorliegt (genauer: als Template). Und auch nur deswegen lässt es sich so gut optimieren. Würde man es in Shared Object auslagern und ein ABI-kompatibles Objekt erzwingen, könnte man a) keine Funktionspointer mehr übergeben und b) wäre es das mit dem Geschwindigkeitsvorteil auch gewesen.
volkard schrieb:
mir erscheinst du ein mächtiger ahnunghaber in diesem thema zu sein.
Das hat GPC von mir über Templates auch behauptet, ich weiß gar nicht, wie ihr auf solche Ideen kommt
-
tommie-lie schrieb:
volkard schrieb:
mir erscheinst du ein mächtiger ahnunghaber in diesem thema zu sein.
Das hat GPC von mir über Templates auch behauptet, ich weiß gar nicht, wie ihr auf solche Ideen kommt
Nu mal nicht so bescheiden
Klar, der Artikel gehört dir. Wir nehmen dich bald in die Red auf.
Grüße
GPC