DevCpp capricieux ? bug étrange... Résolu

Question

Bonjour, J'ai un comportement étrange (et pour le moins énervant) de dev cpp, je me dis que ce bug est peut-être connu et résolu. J'ai la 4.9.9.2 (dernière en vie) Je vais faire simple : Voici mon code, et voici les symptomes : 1 - Je déclare la structure test *ptest; et je metptest->valeur=10;, qui pointe dans la structure. Ca compile mais plante à l'exécution.(ca n'arrive pas au system(pause)). 2 - Si ensuite j'enlève ptest->valeur=10; et que je ne conserve que test *ptest; même réaction, plante. 3 - Si ensuite encore, après avoir enlevé les deux, je compile, ca marche jusqu'au system(pause). 4 - Je me remet dans la même config que 2, ca marche. Si je repasse ensuite à la 1, ca replante... #include #include struct _test { int valeur; }; typedef struct _test test; int main(int argc, char *argv[]) { test *ptest; ptest->valeur=10; printf("Valeur : %d ",ptest->valeur); system("PAUSE"); return 0; } En aucun cas la compil ne plante. Le code me parait parfaitement juste. Autre symptomes étranges : Je suis actuellement sur une appli GTK temps réel (450 lignes), je fonctionne beaucoup avec des pointeurs sur des structures. Je déclare ces pointeurs en local à main ou en global selon que j'ai besoin de récupérer les adresses dans des threads ou pas. Bref ca fonctionne parfaitement bien, jusqu'a ce que j'ai créé (rajouté !) une nouvelle structure (identique aux autres !) en global pour passer des paramètres, et que j'y affecte une valeur dans main. Ce coup ci, une autre blague : compil OK, mais ne lance rien. Il me créee un fichier projet1.3 au lieu d'un projet1.3.exe, et si je renomme le projet1.3 en projet1.3.exe, ca marche (les valeurs dans les structures sont bien appliquées, ca plante pas ni rien). J'ai bien essayé entre chaque compile de virer tous les fichiers sauf le *.dev et le *.c (vaut mieux !) Bref,

deck_bsd · Accepted Answer

Yop,

test *ptest;
ptest->valeur=10;
ici ptest ne pointe sur rien. Tu doit allouer la mémoire nécessaire à ta structure et faire pointé ptest sur celle-ci. Exemple :
if((ptest (test*)malloc(sizeof(test))) NULL)return 1;

++
deck_bsd
___________________________________
[http://deck-bsd.eurower.net]

The_Guardian · Answer

Le DevC++ étant devenu quasi obsoléte, sans mise a jour, tu devrais penser à changer de compilateur, et de prendre code::block qui est vraiment extra, c'est mon avis perso.

Une autruche ne se cuit pas aux petits lardons

cs_aardman · Answer

Salut,

ptest est un pointeur qui ne pointe sur rien, normal que ca plante.

BruNews · Answer

aardman > je ferai un de ces jours le compte par semaine sur les questions de pointeurs fantomes.

nollyflip > Le compilateur c'est important mais l'étude du C dans un bon bouquin est indispensable. Si on peut y aller par tatonnement en interprété, c'est hors de question en C.

ciao...
BruNews, MVP VC++

deck_bsd · Answer

Biensur ne pas oublié le free à la fin.

++
deck_bsd
___________________________________
[http://deck-bsd.eurower.net]

The_Guardian · Answer

Ah oui, tiens, j'avais même pas regarder le code, tant j'étais fixée sur le compil ( lol )

Une autruche ne se cuit pas aux petits lardons

julien_boss · Answer

Je code sous dev-cpp et tous les bugs qui me sont apparus étaient tjs causés par une erreur de code, jamais à cause du compilo :)

The_Guardian · Answer

Oui, sans doute que j'ai trop de aprioris sur le devC++ :p

Une autruche ne se cuit pas aux petits lardons

cs_vicenzo · Answer

Ne pas oublier que DevC++ est un IDE qui utilise par défaut GCC (minGW).

Donc parler du compilo de DevC++, c'est parler de GCC et  prendre en défaut GCC n'est pas évident, surtout en compilation C et si on veut profiter du C99 car Visual Studio ne supporte pas et ne supportera surement jamais le C99 !

Sinon BruNews a raison, DevC++ est obsolète et a connu son heure de gloire par sa gratuité... Masi depuis de Tonton Bill a sortie VS en version Express gratuite, sous Windows, autant utiliser VS Express... Surtout que les compilateurs VC7 (VS2003) et VC8 (VS2005) sont maintenant beaucoup plus respectueux des normes (pour le C++ du moins) et sont ceux qui , sous Windows, fourniront le meilleur code machine (sauf peut être encore pour les templates qui ont tout de même été entierement revisités...).

Donc un peu d'humilité !! Avant que dire que ca marche par et que c'est la faute aux autres ou aux outils, vaut mieux examiner son code car dans 100% des cas c'est la faute au code... surtout si on manipule des pointeurs en C sans savoir ce quoi il s'agit... 

Car déclarer un pointeur sur une structure sans initialisation et à la ligne suivante accèder à des membres de la structure référencée par le pointeur, c'est d'une part suicidaire mais cela dénote que l'on rien compris aux pointeurs et que c'est pas gagné et qu'il ya du taf !

BruNews, en temps qu'admin, ca te déprime pas ??

Bon week end
...

nollyflip · Answer

Qui peut se vanter d'avoir compris rapidement les pointeurs ? 
En tout cas j'y crois pas que j'ai oublié mon g_malloc je devais être fatigué hier soir, car j'avais bien fait l'allocation mémoire pour toutes mes autres structures (dans mon prog gtk) avant de pointer dessus.
Ca marche bien en rajoutant     ptest=malloc(sizeof(test));  et à la fin free(ptest);

Je suis d'accord à dire qu'il faut regarder son code en premier, je suis même le premier à le dire ! Seulement je comprenais vraiment pas..Codez tête reposée

mogwai93 · Answer

petit HS 

The Guardian : Le DevC++ étant devenu quasi obsoléte, sans mise a jour, tu devrais
penser à changer de compilateur, et de prendre code::block qui est
vraiment extra, c'est mon avis perso.

Depuis quand code:block n'a pas été mis à jour ???  ...... (octobre 2005 si je me base au site.....)
il ne faut pas confondre IDE et compilateur !!

devc++ est suffisant pour un debutant qui souhaite commencer
sans avoir une usine à gaz avec des options dans tous les coins

après s'il souhaite modifier + d'options, il pourra changer d'IDE et/ou de compilo

d'ailleurs regarde ce que fait gagah1 avec Devc++, 
et pourtant personne ne lui fait de reproche sur son IDE

donc le + important est la façon de coder !

fin du HS

The_Guardian · Answer

LooL oui ok c'est vrai que l'important c'est de savoir coder. 
Mais j'aime bien code::block voilà.
Je voulais le dire :p

Une autruche ne se cuit pas aux petits lardons

alextm · Answer

avant de croire savoir utiliser les pointeurs utilise tes objets normalement.


test mTest;

mText.valeur = 10;


et puis un typedef sur structure se declare bien mieux sous cette forme plus lisible :


typedef struct

{

    int valeur;

} test;

alextm · Answer

et malloc c'est deprecated c'est du C. Depuis le c++ on a un bel operateur qui s'appelle new

BruNews · Answer

malloc() n'a rien de deprecated, c'est du C qui n'a rien de deprecated non plus.

Le code de nollyflip est d'ailleurs du C, new() n'a donc rien à y faire.

ciao...
BruNews, MVP VC++

alextm · Answer

new n'est pas une fonction mais un opérateur donc pas de ( ).


malloc c'est de la programmation "papy" ! lol . rien contre malloc mais
compile avec VS2005 taura un deprecated et puis new est bien plus
simple dans son utilisation : il determine seul la taille a allouer
pour l'objet et ajoute quelques notions de securité ! 


De plus un malloc() ne suffit plus sous vista 64 bits ultimate
(seulement) par exemple tu auras une exception du système
d'exploitation car le système d'exploitation a besoin de 4 octets de
plus par objet pour y stocke l'uid de l'utilisateur qui demande
l'allocation de l'objet.

alextm · Answer

pardon je corrige mon précédent message, ce n'est pas a l'allocation
que ça crotte sous vista ultimate 64 bits mais à la libération de
mémoire , au free() donc ! car ce dernier ne libére pas les 4 octets
supplémentaires rajoutés par l'OS

cs_vicenzo · Answer

bon Alextm, on se retrouve donc...

 malloc c'est du C. donc quand on code en C, on n'a pas de de new mais malloc. Comme C++ est un surensemble de C, ca marche aussi même si on devrait faire un new qui est la voie naturelle du c++... voici ce que veut dire le compilo par deprecated !

Maintenant, il n'y a pas que le C++ sur terre. Le code de départ de ce fil était du C (inclusion de header de la lib standard C)... Donc faut pas embêter le monde avec tes 3 connaissances de programmation...

Je te le répête  : humilité ! et tourne 49 fois ta langue avant de parler !

BruNews · Answer

4 octets supplémentaires ???
Faudra que je pense à tester cela.

J'avais pourtant regardé l'asm généré (il y a qlq temps deja), new finissait par un appel malloc qui lui meme finit chez HeapAlloc().

ciao...
BruNews, MVP VC++

alextm · Answer

Oui relativement bizard et uniquement sous Vista Ultimate en 64 bits.
Je me suis rendu contre de cela car au sein de l'entreprise dans
laquelle je développe, notre logiciel ne fonctionne pas sous cette
version de Windows car tous les objets font 4 octets de plus donc à la
fermeture de l'application, lors de la destruction des objets ==>
plantage !

BruNews · Answer

Un pointeur sur x64 fait bien entendu 8 octets (taille de registre CPU), pas spécifique à la version ultimate.

De là à dire qu'on alloue 4 octets de plus qui ne seront pas libérés, aucun rapport.
Faudrait voir le code en cause pour trouver la raison du plantage.

ciao...
BruNews, MVP VC++

alextm · Answer

non je n'ai pas parler de pointeur mais d'uid qui fait 4 octets sur une version 32 bits et pareil sur une version 64

alextm · Answer

type short

alextm · Answer

pardon 2 octets sur 32 et 4 sur x64 :/ c'est l'heure du dodo ...

BruNews · Answer

Alors quel rapport avec malloc ou new.

ciao...
BruNews, MVP VC++

BruNews · Answer

Les compilos MS sont assez bien faits pour qu'on puisse faire du code portable de 32 vers 64 à la condition qu'on emploie les types Windows (UINT_PTR, etc...), les types standards ne variient pas en taille de 32 à 64 (int 32 à tout coup, etc...).
Il faut donc employer les codes Win si on sait devoir compiler ensuite en x64 sinon on réécrit.

ciao...
BruNews, MVP VC++

DevCpp capricieux ? bug étrange...

26 réponses

Votre réponse