je suis new et je voudraissavoir quelque chose:
Admettons que je crée un tableau de char de 250 elements et que je
n'initialise que les 10 premiers (avec un cin et une commande du string.h
(dont je ne me rapelle plus le nom)) et que le 11e char est le " ".
Ce tableau va prendre la place en memoire de 10 char + " " ou de 250 char
(meme si j'en ai initialisé que 11) ???
je suis new et je voudraissavoir quelque chose:
Admettons que je crée un tableau de char de 250 elements et que je
n'initialise que les 10 premiers (avec un cin et une commande du string.h
(dont je ne me rapelle plus le nom)) et que le 11e char est le " ".
Ce tableau va prendre la place en memoire de 10 char + " " ou de 250 char
(meme si j'en ai initialisé que 11) ???
je suis new et je voudraissavoir quelque chose:
Admettons que je crée un tableau de char de 250 elements et que je
n'initialise que les 10 premiers (avec un cin et une commande du string.h
(dont je ne me rapelle plus le nom)) et que le 11e char est le " ".
Ce tableau va prendre la place en memoire de 10 char + " " ou de 250 char
(meme si j'en ai initialisé que 11) ???
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur de
design, qui va probablement être à l'origine de nombreuses erreurs de codage.
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur de
design, qui va probablement être à l'origine de nombreuses erreurs de codage.
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur de
design, qui va probablement être à l'origine de nombreuses erreurs de codage.
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion,
et ce que vous proposez comme alternative?
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion,
et ce que vous proposez comme alternative?
Je dirais qu'en général (surtout dans du code de débutant), utiliser
des tableaux de caractères pour gérer des chaines de caractères est
une erreur de design, qui va probablement être à l'origine de
nombreuses erreurs de codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire
sur quoi se fonde votre opinion,
et ce que vous proposez comme alternative?
phneveu wrote:
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur
de design, qui va probablement être à l'origine de nombreuses erreurs de
codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire sur
quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Il faut éviter les fonctions strcpy(3), strcat(3), sprintf(3), scanf, gets(3)
et d'autres... strncpy, strncat, snprintf (?) résolvent le problème.
Mais le plus simple est encore d'utiliser les std::string qui gérent les
accès mémoires d'elle-même.
phneveu wrote:
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur
de design, qui va probablement être à l'origine de nombreuses erreurs de
codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire sur
quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Il faut éviter les fonctions strcpy(3), strcat(3), sprintf(3), scanf, gets(3)
et d'autres... strncpy, strncat, snprintf (?) résolvent le problème.
Mais le plus simple est encore d'utiliser les std::string qui gérent les
accès mémoires d'elle-même.
phneveu wrote:
Je dirais qu'en général (surtout dans du code de débutant), utiliser des
tableaux de caractères pour gérer des chaines de caractères est une erreur
de design, qui va probablement être à l'origine de nombreuses erreurs de
codage.
Votre affirmation m'interpelle, comme on dit... Pourriez-vous me dire sur
quoi se fonde votre opinion, et ce que vous proposez comme alternative?
Bien à vous.
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Il faut éviter les fonctions strcpy(3), strcat(3), sprintf(3), scanf, gets(3)
et d'autres... strncpy, strncat, snprintf (?) résolvent le problème.
Mais le plus simple est encore d'utiliser les std::string qui gérent les
accès mémoires d'elle-même.
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Tout à fait d'accord. Mais je n'imaginais pas que l'on pouvait écrire
dans un tableau de caractères (ou autre) sans se préoccuper des indices,
Ici c'est vraiment très con, mais l'erreur peut être plus subtile...
et il ne m'est pas venu à l'idée que la réticence de Loïc Joly se
limitait à cet aspect-là. Je croyais qu'il avait qqchose contre les
tableaux de char en eux-mêmes. D'où mon intérêt...
Non, il donne d'autres raisons dans un autre post
strcpy(3)? strcat(3)? Voulez-vous dire "strcpy(), strcat() avec 3
arguments"? Je croyais qu'elles n'en prenaient que 2...
c'est le numéro des man pages sur Unix, c'est de là que je tirais les
Mais le plus simple est encore d'utiliser les std::string qui gérent
les accès mémoires d'elle-même.
Oui, mais comment résister à la tentation de les "wrapper" pour éviter de
réecrire X fois la même chose? Et à partir de ce moment-là, comment ne
pas glisser dans l'implémentation d'une classe de service, bien que ce
soit fortement déconseillé par Loic Joly? Travaillant sous VisualC je ne
connais ni QString ni AnsiString, mais je connais CString, sa lourdeur
et sa gourmandise...
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Tout à fait d'accord. Mais je n'imaginais pas que l'on pouvait écrire
dans un tableau de caractères (ou autre) sans se préoccuper des indices,
Ici c'est vraiment très con, mais l'erreur peut être plus subtile...
et il ne m'est pas venu à l'idée que la réticence de Loïc Joly se
limitait à cet aspect-là. Je croyais qu'il avait qqchose contre les
tableaux de char en eux-mêmes. D'où mon intérêt...
Non, il donne d'autres raisons dans un autre post
strcpy(3)? strcat(3)? Voulez-vous dire "strcpy(), strcat() avec 3
arguments"? Je croyais qu'elles n'en prenaient que 2...
c'est le numéro des man pages sur Unix, c'est de là que je tirais les
Mais le plus simple est encore d'utiliser les std::string qui gérent
les accès mémoires d'elle-même.
Oui, mais comment résister à la tentation de les "wrapper" pour éviter de
réecrire X fois la même chose? Et à partir de ce moment-là, comment ne
pas glisser dans l'implémentation d'une classe de service, bien que ce
soit fortement déconseillé par Loic Joly? Travaillant sous VisualC je ne
connais ni QString ni AnsiString, mais je connais CString, sa lourdeur
et sa gourmandise...
Tout simplement parcequ'il n'y a pas de vérification sur l'indice d'un
tableau de caractères.
On peut très bien écrire
char my_string[64];
my_string[100] = 'a';
(...)
Tout à fait d'accord. Mais je n'imaginais pas que l'on pouvait écrire
dans un tableau de caractères (ou autre) sans se préoccuper des indices,
Ici c'est vraiment très con, mais l'erreur peut être plus subtile...
et il ne m'est pas venu à l'idée que la réticence de Loïc Joly se
limitait à cet aspect-là. Je croyais qu'il avait qqchose contre les
tableaux de char en eux-mêmes. D'où mon intérêt...
Non, il donne d'autres raisons dans un autre post
strcpy(3)? strcat(3)? Voulez-vous dire "strcpy(), strcat() avec 3
arguments"? Je croyais qu'elles n'en prenaient que 2...
c'est le numéro des man pages sur Unix, c'est de là que je tirais les
Mais le plus simple est encore d'utiliser les std::string qui gérent
les accès mémoires d'elle-même.
Oui, mais comment résister à la tentation de les "wrapper" pour éviter de
réecrire X fois la même chose? Et à partir de ce moment-là, comment ne
pas glisser dans l'implémentation d'une classe de service, bien que ce
soit fortement déconseillé par Loic Joly? Travaillant sous VisualC je ne
connais ni QString ni AnsiString, mais je connais CString, sa lourdeur
et sa gourmandise...
En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Loïc Joly wrote in message
news:<bqvd39$dcd$...
[...]En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
[...]
Et tu en as oublié la plus importante. L'initialisation d'un tableau du
genre char[] est statique -- c-à-d qu'elle aura lieu avant
l'initialisation dynamique.
Et qu'évidemment, une constante de chaîne est un tableau du type char
const[] ; bien des fois, ça ne vaut pas la peine de le convertir. (Donc,
par example, j'écrirais plutôt :
std::cout << "La valeur est : " << value << 'n' ;
et non :
std::cout << std::string( "La valeur est : " ) << value << 'n' ;
Mais j'imagine que toi aussi.)
[...]Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a largement
diminué quand j'ai passé du C en C++ (et donc de char*/char[] à
GB_String), le passage de GB_String à std::string en revanche l'a
légèrement augmenté (probablement parce que je n'avais pas une bonne
implémentation -- il existe aussi des implémentations où une erreur
d'indice provoque l'échec d'une assertion, comme dans GB_String.)
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bqvd39$dcd$1@news-reader3.wanadoo.fr>...
[...]
En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
[...]
Et tu en as oublié la plus importante. L'initialisation d'un tableau du
genre char[] est statique -- c-à-d qu'elle aura lieu avant
l'initialisation dynamique.
Et qu'évidemment, une constante de chaîne est un tableau du type char
const[] ; bien des fois, ça ne vaut pas la peine de le convertir. (Donc,
par example, j'écrirais plutôt :
std::cout << "La valeur est : " << value << 'n' ;
et non :
std::cout << std::string( "La valeur est : " ) << value << 'n' ;
Mais j'imagine que toi aussi.)
[...]
Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a largement
diminué quand j'ai passé du C en C++ (et donc de char*/char[] à
GB_String), le passage de GB_String à std::string en revanche l'a
légèrement augmenté (probablement parce que je n'avais pas une bonne
implémentation -- il existe aussi des implémentations où une erreur
d'indice provoque l'échec d'une assertion, comme dans GB_String.)
Loïc Joly wrote in message
news:<bqvd39$dcd$...
[...]En général, l'utilisation de tableaux de char pour gérér des chaînes de
caractères peut avoir plusieurs raisons :
[...]
Et tu en as oublié la plus importante. L'initialisation d'un tableau du
genre char[] est statique -- c-à-d qu'elle aura lieu avant
l'initialisation dynamique.
Et qu'évidemment, une constante de chaîne est un tableau du type char
const[] ; bien des fois, ça ne vaut pas la peine de le convertir. (Donc,
par example, j'écrirais plutôt :
std::cout << "La valeur est : " << value << 'n' ;
et non :
std::cout << std::string( "La valeur est : " ) << value << 'n' ;
Mais j'imagine que toi aussi.)
[...]Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a largement
diminué quand j'ai passé du C en C++ (et donc de char*/char[] à
GB_String), le passage de GB_String à std::string en revanche l'a
légèrement augmenté (probablement parce que je n'avais pas une bonne
implémentation -- il existe aussi des implémentations où une erreur
d'indice provoque l'échec d'une assertion, comme dans GB_String.)
[...]Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a
largement diminué quand j'ai passé du C en C++ (et donc de
char*/char[] à GB_String), le passage de GB_String à std::string en
revanche l'a légèrement augmenté (probablement parce que je n'avais
pas une bonne implémentation -- il existe aussi des implémentations
où une erreur d'indice provoque l'échec d'une assertion, comme dans
GB_String.)
Loïc Joly a raison de dire que des tableaux de char "à la main" sont
source d'erreurs probables, pour ne pas dire certaines.
Et qu'en tout cas ils "conduisent à écrire beaucoup de code". On
pourrait donc en déduire que les alternatives présentées,
"industrielles", sont un gage de sécurité. Mais on peut légitimement
se poser la question. Si elles sont certainement plus sûres que la
plupart des classes implémentant des strings que l'on trouve sur les
sites consacrés au développement, elles n'en présentent pas moins,
elles aussi, leurs péchés mignons. Pour preuve ce fix de Microsoft
concernant la fameuse std::string dont on fait grand cas ici :
"When you assign a shorter string to an existing string that
originally contained a longer string, the assignment corrupts the
heap. [...] This problem is due to a bug in the Standard C++ Library
basic_string class implementation. When assigning a shorter string
to > an existing string that originally contained a longer string,
the heap > is corrupted. The assignment can be done either through
operator=() or > assign()."
Ce bug affectait la version 5 de VisualC++ et a été corrigé dans la
version 6 (MS dixit).
Il n'en reste pas moins vrai qu'on ne peut pas accorder une confiance
aveugle aux implémentations "plaquées or", commme dirait Stroustrup.
Et que dire de la classe CString, qui vérifie bien la taille de ses
entrées (limitée à INT_MAX!), mais ne surveille pas la taille que peut
prendre la chaine en interne à la suite d'une ou pusieurs
concaténations. Faites-moi signe le jour où vous affecterez une chaîne
de 2147483647 caractères à une CString ou autre chose!
En revanche, il est très facile de déclarer une CString avant une
boucle qui va la concaténer 10 million de fois avec la même chaine de
25 caractères, et avant même d'avoir atteint le fatidique INT_MAX,
CString plante lamentablement... Alors, à qui faire confiance?
Pour résumer, tout cela est bien difficile et donne à penser. :')
[...]
Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a
largement diminué quand j'ai passé du C en C++ (et donc de
char*/char[] à GB_String), le passage de GB_String à std::string en
revanche l'a légèrement augmenté (probablement parce que je n'avais
pas une bonne implémentation -- il existe aussi des implémentations
où une erreur d'indice provoque l'échec d'une assertion, comme dans
GB_String.)
Loïc Joly a raison de dire que des tableaux de char "à la main" sont
source d'erreurs probables, pour ne pas dire certaines.
Et qu'en tout cas ils "conduisent à écrire beaucoup de code". On
pourrait donc en déduire que les alternatives présentées,
"industrielles", sont un gage de sécurité. Mais on peut légitimement
se poser la question. Si elles sont certainement plus sûres que la
plupart des classes implémentant des strings que l'on trouve sur les
sites consacrés au développement, elles n'en présentent pas moins,
elles aussi, leurs péchés mignons. Pour preuve ce fix de Microsoft
concernant la fameuse std::string dont on fait grand cas ici :
"When you assign a shorter string to an existing string that
originally contained a longer string, the assignment corrupts the
heap. [...] This problem is due to a bug in the Standard C++ Library
basic_string class implementation. When assigning a shorter string
to > an existing string that originally contained a longer string,
the heap > is corrupted. The assignment can be done either through
operator=() or > assign()."
Ce bug affectait la version 5 de VisualC++ et a été corrigé dans la
version 6 (MS dixit).
Il n'en reste pas moins vrai qu'on ne peut pas accorder une confiance
aveugle aux implémentations "plaquées or", commme dirait Stroustrup.
Et que dire de la classe CString, qui vérifie bien la taille de ses
entrées (limitée à INT_MAX!), mais ne surveille pas la taille que peut
prendre la chaine en interne à la suite d'une ou pusieurs
concaténations. Faites-moi signe le jour où vous affecterez une chaîne
de 2147483647 caractères à une CString ou autre chose!
En revanche, il est très facile de déclarer une CString avant une
boucle qui va la concaténer 10 million de fois avec la même chaine de
25 caractères, et avant même d'avoir atteint le fatidique INT_MAX,
CString plante lamentablement... Alors, à qui faire confiance?
Pour résumer, tout cela est bien difficile et donne à penser. :')
[...]Dans tout les cas, l'utilisation de tableaux de char à la main est
très sujette à erreur (personnellement, le temps de débugage de mes
programmes a été grandement diminué quand je suis passé à
std::string), et conduit à écrire beaucoup de code pour dire peu de
choses.
Tiens, chez moi, c'est l'inverse. Le temps de mise au point a
largement diminué quand j'ai passé du C en C++ (et donc de
char*/char[] à GB_String), le passage de GB_String à std::string en
revanche l'a légèrement augmenté (probablement parce que je n'avais
pas une bonne implémentation -- il existe aussi des implémentations
où une erreur d'indice provoque l'échec d'une assertion, comme dans
GB_String.)
Loïc Joly a raison de dire que des tableaux de char "à la main" sont
source d'erreurs probables, pour ne pas dire certaines.
Et qu'en tout cas ils "conduisent à écrire beaucoup de code". On
pourrait donc en déduire que les alternatives présentées,
"industrielles", sont un gage de sécurité. Mais on peut légitimement
se poser la question. Si elles sont certainement plus sûres que la
plupart des classes implémentant des strings que l'on trouve sur les
sites consacrés au développement, elles n'en présentent pas moins,
elles aussi, leurs péchés mignons. Pour preuve ce fix de Microsoft
concernant la fameuse std::string dont on fait grand cas ici :
"When you assign a shorter string to an existing string that
originally contained a longer string, the assignment corrupts the
heap. [...] This problem is due to a bug in the Standard C++ Library
basic_string class implementation. When assigning a shorter string
to > an existing string that originally contained a longer string,
the heap > is corrupted. The assignment can be done either through
operator=() or > assign()."
Ce bug affectait la version 5 de VisualC++ et a été corrigé dans la
version 6 (MS dixit).
Il n'en reste pas moins vrai qu'on ne peut pas accorder une confiance
aveugle aux implémentations "plaquées or", commme dirait Stroustrup.
Et que dire de la classe CString, qui vérifie bien la taille de ses
entrées (limitée à INT_MAX!), mais ne surveille pas la taille que peut
prendre la chaine en interne à la suite d'une ou pusieurs
concaténations. Faites-moi signe le jour où vous affecterez une chaîne
de 2147483647 caractères à une CString ou autre chose!
En revanche, il est très facile de déclarer une CString avant une
boucle qui va la concaténer 10 million de fois avec la même chaine de
25 caractères, et avant même d'avoir atteint le fatidique INT_MAX,
CString plante lamentablement... Alors, à qui faire confiance?
Pour résumer, tout cela est bien difficile et donne à penser. :')
