"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
|
| >
| > Il n'a jamais fait un doute dans la tête de ceux qui ont travaillé
| > activement à l'adoption d'une partie de la STL dans la norme qu'un
| > std::vector<> devait garantir la contiguité.
| >
| > -- Gaby
|
| Question naïve : que faire de la notion d'adresse dans une
| librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter
| sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser
| serait en quelque sorte "malpropre", c'est à dire par des
| calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait
« malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque,
| sauf erreur de ma part (c'est ma question) cette propriété
| de contiguïté n'est pas modélisée (représentée) dans cette
| interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont
pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont
| la garantie d'existence n'est pas représentée dans l'interface
| de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment
| représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les
bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette
| classe, mais à partir du moment où l'utilisateur peut avoir
| accès au "prochain" élément, en quoi cela l'intéresse-t-il
| de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
std::vector<char> v(100);
std::cin.read(&v[0], v.size());
| Finalement j'arrive à formuler ma question sous sa forme la
| plus intéressante : en quoi cette contiguïté est-elle pertinente
| dans le contexte d'une classe munie d'un itérateur ? (dont
| l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes
d'autres codes avec des interfaces "C", tu verras l'utilité.
std::cin.read(&v[0], v.size());
va échouer s'il n'y a pas contiguïté, mais cela n'est pas propre
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le
message
| news: m3znjjhoy6.fsf@uniton.integrable-solutions.net...
|
| >
| > Il n'a jamais fait un doute dans la tête de ceux qui ont travaillé
| > activement à l'adoption d'une partie de la STL dans la norme qu'un
| > std::vector<> devait garantir la contiguité.
| >
| > -- Gaby
|
| Question naïve : que faire de la notion d'adresse dans une
| librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter
| sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser
| serait en quelque sorte "malpropre", c'est à dire par des
| calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait
« malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque,
| sauf erreur de ma part (c'est ma question) cette propriété
| de contiguïté n'est pas modélisée (représentée) dans cette
| interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont
pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont
| la garantie d'existence n'est pas représentée dans l'interface
| de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment
| représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les
bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette
| classe, mais à partir du moment où l'utilisateur peut avoir
| accès au "prochain" élément, en quoi cela l'intéresse-t-il
| de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
std::vector<char> v(100);
std::cin.read(&v[0], v.size());
| Finalement j'arrive à formuler ma question sous sa forme la
| plus intéressante : en quoi cette contiguïté est-elle pertinente
| dans le contexte d'une classe munie d'un itérateur ? (dont
| l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes
d'autres codes avec des interfaces "C", tu verras l'utilité.
std::cin.read(&v[0], v.size());
va échouer s'il n'y a pas contiguïté, mais cela n'est pas propre
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
|
| >
| > Il n'a jamais fait un doute dans la tête de ceux qui ont travaillé
| > activement à l'adoption d'une partie de la STL dans la norme qu'un
| > std::vector<> devait garantir la contiguité.
| >
| > -- Gaby
|
| Question naïve : que faire de la notion d'adresse dans une
| librairie un peu abstraite ? Je m'explique :
la notion d'adresse est aussi abstraite. Où est le problème ?
| - d'une part, tu nous dis clairement qu'on peut compter
| sur cette contiguïté ;
Sans aucun doute.
| - d'autre part, il me semble que la seule façon de l'utiliser
| serait en quelque sorte "malpropre", c'est à dire par des
| calculs sur pointeurs avec des sizeof, etc - autrement dit
peux-tu expliquer cette utilisation de sizeof et en quoi ce serait
« malpropre » ?
| en "court-circuitant" l'interface de std::vector puisque,
| sauf erreur de ma part (c'est ma question) cette propriété
| de contiguïté n'est pas modélisée (représentée) dans cette
| interface ?!
C'est de la sémantique. Et il y a beaucoup de sémantique qui ne sont
pas exprimée par de la syntaxe.
| N'est -ce pas un peu choquant d'avoir une propriété dont
| la garantie d'existence n'est pas représentée dans l'interface
| de la classe - c'est une entorse à l'abstraction du type !?
Non.
Tout simplement, parce que tout ne se réduit pas à la syntaxe.
| D'un autre côté je me demande moi-même comment
| représenter une telle propriété... après tout, cela concerne
C'est une garantie *sémantique*. Si i, j sont des entiers dans les
bornes alors
&v[i] == &v[j] + (i - j);
où « & » est addressof natif.
| en premier lieu *l'implémentation* d'un itérateur sur cette
| classe, mais à partir du moment où l'utilisateur peut avoir
| accès au "prochain" élément, en quoi cela l'intéresse-t-il
| de savoir où il se trouve par rapport au précédent ?
Parce que le monde ne tourne pas autour des itérateurs ?
std::vector<char> v(100);
std::cin.read(&v[0], v.size());
| Finalement j'arrive à formuler ma question sous sa forme la
| plus intéressante : en quoi cette contiguïté est-elle pertinente
| dans le contexte d'une classe munie d'un itérateur ? (dont
| l'usager, je me répète, n'a pas à savoir *comment* il itère).
Voir ci-dessus par exemple. Mais je suis certain que si tu regardes
d'autres codes avec des interfaces "C", tu verras l'utilité.
std::cin.read(&v[0], v.size());
va échouer s'il n'y a pas contiguïté, mais cela n'est pas propre
"Alain Naigeon" writes:
|
| Une abstraction consiste à prendre de la hauteur par rapport
| à un niveau moins abstrait ; en l'occurrence, peux-tu expliquer
| quel est le concept moins abstrait que l'adresse qui est englobé
| par celle-ci ?
le métal ?
| Pour ma part je te dirai que la notion de handle, rencontrée dans
| mes petites aventures, est une abstraction de l'adresse, non ?
C'est une autre *forme* d'adresse -- pas directement celle du langage
C++, mais elle est bien une forme d'adresse.
Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
de ses éléments.
La syntaxe, en ce qui concerne C++, c'est d'exprimer quelque chose.
Si on veut avoir des erreurs compile-time, il vaut mieux utiliser le
système de type.
| > | N'est -ce pas un peu choquant d'avoir une propriété dont
| > | la garantie d'existence n'est pas représentée dans l'interface
| > | de la classe - c'est une entorse à l'abstraction du type !?
| >
| > Non.
| >
| > Tout simplement, parce que tout ne se réduit pas à la syntaxe.
|
| Attends, entendons-nous bien : si tu nommes "lire" une fonction
| qui écrit, personne ne peut rien contre ça, nous sommes d'accord.
Ce qui ne fait que souligner que « sémantique » est la bonne porte.
| Mais il ne faut peut-être pas appeler sémantique tout ce qui échappe
| à la syntaxe (faute de quoi une syntaxe incomplète, donc fautive,
| serait toujours pardonnée).
c'est pourtant le cas. Du moins en ce qui concerne C++.
| peux-tu me dire quelle fonction de l'interface
| public de std:vector est susceptible d'échouer si les éléments sont
| non contigus ?
comme je te l'ai dit plus haut, C++ ne se réduit pas à la syntaxe.
Si tu veux comprendre et utiliser C++, il faut sonner à la porte
« sémantique ». Et si tu sonnes à cette porte, la réponse à ta
question est évidente.
| Je n'en vois aucune (sous réserve que l'*implémentation*
| en tienne compte, évidemment).
| et non du type défini par son interface public. En l'occurrence, je ne
| dirais pas "sémantique" pour implémentation ;-) Mais bon, je suis sûr
| que ce n'est pas ta position non plus...
je ne te le fais pas dire.
| Par conséquent, si l'interface public fonctionne même en l'absence
| de contiguïté, alors c'est que c'est une propriété de l'implémentation,
| La façon propre serait de prévoir, dans l'interface public,
| une fonction de lecture de n éléments ;
C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
| après quoi, si l'implémenteur
| décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| ta tournure, pour des raisons de simplicité et d'efficacité - mais je ne
| vois pas en quoi cela doit concerner l'appelant.
| Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| qu'une classe template du genre chaine d'objets nous mettrait d'accord
qu'est-ce qu'une chaîne d'objets sinon une suite ?
| tous les deux, et d'une façon élégante (tu aurais évidemment une
| strstream qui ferait exactement le boulot ci-dessus) - et pourquoi
est-elle
| manquante, cette classe ?!!
Parce qu'est est déjà là.
-- Gaby
« I am of the opinion that most people focus on syntax issues to the
detriment of type issues. The critical issues in the design of C++
were always those of type, ambiguity, and access control, not those
of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
"Alain Naigeon" <anaigeon@free.fr> writes:
|
| Une abstraction consiste à prendre de la hauteur par rapport
| à un niveau moins abstrait ; en l'occurrence, peux-tu expliquer
| quel est le concept moins abstrait que l'adresse qui est englobé
| par celle-ci ?
le métal ?
| Pour ma part je te dirai que la notion de handle, rencontrée dans
| mes petites aventures, est une abstraction de l'adresse, non ?
C'est une autre *forme* d'adresse -- pas directement celle du langage
C++, mais elle est bien une forme d'adresse.
Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
de ses éléments.
La syntaxe, en ce qui concerne C++, c'est d'exprimer quelque chose.
Si on veut avoir des erreurs compile-time, il vaut mieux utiliser le
système de type.
| > | N'est -ce pas un peu choquant d'avoir une propriété dont
| > | la garantie d'existence n'est pas représentée dans l'interface
| > | de la classe - c'est une entorse à l'abstraction du type !?
| >
| > Non.
| >
| > Tout simplement, parce que tout ne se réduit pas à la syntaxe.
|
| Attends, entendons-nous bien : si tu nommes "lire" une fonction
| qui écrit, personne ne peut rien contre ça, nous sommes d'accord.
Ce qui ne fait que souligner que « sémantique » est la bonne porte.
| Mais il ne faut peut-être pas appeler sémantique tout ce qui échappe
| à la syntaxe (faute de quoi une syntaxe incomplète, donc fautive,
| serait toujours pardonnée).
c'est pourtant le cas. Du moins en ce qui concerne C++.
| peux-tu me dire quelle fonction de l'interface
| public de std:vector est susceptible d'échouer si les éléments sont
| non contigus ?
comme je te l'ai dit plus haut, C++ ne se réduit pas à la syntaxe.
Si tu veux comprendre et utiliser C++, il faut sonner à la porte
« sémantique ». Et si tu sonnes à cette porte, la réponse à ta
question est évidente.
| Je n'en vois aucune (sous réserve que l'*implémentation*
| en tienne compte, évidemment).
| et non du type défini par son interface public. En l'occurrence, je ne
| dirais pas "sémantique" pour implémentation ;-) Mais bon, je suis sûr
| que ce n'est pas ta position non plus...
je ne te le fais pas dire.
| Par conséquent, si l'interface public fonctionne même en l'absence
| de contiguïté, alors c'est que c'est une propriété de l'implémentation,
| La façon propre serait de prévoir, dans l'interface public,
| une fonction de lecture de n éléments ;
C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
| après quoi, si l'implémenteur
| décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| ta tournure, pour des raisons de simplicité et d'efficacité - mais je ne
| vois pas en quoi cela doit concerner l'appelant.
| Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| qu'une classe template du genre chaine d'objets nous mettrait d'accord
qu'est-ce qu'une chaîne d'objets sinon une suite ?
| tous les deux, et d'une façon élégante (tu aurais évidemment une
| strstream qui ferait exactement le boulot ci-dessus) - et pourquoi
est-elle
| manquante, cette classe ?!!
Parce qu'est est déjà là.
-- Gaby
« I am of the opinion that most people focus on syntax issues to the
detriment of type issues. The critical issues in the design of C++
were always those of type, ambiguity, and access control, not those
of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
"Alain Naigeon" writes:
|
| Une abstraction consiste à prendre de la hauteur par rapport
| à un niveau moins abstrait ; en l'occurrence, peux-tu expliquer
| quel est le concept moins abstrait que l'adresse qui est englobé
| par celle-ci ?
le métal ?
| Pour ma part je te dirai que la notion de handle, rencontrée dans
| mes petites aventures, est une abstraction de l'adresse, non ?
C'est une autre *forme* d'adresse -- pas directement celle du langage
C++, mais elle est bien une forme d'adresse.
Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
de ses éléments.
La syntaxe, en ce qui concerne C++, c'est d'exprimer quelque chose.
Si on veut avoir des erreurs compile-time, il vaut mieux utiliser le
système de type.
| > | N'est -ce pas un peu choquant d'avoir une propriété dont
| > | la garantie d'existence n'est pas représentée dans l'interface
| > | de la classe - c'est une entorse à l'abstraction du type !?
| >
| > Non.
| >
| > Tout simplement, parce que tout ne se réduit pas à la syntaxe.
|
| Attends, entendons-nous bien : si tu nommes "lire" une fonction
| qui écrit, personne ne peut rien contre ça, nous sommes d'accord.
Ce qui ne fait que souligner que « sémantique » est la bonne porte.
| Mais il ne faut peut-être pas appeler sémantique tout ce qui échappe
| à la syntaxe (faute de quoi une syntaxe incomplète, donc fautive,
| serait toujours pardonnée).
c'est pourtant le cas. Du moins en ce qui concerne C++.
| peux-tu me dire quelle fonction de l'interface
| public de std:vector est susceptible d'échouer si les éléments sont
| non contigus ?
comme je te l'ai dit plus haut, C++ ne se réduit pas à la syntaxe.
Si tu veux comprendre et utiliser C++, il faut sonner à la porte
« sémantique ». Et si tu sonnes à cette porte, la réponse à ta
question est évidente.
| Je n'en vois aucune (sous réserve que l'*implémentation*
| en tienne compte, évidemment).
| et non du type défini par son interface public. En l'occurrence, je ne
| dirais pas "sémantique" pour implémentation ;-) Mais bon, je suis sûr
| que ce n'est pas ta position non plus...
je ne te le fais pas dire.
| Par conséquent, si l'interface public fonctionne même en l'absence
| de contiguïté, alors c'est que c'est une propriété de l'implémentation,
| La façon propre serait de prévoir, dans l'interface public,
| une fonction de lecture de n éléments ;
C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
| après quoi, si l'implémenteur
| décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| ta tournure, pour des raisons de simplicité et d'efficacité - mais je ne
| vois pas en quoi cela doit concerner l'appelant.
| Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| qu'une classe template du genre chaine d'objets nous mettrait d'accord
qu'est-ce qu'une chaîne d'objets sinon une suite ?
| tous les deux, et d'une façon élégante (tu aurais évidemment une
| strstream qui ferait exactement le boulot ci-dessus) - et pourquoi
est-elle
| manquante, cette classe ?!!
Parce qu'est est déjà là.
-- Gaby
« I am of the opinion that most people focus on syntax issues to the
detriment of type issues. The critical issues in the design of C++
were always those of type, ambiguity, and access control, not those
of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
"Alain Naigeon" writes:
| > | Pour ma part je te dirai que la notion de handle, rencontrée dans
| > | mes petites aventures, est une abstraction de l'adresse, non ?
| >
| > C'est une autre *forme* d'adresse -- pas directement celle du langage
| > C++, mais elle est bien une forme d'adresse.
|
| Le mot qui m'intéresse ici, c'est "autre" ; l'objet peut être déplacé
| sans que l'utilisateur ait à s'en soucier, puisque le handle lui permet
| de garder une référence valide.
| C'est donc une abstraction *supplémentaire*. Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas, mais c'est une adresse
| plus abstraite que la première, puisqu'elle reste valide dans des
| circonstances plus larges.
cela en fait moins une forme d'adresse ?
| Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas,
| [...]
| > Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
| > de ses éléments.
|
| Alors tu peux ré-écrire tes exemples sans utiliser '&', je suppose ?!
comment prends-tu l'adresse d'un objet sans utiliser « & » ?
Si std::vector<>::operator[] renvoie une reférence, c'est qu'on peut
prendre l'adresse de la chose sur laquelle la référence est renvoyée
comme je l'ai souligné dans mon message, « sémantique » n'est pas
une « poubelle » comme tu l'entends. « sémantique » est la source d'où
tout découle. La syntaxe n'est qu'un subalterne qui essaye de porter
-- autant qu'elle peut le message, je veux dire la sémantique. Mais la
clé, le trésor, la clé du trésor c'est la sémantique. En C++, elle ne
délègue pas tout à la syntaxe.
| Mais alors cela rend vain toute tentative de savoir ce qu'est une bonne
| syntaxe... à moins d'énoncer une tautologie = une syntaxe est bonne
| si elle minimise la sémantique.
je crois que ce que cela montre c'est le flou de « bonne »,
réduire les idées aux graffitis qui servent à en exprimer n'est pas
une manière efficace de les comprendre.
| mon argument - peut-être erronné, mais alors *en quoi* est-il erroné
| d'affirmer que :
| > | Par conséquent, si l'interface public fonctionne même en l'absence
| > | de contiguïté, alors c'est que c'est une propriété de
l'implémentation,
puisque j'ai répondu aux prémises qui précédaient ce « par conséquent »
était-il nécessaire de se prononcer/répéter sur la conclusion ?
| > | La façon propre serait de prévoir, dans l'interface public,
| > | une fonction de lecture de n éléments ;
| >
| > C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
|
| Mais non, ne nous énervons pas,
je ne m'énerve pas. Ou alors tu parlais de toi ? ;-/
std::vector<>::operator[] renvoie une référence, donc on peut en prendre
l'adresse -- cela fait partie de l'interface comme tu dirais.
L'utilisation de std::cin.read, c'est pour te montrer d'autres
combinaisons utiles avec le reste de la bibliothèque.
| > | après quoi, si l'implémenteur
| > | décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| > | ta tournure, pour des raisons de simplicité et d'efficacité - mais
je ne
| > | vois pas en quoi cela doit concerner l'appelant.
| > | Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| > | que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| > | qu'une classe template du genre chaine d'objets nous mettrait
d'accord
| >
| > qu'est-ce qu'une chaîne d'objets sinon une suite ?
|
| Précisément, dans le cas d'une chaîne la contiguïté est évidente,
Pourquoi est-ce plus évidente que dans le cas d'une suite ?
| et elle est constitutive de la classe ; tu ne peux pas "vider" un
caractère
nous parlons toujours bien de ta « chaîne d'objets » ?
| sans diminuer la longeur de la chaîne, par exemple ; alors que pour
| un vecteur tu peux mémoriser une place vide si tu prévois un objet
| spécial pour cela.
??? Peux-tu expliquer ?
| En dehors de cette différence (importante !) je ne
| vois guère de distinction entre une chaîne et un std::vector<char>
| mais là tu peux peut-être m'éclairer... c'est une vraie question,
sincère.
Quelle est exactement ta question ?
std::vector est une chaîne contigüe d'objets.
| > -- Gaby
| > « I am of the opinion that most people focus on syntax issues to the
| > detriment of type issues. The critical issues in the design of C++
| > were always those of type, ambiguity, and access control, not those
| > of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
|
| I'm of the opinion that a reference to a few famous people is possible
| only because they are many other ones that are neither as brilliant
| nor as famous... But, if you "kill" the latter ones, amongst whom will
| you remain famous ? :-)
probablement à la Santé ou Guantanamo, ça dépend.
"Alain Naigeon" <anaigeon@free.fr> writes:
| > | Pour ma part je te dirai que la notion de handle, rencontrée dans
| > | mes petites aventures, est une abstraction de l'adresse, non ?
| >
| > C'est une autre *forme* d'adresse -- pas directement celle du langage
| > C++, mais elle est bien une forme d'adresse.
|
| Le mot qui m'intéresse ici, c'est "autre" ; l'objet peut être déplacé
| sans que l'utilisateur ait à s'en soucier, puisque le handle lui permet
| de garder une référence valide.
| C'est donc une abstraction *supplémentaire*. Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas, mais c'est une adresse
| plus abstraite que la première, puisqu'elle reste valide dans des
| circonstances plus larges.
cela en fait moins une forme d'adresse ?
| Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas,
| [...]
| > Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
| > de ses éléments.
|
| Alors tu peux ré-écrire tes exemples sans utiliser '&', je suppose ?!
comment prends-tu l'adresse d'un objet sans utiliser « & » ?
Si std::vector<>::operator[] renvoie une reférence, c'est qu'on peut
prendre l'adresse de la chose sur laquelle la référence est renvoyée
comme je l'ai souligné dans mon message, « sémantique » n'est pas
une « poubelle » comme tu l'entends. « sémantique » est la source d'où
tout découle. La syntaxe n'est qu'un subalterne qui essaye de porter
-- autant qu'elle peut le message, je veux dire la sémantique. Mais la
clé, le trésor, la clé du trésor c'est la sémantique. En C++, elle ne
délègue pas tout à la syntaxe.
| Mais alors cela rend vain toute tentative de savoir ce qu'est une bonne
| syntaxe... à moins d'énoncer une tautologie = une syntaxe est bonne
| si elle minimise la sémantique.
je crois que ce que cela montre c'est le flou de « bonne »,
réduire les idées aux graffitis qui servent à en exprimer n'est pas
une manière efficace de les comprendre.
| mon argument - peut-être erronné, mais alors *en quoi* est-il erroné
| d'affirmer que :
| > | Par conséquent, si l'interface public fonctionne même en l'absence
| > | de contiguïté, alors c'est que c'est une propriété de
l'implémentation,
puisque j'ai répondu aux prémises qui précédaient ce « par conséquent »
était-il nécessaire de se prononcer/répéter sur la conclusion ?
| > | La façon propre serait de prévoir, dans l'interface public,
| > | une fonction de lecture de n éléments ;
| >
| > C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
|
| Mais non, ne nous énervons pas,
je ne m'énerve pas. Ou alors tu parlais de toi ? ;-/
std::vector<>::operator[] renvoie une référence, donc on peut en prendre
l'adresse -- cela fait partie de l'interface comme tu dirais.
L'utilisation de std::cin.read, c'est pour te montrer d'autres
combinaisons utiles avec le reste de la bibliothèque.
| > | après quoi, si l'implémenteur
| > | décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| > | ta tournure, pour des raisons de simplicité et d'efficacité - mais
je ne
| > | vois pas en quoi cela doit concerner l'appelant.
| > | Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| > | que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| > | qu'une classe template du genre chaine d'objets nous mettrait
d'accord
| >
| > qu'est-ce qu'une chaîne d'objets sinon une suite ?
|
| Précisément, dans le cas d'une chaîne la contiguïté est évidente,
Pourquoi est-ce plus évidente que dans le cas d'une suite ?
| et elle est constitutive de la classe ; tu ne peux pas "vider" un
caractère
nous parlons toujours bien de ta « chaîne d'objets » ?
| sans diminuer la longeur de la chaîne, par exemple ; alors que pour
| un vecteur tu peux mémoriser une place vide si tu prévois un objet
| spécial pour cela.
??? Peux-tu expliquer ?
| En dehors de cette différence (importante !) je ne
| vois guère de distinction entre une chaîne et un std::vector<char>
| mais là tu peux peut-être m'éclairer... c'est une vraie question,
sincère.
Quelle est exactement ta question ?
std::vector est une chaîne contigüe d'objets.
| > -- Gaby
| > « I am of the opinion that most people focus on syntax issues to the
| > detriment of type issues. The critical issues in the design of C++
| > were always those of type, ambiguity, and access control, not those
| > of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
|
| I'm of the opinion that a reference to a few famous people is possible
| only because they are many other ones that are neither as brilliant
| nor as famous... But, if you "kill" the latter ones, amongst whom will
| you remain famous ? :-)
probablement à la Santé ou Guantanamo, ça dépend.
"Alain Naigeon" writes:
| > | Pour ma part je te dirai que la notion de handle, rencontrée dans
| > | mes petites aventures, est une abstraction de l'adresse, non ?
| >
| > C'est une autre *forme* d'adresse -- pas directement celle du langage
| > C++, mais elle est bien une forme d'adresse.
|
| Le mot qui m'intéresse ici, c'est "autre" ; l'objet peut être déplacé
| sans que l'utilisateur ait à s'en soucier, puisque le handle lui permet
| de garder une référence valide.
| C'est donc une abstraction *supplémentaire*. Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas, mais c'est une adresse
| plus abstraite que la première, puisqu'elle reste valide dans des
| circonstances plus larges.
cela en fait moins une forme d'adresse ?
| Tu peux appeler cela
| une adresse si tu veux, ça ne me dérange pas,
| [...]
| > Sauf que l'interface de std::vector prévoit aussi de prendre l'adresse
| > de ses éléments.
|
| Alors tu peux ré-écrire tes exemples sans utiliser '&', je suppose ?!
comment prends-tu l'adresse d'un objet sans utiliser « & » ?
Si std::vector<>::operator[] renvoie une reférence, c'est qu'on peut
prendre l'adresse de la chose sur laquelle la référence est renvoyée
comme je l'ai souligné dans mon message, « sémantique » n'est pas
une « poubelle » comme tu l'entends. « sémantique » est la source d'où
tout découle. La syntaxe n'est qu'un subalterne qui essaye de porter
-- autant qu'elle peut le message, je veux dire la sémantique. Mais la
clé, le trésor, la clé du trésor c'est la sémantique. En C++, elle ne
délègue pas tout à la syntaxe.
| Mais alors cela rend vain toute tentative de savoir ce qu'est une bonne
| syntaxe... à moins d'énoncer une tautologie = une syntaxe est bonne
| si elle minimise la sémantique.
je crois que ce que cela montre c'est le flou de « bonne »,
réduire les idées aux graffitis qui servent à en exprimer n'est pas
une manière efficace de les comprendre.
| mon argument - peut-être erronné, mais alors *en quoi* est-il erroné
| d'affirmer que :
| > | Par conséquent, si l'interface public fonctionne même en l'absence
| > | de contiguïté, alors c'est que c'est une propriété de
l'implémentation,
puisque j'ai répondu aux prémises qui précédaient ce « par conséquent »
était-il nécessaire de se prononcer/répéter sur la conclusion ?
| > | La façon propre serait de prévoir, dans l'interface public,
| > | une fonction de lecture de n éléments ;
| >
| > C'ets fait. c'est juste que tu refuses de la voir et de l'admettre.
|
| Mais non, ne nous énervons pas,
je ne m'énerve pas. Ou alors tu parlais de toi ? ;-/
std::vector<>::operator[] renvoie une référence, donc on peut en prendre
l'adresse -- cela fait partie de l'interface comme tu dirais.
L'utilisation de std::cin.read, c'est pour te montrer d'autres
combinaisons utiles avec le reste de la bibliothèque.
| > | après quoi, si l'implémenteur
| > | décide qu'il y a contiguïté, il peut implémenter cette fonction avec
| > | ta tournure, pour des raisons de simplicité et d'efficacité - mais
je ne
| > | vois pas en quoi cela doit concerner l'appelant.
| > | Sans compter que, dans le cas que tu donnes en exemple, ça prouve
| > | que la librairie manque de hauteur de vue (AMHA) : il est manifeste
| > | qu'une classe template du genre chaine d'objets nous mettrait
d'accord
| >
| > qu'est-ce qu'une chaîne d'objets sinon une suite ?
|
| Précisément, dans le cas d'une chaîne la contiguïté est évidente,
Pourquoi est-ce plus évidente que dans le cas d'une suite ?
| et elle est constitutive de la classe ; tu ne peux pas "vider" un
caractère
nous parlons toujours bien de ta « chaîne d'objets » ?
| sans diminuer la longeur de la chaîne, par exemple ; alors que pour
| un vecteur tu peux mémoriser une place vide si tu prévois un objet
| spécial pour cela.
??? Peux-tu expliquer ?
| En dehors de cette différence (importante !) je ne
| vois guère de distinction entre une chaîne et un std::vector<char>
| mais là tu peux peut-être m'éclairer... c'est une vraie question,
sincère.
Quelle est exactement ta question ?
std::vector est une chaîne contigüe d'objets.
| > -- Gaby
| > « I am of the opinion that most people focus on syntax issues to the
| > detriment of type issues. The critical issues in the design of C++
| > were always those of type, ambiguity, and access control, not those
| > of syntax. » -- B. Stroustrup in "Design and Evolution of C++"
|
| I'm of the opinion that a reference to a few famous people is possible
| only because they are many other ones that are neither as brilliant
| nor as famous... But, if you "kill" the latter ones, amongst whom will
| you remain famous ? :-)
probablement à la Santé ou Guantanamo, ça dépend.
