Reprise du message précédent :

 
J'ai toujours pas compris ou était l'erreur

"Hello world" est une chaîne littérale, en conséquence constante, faite de "const char".
 
"char * chaineC =" est un pointeur de caractères sans plus.
donc, il permet de faire "chaineC[6]='W'" par exemple, et de modifier une constante.
 
C'est pas une erreur ça ?

boaf, non, j'en fais plein des char *roger = "toto"
 
d'ailleurs tu dois meme pouvoir le modifier
 
 
 
edit : nan ca plante lamentablement (la modif)

Normal, il ne mets pas les chaines statiques au meme endroit que les variables dans la mémoire

 
Je trouve pas... Apres tout le code que tu as donné marche tres bien. De plus qui irait s'amuser a modifier cette chaine? D'apres toi, alors, il ne faudrait jamais utiliser de chaines statiques?

 
C'est tout con, au bout de 500 lignes de code tu sais plus forcément sur quoi pointe ta variable et tu tante une modification d'une chaîne qui aurait du rester constante.

Je vois
Ce qu'il manque alors c'est tout simplement le "const"

Ace17 a écrit a écrit : Je vois Ce qu'il manque alors c'est tout simplement le "const"

 
Ouai

 
exact
en C++ des const il faut en mettre partout et c'est bien sympa : on obtient un code plus robuste pour pas cher.
 
d'ailleurs const a été étendu pour le C99 il me semble. la preuve que c'est bien
 

non static à plusieurs significations mais aucune ne correspond à const. se sont 2 choses différentes et complémentaires
 
d'ailleurs en C++ les #define du préprocesseur on essaye au maximum de les remplacer par des static const, ca pose moins de problèmes.

Forme générale de la loi de Murphy: Si quelque chose peut foirer, alors ça va foirer.
 
Si tu laisses un truc pas protégé dans ton programme, alors c'est celui-là que quelqu'un va modifier.
 
 
Pour les const, oui, il faudrait les mettre systématiquement et les enlever seulement quand on sait pourquoi.

hem...
 
fodrait éviter de penser que le const protège quoi que ce soit...
 
le const vous protège contre vous-même....
 
pas contre les autres....

 
effectivement sufit de faire un cast (je crois que c le static_cast mais je suis plus sûr) pour virer un const, mais bon quand on cherche la merde faut pas s'étonner après de se prendre un truc dans la gueule

pour le détail, c'et un const_cast

 
suis-je bête  

Ce sont des guides pour savoir quand on fait une bêtise.
Ça n'a pas vocation à empêcher le viol, juste le signaler...

 
restez poli

Au fait, en lisant les commentaires, il m'a semblé que la durée de vie de la chaine allouée n'etait pas claire pour certains.
Je met ici ce qu'il me semble etre juste (sans rentrer dans le detail de ou les structures de données correspondant aux variables vont etre allouées). S'il y a des erreurs, n'hesitez pas a les corriger.
 
char chaineC[] = "Hello World";
Le compilo va creer un tableau de 12 caracteres, le remplir avec les 11 caracteres puis un 0 final et stocker celà dans un segment de données specifique (a priori, .rodata [pour read-only data]).
A l'appel du bloc de programme declarant chaineC, variable "auto", il y a allocation sur la stack et copie du tableau stocké a la compil, et association du tableau copié avec la variable chaineC.
 
char *chaineC = "Hello World";
Le compilo va creer un tableau de 12 caracteres, le remplir avec les 11 caracteres puis un 0 final et stocker celà dans un segment de données specifique (a priori, .rodata [pour read-only data]).
A l'appel du bloc de programme declarant chaineC, variable "auto", il y a allocation d'un pointeur sur la stack, rangement de l'adresse du tableau dans le pointeur, et association du pointeur avec la variable chaineC.  
 
La durée de vie de la chaine et sa visibilité est celle de la variable, donc limitée au bloc ou la variable est declarée.
 
Une des erreurs possibles avec l'ecriture  
char *chaineC = "Hello World";
c'est de vouloir reutiliser chaineC plus tard, dans le bloc, sans se souvenir comment il a ete initialisé, et de faire un free(chaineC) avant de lui allouer une nouvelle zone memoire pour une autre chaine.
 
Note: (pour faire simple, je me limite au cas du tableau).
 
Si on avait declaré:
static char chaineC[] = "Hello World";
Le compilo va creer un tableau de 12 caracteres, le remplir avec les 11 caracteres puis un 0 final et stocker celà dans un segment de données specifique (a priori, .data [pour les variables static initialisées]).  
A l'appel du bloc de programme declarant chaineC, variable "static", il y a association du tableau avec la variable chaineC.
La durée de vie du tableau est le programme, mais son accessibilité est celui de la variable, donc le bloc ou la variable est declarée.
 
Si on avait declaré:  
const char chaineC[] = "Hello World";
il se produirait la meme chose que sans le qualificateur const, mais de plus le compilateur verifiera a la compilation que l'on essaye pas de modifier chaineC, et a l'execution, la zone memoire allouée pour le tableau aura un flag indiquant qu'elle est read-only.
 
A+,

• Tu vas chercher bien compliqué...

  Code : char  tabChar1[] = {'H','e','l','l','o',' ','W','o','r','l','d','\0'}; char  tabChar2[] = "Hello World"; char *ptrChar    = "Hello World";

  tabChar1 est un tableau de taille appropriée (12).

Si c'est dans une fonction, le tableau est alloué localement, donc sur la pile. Et désalloué à la "}" fermant le bloc de code.
Qu'il soit copié depuis un original global ou généré par le code exécutable, on n'en sait rien, et on n'a pas besoin de le savoir...
 
tabChar2 est exactement pareil à tabChar1.
C'est juste une forme d'écriture simplifiée...
 
ptrChar est uniquement un pointeur. Il est initialisé pour désigner...
..."Hello World", qui est ici un tableau global(i.e. statique) [B]constant[/B]. J'insiste là-dessus.
Il n'y a aucune allocation/désallocation de chaîne.
 
 

• free ne doit être fait que sur des adresses obtenues avec malloc/realloc, on est bien d'accord !

• Ta remarque sur le tableau statique local est pertinente, mais incomplète...

Une variable statique locale est initialisée à la première éxécution de sa déclaration/définition.
Cela implique qu'elle est accompagnée par un booléen caché.
Ce comportement étrange est destiné aux types C++ avec constructeurs: S'ils étaient éxécutés au niveau global, ils pourraient dépendre de valeurs pas encore prêtes.
Dans ce code, o n'est jamais construit:

• Ne sont allouées dans une zone mémoire read-only que les constantes connues dès la compilation.

Exit donc les types avec constructeurs, les variables statiques locales, les pointeurs/références. Mêmes constants, il sont construits à l'exécution !
 
 

• Là, on cherche vraiment la petite bête dans les recoins sombres du langage...

Bon, personne ne trouves les deux derniers bogues ?

depuis quand on fou un constructeur dans une struct

Depuis que je suis en C++ .
 
Si ça dérange, il suffit de faire

on met pas trop de constructeur dans les structs en general
sinon a part ke ca ma frapper v quand meme essayer de lire le reste
mais bon, j'aurais peut etre du suivre du debut

Ca, ca depends de ce que tu fais. Si tu ecris un compilo ou un un debugger...
 

Elle se limitait au cas du C.
 
A+,

Je me plaçais dans le cas d'un utilisateur du langage, sans plus.

C'est vrai qu'il vaut mieux réserver les "struct" aux types simples... pas de ctor/dtor, pas de méthode virtuelle, voire pas de méthodes du tout.
 
Bon, allez...
[B]Solution (14):[/B]

La séquence d'échappement '\m' n'existe pas et le comportement est indéfini.
Vous l'avez vraiment pas vu, ou c'est la flemme de le signaler ?
 
[B]Solution (15):[/B]

Donc, utiliser 128 comme valeur de char est incorrect.
Et afficher un char par "%u" (unsigned int) est incorrect, il faut utliser %i ou %d (signed int) qui peut recevoir de -127 à 255.
Dans les deux cas: comportement indéfini.

Bon, je vous sent pas trop en forme alors j'en mets un petit...
 
[B]Trouvez le bogue !(16)[/B]

Un bon compilateur peut émettre un warning.

 
Effectivement, normalement il signal une oppération non valide sur des pointeurs. En effet la soustraction de deux pointeurs n'as pas vraiment de sens dans l'absolue.

Mais qu'est-ce que tu racontes ?

C'est parfaitement défini et standard.

 
T deux pointeurs sont sur le même tableau, bien sûr que ça a un sens, mais si tu prend deux pointeurs quelconques je suis désolé mais ça n'a pas vraiment de sens en sois.
 
Maintenent je me suis peut être emballé et le compilo va peut être pas mettre de warning (encoreque je suis sûr de l'avoir vu qq part)

D'autre part à par le warning sur lea différence de pointeur il peut aussi gueuler à cause du cast implicite.
 

 
comme ça, ça passe mieu

Le compilateur ne vérifies pas que les pointeurs sont sur le même tableau, et de toutes façon cette fonction n'a aucun moyen de le savoir.
Son rôle est de donner le nombre d'octets séparant deux adresses, je ne me soucies pas du sens que ça a pour l'utilisateur !
 
char signifiant octet, ses pointeurs n'ont aucun problème d'alignement, on peut toujours en faire une différence...
 

Tu me scies !
Tu brûles, mais ta réponse est à coté de la plaque !

 
Heu le warning sur le cast implicite je l'ai déjà vu.

Et puis les adresses étant toutes positives tu va avoir des pb en renvoyant ton résultat sur un int, typiquement en 32 bit il faudrait que tu renvoie ton résultat sur 33bits: si tu fais 0 - l'adresse la plus grande tu va avoir un problème.

 
Heu je sais pas si j'ai été bien clair là  

Tu as juste oublié de préciser signed int.
 
[B]Solution (16):[/B]
On suppose ici qu'un entier peut recevoir la différence de deux pointeurs, donc que les pointeurs et les entiers sont de même taille.
 
Ce n'est pas garanti !
Par exemple, une machine peut avoir des registres 16 bits mais adresser 4Go de RAM, ce qui requiert des pointeurs 32 bits.
 
Bonne version:

 
Sur ma machine, ptrdiff_t est synonyme de int.
Donc effectivement, faire la différence d'adresses trop distantes risque de dépasser.
 
A mon avis:
-On ne doit effectivement faire de différence de pointeur que s'ils pointe le même tableau.
-Un tableau ne peut pas être plus grand que la moitié de l'espace adressable.
 
Bogue bonus:
Cette fonction ne déclare pas ses arguments const, elle ne peut être appelée avec valeurs const.
Alors qu'elle le pourrait très bien !

[B]Trouvez le bogue n° 17![/B]

 
Et t'as ça avec quoi comme compilo, par ce que moi j'ai essayé ça passe (ts warning activés)

 
Moi j'aurai imaginé qu'il mettrait des warnings ds les 2 cas, et que pour éviter ça, il faut :

 
parce que quand on écrit un chiffre avec virgule en dur comme ça, si on précise pas que c un float (avec le "f" ), il considère que c un double, non !?

 
ha mon avis ça doit dépendre des compilo.

El_gringo a partiellement répondu.
 
[B]Solution n°17:[/B]
Les constantes de la forme n.n ou nEn sont des doubles, c'est officiel.
 
0.5 = 5/10 = 1/2 qui est une division   exacte (en binaire), donc décimales binaires finissant par des 0.
0.6 = 6/10 = 3/5 qui est une division inexacte (en binaire), donc décimales binaires répétées sans fin.
Quand on tronque un double en flottant, perdre des 0 ne change pas la valeur. Perdre des 1 si.
 
Donc float b= 0.5 ne génère pas d'alerte, et c'est normal.
Pareil avec n.25, n.125 ect...
Cela dit, on pourrait en souhaiter une quand même.
 
Pour éviter tout problème, penser à typer correctement dès le départ:

Mon compilateur est Visual C++ 6, et pour une fois il agit correctement.
 
Bon, je fais une pause.
Mais c'est pas interdit de prendre le relais .

 
C effectivement suffisament rare pour être signalé

Juste une précision sur les "chaînes littérales" utilisées dans une expression:
(je viens de l'apprendre ici: http://david.tribble.com/text/cdiffs.htm)
 
En C(99), elles sont converties en char*.
En C++98, elles sont converties en const char*, puis en char*. Mais cette dernière conversion est dépréciée.
Dans les deux cas, elles ne sont pas modifiables.
 
Soignons bien notre code, si nous ne voulons pas faire partie des "break millions lines of code".
 
Je me demande comment une telle bévue a été possible, alors que le typage C++ est censé être très sur ?