C++ Community

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

_matze

knivil schrieb:

Ich habe reinterpret_cast genau einmal benoetigt.

Es gibt aber auch Projekte, bei denen das ständig nötig ist. Bei uns ist es so. Wir müssen Pointer (auf verschiedene Handles) an LabView übergeben. LV kann aber keine Pointer. Also müssen wir nach long reinterpretieren. Und das an tausend Stellen. Auch wenn wir C-Casts benutzen (auch, weil viele Projekte einfach C sind), der Effekt ist derselbe.

pumuckl

_matze schrieb:

Also müssen wir nach long reinterpretieren. Und das an tausend Stellen.

Dann ist euer Interface zwischen Labview und C++-Code aber extrem breit. Davon mal abgesehen würde ich sowas dann in eine eigene Funktion mit sprechendem Namen packen, aus dem klar wird dass es sich um eine Konvertierung an den Grenzen zweier verschiedener Sprachen handelt. Diese Konvertierung fände dann in einer festgelegten Schicht statt und würde sich auf keinen Fall in den verschiedenen Schichten im C++-Teil wiederfinden. Damit hätte es dann genau einen reinterpret_cast (oder zwei für hin und zurück) innerhalb dieser Funktion und nicht tausende.

_matze

Die 'tausend Stellen' waren natürlich eine stilistische Übertreibung...

_matze schrieb:

Die 'tausend Stellen' waren natürlich eine stilistische Übertreibung...

Trotzdem kein Grund, nicht aufs Design zu achten!

hustbaer

SeppJ schrieb:

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.

Gängig sind Rot-Schwarz Bäume
(OK, AVL Bäumchen werden sicher auch mancherorts verwendet)

Re