void* vs Templates (Split aus "Prozentuale Verteilung der Datentypen")

[Shade Of Mine]

dot schrieb:

a void able schrieb:

void* schweigt, egal wie viel du über ihn herausfinden willst.

Und wenn ich genau das will? Wieso genau wäre ein char* z.B. im Kontext mit Type Erasure deiner Meinung nach besser als void*?

Hast du denn ein Beispiel wo man void* oder char* braucht?

Ich denke nämlich, dass es nicht notwendig ist.

[knivil]

Der Tobi schrieb:

void-Pointer kann man sehr wohl in C++ brauchen...

Zeig mir ein sinnvolles Beispiel für void* (OHNE eine Bibliotheksfunktion zu benutzen, die das fordert), wo man nicht genauso gut mit Templates arbeiten kann.

Aehm was ist denn das fuer ein Quatsch? Was wenn ich Bibliotheken in C++ schreibe, die in C verwendet werden? Fuer die ganze Interoperabilitaet, abstrakte Datentypen, ... ist void* noetig.

[Kellerautomat]

Die Begruendung, man koennte doch statt void* ueberall char* verwenden, ist hirnrissig. Letztendlich ist alles ein haufen Bytes, warum also ueberhaupt Typen...

[Bitte ein Bit]

Aber meines Wissens muss 1 byte nicht 8 bit gross sein ... oder? Aber dann gibts ja noch uint8_t / int8_t ...

Welchen Sinn macht ein Byte, welches nicht exakt 8 Bit groß ist ???

Hast du denn ein Beispiel wo man void* oder char* braucht?

Ich denke nämlich, dass es nicht notwendig ist.

Ich habe mal einen generischen Container für mehrere Typen geschrieben. Dabei hatte ich den Programmablauf mit Hilfe einer XML Datei gesteuert. Also etwas in der Form:

// Kein Anspruch auf Vollständigkeit!
class Node  // Klasse zur Speicherung von verschiedenen Datentypen
{
private: 
  void* Data;
  std::string Type;

public:
  void Set(const XMLElementA& V)
  {
     this->Data = new XMLElementA(V);
     this->Type = "XMLElementA";
  }

  void Set(const XMLElementB& V)
  {
     this->Data = new XMLElementB(V);
     this->Type = "XMLElementB";
  }

  void Set(const XMLElementC& V)
  {
     this->Data = new XMLElementC(V);
     this->Type = "XMLElementC";
  }

  // ...
};

// ...

std::list<Node> XMLFileContent;

Gibt es da eine andere, elegantere Möglichkeit ?

[a void able]

Kellerautomat schrieb:

Die Begruendung, man koennte doch statt void* ueberall char* verwenden, ist hirnrissig. Letztendlich ist alles ein haufen Bytes, warum also ueberhaupt Typen...

Das war nie mein Argument. Ich habe gesagt, dass man void* fast immer durch Templates ersetzen kann (und das dann besserer Code ist).
In den wenigen Fällen wo das nicht geht, will man meistens einen char* (Beispiel operator new/delete) oder, wenn es um Template-Bloat geht, einen std::aligned_storage<char*> .

@Bitte ein Bit: Etwas mehr Kontext wäre nicht schlecht. Bei dir sieht es aus, als wären entweder die verschiedenen Klassen unnötig (einfach zwei strings speichern) oder du brauchst eine gemeinsame Basisklasse.

[Shade Of Mine]

Bitte ein Bit schrieb:

Gibt es da eine andere, elegantere Möglichkeit ?

Wenn XMLElementA und XElementB etc. von einer gemeinsamen Basisklasse erben, dann hast du Polymorpgie als Ergebnis.

Aktuell musst du über Type gehen um das korrekte Element lesen zu können. Wenn du es aber über Polymorphie machst, hast du viele Vorteile - zB dass du eine get-Template Funktion schreiben kannst die Typsicher ist.

[a void able]

a void able schrieb:

std::aligned_storage<char*>

Ich fall jedesmal drauf rein. Ich meinte das, was oben als generic_pointer definiert habe.

[Tobias Gerg]

Bitte ein Bit schrieb:

Aber meines Wissens muss 1 byte nicht 8 bit gross sein ... oder? Aber dann gibts ja noch uint8_t / int8_t ...

Welchen Sinn macht ein Byte, welches nicht exakt 8 Bit groß ist ???

....

Auf Plattformen die keinen Bytezugriff beherrschen. (Es gibt durchaus DSPs die nur 32bit Zugriffe erlauben...)

Greets
Tobi

[Bitte ein Bit]

Auf Plattformen die keinen Bytezugriff beherrschen. (Es gibt durchaus DSPs die nur 32bit Zugriffe erlauben...)

Boing, und wieder was gelernt. In der Wiki heißt es sogar dass ein Byte auch weniger Bits haben kann.

Wenn XMLElementA und XElementB etc. von einer gemeinsamen Basisklasse erben, dann hast du Polymorpgie als Ergebnis.

Hmm, könnte auch so klappen. Man könnte dazu in der Basisklasse nur die Typinfo speichern und alle anderen XML Element davon ableiten. Dafür würde die Basisklasse vermutlich aber einen virtuellen Copy Konstruktor als auch virtuellen Zuweisungsoperator benötigen.

[Shade Of Mine]

Bitte ein Bit schrieb:

Dafür würde die Basisklasse vermutlich aber einen virtuellen Copy Konstruktor als auch virtuellen Zuweisungsoperator benötigen.

Nein.

Maximal eine clone() Methode, falls denn unbedingt notwendig.