XCode, cin and string => problèmes :s

[steiner]

Bonjour à tous,

Je développe habituellement sous Eclipse (sous linux le plus souvent) et pour une fois je me suis dis que j'allais essayer XCode. Seulement voilà je suis tombé sur un os :/

J'ai un code source très basique :

#include <iostream>

using namespace std;
int main (int argc, char * const argv[]) {
	
	string s;
	cout << "Type something (using string) : ";
	cin >> s;
	cout << s << "\n\n";
	
	char* c;
	cout << "Type something (using char*) : ";
	cin >> c;
	cout << c << "\n\n";
	
    return 0;
}

Sous linux avec Eclipse : rien à signaler (compilation OK, exécution OK)
Sous Mac OS X avec un makefile : rien à signaler (compilation OK, exécution OK)
Sous Mac OS X avec XCode : compilation OK, problème lors de l'exécution pour la partie du code utilisant un string, j'obtiens une erreur de ce genre :

helloworld(2945) malloc: *** error for object 0x40e4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

(mais le programme ne quitte pas)
(NB : la partie avec char* fonctionne parfaitement)

J'en déduis donc qu'il s'agit d'un problème de configuration/réglage de XCode mais je ne parviens pas à comprendre d'où vient le problème.

Pour la compilation "à la mano" (qui donne donc un programme fonctionnel sous OS X) j'utilise le make file basique suivant :

CPP=g++
CXXFLAGS=-Wall -ansi -pedantic
LDFLAGS=
EXEC=helloworld_makefile
SRC= $(wildcard *.cpp)
OBJ= $(SRC:.cpp=.o)
all: $(EXEC)
helloworld_makefile: $(OBJ)
	$(CPP) -o $@ $^ $(LDFLAGS)
%.o: %.cpp
	$(CPP) -o $@ -c $< $(CFLAGS)
.PHONY: clean mrproper
clean:
	rm -rf $(DIRSRC)*.o
mrproper: clean
	rm -rf $(EXEC)

J'utilise Mac OS X Snow Leopard sur un Macbook Core Duo (i.e. 32 bits) et XCode 3.2.1.

Afin qu'on puisse m'aider efficacement à résoudre ce problème je joins à ce message un lien vers un fichier zip contenant :
- makefile
- code source (main.cpp)
- version compilée avec make fille du programme (main.o et helloworld_makefile)
- projet XCode (helloworld.xcodeproj)
- version compilée avec XCode du programme (build/Debug/helloworld)
URL : http://lepommier.boinc-af.org/public/helloworld.zip

Merci d'avance pour votre aide.
En espérant que quelqu'un trouve la solution à cet étrange problème !

 

[ntx]

La différence que je vois est que dans ton makefile tu utilises g++ alors que Xcode utilse gcc. Essaie voir avec gcc dans ton makefile.

PS : si tu initialises la string avec une chaîne non vide, ça passe. Je pense qu'il y a comme un bug.

 

[steiner]

Ah tiens grâce à ta remarque (et à celle d'un autre utilisateur sur un autre forum), je viens de me rendre compte de quelque chose de bizzare.

si j'initialise le string avec une valeur non vide genre :
string s("test");
Dans ce cas, sous XCode, le string fonctionne à l'exécution mais plus le char*, ce qui est "normal" vu que comme qq me l'a fait remarquer, je n'ai pas alloué de l'espace.
En utilisant :

string s("test");
char c[10];

Les deux versions sont fonctionnelles sous XCode.
Pour le string je ne suis pas limité à 4 caractères, mais pour le char je suis limité à 10 caractères (logique).

Serais-ce donc un bug de XCode ? :/

---------- Nouveau message ajouté à 15h06 ---------- Le message précédent a été envoyé à 13h39 ----------

J'ai encore des nouvelles du front ^^
Afin d'exclure tout problème lié au code source, j'ai rendu le code encore plus "safe" :

string input;
cout << "type something : ";
getline(cin, input);
cout << "you entered : " << input << endl << endl;
return 0;

Quand je compile en mode Debug : j'ai toujours la même erreur
Quand je compile en mode Release : je n'ai plus d'erreur à l'exécution.

J'ai cherché dans la configuration du projet après les options différentes entre Deubg/Release, mais j'ai rien trouvé de très "probant" :s
Quelqu'un a une idée ? (ou alors c'est un bug du debugger ? :s)

 

[ntx]

Serais-ce donc un bug de XCode ?

Vérifie avec gcc dans ton makefile car je ne suis pas sûr que gcc et g++ tirent la même librairie stdc++.

 

[steiner]

La "réponse" m'a été donnée via la mailing list XCode apple.

La réponse n'est pas triviale, et j'ai pas tout compris, et c'est en anglais donc je vais pas la poster ici, si quelqu'un est intéressé qu'il me contacte.