Re

[AlexXXx]

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.

[AlexXXx]

@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.

[AlexXXx]

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.

[AlexXXx]

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.

[AlexXXx]

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 ?

[AlexXXx]

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

[drakon]

AlexXXx schrieb:

-Ich mag selber machen lieber Ist kein argument ich weiß.

Wenn es zu Lernzwecken ist schon. Sogar ein guter.

[AlexXXx]

@Drakon
Wenigstens ein aufbauendes Wort in diesem Thread für mich

Gruß

[drakon]

AlexXXx schrieb:

@Drakon
Wenigstens ein aufbauendes Wort in diesem Thread für mich

Gruß

Jezt kommt das grose ABER..
Dein Code sieht ehrlich gesagt nicht so aus, als ob du den lediglich zu Lernzwecken benutzt und den produktiv einsetzen willst. (nicht unbedingt irgendwie kommerziell).
Sei dir bei dem, was du machst einfach bewusst, dass du dir so enorm viele Probleme einhandeln kannst, welche du nicht hast, wenn du bei Möglichkeit vorgegebene Methoden, welche dir von der Standardbibliothek gegeben sind benutzt. Merken wirst du das, sobald du viel weiter in deinem Projekt bist und plötzlich irgendwas komisches passiert. Das kann dann von so etwas kleinem, wie hier her langen und möglicherweise durch undefinierstes Verhalten einen wirklich merkwürdigen Fehler geben.

[AlexXXx]

Gibts überhaupt noch Listen oder Bäume die man nicht mit der STL machen sollte ??
Und wenn ja, welche??
(Möchtein Zukunft sowas ja vermeiden. Und dann hätte ich gerne ein paar Anhaltspunkte)
Gruß

[Nexus]

AlexXXx schrieb:

Gibts überhaupt noch Listen oder Bäume die man nicht mit der STL machen sollte ??
Und wenn ja, welche??

Naja, vielleicht hast du spezielle Anforderungen, die dir die STL nicht erfüllt. Aber im Normalfall sollte man mit der STL recht lange auskommen (dort gibts std::set und std::map , im TR1 sind ausserdem die Hash-Implementierungen std::tr1::unordered_set und std::tr1::unordered_map vorhanden).