Je me pose une question. Peut-on écrire: char *p = new char[0]; ?
Je ne sais pas si c'est autorisé, et si oui si c'est bien supporté par tous les compilos.
Quelqu'un aurait des infos là dessus ? (question mot-clé, "[0]" n'e st pas terrible pour faire des recherches sur le net :-()
C'est autorisé 5.3.4/8 du standard.
Tu voulais dire 5.3.4/7 ? ^^
When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements.
Bien supporté, je ne sais pas.
Super je te remercie. Cela m'apprendra à : - chercher sur [0] au lieu de zero - me contenter à l'index pour le chapitre sur new[].
-- Luc Hermitte
Michael DOUBEZ
On 16 juil, 15:51, Michael DOUBEZ wrote:
Je me pose une question. Peut-on écrire: char *p = new char[0]; ? Je ne sais pas si c'est autorisé, et si oui si c'est bien supporté par tous les compilos. Quelqu'un aurait des infos là dessus ? (question mot-clé, "[0]" n'est pas terrible pour faire des recherches sur le net :-() C'est autorisé 5.3.4/8 du standard.
Tu voulais dire 5.3.4/7 ? ^^
Oui. 5.3.4/7. Pour copier/coller, j'ai utiliser le report N2135 dans lequel ce paragraphe est en 5.3.4/8, encore un coup du type auto.
Michael
On 16 juil, 15:51, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Je me pose une question. Peut-on écrire:
char *p = new char[0];
?
Je ne sais pas si c'est autorisé, et si oui si c'est bien supporté par
tous les compilos.
Quelqu'un aurait des infos là dessus ? (question mot-clé, "[0]" n'est
pas terrible pour faire des recherches sur le net :-()
C'est autorisé 5.3.4/8 du standard.
Tu voulais dire 5.3.4/7 ? ^^
Oui. 5.3.4/7.
Pour copier/coller, j'ai utiliser le report N2135 dans lequel ce
paragraphe est en 5.3.4/8, encore un coup du type auto.
Je me pose une question. Peut-on écrire: char *p = new char[0]; ? Je ne sais pas si c'est autorisé, et si oui si c'est bien supporté par tous les compilos. Quelqu'un aurait des infos là dessus ? (question mot-clé, "[0]" n'est pas terrible pour faire des recherches sur le net :-() C'est autorisé 5.3.4/8 du standard.
Tu voulais dire 5.3.4/7 ? ^^
Oui. 5.3.4/7. Pour copier/coller, j'ai utiliser le report N2135 dans lequel ce paragraphe est en 5.3.4/8, encore un coup du type auto.
Michael
Doms
Bonjour,
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ? PArceque la, ca me turlupine de derriere le chapeau. S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Doms.
Bonjour,
Je me pose une question. Peut-on écrire:
char *p = new char[0];
C'est pourquoi faire de comment donc ?
PArceque la, ca me turlupine de derriere le chapeau.
S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ? PArceque la, ca me turlupine de derriere le chapeau. S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Doms.
espie
In article , Doms wrote:
Bonjour,
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ? PArceque la, ca me turlupine de derriere le chapeau. S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
In article <f7gc9g.5c0.1@invalid.net>, Doms <Doms@fr.invalid> wrote:
Bonjour,
Je me pose une question. Peut-on écrire:
char *p = new char[0];
C'est pourquoi faire de comment donc ?
PArceque la, ca me turlupine de derriere le chapeau.
S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide
ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que
ton index est plus petit que la taille du tableau, ce que tu dois faire de
toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ? PArceque la, ca me turlupine de derriere le chapeau. S'il ont prevu ce cas la, c'est bien qu'il sert, non ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Olivier Miakinen
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
Je me pose une question. Peut-on écrire:
char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide
ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que
ton index est plus petit que la taille du tableau, ce que tu dois faire de
toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0),
et il me semble avoir lu que c'était devenu le comportement standard.
Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association
d'idées).
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
espie
In article , Olivier Miakinen <om+ wrote:
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux petits details...
Pour malloc(0): non, ca n'est pas LE comportement standard: la norme est parfaitement explicite:
If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.
Comme tu le vois, il y a deux comportements possibles. L'implementation doit documenter lequel des deux elle adopte. - soit malloc(0) echoue. - soit malloc(0) reussit, et doit renvoyer un pointeur different pour chaque appel (pointeur non dereferencable au demeurant, si possible).
Par contre, free(0) est parfaitement standard, et non dependant de l'implementation, sauf si celle-ci ne respecte pas la norme...
In article <469d2652@neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:
Je me pose une question. Peut-on écrire:
char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide
ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que
ton index est plus petit que la taille du tableau, ce que tu dois faire de
toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0),
et il me semble avoir lu que c'était devenu le comportement standard.
Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association
d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai
un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux
petits details...
Pour malloc(0):
non, ca n'est pas LE comportement standard: la norme est parfaitement
explicite:
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access an object.
Comme tu le vois, il y a deux comportements possibles. L'implementation
doit documenter lequel des deux elle adopte.
- soit malloc(0) echoue.
- soit malloc(0) reussit, et doit renvoyer un pointeur different pour
chaque appel (pointeur non dereferencable au demeurant, si possible).
Par contre, free(0) est parfaitement standard, et non dependant de
l'implementation, sauf si celle-ci ne respecte pas la norme...
Je me pose une question. Peut-on écrire: char *p = new char[0];
C'est pourquoi faire de comment donc ?
Ca evite de faire des cas particuliers. Que ton tableau soit vide ou pas, tu appelles new. Apres, pour acceder a un element, tu verifies que ton index est plus petit que la taille du tableau, ce que tu dois faire de toutes facons.
(c'est la meme regle qui fait que free(NULL) est valide en C).
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux petits details...
Pour malloc(0): non, ca n'est pas LE comportement standard: la norme est parfaitement explicite:
If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.
Comme tu le vois, il y a deux comportements possibles. L'implementation doit documenter lequel des deux elle adopte. - soit malloc(0) echoue. - soit malloc(0) reussit, et doit renvoyer un pointeur different pour chaque appel (pointeur non dereferencable au demeurant, si possible).
Par contre, free(0) est parfaitement standard, et non dependant de l'implementation, sauf si celle-ci ne respecte pas la norme...
Olivier Miakinen
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
:-D
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux petits details...
Pour malloc(0): non, ca n'est pas LE comportement standard: la norme est parfaitement explicite:
If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.
Ah, donc on ne peut être sûr de rien : ni du pointeur nul, ni du pointeur non nul. Sur AIX, c'est un pointeur nul avec un code d'erreur spécifique (à moins que ça n'ait changé très récemment).
Comme tu le vois, il y a deux comportements possibles. L'implementation doit documenter lequel des deux elle adopte. - soit malloc(0) echoue. - soit malloc(0) reussit, et doit renvoyer un pointeur different pour chaque appel (pointeur non dereferencable au demeurant, si possible).
Oui. Donc, si je veux pouvoir compter sur un pointeur non nul pour éviter de faire des cas particuliers (comme pour new T[0] en C++), je dois continuer à faire appel à ma fonction mon_malloc_a_moi(longueur) qui fait malloc(longueur) si longueur est non nulle et malloc(1) si longueur est nulle.
Par contre, free(0) est parfaitement standard, et non dependant de l'implementation, sauf si celle-ci ne respecte pas la norme...
Oui, et c'est bien pratique.
Ça me rappelle que certaines libc retournent une erreur pour malloc(0),
et il me semble avoir lu que c'était devenu le comportement standard.
Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association
d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
:-D
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai
un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux
petits details...
Pour malloc(0):
non, ca n'est pas LE comportement standard: la norme est parfaitement
explicite:
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access an object.
Ah, donc on ne peut être sûr de rien : ni du pointeur nul, ni du
pointeur non nul. Sur AIX, c'est un pointeur nul avec un code d'erreur
spécifique (à moins que ça n'ait changé très récemment).
Comme tu le vois, il y a deux comportements possibles. L'implementation
doit documenter lequel des deux elle adopte.
- soit malloc(0) echoue.
- soit malloc(0) reussit, et doit renvoyer un pointeur different pour
chaque appel (pointeur non dereferencable au demeurant, si possible).
Oui. Donc, si je veux pouvoir compter sur un pointeur non nul pour
éviter de faire des cas particuliers (comme pour new T[0] en C++), je
dois continuer à faire appel à ma fonction mon_malloc_a_moi(longueur)
qui fait malloc(longueur) si longueur est non nulle et malloc(1) si
longueur est nulle.
Par contre, free(0) est parfaitement standard, et non dependant de
l'implementation, sauf si celle-ci ne respecte pas la norme...
Ça me rappelle que certaines libc retournent une erreur pour malloc(0), et il me semble avoir lu que c'était devenu le comportement standard. Quelqu'un sait si c'est toujours le cas ?
(Oui, je sais, c'est du C et pas du C++, mais bon, c'est par association d'idées).
Mais si, c'est du C++, puisque la norme inclut celle du C ;-)
:-D
Bon, je vais quand meme faire une entorse au reglement, puisque j'ai un C99 sous les mains, et que C++98 n'inclut pas certains des nouveaux petits details...
Pour malloc(0): non, ca n'est pas LE comportement standard: la norme est parfaitement explicite:
If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.
Ah, donc on ne peut être sûr de rien : ni du pointeur nul, ni du pointeur non nul. Sur AIX, c'est un pointeur nul avec un code d'erreur spécifique (à moins que ça n'ait changé très récemment).
Comme tu le vois, il y a deux comportements possibles. L'implementation doit documenter lequel des deux elle adopte. - soit malloc(0) echoue. - soit malloc(0) reussit, et doit renvoyer un pointeur different pour chaque appel (pointeur non dereferencable au demeurant, si possible).
Oui. Donc, si je veux pouvoir compter sur un pointeur non nul pour éviter de faire des cas particuliers (comme pour new T[0] en C++), je dois continuer à faire appel à ma fonction mon_malloc_a_moi(longueur) qui fait malloc(longueur) si longueur est non nulle et malloc(1) si longueur est nulle.
Par contre, free(0) est parfaitement standard, et non dependant de l'implementation, sauf si celle-ci ne respecte pas la norme...
Oui, et c'est bien pratique.
Fabien LE LEZ
On Tue, 17 Jul 2007 21:40:06 +0000 (UTC), (Marc Espie):
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
- soit malloc(0) echoue.
- soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut
mieux écrire NULL, histoire de ne pas faire le rapprochement entre
malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
On Tue, 17 Jul 2007 21:40:06 +0000 (UTC), (Marc Espie):
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Olivier Miakinen
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
- soit malloc(0) echoue.
- soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut
mieux écrire NULL, histoire de ne pas faire le rapprochement entre
malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations
du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci
est normalisé en C++ ?
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
