#ifdef -> einrücken oder nicht?

[gruppa]

Nein das will ich nicht. Mir wurde eingetrichtert nach SingleSource Prinzip zu arbeiten und ich will das auch. Es wird ja wohl einen eleganten und effizienten und allgmein üblichen weg geben beides in einem code zu vereinen...

[Shade@work]

gruppa schrieb:

Nein das will ich nicht. Mir wurde eingetrichtert nach SingleSource Prinzip zu arbeiten und ich will das auch. Es wird ja wohl einen eleganten und effizienten und allgmein üblichen weg geben beides in einem code zu vereinen...

was knivil meint ist, dass sequentielle archtiekturen komplett anders aussehen als parallele. wenn du es richtig machen würdest, hättest du 2 komplett unterschiedliche designs. denn parallel löst du einfach probleme komplett anders...

und beides mit dem selben design zu realisieren kann nicht optimal sein...

[gruppa]

ok ....ich verstehe jetzt knivil aber bin überrascht...ich wüsste jetzt überhaupt nicht wo der unterschied sein sollte bzw. wieso man da unterschiede hat.
Und wenn es unterschiede gibt, warum wird von Leuten die sich deutlich im Forschungsbereich etabliert haben verzählt, dass man sequentiell und parallel in einen code packen sollte...

[MisterDoubt]

Ich finde es sehr interessant, was hier geschrieben wird Ich habe zu dem Thema auch eine Frage: Was ist zum Beispiel, wenn ich in C++ eine Socketklasse schreiben will, die Plattformunabhängig ist? Es handelt sich hierbei nur um ein Beispiel. Ich weiß, dass es sowas bereits gibt

Sehe ich das richtig, dass ich die Klasse für jedes System neu schreiben soll?

#ifdef WIN32
#include "win32/Socket.h"
//...
#else
#error Not supported yet.
#endif

Ich hätte ja sehr viel doppelten Code. Was mache ich dann zum Beispiel, wenn ein Bug gefunden wurde?
Ich müsste in jeder Datei etwas abändern. Ist das nicht sehr fehleranfällig?

In der Hinsicht habe ich meine Zweifel...

MisterDoubt

[gruppa]

*push

[gruppa]

würde denn bezüglich der augangsfrage mit der bedingten kompilierung vielleicht funktions-pointer ein sinnvolle alternative ?

[Shade Of Mine]

gruppa schrieb:

ok ....ich verstehe jetzt knivil aber bin überrascht...ich wüsste jetzt überhaupt nicht wo der unterschied sein sollte bzw. wieso man da unterschiede hat.
Und wenn es unterschiede gibt, warum wird von Leuten die sich deutlich im Forschungsbereich etabliert haben verzählt, dass man sequentiell und parallel in einen code packen sollte...

Ne, das hast du falsch verstanden.

Du kannst parallelen und sequentiellen Code schon gemeinsam haben (musst du sogar). Aber du löst Probleme unterschiedlich. Du kannst ein Problem zB parallel lösen oder aber sequentiell. Die Lösung wird bei beiden varianten funktionieren, aber komplett anders aussehen.

Sehen wir uns zB IO an. Wir haben eine blockende Operation. Jetzt können wir diese zB über etwas select() ähnliches ansteuern um zu wissen wann wir welche Aktion setzen können, oder aber über signale die asynchron laufen.

Beides funktioniert, aber der ganze ansatz ist ein komplett anderer.

deshalb denke ich, dass es nicht sehr sinnvoll sein kann beides gleichzeitig anzubieten.

[gruppa]

Ok danke - und nochmal zu meinem jetzigen vorhaben bezüglich der auslagerung der ifdefs.

Ich habe jetzt vor für den sequentiellen code ein file anzulegen im ordner sequentiell/variante1.hpp und für den parallelen code ein file anzulegen im ordner parallel/variante2.hpp bzw. einfach nur die 2 files im source-verzeichnis.

Und in jedes file abhängig von sequentiell/parallel die funktion mit gleichem namen von der syntax her zu benennen und über 1 ifdef dann in den jeweiligen *.cpp files einzubinden.

Damit wird über den präprozessor immer nur ein file von den beiden eingebunden und die sequentielle oder parallele funktion angestoßen.

Wäre das ein sauberer weg? War doch das was ihr (Dravere etc...) mir vorgeschlagen haben...oder?

[gruppa]

Und dann fällt mir noch was ein bzw. eine Frage:

Wenn ich jetzt z.B. in einem flag einiges ausführen möchte im anderen aber nichts... macht dann sowas sinn?

//irgendwo in main.cpp z.B.

finalize();

//in file variante1.hpp

void finalize()
{
    delete ....//irgendwas
    lib_call_finalize();
}

//in file variante2.hpp

void finalize()
{

}

[Shade Of Mine]

ja und ja.

[gruppa]

Danke erneut für die Antwort. Könnte man das auch irgendwie über Makros realisieren. Also ein Makro setzen in der main z.B. und dann die verzweigung in separatem file oder so ähnlich? Ginge das und wenn ja - wie?

[Shade Of Mine]

gruppa schrieb:

Danke erneut für die Antwort. Könnte man das auch irgendwie über Makros realisieren. Also ein Makro setzen in der main z.B. und dann die verzweigung in separatem file oder so ähnlich? Ginge das und wenn ja - wie?

Dafür hast du ja die proxy dateien.
foo.cpp sieht zB so aus:

#ifdef X
#  include "X/foo.cpp"
#elif Y
#  include "Y/foo.cpp"
...

[gruppa]

bitte nicht wundern warum ich so nachbohre...es interessiert mich einfach:

zu schadeofmine: hmm...meinst Du jetzt dass das so gesehen das gleiche ist? Über Makros und über die auslagerung der ifdefs?

Ich würde gerne noch folgendes wissen und hoffe auf die Geduld der Leser

* Wenn ich jetzt über eine bedingte Kompilierung eine leere Methode einbinde (wie z.B. das finalize() vom vorigen post) - ist das von der Performance her bremsed. Natürlich nur unwesentlich aber wenn es z.B. sehr oft vorkommen würde...? Nur aus Interesse die Frage...

* Würde man vielleicht sowas auch über function-pointer lösen - also über ein if-else einen function-pointer zur laufzeit definieren und dann über diesen in die richtige methode switchen? Oder wäre das von der performance her langsamer oder gar unübersichtlicher?

[volkard]

gruppa schrieb:

* Wenn ich jetzt über eine bedingte Kompilierung eine leere Methode einbinde (wie z.B. das finalize() vom vorigen post) - ist das von der Performance her bremsed. Natürlich nur unwesentlich aber wenn es z.B. sehr oft vorkommen würde...? Nur aus Interesse die Frage...

ja, bremst, wenn finalize() nicht inline ist und in einer anderen cpp-datei wohnt und der compiler sie nicht einfach wegoptimieren kann.
wenn sie in einem header wohnt und inline ist, kostet das gar nix.

[gruppa]

und wenn ich über -O3 kompiliere - werden da nicht alle funktionen als inline behandelt? Oder red ich jetzt völligen quatsch?

[Shade Of Mine]

gruppa schrieb:

und wenn ich über -O3 kompiliere - werden da nicht alle funktionen als inline behandelt? Oder red ich jetzt völligen quatsch?

inline bedeutet nicht das der code schneller wird, er kann auch langsamer werden...

was volkard aber gemeint hat ist, wenn der compiler die funktion inlinen kann und sieht dass die funktion leer ist und spart es sich code zu generieren.

je nachdem wie clever ein compiler ist, desto mehr funktionen könnte er inlinen. der vc++ zB kann funktionen über mehrere .cpp Dateien hinweg inlinen - was aber jeder kann ist wenn die funktion in einem header steht.

[gruppa]

ah ok- danke für die Antwort.

jetzt mal wieder ne blöde frage: eine funktion im header - damit ist gemeint sie soll einfach roh in einem header-file (z.B. variante1.hpp) liegen?

Wo kann eine Funktion noch liegen wenn nicht im header? Als methode einer Klasse?

[Shade Of Mine]

gruppa schrieb:

Wo kann eine Funktion noch liegen wenn nicht im header? Als methode einer Klasse?

Die funktions definition muss im header liegen damit die compiler problemlos geinlined werden können. die deklaration muss sowieso im header stehen.

definition:
void foo() {}

deklaration:
void foo();

[knivil]

Shade Of Mine schrieb:

Dafür hast du ja die proxy dateien.
foo.cpp sieht zB so aus:

#ifdef X
#  include "X/foo.cpp"
#elif Y
#  include "Y/foo.cpp"
...

Sowas wuerde ich nie machen, da ich es als viel sauberer empfinde, es ueber entsprechende Build-/Linkeinstellungen (Skripte, what ever) zu steuern. Ich finde es einfach haesslich.

[Shade Of Mine]

knivil schrieb:

Sowas wuerde ich nie machen, da ich es als viel sauberer empfinde, es ueber entsprechende Build-/Linkeinstellungen (Skripte, what ever) zu steuern. Ich finde es einfach haesslich.

dh du musst dauernd die build scripte anpassen...?

das wäre zB für mich ein no-go.
der vorteil von meiner #include variante ist, das alles transparent abläuft. du kompilierst die foo.cpp und die flags definieren was genau passiert.

denn wozu muss man wissen dass foo.cpp in wirklichkeit 3 unterschiedliche implementierungen hat? und vorallem wann diese verwendet werden. diese logik würde ich zB nie in ein buildscript packen. da sie sich nämlich konstant ändern kann. und build scripte sind in meinen augen etwas konstantes woran man nicht unnötig viel herum manipulieren sollte...