SoRResult process(SoRID pId, short pParam1, short pParam2)
{
    switch(pID)
    {
        case ID1:
            return Funktion1(pParam1);
        case ID2:
            return Funktion2(pParam1, pParam2);
        // ne ganze Menge weiterer Funktionsaufrufe //
        default:
            return Empty;
    }
}

Da das Projekt sehr performanceabhängig ist, würde ich jetzt gerne wissen, ob man das vielleicht irgendwie optimieren kann oder ob es eine andere Alternative gibt.

Dann kannst du mit einem Array von Funktionspointern arbeiten und bin schneller als die Feuerwehr:

// könnten fehler drin sien, ungetestet und so

// init
SoRREsult (*BlubbFunc) (short, short);
BlubbFunc funcs [size];

funcs[0] = Funktion1;
funcs[1] = Funktion2;

inline SoRResult process(SoRID pId, short pParam1, short pParam2)
{
    return funcs[pId](pParam1,pParam2);
}

MfG SideWinder

BTW: Ungarische Notation ist - wie würde Jimmy Pop sagen - homosexuell.

BTW2: Hatten wir nicht heute schonmal ein Problem mit einem Wort das Homosexualität als schlecht darstellt? Ich diskriminiere niemanden.

...

BTW: Ungarische Notation ist - wie würde Jimmy Pop sagen - homosexuell.

BTW2: Hatten wir nicht heute schonmal ein Problem mit einem Wort das Homosexualität als schlecht darstellt? Ich diskriminiere niemanden.

Findest du nun Ungarische Notation gut oder schlecht??

MfG SideWinder

Schlecht.

MfG SideWinder

Genau UN kannste Dir in den Arsch schieben!

Wenn es wirklcih eine ganze Menge weiterer Aufrufe sind, schau, dass alle Funktionen die selbe Anzahl an Parametern haben.
Dann kannst du mit einem Array von Funktionspointern arbeiten und bin schneller als die Feuerwehr:

switch ist schneller als dein array.
bei switch sollte man natürlich darauf achten, daß die IDs bei 0 beginnen und fortlaufend sind, damit's von dem gleichen vortiele-tellerchen essen kann. außerdem tut ein default: __assume(false); auch ganz gut, wenn man sich's leisten kann (entspricht ungefähr dem assert(ID>=0 && ID<=MAXID)).
switch ist deswegen schneller, weils die kleinen funktionsaufrufe auch inline läßt und hier kann der optimierer zuschlagen.

wenn du maximale performance willst, dann nimm ein switch und sorg dafür, dass die implementierung der funktionen in diesem modul sichtbar sind, dann sind die chancen optimal für gute compilerarbeit

SideWinder schrieb:

Wenn es wirklcih eine ganze Menge weiterer Aufrufe sind, schau, dass alle Funktionen die selbe Anzahl an Parametern haben.
Dann kannst du mit einem Array von Funktionspointern arbeiten und bin schneller als die Feuerwehr:

switch ist schneller als dein array.
bei switch sollte man natürlich darauf achten, daß die IDs bei 0 beginnen und fortlaufend sind, damit's von dem gleichen vortiele-tellerchen essen kann. außerdem tut ein default: __assume(false); auch ganz gut, wenn man sich's leisten kann (entspricht ungefähr dem assert(ID>=0 && ID<=MAXID)).
switch ist deswegen schneller, weils die kleinen funktionsaufrufe auch inline läßt und hier kann der optimierer zuschlagen.

Oh, switch ist noch besser als ich dachte. Gut zu wissen, danke.

MfG SideWinder

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

...das mit der UN wurde schon x Mal diskutiert. Wenn Du alleine codest, machs wies Dir gefällt, im Team sind Konventionen nützlich.
Was ich eher..naja..sagen wir mal..affig finde, ist die Verknüpfung von Wörtern mit Grossbuchstaben, wie zB SideWinder...

btw: was hast Du denn für Arbeitszeiten

naja...

Mein Beileid.
Aber lass Dir wenigstens die Überstunden ordentlich vergolden beim nächsten "Qualifikationsgespräch" ( Bingo ) sprich Lohnverhandlung

Ein gewaltiger Unterschied ist es aber, wenn Wörter komplett in Großbuchstaben geschrieben sind (Die Microsoft-Leute machen das ja fürs Leben gern), dann ist es sehr schwer die einzelne Wörter rauszulesen und es erfordert sehr viel mehr Konzentration, als bei den anderen beiden Varianten.

jeder_sollte_selbst_entscheiden_was_er_besser_lesen_kann_und_das_dann_auch_so_anwenden

Ich mach übrigens beides: Für Klassen, Typenames/defs, Structs, also alles was einem Typ irgendwie ähnelt, schreib ich erste Version.
Instanzierungen, Variablen etc schreib ich nach zweiter Art.
Dann kann ich das schön trennen.

MeineTolleKlasse eine_tolle_klasse = 0;

PS: Ich habe euren "Feldzug" gegen die Ungarische Notation mitverfolgt und finde das ehrlich gesagt etwas überzogen. Ich benutze Teile der UN weil sie mir hilft (c=Counter, f=Flag usw.) und nicht weil ich sie schön/cool/individuell oder sowas finde. In diesem Beispiel habe ich nichtmal reine UN verwendet sondern nur eine Markierung p für Parameter (im Gegensatz zu m für Member).

das is ja auch die richtige nutzung der UN gegen die wohl niemand etwas hat. Es geht hier eher um sowas wie iFlag(i=int). Also typinformationen die nie jemand braucht. Was die UN ursprünglich machen wollte, war informationen über den verwendungszweck zu vermitteln, und das ist ok.

das is ja auch die richtige nutzung der UN gegen die wohl niemand etwas hat.

naja, ist auch unfug. kräftig ist sie zum beispiel bei koordinaten kann man horizontale werte mit h und vertikale werte mit v kennzeichnen und wenn da dann steht ha=hk+hp*(hx-hy)/(vm-vb), dann sieht man auf den ersten blick, daß die typengeschichichte stimmt. differenzen und summen haben gleichtypige summanden und so.