kaum habe ich mein erstes Problem, komme ich auch gleich mit einem zweiten -:

Wahrscheinlich lässt sich diese Frage nun schneller beantworten, weil es mir eigentlich nur um eine einzige Methode geht, die ich nicht zu deklarieren weiß. Aber vielleicht - habe ich mir gedacht - spielt ja eine Frage im Forum gutes Fachwissen von Euch ein.

Nun, man nehme an, wir haben eine Template-Klasse namens "Test", die wie folgt aufgebaut ist:

// ...

template <typename T = void>
class Test
{
public:
  typedef T value_type;

  Test();
  Test(value_type* value);

  void       set(value_type* value);
  value_type get() const;

private:
  value_type* value;
};

/* Template-Methoden: */

template <typename T> Test<T>::Test()
{
  this->value = std::NULL;
}

template <typename T> Test<T>::Test(value_type* value)
{
  this->set(value);
}

template <typename T> void Test<T>::set(value_type* value)
{
  this->value = value;
}

template <typename T> T Test<T>::get() const
{
  return *this->value;
}

Meine Frage ist: Wie muss die Methode zur Konvertierung von "Test<irgendwas>* zu Test<>* bzw. Test<void>" lauten? Meine Schwierigkeit ist, dass ich hier einen Zeiger in einen Zeiger umwandeln muss, wofür ich keinerlei Formulierung einer solchen Konvertierungs-Methode kenne. Natürlich kann ich einfach jedes Mal den Konvertierung-Operator (Test<>) verwenden, aber genau das "jedes Mal" möchte ich ja mit einer Klassenmethode automatisieren.

Wenn ich also habe:

Test<int> x(new int(123));
Test<void>* y = &x;

, dann soll mir die zweite Zeile keinen Fehler ausspucken.

Kennt jemand zufällig eine Lösung dazu, oder zählt mein Vorhaben zu den vielen, aber oft unbekannten No-Gos von C++.

Außerdem bin ich für Kritik zu meinem Programmier-Stil, insbesondere zu meiner obigen Kassendefinition, immer offen.

Gruß Josef

template <typename U>
  Test(const Test<U>& other) {/*Was auch immer...*/}

  template <typename U>
  Test<T>& operator=(const Test<U>& other) {/*Was auch immer...*/return *this;}

Das andere wär' eher etwas für reinterpret_cast und beim Dereferenzieren dann UB.
Achso, deinen Programmierstil find' ich da jetzt eigentlich ganz ok. Die Funktion der Klasse versteh' ich zwar nicht, aber es ist ja wahrscheinlich nur ne Übung. (Versuchst du std::unique_ptr nachzubauen?) Achja, du hast da keine Template-Klasse sondern ein Klassen-Template.

Wenn ich also habe:

Test<int> x(new int(123));
Test<void>* y = &x;

, dann soll mir die zweite Zeile keinen Fehler ausspucken.

Dann wirst du Test<int> von Test<void> ableiten müssen.

Adressoperator überladen :p

Zeig mal, was du dir da vorstellst. Mir fällt nichts sinnvolles ein...

Mein Fehler war, dass ich - was ja allgemein ziemlich oft vorkommt - eine Frage gestellt habe, die an meinem eigentlichen Problem vorbeigeht:

In Java spricht man von einer sog. uneingeschränkten parametrischen Polymorphie, wenn man den Typ einer generischen Klasse (Klassen-Template) nicht genauer spezifiziert. Das kann z.B. vorkommen, wenn man eine Funktion definiert, die jede Art von Listen als Parameter annehmen soll, also Integer-Listen, Float-Listen usw.

In C++ geht das ja ebenso wunderbar mit dem Schlüsselwort "template". Nun wurde mir in einigen Büchern eingeimpft, dass ein Funktions-Template für jeden Typ neu generiert wird und damit bei wachsendem Code immer mehr Speicher beansprucht. Und eben das möchte ich vermeiden.

Um zurück zum Beispiel zu kommen. Was ich eigentlich vorhatte, ist folgendes:

void irgendeineFunktion(Test<void>* x)
{
  ...
}

Würde nun die automatische Typen-Konversion von "Test<irgendwas>" in "Test<void>" funktionieren, dann hätte ich eine Funktion, die jeden Typ von "Test" annehmen könnte.

Um eine solche "unschöne" Konversion zu vermeiden, ist natürlich "template" die Lösung:

template <typename T>
void irgendeineFunktion(Test<T>* x)
{
  ...
}

Hier würde jedoch theoretisch (es kann sein, dass ich mich irre) der Compiler bei jedem Zeigertyp von Test eine neue Funktion generieren.

Meine eigentliche Frage lautet also: Ist es in diesem Fall möglich, nur eine Funktion generieren zu lassen (wenn ja, wie?), oder ist der Compiler schon schlau genug, das selbst zu erkennen?

Gruß Josef

Abgesehen davon: Warum machst du dir überhaupt Gedanken darüber, wie oft eine Funktion generiert wird? In der heutigen Zeit haben wir so viel Speicher zur Verfügung, da spielt das keine Rolle. Wenn der Compiler das optimieren kann, wird er das von selbst tun.

Dazu, wieso ich mir darüber Gedanken mache: Allgemein ist es sicherlich nicht schädlich, etwas genauer unter die Lupe zu nehmen und zu hinterfragen. Im Gegenteil, Strukturwissenschaften wie Mathematik wachsen ja gerade durch den Zweifelnden heran (ich verweise dabei auf die Mathematikgeschichte der 30er).

Nun gibt es aber den Zweifelnden, der keine Fachkenntnisse hat und bezweifelt was schon längst bewiesen ist, und den, der seines Faches mächtig ist und das für selbstverständlich hält, das der ungebildete dennoch hinterfragt.

Weil sich eben gezeigt hat, dass ich Generics und Templates noch nicht in Hülle und Fülle begreife, ordne ich mich mal diesbezüglich dem ersteren zu.
Nichtsdestotrotz kann und will ich nicht befürworten, dass man (meinen Ausdruck bitte nicht offensiv auffassen) schlampig programmieren soll, nur weil das Schlampigsein sich für den Endnutzer kaum mehr bemerkbar mache. Natürlich wurde das hier von keinem behauptet noch angedeutet, aber schließlich führt das genau auf eben diesen Trott hinaus, den so viele Programmierer pflegen. Speicherverbrauch hin oder her, dass Festplatten und Arbeitsspeicher alles schlucken können, heißt noch lange nicht, dass wir fraglos literweise Maschinencode verabreichen sollen, wenn auch genauso ein Tropfen mit dem wesentlichsten reichen würde.

Ob nun jemand seinen Programmcode und die Ausgabe optimiert oder nicht, bleibt seine Entscheidung. Aber wenn eine Programmiersprache nicht die nötigen Schnittstellen bietet (jetzt mal abgesehen von inline ASM), die Wünsche des Programmierers zu realisieren, dann ist das beider Fehler: Fehler des Sprachkonzepts, das nicht alle Möglichkeiten eröffnet, und Fehler des Programmierers, der diese Sprache für seine Zwecke gewählt hat. Mir ist es nur leid, ständig diesen Fehler zu begehen.

Ehrlich gesagt, habe ich gerade und auch später nicht die Zeit dazu, das Thema weiter auszuführen oder gar in einer Diskussion vollständig aufzurollen. Ich wollte mich lediglich hinsichtlich meiner Gedanken erklären, die hier auf Verwunderung stoßen.

Gruß Josef

Außer der Compiler macht da noch irgendwas tolles, und Compiler machen oft viel tollere Sachen als man denkt.

Wenn es schlanker und schneller geht, dann soll es eben schlanker und schneller sein

Dann nimm doch optimierten inline-assembler

@Sone:

Mal abgesehen davon sind Templates schneller als Generics...

Laut dem was ich im Netz lese, sind Templates eine Form der Unterstützung von Generics.

Kellerautomat schrieb:

Generics und Templates sind nunmal zwei komplett verschiedene Dinge. [...]

Darf ich dich bitten, zuerst den Thread zu lesen, bevor du schreibst?

Kellerautomat schrieb:

Generics und Templates sind nunmal zwei komplett verschiedene Dinge. [...]

Vielen Dank, ich habe den Thread gelesen.
Falls du Recht haben solltest, kannst du den Wikipedia-Eintrag editieren.

Bei Programmiersprachen gibt es prinzipiell zwei Ansätze, generische Typen zu unterstützen. Der eine ist es, dass GenerischerTyp<T> für alle Ts denselben Code verwendet und über dynamische Bindung von Methoden spezifische Eigenschaften von T nutzt. Ein anderer Weg, den u.A. C++ geht, ist die Anwendung von Templates. Dabei wird der Typparameter zur Compilierzeit direkt mit dem konkreten Typ ersetzt.

Bei Programmiersprachen gibt es prinzipiell zwei Ansätze, generische Typen zu unterstützen. Der eine ist es, dass GenerischerTyp<T> für alle Ts denselben Code verwendet und über dynamische Bindung von Methoden spezifische Eigenschaften von T nutzt. Ein anderer Weg, den u.A. C++ geht, ist die Anwendung von Templates. Dabei wird der Typparameter zur Compilierzeit direkt mit dem konkreten Typ ersetzt.

Halt, da hab' ich wohl falsch verstanden. Ich dachte, Generics sind generische Typen. Dabei sind, wie du schon angedeutet hast, Generics und Templates die Umsetzung von generischen Typen. wurde so im Artikel falsch impliziert.

Danke.