C++ Community

knivil schrieb:

reinterpret_cast
Willkommen in der Hoelle.

Hauptsache du hast irgendwas geschrieben, ne?

reinterpret_cast ist absolut nichts schlimmes und wird oft einfach benötigt.

pumuckl

AlexXXx schrieb:

Und wenne s geht, wie schnell ist denn so ein reinterpret_cast ??

Recht schnell. Und vor allem recht schnell im produzieren von sinnfreien Daten.

Eine der üblichen Fragen: Was willst du mit all dem erreichen? Da gibts ziemlich sicher ne bessere Lösung.

knivil

Hauptsache du hast irgendwas geschrieben, ne?
reinterpret_cast ist absolut nichts schlimmes und wird oft einfach benötigt.

Dito. Ich habe reinterpret_cast genau einmal benoetigt. Und sollte auch nur verwendet werden, wenn man weiss, was man tut. Aber AlexXXx scheint nicht zu wissen, was er tut (und ist wahrscheinlich noch weit entfernt davon).

Also DataI und DataJ sind Elemente EIner Matrix. Die hat folgende Struktur (In Typen):

DataI->DataJ->DataJ->DataJ->NULL
|
DataI->DataJ->NULL
|
DataI->DataJ->DataJ->DataJ->DataJ->DataJ->DataJ->NULL
|
NULL;

Das Problem ist, daß ich daran eigentlich nichts mehr änder möchte, da schon ziemlich viel Quelltext dazu steht.
Das ist zwar kompliziert, aberr sher Speichereffizient und eigentlich auch zimelich schnell.

Jetzt würde cih gerne einen Zeiger haben, mit dem ich duch die Matrix laufen kann. Sont brauche ich immer zwei, einen für das erste Element in jeder zeile (Typ DataI und dann einen für (DataJ für die weiteren Zeilen.

Klassen benötige ich, da später noch new und delete für die DataI und DataJ überschrieben werden müssen.

Gruß

knivil schrieb:

Hauptsache du hast irgendwas geschrieben, ne?
reinterpret_cast ist absolut nichts schlimmes und wird oft einfach benötigt.

Dito. Ich habe reinterpret_cast genau einmal benoetigt.

Dann hast du offenbar noch nie low level Funktionen benutzen müssen.

knivil schrieb:

Hauptsache du hast irgendwas geschrieben, ne?
reinterpret_cast ist absolut nichts schlimmes und wird oft einfach benötigt.

Dito. Ich habe reinterpret_cast genau einmal benoetigt. Und sollte auch nur verwendet werden, wenn man weiss, was man tut. Aber AlexXXx scheint nicht zu wissen, was er tut (und ist wahrscheinlich noch weit entfernt davon).

Na also hör mal. So schlecht ist das jetzt auch wieder nicht =).
Bis jetzt wurde auf den reinterpret_cast nur geschimpft. Da bei wollt ich nur wissen wie und was
Gruß

pumuckl

AlexXXx schrieb:

Das ist zwar kompliziert, aberr sher Speichereffizient und eigentlich auch zimelich schnell.

Womit hast du das nachgeprüft und mit welcher Alternative hast du das verglichen?

Ich würd sowas mit gechachtelten Containern machen, z.B. std::list<std::list<DataType> >, oder std::vector, je nachdem welche Operationen du effektiv drauf ausführen willst. Für die eigene Speicherverwaltung schreibst du dann eine eigene Allocator-Klasse und gibst die als Templateparameter mit.

@Pumuckel
Am anfang habe ich einen Testlauf mit der STL gemacht.
Habe dazu aber nicht zwei listen genommen muß ich zugeben.
Ich habe dazu 2.5 mal mehr Arbeitsspeicher benötigt.
Weiß gerade aber nicht mehr genau Welche kontainer ich genommen habe.

Dann ist es so dass ich noch nichts mit allocatoren gemacht habe.
Hab zu spät mitbekommen dass es sowas gibt. Das war schade, sonst hätte ich es wahrscheinlich so gemacht wie du gesagt hast.

Aber leider kann ich es jetzt nicht mehr ändern. Ich benötige die Lösung für dieses Problem. DataI und DataJ kann ich nicht mehr ändern. Das benötigt zu viel Zeit.

Wie schauts denn generell mti dem reinterpret_cast aus.
-Wie arbeitet er ??
-Wo sind fallstricke ??
-Und warum mga man ihn nicht
Gruß

pumuckl

AlexXXx schrieb:

@Pumuckel
Am anfang habe ich einen Testlauf mit der STL gemacht.
Habe dazu aber nicht zwei listen genommen muß ich zugeben.
Ich habe dazu 2.5 mal mehr Arbeitsspeicher benötigt.

Bei welcher Größe von DataType und welcher Anzahl von Objekten des Typs? Das ist für so einen Vergleich schon relevant.

Dann ist es so dass ich noch nichts mit allocatoren gemacht habe.
Hab zu spät mitbekommen dass es sowas gibt.

Allocatoren sind nicht weiter schwer zu verstehen. Und da du ja eh schon über die Speicherverwaltung an sich Bescheid zu wissen scheinst, sollten sie auch kein großes Problem darstellen.

Aber leider kann ich es jetzt nicht mehr ändern. Ich benötige die Lösung für dieses Problem. DataI und DataJ kann ich nicht mehr ändern. Das benötigt zu viel Zeit.

So wie du es aufgebaut hast ist es nicht gut machbar. Das Design ist, so wie du es dort hast, bestenfalls unschön. Um da was halbwegs vernünftiges draus zu machen müsstest zu zumindest die Member DataType a, nextJ und den Index j in die Basisklasse hochziehen. Dann würd ich um über die J zu iterieren einen Pointer auf den Basistyp nehmen und für die Iteration über die I einen zusätzlichen Pointer auf DataI. Aber wie gesagt, die Mechnanismen gibts schon in der STL, und die sollte man auch nutzen, wenn nichts wirklich dagegen spricht. Dass es zu viel Zeit braucht ist meist kein gültiges Argument gegen ein Refactoring. Die Zeit (und die Nerven) die du vergeudest weil du dich für den Rest der Lebenszeit deines Programms mit einem verkorksten Design herumschlagen musst, überwiegt das nämlich normalerweise bei weitem.

knivil

Dann hast du offenbar noch nie low level Funktionen benutzen müssen.

Was sind low level Funktionen, also fuer dich? Ich habe ihn benoetigt, als ich mit pthread gearbeitet habe, da Parameter nur ueber void* weitergereicht werden. Aber wenn ich mich innerhalb von C++ befand, war dieser nie noetig. Und hier scheint es ein reines C++ Problem zu sein.

@AlexXXx, ich bin einfach zu faul: http://www.codeguru.com/forum/archive/index.php/t-393998.html

Ich habe dazu 2.5 mal mehr Arbeitsspeicher benötigt.

Um wieviel Gigabyte geht es denn? Wie gemessen? Wie in den STL-Container eingefuegt? Ist dir die Allokationsstrategie von std::vector bekannt? Ein guter Startpunkt ist http://www.sgi.com/tech/stl/Vector.html .

Nexus

knivil schrieb:

Was sind low level Funktionen, also fuer dich? Ich habe ihn benoetigt, als ich mit pthread gearbeitet habe, da Parameter nur ueber void* weitergereicht werden.

*flüster* für void* reicht static_cast .

reinterpret_cast braucht man in modernem C++ eigentlich nicht allzu oft. Meist in Zusammenhang mit Low-Level-APIs oder Dingen wie std::fstream::write() . Oft riskiert man damit aber unnötigerweise undefiniertes Verhalten (unnötig, weil es meistens bessere, sichere Alternativen gibt).

knivil

*flüster* für void* reicht static_cast.

Nein, mein g++ hat gemeckert (mit Option -pedantic).

Nexus

knivil schrieb:

Nein, mein g++ hat gemeckert (mit Optionen -Wall -pedantic).

Bei sowas?

void* void_ptr;
MyClass* ptr = static_cast<MyClass*>(void_ptr);

Würde mich wundern. Und in die umgekehrte Richtung gehts sowieso implizit.

knivil

void* Thread::entry(void* me)
{
  //Thread* pthis = dynamic_cast<Thread*>(me); // does not compile
  //Thread* pthis = static_cast<Thread*>(me);  // does not compile
  Thread* pthis = (Thread*)(me);
  ...
  pthis->run()   
  ...

Ist schon laenger her, gcc-Version war damals glaube 3.2 oder 3.4. Aber so genau kann ich mich auch nicht mehr an die Umstaende erinnern.

Okay habe mich dazu entschiedenes ohen static_cast zu machen.
Ist so doer so umständlich. Stimmt schon.
Grup und danke für antwort

Nexus

Das war nicht unsere Absicht, dir static_cast zu empfehlen (nicht mal sicher, obs geht). Das war nur Bestandteil der Diskussion von knivil und mir...

AlexXXx, du solltest dir grundsätzlich überlegen, ob du wirklich einen Cast brauchst. Wahrscheinlich geht das sauberer.

Habs schon ohne cast gemacht. Verwende zwei pointer. Einen für dataI und den anderen für dataJ.
Ihr habt schon recht.

Gruß

Ad aCTa

Also mal abgesehen von dem Code stört mich da noch einiges anderes.

Öffentliche Attribute quälen die Kapselung
Wieso verwendest du keine abstrakte Basisklasse? Ist dir virtual zu teuer?
Du willst scheinbar Random-Access. Wieso nimmst du dann nicht gleich verschachtelte, dynamische, verwaltete Arrays wie std::vector ?

-Die klassen waren mal Stukturen.
-Ja
-Ich mag selber machen lieber Ist kein argument ich weiß.