Templates: Zur Laufzeit entscheiden?

Ok - ja ich sehe das auch wie Du - danke hier schonmal. Ich habe nur mal von jemanden was gehört dass es auch zur Laufzeit ginge und diese person kennt sich wirklich aus. Ich hatte es damals nicht verstanden und der Kontakt ist leider abgebrochen.

Ich sehe das aber eigentlich nicht als allzu problematisch an, da man diese Unterscheidung in eine Klasse wegkapseln kann.

Könntest Du vielleicht zeigen wie du das meinst mit der wegkapselung - würd mich interessieren. Danke

gambo schrieb:

Ok - ja ich sehe das auch wie Du - danke hier schonmal. Ich habe nur mal von jemanden was gehört dass es auch zur Laufzeit ginge und diese person kennt sich wirklich aus. Ich hatte es damals nicht verstanden und der Kontakt ist leider abgebrochen.

Klar, nennt sich Polymorphie, wundert mich, dass du das nicht kennst, das lernst man meist vor den Templates kennen.

Tachyon

Tippgeber schrieb:

Klar, nennt sich Polymorphie, wundert mich, dass du das nicht kennst, das lernst man meist vor den Templates kennen.

Polymorphie macht hier aber keinen Sinn, da Du verschiedene Klassen hast, und immer noch unterscheiden musst, für welchen Zahlentyp Du einlesen willst.

außerdem ist polymorphie von der performance zu langsam - zumindest hab ich das so bisher verstanden. Und mir geht es um performance.

unskilled

gambo schrieb:

außerdem ist polymorphie von der performance zu langsam - zumindest hab ich das so bisher verstanden. Und mir geht es um performance.

google das mal: "premature optimization"

und was programmierst du denn, dass es dir auf nen paar Zehntel Prozent ankommt - nicht mal...

sag halt, was du willst - wenn du max. performance haben möchtest, nimm halt asm... xD

bb

Tachyon schrieb:

Tippgeber schrieb:

Klar, nennt sich Polymorphie, wundert mich, dass du das nicht kennst, das lernst man meist vor den Templates kennen.

Polymorphie macht hier aber keinen Sinn, da Du verschiedene Klassen hast, und immer noch unterscheiden musst, für welchen Zahlentyp Du einlesen willst.

Wieso nicht? Dafür gibt es Factories.

hui jetzt mal langsam leudde

was genau ist asm und was sind Factories..

ach inline-assembler... naja - muss net sein

gambo schrieb:

hui jetzt mal langsam leudde

was genau ist asm und was sind Factories..

Factory Pattern, das soll jetzt aber nicht heißen, dass du das benutzen musst/sollst.

Shade Of Mine

unskilled schrieb:

google das mal: "premature optimization"

Will nur kurz anmerken dass das hier eine Designentscheidung ist an die man dann ewig gebunden ist. Da sollte man sich schon vorher gedanken machen...

ich hätte hier noch eine spezielle zusatzfrage die jetzt nicht in richtung performance zielt sondern auf die funktionsweise.

Mir ist nicht klar wie ich denn typ-abhängig die funktion aufrufen kann. Im Moment geschieht das bei mir so dass ich für jeden typ variablen anlege die ich brauchen werde und es werden halt nur die gesetzt in welchen typ-zweig gelaufen wird. Geht das nicht sauberer? So bleibt ja die Hälfte (bei 2 typen) an variablen immer auf Null z.B.:

//irgndwo in der main.cpp

int* arr_int = NULL;
float* arr_float = NULL;

//jetzt wird herausgefunden welcher typ festliegt
// z.B. durch einlesen eines files oder sonstwie das ist
//unerheblich
type = get_type(file); 

// jetzt kommt der if-zweig oder switch (man weiß ja nie welche typen noch  
// kommen)
switch(type)
{
    //t_int und t_float wurden über enum definiert
    case t_int: // wir sind im int-fall
       fülle_int_arr(arr_int);
    case t_float: // wir sind im float-fall
       fülle_float_arr(arr_float);
}

delete arr_int;
delete arr_float;

dnake

Habe ich etwas verpasst? Es ging doch eben noch um reell vs. komplex und nicht int vs. float.

Vielleicht solltest du doch etwas mehr Informationen rausrücken.

ob reell oder komplex oder int oder float ist doch für das Problem dass hier gerade gepostet habe irrelevant. Um konsistent zu bleiben hätte ich aber auch komplex benutzen können ja - sorry für die verwirrung. mehr infos sind für eine derartige frage zu viel overkill - es heißt doch immer minimalbeispiel..

unskilled

Shade Of Mine schrieb:

unskilled schrieb:

google das mal: "premature optimization"

Will nur kurz anmerken dass das hier eine Designentscheidung ist an die man dann ewig gebunden ist. Da sollte man sich schon vorher gedanken machen...

Seh ich genauso - allerdings sind dann so ne Sätze kein Argument gegen irgendetwas:
"außerdem ist polymorphie von der performance zu langsam - zumindest hab ich das so bisher verstanden."
Wenn ich ne aufwendige, zeitintensive Fkt habe, dann ist die eben immer genauso zeitintensiv - vll ist sie immer 25 Taktzyklen früher fertig - aber wenn das so wichtig ist, sollte Performance auch keine Rolle spielen (sollte ja klar sein, dass 25 Taktzyklen entweder 0% sind, also egal oder wenns mehr ist, dann hat man au kein Performance-Problem)...
Kannst mich ja gern korrigieren, wenn ich damit falsch liege - aber denke nicht, dass es da so viel geben wird ;P

Machts gut - ich tu mal so, als ob ich kein Kellerkind wäre und bin dann ma paar Stunden weg

Tachyon

Tippgeber schrieb:

Tachyon schrieb:

Tippgeber schrieb:

Klar, nennt sich Polymorphie, wundert mich, dass du das nicht kennst, das lernst man meist vor den Templates kennen.

Polymorphie macht hier aber keinen Sinn, da Du verschiedene Klassen hast, und immer noch unterscheiden musst, für welchen Zahlentyp Du einlesen willst.

Wieso nicht? Dafür gibt es Factories.

Und in der Factory wird nicht über eine Fallunterscheidung entschieden, ein Objekt welchen ADTs erstellt werden soll? Ich denke mal doch. Zumal reelle Zahlen und komplexe Zahlen aufgrund der unterschiedlichen Datentypen eigentlich eher nicht in den Bereich dessen Fallen, was Du mit Polymorphie meinst. Und für statische Polymorphie brauchts keine Factory.

Tachyon schrieb:

Tippgeber schrieb:

Tachyon schrieb:

Tippgeber schrieb:

Klar, nennt sich Polymorphie, wundert mich, dass du das nicht kennst, das lernst man meist vor den Templates kennen.

Polymorphie macht hier aber keinen Sinn, da Du verschiedene Klassen hast, und immer noch unterscheiden musst, für welchen Zahlentyp Du einlesen willst.

Wieso nicht? Dafür gibt es Factories.

Und in der Factory wird nicht über eine Fallunterscheidung entschieden, ein Objekt welchen ADTs erstellt werden soll? Ich denke mal doch. Zumal reelle Zahlen und komplexe Zahlen aufgrund der unterschiedlichen Datentypen eigentlich eher nicht in den Bereich dessen Fallen, was Du mit Polymorphie meinst. Und für statische Polymorphie brauchts keine Factory.

Gehen wir von verschiedenen Dingen aus? Ich dachte, dass es hier darum geht wie die Daten nach dem Einlesen gehandhabt werden.
Und das Einlesen an für sich sollte in der Factory geschehen bzw. dort so realisiert werden, dass eben (im Idealfall) nur dort diese Fallunterscheidung auftaucht.

Tachyon

Tippgeber schrieb:

...

Und dann? Dann hast Du immer noch verschiedene Typen. Da hilft Laufzeitpolymorphie nicht.

Tachyon schrieb:

Tippgeber schrieb:

...

Und dann? Dann hast Du immer noch verschiedene Typen. Da hilft Laufzeitpolymorphie nicht.

Ich denke dabei an

struct Number { /* ... */ };

struct Real : Number { /* ... */ };

struct Complex : Number { /* ... */ };

Und du?

Tachyon

Tippgeber schrieb:

...

Ich würde jetzt eher an z.B. float und std::complex<float> denken. Die Idee irgenwelche Wrapper dafür zu schreiben, halte ich nicht gerade für optimal.
Das hat ja schon fast was von den hier im Forum immer wieder auftauchenden "bool-Wrappern".

Tachyon schrieb:

Tippgeber schrieb:

...

Ich würde jetzt eher an z.B. float und std::complex<float> denken. Die Idee irgenwelche Wrapper dafür zu schreiben, halte ich nicht gerade für optimal.
Das hat ja schon fast was von den hier im Forum immer wieder auftauchenden "bool-Wrappern".

Du hast ja keinen zusätzlichen Speicherverbrauch durch diese Wrapper, aber ein Problem für das mir gerade keine schöne Lösung einfällt ist das Wrappen der Arrays, ein Number[] bzw. std::vector< Number > geht ja leider nicht. Von daher ist diese Lösung auch nicht wirklich ausgereift.

Aber ich bin sowieso der Meinung, dass man keine sinnvolle Lösung vorschlagen kann, so lange man nicht weiß wie komplex die Aufgabe wirklich ist.