bonjour
je debute en c++ et j`ai un soucis avec les allocations dynamiques de
tableaux
je suis sous window avec vc++
voici un resume de mon code :
int main() {
"Michel Michaud" a écrit dans le message news: IEVlc.38550 $
[...]
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o Et voui, je vois bien que ça repart. A proposer dans l'Express dans quelques mois, quand ils auront épuisé "L'amour à la plage" ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Michel Michaud" <mm@gdzid.com> a écrit dans le message news: IEVlc.38550
$ZJ5.1037611@news20.bellglobal.com...
[...]
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer
que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o
Et voui, je vois bien que ça repart.
A proposer dans l'Express dans quelques mois,
quand ils auront épuisé "L'amour à la plage" ;-)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Michel Michaud" a écrit dans le message news: IEVlc.38550 $
[...]
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o Et voui, je vois bien que ça repart. A proposer dans l'Express dans quelques mois, quand ils auront épuisé "L'amour à la plage" ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Michel Michaud
Dans news:40995cc3$0$27674$, Alain
"Michel Michaud" a écrit dans le message news: IEVlc.38550 $
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o
Mais non. On le continue :-)
(Sérieusement, j'étais pour faire la même remarque que toi !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:40995cc3$0$27674$636a15ce@news.free.fr, Alain
"Michel Michaud" <mm@gdzid.com> a écrit dans le message news:
IEVlc.38550 $ZJ5.1037611@news20.bellglobal.com...
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer
que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o
Mais non. On le continue :-)
(Sérieusement, j'étais pour faire la même remarque que toi !)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" a écrit dans le message news: IEVlc.38550 $
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Z'allez recommencer ce débat ? ? :-o
Mais non. On le continue :-)
(Sérieusement, j'étais pour faire la même remarque que toi !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:,
Ça varie. À vue d'oeil (un « guestimate », comme on dit en anglais), je dirais qu'en C++, il y a à peu près 60% NULL, et 40% 0, tandis qu'en C, la différence est plus près des 95%/5%. Mais je ne sais pas réelement des pourcentages -- dans les boîtes où j'ai travaillé, on s'est toujours servi de NULL, que ce soit du C ou du C++.
Bon, pour équilibrer la discussion, si on veut se mettre à faire des statistiques officieuses et biaisées, je crois que j'ai connu personnellement plus de programmeurs C++ que toi. Et moi, tout ceux que je connais personnellement utilisent 0 :-)
(Si je te rencontre en personne un jour, je ne pourrai plus dire ça :-). Curieusement je connais personnellement d'autres programmeurs C++, mais je ne sais pas s'ils utilisent 0 ou NULL...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0405050043.6a88c1f2@posting.google.com,
Ça varie. À vue d'oeil (un « guestimate », comme on dit en
anglais), je dirais qu'en C++, il y a à peu près 60% NULL, et
40% 0, tandis qu'en C, la différence est plus près des 95%/5%.
Mais je ne sais pas réelement des pourcentages -- dans les
boîtes où j'ai travaillé, on s'est toujours servi de NULL, que
ce soit du C ou du C++.
Bon, pour équilibrer la discussion, si on veut se mettre à
faire des statistiques officieuses et biaisées, je crois que
j'ai connu personnellement plus de programmeurs C++ que toi.
Et moi, tout ceux que je connais personnellement utilisent 0 :-)
(Si je te rencontre en personne un jour, je ne pourrai plus
dire ça :-). Curieusement je connais personnellement d'autres
programmeurs C++, mais je ne sais pas s'ils utilisent 0 ou
NULL...)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Ça varie. À vue d'oeil (un « guestimate », comme on dit en anglais), je dirais qu'en C++, il y a à peu près 60% NULL, et 40% 0, tandis qu'en C, la différence est plus près des 95%/5%. Mais je ne sais pas réelement des pourcentages -- dans les boîtes où j'ai travaillé, on s'est toujours servi de NULL, que ce soit du C ou du C++.
Bon, pour équilibrer la discussion, si on veut se mettre à faire des statistiques officieuses et biaisées, je crois que j'ai connu personnellement plus de programmeurs C++ que toi. Et moi, tout ceux que je connais personnellement utilisent 0 :-)
(Si je te rencontre en personne un jour, je ne pourrai plus dire ça :-). Curieusement je connais personnellement d'autres programmeurs C++, mais je ne sais pas s'ils utilisent 0 ou NULL...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
Jean-Marc Bourguet wrote in message news:...
NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il est introduit un jour avec une signification assez stricte: son utilisation dans des contextes ou il faut un entier et non un pointeur est trop courante (en particulier je l'ai vu employe systematiquement la ou je mettrais ' ').
Et cependant, il y a des compilateurs (dont g++) qui définisent NULL avec un mot clé. Pour l'instant, il n'émet qu'un avertissement quand on s'en servent en contexte entier, mais c'est déjà un avertissement qui est présent par défaut (même sans -Wall). Et il y a bien une règle que le code doit compiler sans avertissements, non ? :-)
(Il me semble avoir entendu dire que le comité considère une modification en cette direction. Mais je ne suis pas sûr ; je ne suis plus de près la normalisation.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxboep3ia5b.fsf@news.bourguet.org>...
NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il
est introduit un jour avec une signification assez stricte: son
utilisation dans des contextes ou il faut un entier et non un pointeur
est trop courante (en particulier je l'ai vu employe systematiquement
la ou je mettrais ' ').
Et cependant, il y a des compilateurs (dont g++) qui définisent NULL
avec un mot clé. Pour l'instant, il n'émet qu'un avertissement quand on
s'en servent en contexte entier, mais c'est déjà un avertissement qui
est présent par défaut (même sans -Wall). Et il y a bien une règle que
le code doit compiler sans avertissements, non ? :-)
(Il me semble avoir entendu dire que le comité considère une
modification en cette direction. Mais je ne suis pas sûr ; je ne suis
plus de près la normalisation.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il est introduit un jour avec une signification assez stricte: son utilisation dans des contextes ou il faut un entier et non un pointeur est trop courante (en particulier je l'ai vu employe systematiquement la ou je mettrais ' ').
Et cependant, il y a des compilateurs (dont g++) qui définisent NULL avec un mot clé. Pour l'instant, il n'émet qu'un avertissement quand on s'en servent en contexte entier, mais c'est déjà un avertissement qui est présent par défaut (même sans -Wall). Et il y a bien une règle que le code doit compiler sans avertissements, non ? :-)
(Il me semble avoir entendu dire que le comité considère une modification en cette direction. Mais je ne suis pas sûr ; je ne suis plus de près la normalisation.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
drkm wrote in message news:...
writes:
"Michel Michaud" wrote in message news:<IEVlc.38550$...
[...]
Ne pas oublier le cas qui montre que cacher la v rit n'est pas toujours bonne.
void F(int n) { cout << "Ben voyons !"; }
void F(char *p) { cout << " videmment ?"; }
F(NULL);
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Cacher la vérité, ça ne serait pas plutôt donner le même nom à deux fonctions qui font des choses différentes ?
Comme dans
namespace std { template< class Type , class Trait = char traits< Elem > > class basic ostream : virtual public basic ios< Type , Trait > { basic ostream & operator<<( int value ) ; basic ostream & operator<<( void const * value ) ; } ; }
?-)
Elles font des choses différentes ? Je croyais que toutes les deux formattaient la valeur pour la sortir.
Ceci dit, je ne vois pas d'utilité à écrire quelque chose comme « std::cout << NULL ». Enfin, il ne m'est jamais arrivé d'écrire quelque chose de semblable dans mon code.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkllk6a9ua.fsf@fgeorges.org>...
kanze@gabi-soft.fr writes:
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<IEVlc.38550$ZJ5.1037611@news20.bellglobal.com>...
[...]
Ne pas oublier le cas qui montre que cacher la v rit n'est pas
toujours bonne.
void F(int n)
{
cout << "Ben voyons !";
}
void F(char *p)
{
cout << " videmment ?";
}
F(NULL);
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que
NULL n'y ait pas aussi mauvaise presse...
Cacher la vérité, ça ne serait pas plutôt donner le même nom à deux
fonctions qui font des choses différentes ?
Comme dans
namespace std
{
template< class Type , class Trait = char traits< Elem > >
class basic ostream
: virtual public basic ios< Type , Trait >
{
basic ostream & operator<<( int value ) ;
basic ostream & operator<<( void const * value ) ;
} ;
}
?-)
Elles font des choses différentes ? Je croyais que toutes les deux
formattaient la valeur pour la sortir.
Ceci dit, je ne vois pas d'utilité à écrire quelque chose comme
« std::cout << NULL ». Enfin, il ne m'est jamais arrivé d'écrire quelque
chose de semblable dans mon code.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Michel Michaud" wrote in message news:<IEVlc.38550$...
[...]
Ne pas oublier le cas qui montre que cacher la v rit n'est pas toujours bonne.
void F(int n) { cout << "Ben voyons !"; }
void F(char *p) { cout << " videmment ?"; }
F(NULL);
Ce cas n'est pas vraiment possible en C, ce qui peut expliquer que NULL n'y ait pas aussi mauvaise presse...
Cacher la vérité, ça ne serait pas plutôt donner le même nom à deux fonctions qui font des choses différentes ?
Comme dans
namespace std { template< class Type , class Trait = char traits< Elem > > class basic ostream : virtual public basic ios< Type , Trait > { basic ostream & operator<<( int value ) ; basic ostream & operator<<( void const * value ) ; } ; }
?-)
Elles font des choses différentes ? Je croyais que toutes les deux formattaient la valeur pour la sortir.
Ceci dit, je ne vois pas d'utilité à écrire quelque chose comme « std::cout << NULL ». Enfin, il ne m'est jamais arrivé d'écrire quelque chose de semblable dans mon code.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
writes:
| Jean-Marc Bourguet wrote in message | news:... | | > NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il | > est introduit un jour avec une signification assez stricte: son | > utilisation dans des contextes ou il faut un entier et non un pointeur | > est trop courante (en particulier je l'ai vu employe systematiquement | > la ou je mettrais ' '). | | Et cependant, il y a des compilateurs (dont g++) qui définisent NULL | avec un mot clé.
__null n'est pas un mot clé de C++ ;-/
[...]
| (Il me semble avoir entendu dire que le comité considère une | modification en cette direction. Mais je ne suis pas sûr ; je ne suis | plus de près la normalisation.)
| Jean-Marc Bourguet <jm@bourguet.org> wrote in message
| news:<pxboep3ia5b.fsf@news.bourguet.org>...
|
| > NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il
| > est introduit un jour avec une signification assez stricte: son
| > utilisation dans des contextes ou il faut un entier et non un pointeur
| > est trop courante (en particulier je l'ai vu employe systematiquement
| > la ou je mettrais ' ').
|
| Et cependant, il y a des compilateurs (dont g++) qui définisent NULL
| avec un mot clé.
__null n'est pas un mot clé de C++ ;-/
[...]
| (Il me semble avoir entendu dire que le comité considère une
| modification en cette direction. Mais je ne suis pas sûr ; je ne suis
| plus de près la normalisation.)
| Jean-Marc Bourguet wrote in message | news:... | | > NULL n'a meme pas l'avantage de pouvoir etre defini a ce mot cle s'il | > est introduit un jour avec une signification assez stricte: son | > utilisation dans des contextes ou il faut un entier et non un pointeur | > est trop courante (en particulier je l'ai vu employe systematiquement | > la ou je mettrais ' '). | | Et cependant, il y a des compilateurs (dont g++) qui définisent NULL | avec un mot clé.
__null n'est pas un mot clé de C++ ;-/
[...]
| (Il me semble avoir entendu dire que le comité considère une | modification en cette direction. Mais je ne suis pas sûr ; je ne suis | plus de près la normalisation.)
Non. On n'a jamais eu notification de l'arrivee des papiers pre Sydney et j'ai pour le moment une certaine surcharge de travail qui fait que je n'ai pas ete voir regulierement. J'aurais vraissemblablement jete un coup d'oeuil lu certains papiers, peut-etre celui-la.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Non. On n'a jamais eu notification de l'arrivee des papiers pre
Sydney et j'ai pour le moment une certaine surcharge de travail qui
fait que je n'ai pas ete voir regulierement. J'aurais
vraissemblablement jete un coup d'oeuil lu certains papiers, peut-etre
celui-la.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Non. On n'a jamais eu notification de l'arrivee des papiers pre Sydney et j'ai pour le moment une certaine surcharge de travail qui fait que je n'ai pas ete voir regulierement. J'aurais vraissemblablement jete un coup d'oeuil lu certains papiers, peut-etre celui-la.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes: | | > Aide-toi, le comité t'aidera :-) | > | > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf) | > | > (je crois que Jean-Marc est déjà au courant | | Non. On n'a jamais eu notification de l'arrivee des papiers pre | Sydney
ah. On (m'enfin, j'était un peu loin) en avait discuté à la dernière réunion avant Sydney.
J'en profite pour annoncer, avec du retard, que les papiers post-Sydney sont aussi là
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > Aide-toi, le comité t'aidera :-)
| >
| > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf)
| >
| > (je crois que Jean-Marc est déjà au courant
|
| Non. On n'a jamais eu notification de l'arrivee des papiers pre
| Sydney
ah. On (m'enfin, j'était un peu loin) en avait discuté à la
dernière réunion avant Sydney.
J'en profite pour annoncer, avec du retard, que les papiers
post-Sydney sont aussi là
| Gabriel Dos Reis writes: | | > Aide-toi, le comité t'aidera :-) | > | > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf) | > | > (je crois que Jean-Marc est déjà au courant | | Non. On n'a jamais eu notification de l'arrivee des papiers pre | Sydney
ah. On (m'enfin, j'était un peu loin) en avait discuté à la dernière réunion avant Sydney.
J'en profite pour annoncer, avec du retard, que les papiers post-Sydney sont aussi là
Page 4, 2ème phrase du chapitre 2: "The nullptr keyword designates a constant rvalue of type decltype(null_ptr t), assuming (...)" ^^^^ Il n'y aurait pas une faute de frappe là ?
D'autre part, il y a truc que je ne comprend pas bien. Sur la première page, le dernier point du cadre :
"Re the name of the type of nullptr: nullptr_t is introduced as a typedef for decltype(nullptr)"
n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ?
"The null pointer is a value that has no nameable type, and its type cannot be deduced as a template argument"
J'imagine que le typedef évite que le type soit déductible comme argument de template (et encore je suis très loin d'en être sûr), mais cela ne rend-il pas le type de nullptr nommable ?
Page 4, 2ème phrase du chapitre 2:
"The nullptr keyword designates a constant rvalue of type
decltype(null_ptr t), assuming (...)"
^^^^
Il n'y aurait pas une faute de frappe là ?
D'autre part, il y a truc que je ne comprend pas bien. Sur la première
page, le dernier point du cadre :
"Re the name of the type of nullptr: nullptr_t is introduced as a
typedef for decltype(nullptr)"
n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ?
"The null pointer is a value that has no nameable type, and its type
cannot be deduced as a template argument"
J'imagine que le typedef évite que le type soit déductible comme
argument de template (et encore je suis très loin d'en être sûr), mais
cela ne rend-il pas le type de nullptr nommable ?
Page 4, 2ème phrase du chapitre 2: "The nullptr keyword designates a constant rvalue of type decltype(null_ptr t), assuming (...)" ^^^^ Il n'y aurait pas une faute de frappe là ?
D'autre part, il y a truc que je ne comprend pas bien. Sur la première page, le dernier point du cadre :
"Re the name of the type of nullptr: nullptr_t is introduced as a typedef for decltype(nullptr)"
n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ?
"The null pointer is a value that has no nameable type, and its type cannot be deduced as a template argument"
J'imagine que le typedef évite que le type soit déductible comme argument de template (et encore je suis très loin d'en être sûr), mais cela ne rend-il pas le type de nullptr nommable ?
Un petit éclaircissement est le bienvenu.
A+
Christophe
Gabriel Dos Reis
Christophe de VIENNE writes:
| Gabriel Dos Reis wrote: | > Aide-toi, le comité t'aidera :-) | > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf) | > | | Page 4, 2ème phrase du chapitre 2: | "The nullptr keyword designates a constant rvalue of type | decltype(null_ptr t), assuming (...)" | ^^^^ | Il n'y aurait pas une faute de frappe là ?
Oui.
| D'autre part, il y a truc que je ne comprend pas bien. Sur la première | page, le dernier point du cadre : | | "Re the name of the type of nullptr: nullptr_t is introduced as a | typedef for decltype(nullptr)" | | n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ? | | "The null pointer is a value that has no nameable type, and its type | cannot be deduced as a template argument"
Cela paraît en effet une contradiction. La prochaine version sera un peu plus claire sur ce point.
| J'imagine que le typedef évite que le type soit déductible comme | argument de template (et encore je suis très loin d'en être sûr), mais
ce point n'est pas évident, mais passons.
| cela ne rend-il pas le type de nullptr nommable ?
yep.
-- Gaby
Christophe de VIENNE <cdevienne@alphacent.com> writes:
| Gabriel Dos Reis wrote:
| > Aide-toi, le comité t'aidera :-)
| > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf)
| >
|
| Page 4, 2ème phrase du chapitre 2:
| "The nullptr keyword designates a constant rvalue of type
| decltype(null_ptr t), assuming (...)"
| ^^^^
| Il n'y aurait pas une faute de frappe là ?
Oui.
| D'autre part, il y a truc que je ne comprend pas bien. Sur la première
| page, le dernier point du cadre :
|
| "Re the name of the type of nullptr: nullptr_t is introduced as a
| typedef for decltype(nullptr)"
|
| n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ?
|
| "The null pointer is a value that has no nameable type, and its type
| cannot be deduced as a template argument"
Cela paraît en effet une contradiction. La prochaine version sera un
peu plus claire sur ce point.
| J'imagine que le typedef évite que le type soit déductible comme
| argument de template (et encore je suis très loin d'en être sûr), mais
ce point n'est pas évident, mais passons.
| cela ne rend-il pas le type de nullptr nommable ?
| Gabriel Dos Reis wrote: | > Aide-toi, le comité t'aidera :-) | > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf) | > | | Page 4, 2ème phrase du chapitre 2: | "The nullptr keyword designates a constant rvalue of type | decltype(null_ptr t), assuming (...)" | ^^^^ | Il n'y aurait pas une faute de frappe là ?
Oui.
| D'autre part, il y a truc que je ne comprend pas bien. Sur la première | page, le dernier point du cadre : | | "Re the name of the type of nullptr: nullptr_t is introduced as a | typedef for decltype(nullptr)" | | n'est pas en contradiction avec l'avant-avant dernier point de la page 2 ? | | "The null pointer is a value that has no nameable type, and its type | cannot be deduced as a template argument"
Cela paraît en effet une contradiction. La prochaine version sera un peu plus claire sur ce point.
| J'imagine que le typedef évite que le type soit déductible comme | argument de template (et encore je suis très loin d'en être sûr), mais
ce point n'est pas évident, mais passons.
| cela ne rend-il pas le type de nullptr nommable ?
