C++: ostringstream problem im debug mode ?

Scharnagl · 15. September 2009, 23:01

Kann es sein, dass im Debug-Modus ostringstream keine int Ausgaben mehr vornimmt?

Folgendes Beispiel verhält sich unter Xcode 3.2 entsprechend unterschiedlich in Release oder Debug:

C-Quellcode

#include <iostream>
#include <sstream>
using namespace std;
int main (int argc, char * const argv[]) {
ostringstream os;
os << 2 << ' ';
cout << os.str() << " Hello, World!\n";
return 0;
}

Alles anzeigen

Noch ist es für mich ein Rätsel ...

gritsch · 15. September 2009, 23:07

warum postest du nicht die 2 outputs?

Scharnagl · 15. September 2009, 23:14

release:

Quellcode

2 Hello, World!

debug:

Quellcode

Hello, World!

zermelo · 16. September 2009, 00:36

Kann ich mit "gcc version 4.0.1 (Apple Inc. build 5490)" nicht bestätigen.
Kannst Du es vielleicht mal direkt im Terminal kompilieren?

Scharnagl · 16. September 2009, 01:21

Es liegt hier wohl eine aktuellere Version vor:

#define __VERSION__ "4.2.1 (Apple Inc. build 5646)"

zermelo · 16. September 2009, 01:33

Da muss irgendwas komisch sein. Probier es mal auf der Kommandozeile.
Ich habe jetzt nochmal
gcc version 4.2.1 (Apple Inc. build 5566)
und
gcc version 4.4.0 20081219 (experimental) (GCC)
versucht. Funktioniert immer wie erwartet. Kann man in Xcode nicht irgendwo nachschauen, mit welchen flags g++ aufgerufen wird?

Vielleicht nimmt dein Setup auch die "2" als 64bit und ostringstream mag das nicht (will ich aber auch bezweifeln). Kannst ja trotzdem mal statt "2" explizit "short(2)" versuchen.

Scharnagl · 16. September 2009, 01:46

a) mit der Kommandozeile hab ich es nicht so, vertraue da der Entwicklungsumgebung.

b) ob 32-Bit oder 64-Bit Kompilat spielt keine Rolle: das Verhalten ist gleich.

c) (short) casten brachte leider auch nichts anderes.

Offenbar wird der String-Stream komplett gesperrt, nachdem gescheitert ist, einen Integer auszugeben - etwa das nachfolgende Space ' ' wird ignoriert, wie alles, ganz gleich was danach noch auszugeben versucht würde.

zermelo · 16. September 2009, 11:40

Das ist alles total unlogisch. Mir fällt wirklich nichts mehr ein, was das erklären könnte.

Schau doch mal in Xcode, da gibt es denke ich irgendwo ein Build-Output fenster, wo die Befehle stehen, mit denen er es kompiliert hat. Kannst Du die mal posten?

Scharnagl · 16. September 2009, 12:07

Nun, zurzeit bin ich leider von meinem Mac getrennt, es wird also dauern.

Das Problem entdeckte ich, als ich gleiche Sourcen per Borland Turbo C++, diversen MS Visual Studio Versionen und Xcode (vom Snow-Leopard) kompilierte. Nur unter Xcode im Debug Modus tauchte dieser Wirrwarr auf. Nach viel zu viel Zeit konnte ich das Problem dann eingrenzen und auf obiges Mini-Beispiel reduzieren. Witzig ist, dass es mit der deprecated Klasse ostrstream noch klappte, wenn auch mit dem Hinweis auf eingebundene alte Include-Files. Ich gehe also momentan von einem Fehler in den neueren Bibliotheken aus. Es wäre gut, sicherzustellen, dass es nicht an mir selber liegt, insofern wäre ein Reproduktionsversuch auf anderen Xcode (Snowleopard Stand) Umgebungen hilfreich.

Amin Negm-Awad · 16. September 2009, 13:34

Das kann man einfach sehen, indem man unten Rchts im Projektfenster auf das Succeeded klickt und dann im neuen Fenster sich die Aufrufe anzeigen lässt

Scharnagl · 21. September 2009, 20:42

a) Compile ...

Quellcode

CompileC build/Test.build/Debug/Test.build/Objects-normal/x86_64/main.o main.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2
cd /Users/rs/Documents/XProjects/TestA/Test
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.6 -gdwarf-2 -iquote /Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Test-generated-files.hmap -I/Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Test-own-target-headers.hmap -I/Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Test-all-target-headers.hmap -iquote /Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Test-project-headers.hmap -F/Users/rs/Documents/XProjects/TestA/Test/build/Debug -I/Users/rs/Documents/XProjects/TestA/Test/build/Debug/include -I/Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/DerivedSources/x86_64 -I/Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/DerivedSources -c /Users/rs/Documents/XProjects/TestA/Test/main.cpp -o /Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Objects-normal/x86_64/main.o

b) Link ...

Quellcode

Ld build/Debug/Test normal x86_64
cd /Users/rs/Documents/XProjects/TestA/Test
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/g++-4.2 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -L/Users/rs/Documents/XProjects/TestA/Test/build/Debug -F/Users/rs/Documents/XProjects/TestA/Test/build/Debug -filelist /Users/rs/Documents/XProjects/TestA/Test/build/Test.build/Debug/Test.build/Objects-normal/x86_64/Test.LinkFileList -mmacosx-version-min=10.6 -o /Users/rs/Documents/XProjects/TestA/Test/build/Debug/Test

c) Build Succeeded; No issues

zermelo · 21. September 2009, 23:48

Letzte Idee, da Du das ganze ja scheinbar nur in Xcode machst:
Gibt vor und hinter der "2" mal was aus. Vielleicht verschluckt Xcode die, in der irrigen Auffassung, da irgendwas interpretieren zu müssen.

Scharnagl · 21. September 2009, 23:58

Test-Programm:

C-Quellcode

#include <iostream>
#include <sstream>
using namespace std;
int main (int argc, char * const argv[]) {
// insert code here...
ostringstream os;
os << '#' << (short)2 << ':';
cout << os.str() << " Hello, World!\n";
return 0;
}

Alles anzeigen

Release:

Quellcode

#2: Hello, World!

Debug:

Quellcode

# Hello, World!

Es stirbt (ostringstring Ausgabe) im Debug bei der ersten Zahl-Ausgabe.

zermelo · 22. September 2009, 00:03

Sehr mysteriös.
Probier mal deine Anwendung vom Terminal aus zu starten (Terminal.app starten, einfach deine Anwendung(Das Binary, vom Finder aus, aus dem Build? ordner in Deinem Projekt-Ordner) in das Fenster ziehen, Enter)

Scharnagl · 22. September 2009, 00:13

Die beiden Testprogramme verhalten sich dort identisch wie via Xcode aufgerufen.
Ich vermute wirklich, dass etwas mit der Standard Debug Link-Bibliothek nicht stimmt.

Scharnagl · 17. Oktober 2009, 09:58

Unter Xcode 3.2.1 ist leider das fehlerhafte Verhalten immer noch unverändert.

deconceptional · 17. Oktober 2009, 11:49

Ich hab mal einen Bugreport gemacht und folgende Antwort erhalten

Hi Dominik,

This is a courtesy email regarding Bug ID# 7254418.

Engineering has provided the following information:

You can work around this issue by turning of the C++ runtime standard library debug mode in Xcode. This is the option that sets _GLIBCXX_DEBUG for the compiler.

Hab allerdings noch nicht ausprobiert ob das auch tatsächlich funktioniert. Jedenfalls weiss Apple über das Problem bescheid.

Scharnagl · 17. Oktober 2009, 12:56

Hallo Dominik, erstmal danke,

nun habe ich versuchsweise in "Preprocessor Macros Not Used in Precompiled Headers" den Wert "_GLIBCXX_DEBUG" eingetragen - leider ohne den gewünschten Erfolg ...

Scharnagl · 17. Oktober 2009, 13:04

Aus dem Kontext der genannten Flag-Bezeichnung heraus kam mir folgende Idee: ich setzte die Compilerversion im Debug-Mode auf GCC 4.0 zurück. Und schon läuft es wieder. Irgendwie scheinen STL-Bezugnahmen im Debug-Mode unter der Compiler-Version GCC 4.2 zahlreiche, diverse Probleme zu verursachen.

Macht es nun prinzipielle Probleme, die Release unter GCC 4.2 zu erstellen, jedoch unter GCC 4.0 zu debuggen? Es scheint mir eine Vertrauensfrage in die Qualität des GCC 4.2 zu sein. Kann mir hierzu jemand Mut machen?

deconceptional · 17. Oktober 2009, 13:20

Gerade auch ausprobiert

Beide Einträge (in Preprocessor Macros) löschen hat dann allerdings geholfen...