ich portiere gerade ein Projekt von Linux (Ubuntu 8.04, 64 bit) nach Windows (XP 32 bit, MSVC9 SP1).
Es kompiliert schon prima und ausführbar ist es auch.

Nun tauchen leider ein paar Ungereimtheiten auf. An einigen Stellen ist die visuelle Darstellung falsch und es stürzt noch zu oft ab.
Beim debuggen ist mir aufgefallen das scheinbar einige Sachen, welche mit einem STL Vector gemacht werden, unter Windows anders reagieren. So kommt es manchmal zu einem assert Programmabbruch. Unter Linux läuft es an der Stelle natürlich wunderbar weiter.

Nun frag ich mich woher die Unterschiede stammen. Gibt es irgendwo eine Übersicht wie sich die MS STL und die GNU STL unterscheiden?

Gibt es vielleicht einen sinnvollen Ersatz für den MS-STL Vector?
Ich habe bereits STLport probiert. Leider sind in meinem Projekt einige externe Bibliotheken eingebaut und mir fällt es gerade schwer diese gegen STLport zu kompilieren. Ist es vielleicht möglich beide STLs parallel zu nutzen (z.B. Boost mit der MS-STL kompiliert mein Programm mit STLport)?

Schonmal vielen Dank für die Antworten,
sjoe.

Simon

Edit: Zeig doch mal den einen oder anderen Assert...

Ich denke, wenn Du Asserts hast, hast Du Fehler in deinem Programm. Du musst den Code korrigieren, nicht die Library wechseln.

Ja, aber das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab.

In meinem assert prüfe ich ob ein Element an der Stelle steht, an der es stehen soll. Ist leider etwas aufwendiger der Code der dahinter steht.

assert(toChange.getIndex() == changeCp.getIndex());

Mein Code hat sich ja nicht geändert. Nur alles was dahinter steht. Da überlege ich natürlich an welcher Komponente es liegt.

Grüße, sjoe.

Wahrscheinlich greifst du an irgendeiner Stelle über den maximalen Feldindex hinaus zu. Im Debug-Mode fliegt dann halt der Assert. WEnn die Assertion kommt, klicke auf wiederholen und dann abbrechen. So springt der Debugger dann an die Stelle der Assertion. Das wird dann irgendwo im STL-Code sein. Über die Funktionsaufrufliste kannst du die darüber liegenden Funktionen anschauen und so suchen, an welcher Stelle dein eigener Code den falschen Zugriff macht.

Genau das habe ich gemacht. Ich versucht nochmal etwas sinnvollen Code zu Posten.

while (!m_v_PointChangesFromUIQueue.empty()) {
		changePoint changeCp = m_v_PointChangesFromUIQueue.back();
		changePoint toChange = m_v_intern_changeList[changeCp.getIndex()];
		assert(toChange.getIndex() == changeCp.getIndex());
// tue was...
		m_v_PointChangesFromUIQueue.pop_back();
	}

Die Listen m_v_PointChangesFromUIQueue und m_v_intern_changeList sind STL Vektoren. changePoint ist ein Vec3f mit einem zusätzlichen Indexfeld. Dieses Indexfeld gibt den Platz in der m_v_intern_changeList an. Wenn ich also auf das n-te Element der m_v_intern_changeList zugreife, so sollte der changePoint auch den Index n besitzen. Dies läuft auch unter Linux. Nun könnte ich mir vorstellen das der Linuxprogrammierer bei uns, die GNU STL bis in die letzten Feinheiten ausgenutzt hat und ein nicht Standardverhalten bei den Zugriffen ausnutzt. Aber vielleicht ist es auch anders rum und die MS STL hat ein nicht Standardverhalten bei den zugriffen und deshalb läuft mein Code ins assert.

Wenn mir jetzt natürlich alle beteuern das die GNU STL und die MS STL in allen belangen gleich reagieren, müsste ich an einem anderen Punkt weitersuchen. Nur wollte ich diesen Aspekt erstmal ausschließen. Es treten nämlich noch an diversen anderen Stellen Ungereimheiten auf.

Grüße, sjoe.

Es tauchen zwar auch eher selten mal Bugs in der STL auf, welche M$ nutzt, aber der std::vector funktioniert

Na das ist ja schön zu hören. Ich werde mir mal anschauen wie die Vectoren befüllt werden.

aber allg. finde ich dieses stück code nicht gerade logisch...

bb

PS: Die assertion scheint mir nicht gerade ein logik-fehler zu sein...

Ja, aber das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab.

Nur weil etwas kein assert auslöst und nicht abstürzt, heisst das nicht, dass es korrekt ist. Die asserts in von MS verwendeten Standard Library zeigen Dir einfach dass dein Code falsch ist.

@Pellaeon

Wahrscheinlich greifst du an irgendeiner Stelle über den maximalen Feldindex hinaus zu.

Ist aber nicht der einzige Grund. Kann auch sein, dass iteratoren von verschiedenen Container Instanzen genutzt werden, oder iteratoren die nicht mehr gültig sind.

Simon

Spricht dein assert an, oder einer vom std::vector?

Mein assert spricht an. Also der Index unterscheidet sich.

Mein assert spricht an. Also der Index unterscheidet sich.

Und nichtmal der Index im vector, sonder der Index den du irgendwann mal reingeschrieben hast. Als erstes würde ich da auf einen Fehler bei der Befüllung der vectoren oder beim Index-setzen schließen. Da gleich von einem Fehler in einer der meistbenutzten C++-Bibliotheken dies gibt auszugehen halte ich für extrem gewagt

Da gleich von einem Fehler in einer der meistbenutzten C++-Bibliotheken dies gibt auszugehen halte ich für extrem gewagt

Von einem Fehler ging ich ja nicht aus, ich dachte ehr an Implementierungsunterschiede. Sowas was im Standard nicht festgelegt ist.

Ich habe inzwischen ein Workaround entwickelt.

Mich würde trotzdem mal interessieren ob es Geschwindigkeitsunterschiede zwischen den STLs gibt. Ich habe mal gelesen das von der STL von VS 2003 abgeraten wurde. Ist das immer noch aktuell?

Grüße, sjoe.

sobald du aber z.b. über DLL grenzen hinweg auf den vector zugreifen (auch schon
lesend) willst, kommt es zu mysteriösen abstürzen (eigene erfahrung :().

und das liegt daran, dass die ms-stl wirklich kaputt war.

je nachdem wie dein projekt aussieht kann es wirklich daran liegen.
in den express-versionen (08) sollte das behoben sein.

Ja, aber das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab.

Das sollte dich aber eher zum Schluss führen, dass die Microsoft STL diesbezüglich besser ist, weil sie mehr Fehler anzeigt (man sollte nicht als erstes von einem Bug in der Standardbibliothek ausgehen). Ich denke, die GNU STL ist da vielleicht weniger strikt und lässt gewisse Dinge durchgehen. Dass da ein paar Sachen mehr "funktionieren", liegt sehrwahrscheinlich am undefinierten Verhalten.

Das sollte dich aber eher zum Schluss führen, dass die Microsoft STL diesbezüglich besser ist, weil sie mehr Fehler anzeigt (man sollte nicht als erstes von einem Bug in der Standardbibliothek ausgehen). Ich denke, die GNU STL ist da vielleicht weniger strikt und lässt gewisse Dinge durchgehen. Dass da ein paar Sachen mehr "funktionieren", liegt sehrwahrscheinlich am undefinierten Verhalten.

das wiederum halte ich fuer eine gewagte These

Ich hab mir im Allgemeinen angewoehnt Fehler immer zuerst in meinem Code zu suchen und zwar bei der Verwendung jeglichem nicht von mir geschribenen Code. in einem Grossteil der Faelle liege ich damit richtig.

Kann aber auch an mir liegen

Ich hab mir im Allgemeinen angewoehnt Fehler immer zuerst in meinem Code zu suchen und zwar bei der Verwendung jeglichem nicht von mir geschribenen Code. in einem Grossteil der Faelle liege ich damit richtig.

Bei Code von Arbeitskollegen oder eher neueren bzw. nicht ausführlich getesteten Frameworks, ja. Bei Problemen mit der STL würde ich den Fehler allerdings nicht als erstes in der Standardbibliothek selbst suchen. Gerade weil die Microsoft-Assertions sehr genau angeben, wo ein Fehler aufgetreten ist, und man so mit grosser Wahrscheinlichkeit den Fehler bei sich findet (wenn man sich ein wenig auskennt). Ich zumindest habe noch nie einen Bug in der Standardbibliothek entdeckt. Designfehler schon, aber das liegt nicht an der Implementierung.

Abgesehen davon erinnert "das lustige ist doch, das der Code unter Linux wunderbar läuft, aber unter Windows stürzt er ab" ein wenig an einen typischen Bash und die fehlende Bereitschaft, eigene Fehler zuzugeben.