Pseudo Templating mit Makros



  • Hallo Leute,

    ich habe folgende Klasse

    class Foo
    {
    public:
       int data[50];
    }
    

    nun will ich diese klasse generisch machen "ohne" templates , nur mit makros! wie könnte ich das umsetzen, so dass der Typ von data "int" und dier größe von data "50" generisch ist.

    Ist das möglich!?



  • NullBockException schrieb:

    Ist das möglich!?

    ja, aber eine selten bloede Idee.

    Sag was du erreichen willst und wir koennen dir gerne eine vernuenftige Loesung vorschlagen.

    Ein: "ich will von Berlin nach Rom fliegen aber ohne flieggeraet" ist eine dumme aufgabenstellung. ein "ich will von Berlin nach Rom reisen, aber ohne flieggeraet" ist dagegen sehr wohl eine vernuenftige Aufgabenstellung.


  • Mod

    #define FOO(TYPE, SIZE)    \
    class Foo_ ## TYPE ## _ ## SIZE \
    {                               \
     public:                        \
      TYPE data[SIZE];              \
    };
    
    FOO(int, 50)
    

    Viel Spaß, wenn du daran jemals was Debuggen musst. Makros sind da noch 10x schlimmer als die Fehlermeldungen bei Templates.



  • Danke schonmal!

    es geht darum, dass ich keine templates benutzen darf! aber C++ schon!

    ich habe einen FIFO bzw. ringpuffer, welcher momemntan eine best. anzahl an elementen haben darf, und der typ der elemenete fix ist.

    Aber ich brauche 3 instancen des puffers mit unterschiedlichen typen.. hmm.. ich weiß , scheiss anforderung..

    habe mir schon überlegt das in C zu machen , für jede funktion, sprich (POP,PUSH,LOAD) eine markofunktion...

    was meint ihr.. lösbar?



  • NullBockException schrieb:

    es geht darum, dass ich keine templates benutzen darf! aber C++ schon!

    Dachte ich mir.
    Dann vergiss den Code von SeppJ gleich wieder.

    ich habe einen FIFO bzw. ringpuffer, welcher momemntan eine best. anzahl an elementen haben darf, und der typ der elemenete fix ist.

    dann machst du das ganze wie man es in C gemacht hat.

    Du musst deine Techniken immer den Tools anpassen die du hast. In C++ wuerdest du Templates verwenden. Sehr schoen. Aber in C eben nicht.

    Aber ich brauche 3 instancen des puffers mit unterschiedlichen typen.. hmm.. ich weiß , scheiss anforderung..

    brauchst du den typ wirklich? oder ist das nur eine fixe idee?

    ein ringbuffer ist nichts anderes als array - uU willst du also nur ein array.

    und wenn nicht, brauchst du wirklich den typen? wenn nicht, dann reicht ja void*

    viele wege fuehren nach rom.



  • Hm ok danke, d.h. ich sollte dann auf c zurückgreifen?

    hmm ja es sind 2 unterschiedliche typen bzw. strukturen die in den ringpuffer sollten. struct FRAME_TX und struct FRAME_RX

    hmm ok, void* is ne gute idee, dann kann ich ja die klasse verwenden, oder? ! und ja es ist ein array das ein fixe größte hat in der klassendefinition..

    welcher weg wäre am schönsten?



  • Kommt darauf an.

    Wenn die Typen aehnlich sind, kannst du ja auch eine struct mit den gleichen Member Typen erstellen - gleiche structs haben ja gleiches speicher layout (sofern man aufpasst).

    gibt viele moeglichkeiten. ich wuerde vielleicht sogar den code einmal mit void* schreiben und dann pro typ eigene accessors anbieten.

    schwer zu sagen.



  • jepp, die strukturen sind gleich groß, an das hab ich auch schon gedacht, kann man eig. easy casten.. aber ich will keinen redundaten code.. das mit void* und typ spezifische accessors wäre auch ne idee... hmmm.. was aber ne größere herrausforderung ist, is die variable größe der arrays oder?? wie könnte ich das anstellen, dynamisch speicher anfordern darf ich nich.. muss fix definiert sein.. nur bei der deklaration könnte ich das irgendwie angeben...



  • Wie wäre es mit einem festen Array und Unions?


  • Mod

    Wie wäre es damit, C++ ganz sein zu lassen und stattdessen C mit VLAs zu nutzen? Anscheinend darfst du ja sowieso nichts machen, was C++ rechtfertigen würde.



  • NullBockException schrieb:

    dynamisch speicher anfordern darf ich nich

    wenn das ein micro controller ist, dann nimm einfach ne richtige sprache dafuer. wenn dein c++ compiler eh keine features hat die c++ zu c++ machen, dann schreib das ganze gleich einer ordentlichen sprache fuer die plattform.



  • Warum dann ueberhaupt generisch? Der Arbeitsaufwand haelt sich doch sehr in Grenzen, dass ganze 3 Mal mit unterschiedlichen Typen zu programmieren.

    Warum ueberhaupt Objekte (class)? Wenn Speicher nicht dynamisch angefordert wird, dann kann auch gleich mit Arrays gerechnet werden.



  • Ja genau mircocontroller. Und ja das ding unterstützt C bzw. C++, auch templating etc. aber mein vorgesetzter vertraut dem c++ compiler nicht, da dieser teilweise falschen code generiet bzw. zu wenige warnungen ausspuckt...

    klassen verwendet ich nur zur kapselung, von einem OO design und dynamic kann man da nich sprechen.

    statt c module , sind c++ ne schönere kapselung (finde ich)

    naja werde dann den buffer glaub in C schreiben mit makros typen...

    Danke!



  • NullbockException schrieb:

    Ja genau mircocontroller. Und ja das ding unterstützt C bzw. C++, auch templating etc. aber mein vorgesetzter vertraut dem c++ compiler nicht, da dieser teilweise falschen code generiet bzw. zu wenige warnungen ausspuckt...

    Ah ja, und ein fehlerhafter Compiler wird plötzlich weniger fehlerhaft, wenn man anfängt, die Sprache zu vergewaltigen?
    Für die Warnungen kann man statische Codechecker einsetzen, die machen in der Hinsicht einen recht guten Job. Für den Verdacht, der Compiler könne falschen Code generieren gibts Tests. "Mein Vorgesetzter vertraut dem nicht" klingt sehr irrational...



  • Ich denke da ist nix schlimmes dran wenn man Klassen wirklich nur als Kapselung nimmt und ansonsten Funktionen nutzt die es auch in C gibt. Wenn ich mich recht erinnere hat John Carmack sein Doom3 auch so programmiert und Bjarne Stroustrup findet wohl auch nix schlimmes dran C mit Klassen zu programmieren, habe ich mal so gelesen.

    Kommt immer drauf an, ist da meine Meinung. OOP ist nur eine Art eine Software zu entwickeln nicht die einzige und mit Sicherheit auch nicht immer Weisheit letzter Schluss.

    Beruflich muss ich leider in PHP+Zend programmieren und unser Leiter ist so verstrickt in Pattern und generalisiert alles zu Tode, so dass man kaum noch nachvollziehen kann was das Programm eigentlich macht. Zu dem brauch er ewig um ein Problem zu lösen und hat es verlernt auch mal ganz einfache und banale Lösungen zu finden. Das hat er selbst zugegeben und wünscht sich mal wieder etwas einfacher an ein Probleme ran gehen zu können, ohne gleich alles generalisieren so wollen und damit ziemlich Lange für eine einfach Lösung zu brauchen.



  • Butterbrot schrieb:

    wünscht sich mal wieder etwas einfacher an ein Probleme ran gehen zu können, ohne gleich alles generalisieren so wollen und damit ziemlich Lange für eine einfach Lösung zu brauchen.

    Vielleicht sollte er ein bisschen Richtung TDD gehen (weiß nicht wie gute Testframeworks es für php+Zend gibt):
    Schreibe zuerst eine Reihe Tests, die genau das überprüfen, was eine Funktion/Klasse/Modul an Funktionalität haben soll. Schreibe danach den zu testenden Code möglichst simpel, so dass er gerade nur die Tests befriedigt, nicht mehr.



  • Das hatte wir wohl auch in der Firma mal, also son Test-Driven-Development auch Scum war im Einsatz. Die Entwickler mochten es, aber die Chefetage kostete beides zu viel Zeit und damit Geld, obwohl man am Ende viel Geld und Nerven sparen kann.



  • Butterbrot schrieb:

    Scum

    nice 😃

    Die Entwickler mochten es, aber die Chefetage kostete beides zu viel Zeit und damit Geld, obwohl man am Ende viel Geld und Nerven sparen kann.

    Wenn die Rechnung am Ende nicht aufgeht, ist natürlich jeder noch so schöne Prozess fürn Eimer. Allerdings muss man häufig der Chefetage erst beibringen, dass ein Produkt noch längst nicht fertig ist und die Kosten noch lange nicht aufhören, wenn der Nightly Build einmal durchgelaufen ist 😉



  • Butterbrot schrieb:

    auch Scum war im Einsatz

    Ich glaube, du meintest
    http://en.wikipedia.org/wiki/Scrum_(development)


Anmelden zum Antworten