Dans une fonction, j'ai besoin de passer comme paramètre l'adresse d'un
élément du vecteur (c'est comme ça...), c'est à dire un paramètre du type
ClassA*.
Quand je tente
&mon_vecteur.at(i)
ça plante.
Quelqu'un sait pourquoi ?
En fait j'ai besoin de stocker quelque part les adresses des éléments du
vecteur.
Merci
Marc
| | > Moi non plus (ni vice versa d'ailleurs), mais je ne savais pas que | > c'était ici la question. | | En ce qui me concerne, ce n'était effectivement pas la question. Mais | il a été question de préférence pour l'une des formes dans un autre | message.
|
| > Moi non plus (ni vice versa d'ailleurs), mais je ne savais pas que
| > c'était ici la question.
|
| En ce qui me concerne, ce n'était effectivement pas la question. Mais
| il a été question de préférence pour l'une des formes dans un autre
| message.
| | > Moi non plus (ni vice versa d'ailleurs), mais je ne savais pas que | > c'était ici la question. | | En ce qui me concerne, ce n'était effectivement pas la question. Mais | il a été question de préférence pour l'une des formes dans un autre | message.
qui a généré ce sous-thread, il a proposé &v[i] là où le posteur originel disait avoir des problème d'éxécution avec &v.at(i).
-- Gaby
--=-=-=--
Ivan Vecerina
"Marc Espie" wrote in message news:bqsikh$2hf8$ | In article , | Zouplaz wrote: | >Marc - : | > | >> En fait j'ai besoin de stocker quelque part les adresses des éléments du | >> vecteur. | > | >Et tu es sur qu'il n'y a pas le moindre risque qu'elle change en cours de | >route (redimensionnement du vecteur, soupe interne réalisée sans que tu en | >sois averti) ? | | Si je ne m'abuse, ca fait partie des defect reports de la norme, et des | assurances qui ont ete donnees depuis: on peut prendre l'adresse d'un | element de vector<T>, ca marche de la facon dont on s'attend, et ca ne | bouge pas tout seul tant qu'on ne joue pas (implicitement ou explicitement) | avec .reserve(). Pas d'accord, voir inversément: Si des éléments sont ajoutés au vecteur, le tableau interne du vecteur peut être réalloué à tout moment -- sauf si une capacité suffisante a précédemment été exigée en appelant .reserve(). A ma conaissance ceci n'est pas sujet à débat dans la norme...
[ ce qui devait être clarifié est que les éléments d'un std::vecteur sont toujours stoqués à des adresses contigues (c-à-d un tableau unique) -- ce qui depuis a été confirmé. ]
hth, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
"Marc Espie" <espie@tetto.gentiane.org> wrote in message
news:bqsikh$2hf8$3@biggoron.nerim.net...
| In article <Xns9448E3E5897FBZoupla@213.228.0.136>,
| Zouplaz <pouet@pouet.com> wrote:
| >Marc - metrica@free.fr :
| >
| >> En fait j'ai besoin de stocker quelque part les adresses des éléments
du
| >> vecteur.
| >
| >Et tu es sur qu'il n'y a pas le moindre risque qu'elle change en cours de
| >route (redimensionnement du vecteur, soupe interne réalisée sans que tu
en
| >sois averti) ?
|
| Si je ne m'abuse, ca fait partie des defect reports de la norme, et des
| assurances qui ont ete donnees depuis: on peut prendre l'adresse d'un
| element de vector<T>, ca marche de la facon dont on s'attend, et ca ne
| bouge pas tout seul tant qu'on ne joue pas (implicitement ou
explicitement)
| avec .reserve().
Pas d'accord, voir inversément:
Si des éléments sont ajoutés au vecteur, le tableau interne du vecteur
peut être réalloué à tout moment -- sauf si une capacité suffisante a
précédemment été exigée en appelant .reserve().
A ma conaissance ceci n'est pas sujet à débat dans la norme...
[ ce qui devait être clarifié est que les éléments d'un std::vecteur
sont toujours stoqués à des adresses contigues (c-à-d un tableau
unique) -- ce qui depuis a été confirmé. ]
hth, Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
"Marc Espie" wrote in message news:bqsikh$2hf8$ | In article , | Zouplaz wrote: | >Marc - : | > | >> En fait j'ai besoin de stocker quelque part les adresses des éléments du | >> vecteur. | > | >Et tu es sur qu'il n'y a pas le moindre risque qu'elle change en cours de | >route (redimensionnement du vecteur, soupe interne réalisée sans que tu en | >sois averti) ? | | Si je ne m'abuse, ca fait partie des defect reports de la norme, et des | assurances qui ont ete donnees depuis: on peut prendre l'adresse d'un | element de vector<T>, ca marche de la facon dont on s'attend, et ca ne | bouge pas tout seul tant qu'on ne joue pas (implicitement ou explicitement) | avec .reserve(). Pas d'accord, voir inversément: Si des éléments sont ajoutés au vecteur, le tableau interne du vecteur peut être réalloué à tout moment -- sauf si une capacité suffisante a précédemment été exigée en appelant .reserve(). A ma conaissance ceci n'est pas sujet à débat dans la norme...
[ ce qui devait être clarifié est que les éléments d'un std::vecteur sont toujours stoqués à des adresses contigues (c-à-d un tableau unique) -- ce qui depuis a été confirmé. ]
hth, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
James Kanze
Gabriel Dos Reis writes:
|> "Michel Michaud" writes:
|> | Dans news:, Benoît |> | > Vincent Richard
|> | >> &(mon_vecteur[i])
|> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme |> | > l'adresse d'un tableau C contenant les éléments du vecteur |> | > ? (toujours avec les mêmes précautions : pas de |> | > modifications du vecteur, etc.)
|> | Oui, en autant que les éléments auxquels tu fais |> | référence existent. Ce n'était pas tout à fait garanti |> | par la norme, mais ça l'est maintenant.
|> Mais je ne vois toujours pas l'intérêt ici de préférer |> v[i] à v.at(i).
Parce que dans la pratique, il ne lève pas d'exception ?
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> "Michel Michaud" <mm@gdzid.com> writes:
|> | Dans news:87y8tpwyag.fsf@free.fr, Benoît
|> | > Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid>
|> | >> &(mon_vecteur[i])
|> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme
|> | > l'adresse d'un tableau C contenant les éléments du vecteur
|> | > ? (toujours avec les mêmes précautions : pas de
|> | > modifications du vecteur, etc.)
|> | Oui, en autant que les éléments auxquels tu fais
|> | référence existent. Ce n'était pas tout à fait garanti
|> | par la norme, mais ça l'est maintenant.
|> Mais je ne vois toujours pas l'intérêt ici de préférer
|> v[i] à v.at(i).
Parce que dans la pratique, il ne lève pas d'exception ?
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme |> | > l'adresse d'un tableau C contenant les éléments du vecteur |> | > ? (toujours avec les mêmes précautions : pas de |> | > modifications du vecteur, etc.)
|> | Oui, en autant que les éléments auxquels tu fais |> | référence existent. Ce n'était pas tout à fait garanti |> | par la norme, mais ça l'est maintenant.
|> Mais je ne vois toujours pas l'intérêt ici de préférer |> v[i] à v.at(i).
Parce que dans la pratique, il ne lève pas d'exception ?
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> "Michel Michaud" writes: | | |> | Dans news:, Benoît | |> | > Vincent Richard | | |> | >> &(mon_vecteur[i]) | | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme | |> | > l'adresse d'un tableau C contenant les éléments du vecteur | |> | > ? (toujours avec les mêmes précautions : pas de | |> | > modifications du vecteur, etc.) | | |> | Oui, en autant que les éléments auxquels tu fais | |> | référence existent. Ce n'était pas tout à fait garanti | |> | par la norme, mais ça l'est maintenant. | | |> Mais je ne vois toujours pas l'intérêt ici de préférer | |> v[i] à v.at(i). | | Parce que dans la pratique, il ne lève pas d'exception ?
Et alors ?
Tu raisonnes comme les élèves qui se contentent de mettre leurs programmes en commentaire... parce que le compilateur leur a dit qu'il y avait une erreur de syntaxe.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> "Michel Michaud" <mm@gdzid.com> writes:
|
| |> | Dans news:87y8tpwyag.fsf@free.fr, Benoît
| |> | > Vincent Richard <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid>
|
| |> | >> &(mon_vecteur[i])
|
| |> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme
| |> | > l'adresse d'un tableau C contenant les éléments du vecteur
| |> | > ? (toujours avec les mêmes précautions : pas de
| |> | > modifications du vecteur, etc.)
|
| |> | Oui, en autant que les éléments auxquels tu fais
| |> | référence existent. Ce n'était pas tout à fait garanti
| |> | par la norme, mais ça l'est maintenant.
|
| |> Mais je ne vois toujours pas l'intérêt ici de préférer
| |> v[i] à v.at(i).
|
| Parce que dans la pratique, il ne lève pas d'exception ?
Et alors ?
Tu raisonnes comme les élèves qui se contentent de mettre leurs
programmes en commentaire... parce que le compilateur leur a dit qu'il
y avait une erreur de syntaxe.
| Gabriel Dos Reis writes: | | |> "Michel Michaud" writes: | | |> | Dans news:, Benoît | |> | > Vincent Richard | | |> | >> &(mon_vecteur[i]) | | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré comme | |> | > l'adresse d'un tableau C contenant les éléments du vecteur | |> | > ? (toujours avec les mêmes précautions : pas de | |> | > modifications du vecteur, etc.) | | |> | Oui, en autant que les éléments auxquels tu fais | |> | référence existent. Ce n'était pas tout à fait garanti | |> | par la norme, mais ça l'est maintenant. | | |> Mais je ne vois toujours pas l'intérêt ici de préférer | |> v[i] à v.at(i). | | Parce que dans la pratique, il ne lève pas d'exception ?
Et alors ?
Tu raisonnes comme les élèves qui se contentent de mettre leurs programmes en commentaire... parce que le compilateur leur a dit qu'il y avait une erreur de syntaxe.
-- Gaby
James Kanze
Gabriel Dos Reis writes:
|> James Kanze writes:
|> | Gabriel Dos Reis writes:
|> | |> "Michel Michaud" writes:
|> | |> | Dans news:, Benoît |> | |> | > Vincent Richard |> | |> | > a
|> | |> | >> &(mon_vecteur[i])
|> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré |> | |> | > comme l'adresse d'un tableau C contenant les |> | |> | > éléments du vecteur ? (toujours avec les mêmes |> | |> | > précautions : pas de modifications du vecteur, etc.)
|> | |> | Oui, en autant que les éléments auxquels tu fais |> | |> | référence existent. Ce n'était pas tout à fait |> | |> | garanti par la norme, mais ça l'est maintenant.
|> | |> Mais je ne vois toujours pas l'intérêt ici de |> | |> préférer v[i] à v.at(i).
|> | Parce que dans la pratique, il ne lève pas d'exception ?
|> Et alors ?
C'est une raison potentielle. Il y a bien des moments où il faut savoir qu'une fonction ne lève pas d'exception -- sinon, le code correct n'est pas possible.
|> Tu raisonnes comme les élèves qui se contentent de mettre |> leurs programmes en commentaire... parce que le compilateur leur a |> dit qu'il y avait une erreur de syntaxe.
Ou comme un professionnel qui doit écrire du code qui marche avec des compilateurs réels. Dans la pratique, si je me limite aux garanties dans la norme, je ne peux pas utiliser la STL dans une application, parce qu'il y a trop de points non spécifiés mais qu'il faut savoir pour écrire du code correct -- que std::vector<>::operator[] ne lève pas d'exception n'en est qu'une. N'empêche que dans les implémentations concrètes, on y arrive.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> James Kanze <kanze@alex.gabi-soft.fr> writes:
|> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> | |> "Michel Michaud" <mm@gdzid.com> writes:
|> | |> | Dans news:87y8tpwyag.fsf@free.fr, Benoît
|> | |> | > Vincent Richard
|> | |> | > <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid> a
|> | |> | >> &(mon_vecteur[i])
|> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré
|> | |> | > comme l'adresse d'un tableau C contenant les
|> | |> | > éléments du vecteur ? (toujours avec les mêmes
|> | |> | > précautions : pas de modifications du vecteur, etc.)
|> | |> | Oui, en autant que les éléments auxquels tu fais
|> | |> | référence existent. Ce n'était pas tout à fait
|> | |> | garanti par la norme, mais ça l'est maintenant.
|> | |> Mais je ne vois toujours pas l'intérêt ici de
|> | |> préférer v[i] à v.at(i).
|> | Parce que dans la pratique, il ne lève pas d'exception ?
|> Et alors ?
C'est une raison potentielle. Il y a bien des moments où il faut
savoir qu'une fonction ne lève pas d'exception -- sinon, le code
correct n'est pas possible.
|> Tu raisonnes comme les élèves qui se contentent de mettre
|> leurs programmes en commentaire... parce que le compilateur leur a
|> dit qu'il y avait une erreur de syntaxe.
Ou comme un professionnel qui doit écrire du code qui marche avec des
compilateurs réels. Dans la pratique, si je me limite aux garanties
dans la norme, je ne peux pas utiliser la STL dans une application,
parce qu'il y a trop de points non spécifiés mais qu'il faut
savoir pour écrire du code correct -- que std::vector<>::operator[]
ne lève pas d'exception n'en est qu'une. N'empêche que dans les
implémentations concrètes, on y arrive.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> | |> | Dans news:, Benoît |> | |> | > Vincent Richard |> | |> | > a
|> | |> | >> &(mon_vecteur[i])
|> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré |> | |> | > comme l'adresse d'un tableau C contenant les |> | |> | > éléments du vecteur ? (toujours avec les mêmes |> | |> | > précautions : pas de modifications du vecteur, etc.)
|> | |> | Oui, en autant que les éléments auxquels tu fais |> | |> | référence existent. Ce n'était pas tout à fait |> | |> | garanti par la norme, mais ça l'est maintenant.
|> | |> Mais je ne vois toujours pas l'intérêt ici de |> | |> préférer v[i] à v.at(i).
|> | Parce que dans la pratique, il ne lève pas d'exception ?
|> Et alors ?
C'est une raison potentielle. Il y a bien des moments où il faut savoir qu'une fonction ne lève pas d'exception -- sinon, le code correct n'est pas possible.
|> Tu raisonnes comme les élèves qui se contentent de mettre |> leurs programmes en commentaire... parce que le compilateur leur a |> dit qu'il y avait une erreur de syntaxe.
Ou comme un professionnel qui doit écrire du code qui marche avec des compilateurs réels. Dans la pratique, si je me limite aux garanties dans la norme, je ne peux pas utiliser la STL dans une application, parce qu'il y a trop de points non spécifiés mais qu'il faut savoir pour écrire du code correct -- que std::vector<>::operator[] ne lève pas d'exception n'en est qu'une. N'empêche que dans les implémentations concrètes, on y arrive.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> "Michel Michaud" writes: | | |> | |> | Dans news:, Benoît | |> | |> | > Vincent Richard | |> | |> | > a | | |> | |> | >> &(mon_vecteur[i]) | | |> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré | |> | |> | > comme l'adresse d'un tableau C contenant les | |> | |> | > éléments du vecteur ? (toujours avec les mêmes | |> | |> | > précautions : pas de modifications du vecteur, etc.) | | |> | |> | Oui, en autant que les éléments auxquels tu fais | |> | |> | référence existent. Ce n'était pas tout à fait | |> | |> | garanti par la norme, mais ça l'est maintenant. | | |> | |> Mais je ne vois toujours pas l'intérêt ici de | |> | |> préférer v[i] à v.at(i). | | |> | Parce que dans la pratique, il ne lève pas d'exception ? | | |> Et alors ? | | C'est une raison potentielle. Il y a bien des moments où il faut | savoir qu'une fonction ne lève pas d'exception -- sinon, le code | correct n'est pas possible.
Et dans ce cas précis, le code ne devient pas subitement correct parce que tu as remplacé v.at(i) par v[i]. Si, v,ay(i) lève une exception, c'est que i n'est pas une bonne valeur pour indexer le tableau. C'est simple.
| | |> Tu raisonnes comme les élèves qui se contentent de mettre | |> leurs programmes en commentaire... parce que le compilateur leur a | |> dit qu'il y avait une erreur de syntaxe. | | Ou comme un professionnel qui doit écrire du code qui marche avec des | compilateurs réels.
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en prétendant que le code devient ainsi correct fait un raisonnement stupide qui ne peut provenir d'un professionnel ; ou alors c'est un professionnel qu'il faut vite enlever du circuit parce qu'il représente un vrai danger public.
Ce n'est pas une question de garantie donnée par la norme. Le fait que v.at(i) lève une exception indique un problème avec la valeur i ou l'indexation. Écrire v[i] ne rend pas le code plus correct.
Et dans la vie concrète, tu vas tomber sur des bibliothèques qui font quand même du range checking pouor v[i].
Il y a de ces jours, il vaut mieux être aveugle.
-- Gaby
James Kanze <kanze@alex.gabi-soft.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> James Kanze <kanze@alex.gabi-soft.fr> writes:
|
| |> | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| |> | |> "Michel Michaud" <mm@gdzid.com> writes:
|
| |> | |> | Dans news:87y8tpwyag.fsf@free.fr, Benoît
| |> | |> | > Vincent Richard
| |> | |> | > <chere-loque.MARRE-DE-LA-PUB@wanadoo.fr.invalid> a
|
| |> | |> | >> &(mon_vecteur[i])
|
| |> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré
| |> | |> | > comme l'adresse d'un tableau C contenant les
| |> | |> | > éléments du vecteur ? (toujours avec les mêmes
| |> | |> | > précautions : pas de modifications du vecteur, etc.)
|
| |> | |> | Oui, en autant que les éléments auxquels tu fais
| |> | |> | référence existent. Ce n'était pas tout à fait
| |> | |> | garanti par la norme, mais ça l'est maintenant.
|
| |> | |> Mais je ne vois toujours pas l'intérêt ici de
| |> | |> préférer v[i] à v.at(i).
|
| |> | Parce que dans la pratique, il ne lève pas d'exception ?
|
| |> Et alors ?
|
| C'est une raison potentielle. Il y a bien des moments où il faut
| savoir qu'une fonction ne lève pas d'exception -- sinon, le code
| correct n'est pas possible.
Et dans ce cas précis, le code ne devient pas subitement correct parce
que tu as remplacé v.at(i) par v[i]. Si, v,ay(i) lève une exception,
c'est que i n'est pas une bonne valeur pour indexer le tableau.
C'est simple.
|
| |> Tu raisonnes comme les élèves qui se contentent de mettre
| |> leurs programmes en commentaire... parce que le compilateur leur a
| |> dit qu'il y avait une erreur de syntaxe.
|
| Ou comme un professionnel qui doit écrire du code qui marche avec des
| compilateurs réels.
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en
prétendant que le code devient ainsi correct fait un raisonnement
stupide qui ne peut provenir d'un professionnel ; ou alors c'est un
professionnel qu'il faut vite enlever du circuit parce qu'il
représente un vrai danger public.
Ce n'est pas une question de garantie donnée par la norme.
Le fait que v.at(i) lève une exception indique un problème avec la
valeur i ou l'indexation. Écrire v[i] ne rend pas le code plus
correct.
Et dans la vie concrète, tu vas tomber sur des bibliothèques qui font
quand même du range checking pouor v[i].
| Gabriel Dos Reis writes: | | |> James Kanze writes: | | |> | Gabriel Dos Reis writes: | | |> | |> "Michel Michaud" writes: | | |> | |> | Dans news:, Benoît | |> | |> | > Vincent Richard | |> | |> | > a | | |> | |> | >> &(mon_vecteur[i]) | | |> | |> | > Est-ce que &(mon_vecteur[0]) peut être considéré | |> | |> | > comme l'adresse d'un tableau C contenant les | |> | |> | > éléments du vecteur ? (toujours avec les mêmes | |> | |> | > précautions : pas de modifications du vecteur, etc.) | | |> | |> | Oui, en autant que les éléments auxquels tu fais | |> | |> | référence existent. Ce n'était pas tout à fait | |> | |> | garanti par la norme, mais ça l'est maintenant. | | |> | |> Mais je ne vois toujours pas l'intérêt ici de | |> | |> préférer v[i] à v.at(i). | | |> | Parce que dans la pratique, il ne lève pas d'exception ? | | |> Et alors ? | | C'est une raison potentielle. Il y a bien des moments où il faut | savoir qu'une fonction ne lève pas d'exception -- sinon, le code | correct n'est pas possible.
Et dans ce cas précis, le code ne devient pas subitement correct parce que tu as remplacé v.at(i) par v[i]. Si, v,ay(i) lève une exception, c'est que i n'est pas une bonne valeur pour indexer le tableau. C'est simple.
| | |> Tu raisonnes comme les élèves qui se contentent de mettre | |> leurs programmes en commentaire... parce que le compilateur leur a | |> dit qu'il y avait une erreur de syntaxe. | | Ou comme un professionnel qui doit écrire du code qui marche avec des | compilateurs réels.
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en prétendant que le code devient ainsi correct fait un raisonnement stupide qui ne peut provenir d'un professionnel ; ou alors c'est un professionnel qu'il faut vite enlever du circuit parce qu'il représente un vrai danger public.
Ce n'est pas une question de garantie donnée par la norme. Le fait que v.at(i) lève une exception indique un problème avec la valeur i ou l'indexation. Écrire v[i] ne rend pas le code plus correct.
Et dans la vie concrète, tu vas tomber sur des bibliothèques qui font quand même du range checking pouor v[i].
Il y a de ces jours, il vaut mieux être aveugle.
-- Gaby
Ivan Vecerina
"James Kanze" wrote in message news: | |> | |> Mais je ne vois toujours pas l'intérêt ici de | |> | |> préférer v[i] à v.at(i). | | |> | Parce que dans la pratique, il ne lève pas d'exception ? | | |> Et alors ? | | C'est une raison potentielle. Il y a bien des moments où il faut | savoir qu'une fonction ne lève pas d'exception -- sinon, le code | correct n'est pas possible.
Uh... mais dans les cas où v.at(i) lance une exception, un appel à v[i] entraîne un comportement indéfini (undefined behavior). Est-ce là un choix raisonnable ?
Si une exception doit être évitée, il faut de toute manière s'assurer que 'i' est dans un intervalle valide. Uniquement lorsque ce point est certain, v[i] peut éventuellement être préféré à v.at(i) pour des raisons de confort, ou de performance...
Ou est-ce que j'ai raté quelque chose ?
Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
"James Kanze" <kanze@alex.gabi-soft.fr> wrote in message
news:86wu98ztr0.fsf@alex.gabi-soft.fr...
| |> | |> Mais je ne vois toujours pas l'intérêt ici de
| |> | |> préférer v[i] à v.at(i).
|
| |> | Parce que dans la pratique, il ne lève pas d'exception ?
|
| |> Et alors ?
|
| C'est une raison potentielle. Il y a bien des moments où il faut
| savoir qu'une fonction ne lève pas d'exception -- sinon, le code
| correct n'est pas possible.
Uh... mais dans les cas où v.at(i) lance une exception,
un appel à v[i] entraîne un comportement indéfini
(undefined behavior).
Est-ce là un choix raisonnable ?
Si une exception doit être évitée, il faut de toute manière
s'assurer que 'i' est dans un intervalle valide. Uniquement
lorsque ce point est certain, v[i] peut éventuellement être
préféré à v.at(i) pour des raisons de confort,
ou de performance...
Ou est-ce que j'ai raté quelque chose ?
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
"James Kanze" wrote in message news: | |> | |> Mais je ne vois toujours pas l'intérêt ici de | |> | |> préférer v[i] à v.at(i). | | |> | Parce que dans la pratique, il ne lève pas d'exception ? | | |> Et alors ? | | C'est une raison potentielle. Il y a bien des moments où il faut | savoir qu'une fonction ne lève pas d'exception -- sinon, le code | correct n'est pas possible.
Uh... mais dans les cas où v.at(i) lance une exception, un appel à v[i] entraîne un comportement indéfini (undefined behavior). Est-ce là un choix raisonnable ?
Si une exception doit être évitée, il faut de toute manière s'assurer que 'i' est dans un intervalle valide. Uniquement lorsque ce point est certain, v[i] peut éventuellement être préféré à v.at(i) pour des raisons de confort, ou de performance...
Ou est-ce que j'ai raté quelque chose ?
Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
Gabriel Dos Reis
"Ivan Vecerina" writes:
| Ou est-ce que j'ai raté quelque chose ?
Tu veux t'assurer que ton programme est correct, donc tu n'es pas un programmeur « professionnel », selon la définition que James semble avoir de « professionnel. »
Tu veux t'assurer que ton programme est correct, donc tu n'es pas un
programmeur « professionnel », selon la définition que James semble
avoir de « professionnel. »
Tu veux t'assurer que ton programme est correct, donc tu n'es pas un programmeur « professionnel », selon la définition que James semble avoir de « professionnel. »
-- Gaby
Michel Michaud
Dans news:, Gabriel Dos
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en prétendant que le code devient ainsi correct fait un raisonnement stupide qui ne peut provenir d'un professionnel ; ou alors c'est un
En pratique (ce qui est souvent le point de vue de James), je ne sais pas si stupide est la seule possibilité :-) En fait, je pense à quelque chose du genre de
vector<int> v; // ... // Il y a maintenant >= nbElem dans mon v, mais je veux // trier nbElem au maximum MonSuperTriSurTableauDeInt(&v[0], &v[nbElem]);
S'il y a exactement nbElem, at(nbElem) lève une exception avant qu'on puisse en prendre l'adresse... Avec [nbElem], c'est moins dangereux (bien que risqué en C++). Ceci dit, je règlerais le problème avec (&v.at(0) + nbElem), mais c'est une autre histoire.
Je ne dis pas que l'un de vous deux a raison et l'autre non, je n'ai pas d'avis pour le moment :-) Sauf que je n'aime pas « at » en général, j'aurais vraiment préféré [] avec validation et at pour optimisation. Dans ce cas, j'ai l'impression que vous seriez peut-être d'accord pour utiliser []...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:m3y8toljvg.fsf@uniton.integrable-solutions.net, Gabriel Dos
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en
prétendant que le code devient ainsi correct fait un raisonnement
stupide qui ne peut provenir d'un professionnel ; ou alors c'est un
En pratique (ce qui est souvent le point de vue de James), je
ne sais pas si stupide est la seule possibilité :-) En fait,
je pense à quelque chose du genre de
vector<int> v;
// ...
// Il y a maintenant >= nbElem dans mon v, mais je veux
// trier nbElem au maximum
MonSuperTriSurTableauDeInt(&v[0], &v[nbElem]);
S'il y a exactement nbElem, at(nbElem) lève une exception avant
qu'on puisse en prendre l'adresse... Avec [nbElem], c'est moins
dangereux (bien que risqué en C++). Ceci dit, je règlerais le
problème avec (&v.at(0) + nbElem), mais c'est une autre
histoire.
Je ne dis pas que l'un de vous deux a raison et l'autre non,
je n'ai pas d'avis pour le moment :-) Sauf que je n'aime pas
« at » en général, j'aurais vraiment préféré [] avec validation
et at pour optimisation. Dans ce cas, j'ai l'impression que
vous seriez peut-être d'accord pour utiliser []...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Excuse-moi, mais quelqu'un qui remplace v.at(i) par v[i] en prétendant que le code devient ainsi correct fait un raisonnement stupide qui ne peut provenir d'un professionnel ; ou alors c'est un
En pratique (ce qui est souvent le point de vue de James), je ne sais pas si stupide est la seule possibilité :-) En fait, je pense à quelque chose du genre de
vector<int> v; // ... // Il y a maintenant >= nbElem dans mon v, mais je veux // trier nbElem au maximum MonSuperTriSurTableauDeInt(&v[0], &v[nbElem]);
S'il y a exactement nbElem, at(nbElem) lève une exception avant qu'on puisse en prendre l'adresse... Avec [nbElem], c'est moins dangereux (bien que risqué en C++). Ceci dit, je règlerais le problème avec (&v.at(0) + nbElem), mais c'est une autre histoire.
Je ne dis pas que l'un de vous deux a raison et l'autre non, je n'ai pas d'avis pour le moment :-) Sauf que je n'aime pas « at » en général, j'aurais vraiment préféré [] avec validation et at pour optimisation. Dans ce cas, j'ai l'impression que vous seriez peut-être d'accord pour utiliser []...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
