Salut,
 
Je me suis rendu compte d'un truc qui me semble extrêmement dangereux (et surtout à cause duquel il m'a fallu des plombes pour débuguer mon programme ). Le programme suivant :

donne (tenez-vous bien) : "Je vaux 5" !!!
 
Et le pire, quand dans une classe sont déclarés deux tableaux à la suite (c'était mon problème, comment j'ai galéré pour trouver ça...) :

Implique que :

affiche : "bidule[0] vaut 30" !!!
 
Je pense que ça méritait d'être signalé... Est-ce un bug ? Est-il corrigé ?
 
EDIT : Ça me pose d'ailleurs un petit problème, j'aimerais justement mettre un try-catch sur un truc comme ça : j'ai une classe avec une fonction qui prend en arguments un tableau et le nombre de cases de ce tableau, et je voudrais capturer l'exception en cas d'overflow, si le nombre de case est plus grand que la taille réelle du tableau. Mais là ça peut pas marcher...   Est-ce que ça peut venir de mes options de compilation ?
 
PS : g++ -v => gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

Salut,
 
C'est un comportement... disons, normal dans l'anormal. Les tableaux se suivent, donc le débordement fait que tu écris dans le 2nd.
Ca peut très mal se passer: imagine qu'avec des tableaux dynamiques, tu peux corrompre autre chose que ta propre appli. Dans le cas de variables locales, tu ne fais que toucher à tes variables, ton prog buggera mais sans plus (enfin, à toi de gérer quoi ).

Ce sont des problèmes "biens connus" en C.

Et ça n'inquiète personne ???    
 
Pourtant il me semble bien avoir connu (intimement même... ) des segmentation faults et des "array index out of range", mais depuis que j'ai découvert ça j'arrive plus à en avoir...  

utilise std::vector.
v.at(i) lèvera une exception si i n'est pas un index valide.

Oui, je pense que c'est ce que je vais faire, mais je voudrais que l'utilisateur puisse passer en argument un simple tableau. Il y a moyen de convertir un tableau en vector sans connaître la taille du tableau, ou je demande (encore !) l'impossible ?

Tu demandes l'impossible.

     
Je m'en doutais un peu... Bon, tant pis pour l'utilisateur (ou pour la sécurité, selon les fruits de ma réflexion à venir...).
 
Merci !

Si c'est pour le pilotage d'un avion, y'a peut-être pas trop de choix ?

c nymp
vous vous plaignez du C parce qu'il ne teste pas si les index ne depassent pas du tableau, et un tas dautre trucs quil pourrait tester au runtime
 mais c justement la toute la force du C : la vitesse
 
ceux que ca ninteresse pas passez votre chemin et ruez vous sur python, .Net , Java et autres usines a gaz

k lol.
 

olololol.

il suffit de ne pas utiliser de tableau

    C'est sûr que chercher une aiguille dans une botte de foin (en l'occurence un tableau mal initialisé perdu au milieu de milliers de lignes de code et qui contamine un tableau bien initialisé, lui...), ça aide à gagner en vitesse...    

Non, pas le choix...
 

Non, pas le choix... Enfin si : le vecteur. Ce qui sera d'ailleurs l'occasion pour nous deux (moi + l'utilisateur en question) de faire un premier pas vers la STL !  

je comprends que tu ne comprends rien. Y a pas à avoir de premier pas vers STL. Quand t'apprends le C, tu fais du printf direct. Ben quand t'apprends le C++, tu fais du vector, string, etc direct.

Alors faudra que tu m'explique pourquoi la STL est toujours reléguée aux derniers chapitres des cours et Faq C++, avec des avertissements style "il faut impérativement avoir compris en profondeur les fonctionnalités les plus avancées du C++ pour appréhender correctement la bibliothèque standard"...

Parce que pour bien la comprendre, c'est vital de comprendre les concepts utilisés? Sinon, tu les comprends pas.
Mais le dernier chapitre ne signifie pas le moins important...
 
PS: et j'ai jamais eu de tels warning dans mes bouquins

Certes, je n'ai pas dit ça, mais tu commence rarement par le dernier chapitre...
 

Celui-ci vient de là.
 

_Accelerated C++_  présente std::string avant de savoir ce qu'est une classe.  

parce que ce sont de mauvais enseignements.

sinon pour le comportement que décrit SkippyleGr andGourou ça m'est déja arrivé, un autre exemple si tu alloues dynamiquement un tableau, tu l'utilises et tout, puis tu fais un free(tab), puis apres tu fais par ex tab[5] tu retrouves la valeur!! en fait il me semble que ça dépend des options de compilation, et gcc est assez "cool" si on lui rentre rien dedans. Je pense que si tu fais le free, la mémoire est effectivment libérée, mais les valeurs restent en mémoire (pas de remise à zeros) et le pointeur est juste un curseur que tu balades dans cette mémoire, si tu fais pas tab=NULL; apres le free ben tu peux encore te balader aux adresses de ta mémoire via tab.

Il faut avoir gardé un pointeur sur la zone, parce qu'il me semble que free() remet la valeur du pointeur à 0.

non, enfin pas de base sous gcc (mingw en tout cas), après ça dépend p'tetre du compilo

 
la remarque n'est pas là, sa remarque est que le coût de vérification à chaque accès d'un tableau peut dramatiquement réduire les performances, d'autant plus que la cause est souvent liée à un algorithme ou une implémentation d'algorithme erronée, ou un dépassement dans un quelquonque calcul qui influence l'indexation.
 
moi ce qui m'aflliges c'est qu'un mec qui demande un truc débile à son compilo, se plaint que le compilo fasse son truc débile, d'une part, et qu'apparemment, on lui a jamais expliqué comment fonctionnait le C ou le C++.
 

J'avais compris, merci...   Ce que je voulais dire, c'est que si tu perds plus de temps à cause de ça pendant la phase de programmation que tu n'en gagneras pendant toute l'exécution, ça sert à rien...
 

Et moi ce qui m'afflige ce sont tous ces gens imbus d'eux-mêmes qui semblent penser qu'il faut au minimum un niveau doctorat en programmation pour avoir le droit de prétendre programmer et de poser des questions, et qui se permettent de faire des commentaires désobligeants sur des personnes qu'ils ne connaissent pas. D'autant plus que dans le cas présent, le truc débile est une faute de frappe, ce qui peut arriver à tout le monde, même à un bjone, un Taz ou un Bjarne Stroustrup, qui peut avoir des conséquences dangereuses (si ça se trouve c'est à cause d'un débordement de tableau de ce genre que la navette Challenger s'est scratchée, qui sait...) et qui à mon humble avis ne devrait pas passer la compilation. Mais bon, ce que j'en dis...  

commence par compiler en -Wall, on verra après

C'est déjà le cas.
 

 
T'inquiètes ça m'est arrivé. C'est l'avantage & l'inconvéniant du C & C++: tu peux faire ce que tu veux comme avec un couteau: tu peux tailler des figurines ou tu peux te le mettre dans la main. (ou automatiser la découpe de la figurine adaptée au dimensions du matériau que tu vas tailler )
 
Ce qui est important c'est d'apprendre des pratiques correctes.
Par exemple ton débordement est à tous le coups dû au fait que tu as utilisé quelque chose de limité.
genre "5 bidules ça suffit, etc..." et plus loin tu fais ta boucle en y mettant 5 dans ta boucle, truc généralement merdique à maintenir.
généralement le code qui a plein de bornes en dur et trop de choses statiques sont des nis à débordements.

mais je veux dire:
 
int tableau[2];
tableau[30]=5;
 
aucun prof ne t'a jamais expliqué que c'était une erreur possible & légale de base ?

moi j'ai juste eu vite fait quelques cours de prog en ecole d'ingé, et jamais on m'a parlé de possibilité de débordement de mémoire

Tutafé. Justement parce que la plupart de mes tableaux sont des tableaux de pointeurs sur des objets plus complexes, et que comme ça dès qu'il y a débordement ça me fait une segfault, je trouve rapidement d'où ça vient et je fais en sorte que ça puisse plus arriver. Donc la leçon à retenir serait de systématiquement surévaluer la taille des tableaux de valeurs ? (ce qui ne résoud pas le problème en cas d'accès à une case vide, mais évite la contamination, ce qui divise déjà notablement les riques, effectivement)
 

Bof, comme neg'gwada, les cours de programmation que j'ai eu à la fac étaient surtout des cours d'introduction, le genre de truc où tu dois faire un programme qui affiche trois pauvres étoiles au bout de la 3e séance de TP (à part un cours de programmation logique en première année de deug)... Donc je les ai systématiquement séchés.  

 
Non la leçon à retenir c'est de tout penser en dynamique (stl/vector par exemple), et de bien structurer pour ne pas indicer dans le vide.

 
Non, la leçon à retenir est d'être capable de maîtriser la taille de ses tableaux, en sachant à tout moment combien d'éléments ils sont supposés contenir.

Oui, faut vraiment que je m'y mettes, bien que dans ce cas particulier ça me gêne un peu, le principal utilisateur auquel le programme est destiné étant un ancien fortraniste et pawiste qui truffe ses programmes "c++" de printf...    
 

Aussi, mais c'est pas toujours évident...    

en principe ça devrait être naturel
 
alors après ça dépends de plein de choses.
 

perso, jamais eu besoin de stl(vector) jusqu'à présent, sauf une fois mais bon après il ya peu etre une habitude à prendre

attitude stupide et malappris

 tin v'la que comme par hazard pour la premiere fois, je me retrouve avec un débordement de mémoire dans mon code en Fortran, 3 jours pour trouver le bleme

En temps réel dur embarqué, il arrive que l'on impose de ne faire que de l'allocation statique une bonne fois pour toutes au démarrage.

Clair que là, c'est un peu la base...

Le F77 ne connait que l'alloc de tableaux statiques. De plus, les indices commencent à 1, d'où ton erreur classique, et enfin, tu vas galérer avec les tableaux à N dimensioins (N>1), vu que les indices sont inversés / C.
Enfin, d'une façon générale, et sauf cas très exceptionnel, les fortranistes ne savent pas programmer.