Aber schon mal so vorweg: "malloc + Klassen" klingt schon mal nicht gut.

Mir gehts ja generell ums Aliasing - da mir eben noch nicht ganz klar ist, woher überhaupt Probleme kommen könnten.

Grüssli

edit: und das Problem wird noch dadurch verschärft, dass ich es nur mit dem g++ 4.3.1 reproduzieren kann, nicht aber mit einem 4.1 oder 4.2 (auch nicht mit -fstrict-aliasing)

Konkret:

class Base {};
class Derived : public Base {};

void foo()
{
    Derived d;
    Derived* pd = &d;
    void* pv = pd;

    Derived* pd2 = static_cast<Derived>(pv); // OK
    Base* pb = static_cast<Base>(pv); // FEHLER!!!
}

was sind denn die genauen Probleme die auftreten?

wobei ich sagen muss, ich kenne "-fno-strict-aliasing" garnicht. Was macht es denn genau? Hab das jetzt auf die schnelle in der gcc docu nicht gefunden. Waere interessant zu wissen was es genau tut

[edit]
Ach, doch noch gefunden.
Sieht doch dann ziemlich deutlich aus, oder?

Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same.

das erklaert IMHO ziemlich deutlich warum du mit -fno-strict-aliasing die gewuenschten resultate hast - wenn du so mit rohem speicher umgehst.

was sind denn die genauen Probleme die auftreten?

Naja, wie so Pointer-Problemchen halt aussehen - es passiert nicht das, was passieren soll. Elemente in den Datencontainer einfügen hat keinen Effekt, die interne Integrität wird zerschossen (Pointer ins Nirvana) etc.

Shade Of Mine schrieb:

wobei ich sagen muss, ich kenne "-fno-strict-aliasing" garnicht. Was macht es denn genau? Hab das jetzt auf die schnelle in der gcc docu nicht gefunden. Waere interessant zu wissen was es genau tut

Das schaltet halt das strenge Aliasing aus.
Laut Standard dürfen zwei Pointer inkompatiblen Typs nicht auf den selben Speicher verweisen.
Beim Optimieren mit striktem Aliasing geht der Compiler bei Pointern unterschiedlichen Typs davon aus, dass sie auf unterschiedlichen Speicher zeigen und hat damit mehr Möglichkeiten, den Code um zu sortieren, weil der Zugriff auf einen Pointer keine Seiteneffekte auf andere haben sollte.

Edit: meine Frage hat ursprünglich auch primär auf das Problem mit den abgeleiteten Klassen gezielt. Die malloc Geschichte ist einmalig beim Initialisieren im Code und wenn das nicht funktionieren würde, sollte (naja...) mir eigentlich alles um die Ohren fliegen.

Ich hab keine Aussage gefunden, nach der das Aliasing auch bei Klassen einer Hierarchie problematisch ist, aber imho wäre es ja reichlich irrsinnig, wenn dem so wäre.

Mein Container hat eine size() Funktion, die die Entfernung zwischen begin() und end() Iterator berechnet.
Nach dem Einfügen eines Elements und nachfolgender Ausgabe von size() ist die immernoch 0, obwohl das Element scheinbar eingetragen wurde.
Nach dem Einfügen eines zweiten Elements und nachfolgender Ausgabe von size() ist sie plötzlich (korrekterweise) 2.
Und nun wirds ganz lustig: Rufe ich nach dem ersten einfügen size() zweimal hintereinander auf, bekomm ich erst 0 und dann 1
Füge ich in die size() z.B. direkt eine Ausgabe ein, funktioniert auch alles so wies soll.
Und wie gesagt, nur wenn der g++ mit striktem Aliasing optimiert. Da wird irgendwie der Code inkorrekt umgebaut.

Die einzigen Casts, die ich in dem Prozess finden kann, sind beim Einfügen eines Elements, eben die vorher erwähnten Upcasts mit static_cast von Basis -zu abgeleiteter Klasse. Das ist nötig, weil die Basisklasse nur die Verlinkung der Elemente zur Verfügung stellt, die abgeleitete Klasse enthält noch das eigentliche Datenelement (die Konstruktion ist nötig, um ein End-Element zu realisieren, das selbst keine Instanz der Daten enthält).

Ich versuche daraus ein Beispiel zu konstruieren, aber das ist nicht so einfach (vorallem so, dass der Fehler auch auftritt).

(last-first)/sizeof(T)
(ggf. noch nen cast von fist bzw last nach size_t - weiß nicht, ob der nötig ist...)

lauten, oder!?

bb

size_type size() const{
	return std::distance(this->begin(), this->end());
}

Und auch eine selbstgeschriebene Schleife ändert da nichts.

Edit: Übrigens habe ich gerade festgestellt, dass ich die Begriffe Up u-Downcast verdreht habe. Mit Upcast meinte ich Basisklasse->Abgeleitete Klasse.

nö, die lautet:

size_type size() const{
	return std::distance(this->begin(), this->end());
}

Und auch eine selbstgeschriebene Schleife ändert da nichts.

na gut - das is natürlich hübscher ^^ erzeugt aber vrmtl den gleichen code
hmm... na dann musst du wohl wirklich mal nen bissl mehr quelltext zeigen ^^

bb

iterator insert(iterator loc, const value_type& val){
  element_base_type *inserted = (this->m_free_end_element.get_next());
  static_cast<element_type*>(inserted)->set_value(val);

  this->move(loc.get_element(), inserted);

  return iterator(inserted);
}

void move(element_base_type *loc, element_base_type *element){
  element->get_prev()->set_next(element->get_next());
  element->get_next()->set_prev(element->get_prev());

  element->set_prev(loc->get_prev());
  element->set_next(loc);

  loc->get_prev()->set_next(element);
  loc->set_prev(element);
}

Der Punkt ist natürlich, dass das Problem nicht einfach hier auftritt. Der Code wird an X Stellen benutzt und funktioniert meisstens wunderbar. Nur hier und da macht der Compiler was beim Optimieren kaputt, da spielen auch noch alle möglichen Randbedingungen mit rein.

bb