generische Operatoren mit Templates

Hallo Leute, ich beschäftige mich erst seit kurzer Zeit mit C++ und hänge jetzt schon seit Tagen an folgendem Problem fest...

Ich habe ein Klassentemplate geschrieben:

#include "systemc.h" 

typedef enum sd_digit {MINUS_ONE=-1, ZERO=0, ONE=1} ; 

template <class T, int Groesse> 

  class SD_Number 
  { 
    public: 
      T a[Groesse];   

      SD_Number& operator+(SD_Number B) ; 
              // weitere 

    private: 
      int seineGroesse ; 

    template <class T, int Groesse> 
    SD_Number<T, Groesse>& SD_Number<T, Groesse>::operator+(SD_Number B) 
       {.....} 

        // weitere

Das ganze wird eine SD-Zahl-Klasse(sd:signed-digit), die statt mit zweiwertiger logik mit dreiwertiger rechnet(1,0,-1). Die bitweise Darstellung wird in dem Array a gespeichert. Es sollen nun alle möglichen Operatoren definiert werden.

Mein Problem ist nun aber, dass ich bei meinen Operatoren(wie oben) immer nur SD-Zahlen gleicher BitLänge addieren,vergl.,... kann. Natürlich möchte ich aber auch "dreiBitige" mit "fünfBitigen" addieren,vergl. etc können!

Leider habe ich keine Ahnung, wie ich das realisieren kann!

Kann mir da jemand helfen ??

Danke

Bigwill

Alten Post gelöscht!

Ich hab da mal 2 Fragen.

1. Wozu an der Stelle überhaupt ein Template? Du müsstest ja schon irgendwie festlegen in welchem Form(at) du das Speicherst, wie willst du sonst die Opertormethoden überladen? Ist ja wohl ein Unterschied ob du das als Char oder als int oder als class xxx machst.

2. Wie stellst du dir das Rechnen und vergleichen vor? Insgesamt oder immer nur die einzelnen Digits?

Du hast natürlich recht, dass ein Template nicht unbedingt nötig wäre,da ich als class T eh nur sd_digit verwenden möchte. Das Template an dieser stelle ist zum einen 'historisch' bedingt (führe eine Arbeit fort) und zum anderen, weil ich die Array-Länge zur Compilezeit statisch festlegen muss! Klar könnte ich auch das Template weglassen und eine normale Klasse mit einem Konstruktor schreiben, der die gewünschte ArrayLänge mitbekommt! Das habe ich auch schon mal versucht. Das problem dabei: Dieses C++ Programm(das hier ist nur nen Teil) soll mit systemC als Hardware synthetisiert werden. SystemC kommt aber anscheinend nur mit standard-Konstruktoren klar. Auf jeden Fall versteht bzw. beachtet es den Konstruktor mit der ArrayLänge nicht. Das macht ja auch Sinn, weil die synthetisierte Hardware natürlich nicht dynamisch sein kann. Beispiel: Die Busbreite(in Bit) muss natürlich statisch zur 'Compilezeit' festehen und kann nicht erst zur 'laufzeit' festgelegt werden. Aber vielleicht gibts ja noch nen anderen u. besseren weg, die ArrayLänge statisch festzulegen??

Die beiden Operatoren, die ich vergleichen,addieren etc. möchte, werden bitweise 'bearbeitet'. Das läuft im Prinzip genauso, wie wenn es sich um Binärzahlen handeln würde, blos eben, daß hier auch -1 an den entsprechenden Stellen (2 hoch irgendwas) stehen können. Die -1 bedeutet dann, das bei der entsprechenden Umwandlung der "Trinärzahl" in eine natürliche Zahl, der entsprechende Summand (1,2,4,8,16,32,...) nicht addiert sondern subtrahiert wird!
Die Logik für das addieren,subtrahieren,vergleichen,etc sieht dann natürlich ein bissl anders aus,aber prinzipiell ähnlich.
Das ganze ist ein redundantes ZahlenSystem mit dem aber viel schnellere additionen etc. möglich sind (als bei binär), weil die Übertragsbits der einzelnen Stellen von einander unabhängig sind und damit parallel berechnet werden können!!!

Mein Problem ist halt, dass zwei SD_Zahlen verschiedener Länge, auf Grund des Templates als verschiedene Typen(Klasseninstanzen) aufgefaßt werden und die Operatoren aber immer nur auf einem konkreten Typ arbeiten (festgelegt Anzahl von Stellen im Array). Ich hätte die Operatoren gern so, dass sie auf SD_Zahlen beliebiger Länge arbeiten. Also der Parameter des Operators soll halt dem Template genügen und nicht durch die konkrete Instanz fest sein.(Generik halt). Bin bin mir auch überhaupt nit sicher ob das vielleicht schon prinzipiell nit geht oder so. Wie gesagt, bin neu im C++ Gebiet.

Bigwill

Und du brauchst unbedingt eine dynamische Länge? In ein normales DWORD könntest du zum Bsp. schon im 16 bit Wertebereich rechnen.

Naja, was heißt unbedingt. Klar könnte ich sagen, meine Operatoren sind 8bit,meine Ergebnisse,Zwischensummen etc. 16bit. Dann könnte ich sicherlich einfach zwei Klasse bauen,eine mit 8 und eine mit 16 bit, die jeweils die andere als Operand für die Operationen braucht. Damit müßte dann ja eigentlich op1(8bit) + op2(16bit) und umgekehrt möglich sein.
Ich brauche wahrscheinlich aber noch zwischenstufen(bezüglich der Bitzahl).
Für jede Bitbreite ne Klasse zu schreiben und für jede ander Klasse nen extra Operator der nur für diese Bitbreite funzt,ich weiß nit. Klingt mir irgendwie garnicht gut....
Wenns halt irgendwie möglich ist, lieber ne Art 'generischen Operator' (bezüglich der BitAnzahl).

Eh sorry, meinte natürlich, dass der Operand 8bit sein könnte,nicht der Operator

Bigwill

Machst du ds der Geschwindigkeit wegen? Ich glaube nämlich nicht das, daß so schneller ist.
Da enum ja vom Typ her nt ist, muust du so ja bei einer 32bit 32*2 ints addieren/subtrahieren oder was auch immer, wo du sonst nur 2 1*2 int hast.

Das ganze wird meine Studienarbeit für meinen technische Informatik Prof.
Es geht eben darum, ein kleines "Rechenwerk" mal mit dieser "trinären" Logik zu bauen. Du hast sicherlich recht,dass das ganze Softwaremäßig sicherlich nicht die beste, schnellste Variante ist. Ich kenn mich da halt c++mäßig nit so aus. Die Geschwindigkeit soll dadurch "entstehen", dass es eben möglich ist die Parallelbearbeitungsmöglichkeit dieser Berechnungstechnik auszunutzen. Im endeffekt laufen ja die umzusetzenden Grundrechenarten alle auf additionen hinaus. D.h. Hardwaremäßig wir mal eine Addierzelle und ein Contoller synthetisiert. Es könnten dann beliebig viele Addierzellen parallel arbeiten. Daraus und mit einer zusätzlichen Pipliningarchitektur sollen die Geschwindigkeitsvorteile entstehen. (so hoffe ich zumindest) Du hast sicherlich recht,dass mein c++ interner Datentypaufbau nicht optimal ist und damit meine viell. mal syntetisierte Hardware auch nicht,aber fürs erste wäre ich schon sehr glücklich, wenns überhaupt mal funzt.....