std::sort nach verschiedenen Objekteigenschaften mit Standardprädikaten (ohne Extrafunktion!)

Hey, das sieht doch fast wie die generalisierte Version meiner Lösung von der ersten Seite aus, mit Memberfunktionen anstatt Membervariablen - du klaust doch!

Snip.

Viele Grüße,
Michael

PS: Ich mach hier nur Spaß

knivil

Und man sieht wieder, wie aus einer simplen Sache unglaublich viel Code entsteht. Ich finde die vorgeschlagenen Loesungen schlecht.

So ist das halt in C++

Nexus

knivil schrieb:

Und man sieht wieder, wie aus einer simplen Sache unglaublich viel Code entsteht. Ich finde die vorgeschlagenen Loesungen schlecht.

Sie entsprechen aber der Anforderung des Threaderstellers und das ist relevant. Wenn du die Funktionalität generisch implementieren willst, kommst du nicht um viel Code herum. Aber wie gesagt kann man das in einen eigenen Header auslagern und von dort aus wiederverwenden. Die Verwendung ist dafür sehr sauber und kann sich schnell mal auszahlen.

Was für ein Problem hast du mit viel Code? Oder ist es eher eine fundamentale Abneigung als ein begründeter Einwand? Und du hast doch sicher einen besseren Vorschlag, oder?

Nebenbei: Was denkst du, wie viel Code braucht Boost.Lambda?

pumuckl

question123 schrieb:

Jein. Die Vergleichsfunktionen existieren ja schon.

Nein tun sie nicht. Was glaubst du was greater<Object> macht? oder dein vorgeschlagenes greater<Object::element> ? Da wird ein Klassentemplate instantiiert, damit erzeugt der Compiler den Code für einen Funktor, der den operator> aufruft. Bei allen anderen vorgeschlagenen Lösungen wird so ein Funktor auf mehr oder weniger komplizierte Art vom Compiler zusammengebastelt - im einfachsten Fall ohne irgendwelche template-Instantiierung auf die handcodierte Art. Im allereinfachsten Fall ist es natürlich deine einfache Funktion, ohne dass irgendein Funktor-Objekt konstruiert werden müsste.
Be einfachen Funktoren hat der Compiler gute Chancen dass ein Großteil des generierten oder selbstgetippten Codes wegoptimiert wird und lediglich die Essenz des Vergleichs übrig bleibt - nämlich der operator>.

Hey, eine der Varianten kam ohne Funktor aus!

Tachyon

knivil schrieb:

Und man sieht wieder, wie aus einer simplen Sache unglaublich viel Code entsteht. Ich finde die vorgeschlagenen Loesungen schlecht.

Du sagst ohnehin immer, dass Du alles schlecht findest ohne dabei irgendwelche Lösungen beizutragen. Mach doch einen besseren Vorschlag, wenn es so schlecht ist.

Mal ganz davon abgesehen widersprichst Du Dir a) selbst, und b) ist die Menge an generiertem Code doch sehr überschaubar.

question123

pumuckl schrieb:

Nein tun sie nicht. Was glaubst du was greater<Object> macht? oder dein vorgeschlagenes greater<Object::element> ?

Ich meinte mit "sie existieren schon" ein bisschen was anderes, nämlich nicht, dass dafür nicht extra Code (durch den Compiler) erzeugt werden müsste (was klar ist), sondern dass ich als Programmierer gerne auf bestehende Konstruktionen zurückgreifen würde.

Nexus (und Decimad) haben ja eine sehr schöne und allgemein verwendbare Möglichkeit aufgezeigt. (Danke dafür schon mal, !) Was mich wundert: Da das Problem, Objekte (Klasseninstanzen) nach verschiedenen Eigenschaften sortieren zu wollen, so selten nicht ist, dass C++ (inkl. STL) da keine Bordmittel hat...

knivil

Da halt ich es wie die Mathematiker. Sie koennen auch Beweise ablehnen, ohne einen richtigen zu liefern. Desweiteren entspricht es nicht den Anforderungen des Threadstellers:

(ohne Extrafunktion!)

Da das aber nicht moeglich ist (es wurden Extrafunktionen/Functoren geschrieben), warum sollte ich eine weitere (Un)loesung liefern. Ausserdem ist die Generalisierung ueber Templates genauso wie fruehzeitige Optimierung ...

Shade Of Mine

knivil schrieb:

Ausserdem ist die Generalisierung ueber Templates genauso wie fruehzeitige Optimierung ...

OMG, da würde man ja etwas lernen.

Die Lösung ist gut. Nicht ideal - aber das liegt an der Aufgabenstellung.

question123

Hey, ich fand die Aufgabenstellung gut!

question123

Nexus schrieb:

question123, kommt das jetzt noch ein wenig näher? Ist es sogar schon gut genug?

Bin verwirrt. Ich krieg's nicht zum Laufen:
minimal5.cxx:75: error: no matching function for call toCompare(int (some::*)())'`

Nexus'-Lösung sieht vor, dass man getter-Funktions-Zeiger verwendet, anstatt Daten-Member-Zeiger. Adaptiere meine längere Lösung von der ersten Seite so, dass sie der Implementierung von Nexus gleichkommt. Oder füge bei Nexus die Daten-Member-Zeiger statt der Methoden-Zeiger ein.

question123

Ja, aber ich verwende doch Funktionszeiger? Oder bin ich grad auf dem Holzweg??

struct some {
    int _a;
    int _b;
    int a(void) { return _a; };
    int b(void) { return _b; };
    some(int a1, int b1) : _a(a1), _b(b1) {}
};

std::sort(l.begin(), l.end(), Compare( &some::a ));

Ahh, okay... du hast die const-qualifier an den Getter-Methoden vergessen.

question123

Dachte ich auch mal Aber

...
const int a(void) { return _a; };
...

bringt auch nur minimal5.cxx:70: error: no matching function for call toCompare(const int (some::*)())'`

int a(void) const { return _a; };

So.

hustbaer

Im Prinzip ist dashier genau dasselbe wie die "Key Extractor" bei Boost.Multiindex.

http://www.boost.org/doc/libs/1_38_0/libs/multi_index/doc/reference/key_extraction.html

question123

Decimad schrieb:

So.

Danke. Scheint Zeit zu sein, nach Hause zu gehen

Nexus

knivil schrieb:

Da halt ich es wie die Mathematiker. Sie koennen auch Beweise ablehnen, ohne einen richtigen zu liefern.

Kritik ist okay, sofern sie begründet ist. Aber Aussagen wie "ich finde das schlecht, zu viel Code" helfen niemandem. Du bist übrigens immer noch nicht auf meine Fragen im letzten Post eingegangen. Insofern kann ich Tachyon nur zustimmen...

question123 schrieb:

Bin verwirrt. Ich krieg's nicht zum Laufen

Tut mir leid, ich hab die Funktionszeiger mal auf const -Versionen beschränkt, da diese für die meisten Fälle reichen sollten. Ausserdem scheint mir das sinnvoller als direkten Zugriff auf Member, da so die Zugriffsrechte der Klasse bewahrt werden können. Natürlich kannst du noch nach Belieben erweitern.