C++ Community

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

drakon

AlexXXx schrieb:

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

Wenn es zu Lernzwecken ist schon. Sogar ein guter.

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

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

unskilled

B-Bäume gibts imho nicht, aber ansonsten gibts so ca. alles^^
kann schon sein, dass irgendeine STL-Implementierung B-Bäume nutzt, aber mir ist keine bekannt ^^

bb

map ist mit nem B-baum implementiert hab ich mir sagen lassen.
Aber es ist von Standart nicht vorgeschrieben. Aber sinnvoll
Gruß

SeppJ

AlexXXx schrieb:

map ist mit nem B-baum implementiert hab ich mir sagen lassen.
Aber es ist von stan**** nicht vorgeschrieben. Aber sinnvoll
Gruß

Das war ich, der das behauptet hat . Ist aber falsch wie ich herausgefunden habe, gängig sind AVL Bäume. Naiv konstruierte B-Bäume haben zwar im typischen Anwendungsfall die vom Standard geforderten Komplexitätsklassen, in worst case Szenarien sind AVL Bäume jedoch besser.

unskilled

B-Bäume sind nur besser, wenn die Lese-Operation an sich eher langsam ist - also wenn die daten beispielsweise auf der HDD liegen oder so - wird in Datenbanken deshalb oft genutzt. Ansonsten machen sie imho keinen Sinn. Das ist allerdings kein Erfahrungswert sondern nur das, was ich gelesen hab...

bb