drkm writes:
| Gabriel Dos Reis writes:
| > Fabien LE LEZ writes:
| > | Euh... j'ai très nettement l'impression que tu es d'accord
| > | avec moi, mais que ton subconscient refuse de l'admettre ;-)
| > Ã ta place, je me retiendrais de m'aventurer sur ce terrain
| > hasardeux.
| Quel terrain hasardeux ?
celui que tu es en train d'emprunter.
drkm <darkman_spam@yahoo.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > Fabien LE LEZ <gramster@gramster.com> writes:
| > | Euh... j'ai très nettement l'impression que tu es d'accord
| > | avec moi, mais que ton subconscient refuse de l'admettre ;-)
| > Ã ta place, je me retiendrais de m'aventurer sur ce terrain
| > hasardeux.
| Quel terrain hasardeux ?
celui que tu es en train d'emprunter.
drkm writes:
| Gabriel Dos Reis writes:
| > Fabien LE LEZ writes:
| > | Euh... j'ai très nettement l'impression que tu es d'accord
| > | avec moi, mais que ton subconscient refuse de l'admettre ;-)
| > Ã ta place, je me retiendrais de m'aventurer sur ce terrain
| > hasardeux.
| Quel terrain hasardeux ?
celui que tu es en train d'emprunter.
(Arnaud Debaene) writes:
| > D'un autre côté je me demande moi-même comment
| > représenter une telle propriété... après tout, cela concerne
| > 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 ?
| Tout simplement parce qu'on peut vouloir accéder aux éléments du
| vector autrement que par un itérateur. L'interface de vector propose
| at et operator[].
Tout à fait exact. Et la question qui se posait était :
Si i et j sont des entiers dans les bornes d'un std::vector<> v,
l'égalité suivante a-t-elle lieu ?
&v[i] == &v[j] + (i - j) // ou &v.at(i) == &v.at(j) + (i - j)
adebaene@club-internet.fr (Arnaud Debaene) writes:
| > D'un autre côté je me demande moi-même comment
| > représenter une telle propriété... après tout, cela concerne
| > 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 ?
| Tout simplement parce qu'on peut vouloir accéder aux éléments du
| vector autrement que par un itérateur. L'interface de vector propose
| at et operator[].
Tout à fait exact. Et la question qui se posait était :
Si i et j sont des entiers dans les bornes d'un std::vector<> v,
l'égalité suivante a-t-elle lieu ?
&v[i] == &v[j] + (i - j) // ou &v.at(i) == &v.at(j) + (i - j)
(Arnaud Debaene) writes:
| > D'un autre côté je me demande moi-même comment
| > représenter une telle propriété... après tout, cela concerne
| > 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 ?
| Tout simplement parce qu'on peut vouloir accéder aux éléments du
| vector autrement que par un itérateur. L'interface de vector propose
| at et operator[].
Tout à fait exact. Et la question qui se posait était :
Si i et j sont des entiers dans les bornes d'un std::vector<> v,
l'égalité suivante a-t-elle lieu ?
&v[i] == &v[j] + (i - j) // ou &v.at(i) == &v.at(j) + (i - j)
"Alain Naigeon" writes:
| > Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
| > l'abstraction de type et à la modélisation objet (y'a qu'à voir le
| > troll que cette question vient - une fois de plus - de déclencher). On
| > peut considérer cela comme une concession à la pratique existante et à
| > l'utilisabilité de vector, personnellement ce ne me choque pas du
| > tout.
|
| Je respecte ton choix, entre le pour et le contre !
| Pour moi C++ serait bien plus séduisant et sûr s'il
| larguait ce boulet de compatibilité avec cet espèce
| d'assembleur amélioré qu'on appelle C.
Pour quoi faire après ?
"Alain Naigeon" <anaigeon@free.fr> writes:
| > Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
| > l'abstraction de type et à la modélisation objet (y'a qu'à voir le
| > troll que cette question vient - une fois de plus - de déclencher). On
| > peut considérer cela comme une concession à la pratique existante et à
| > l'utilisabilité de vector, personnellement ce ne me choque pas du
| > tout.
|
| Je respecte ton choix, entre le pour et le contre !
| Pour moi C++ serait bien plus séduisant et sûr s'il
| larguait ce boulet de compatibilité avec cet espèce
| d'assembleur amélioré qu'on appelle C.
Pour quoi faire après ?
"Alain Naigeon" writes:
| > Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
| > l'abstraction de type et à la modélisation objet (y'a qu'à voir le
| > troll que cette question vient - une fois de plus - de déclencher). On
| > peut considérer cela comme une concession à la pratique existante et à
| > l'utilisabilité de vector, personnellement ce ne me choque pas du
| > tout.
|
| Je respecte ton choix, entre le pour et le contre !
| Pour moi C++ serait bien plus séduisant et sûr s'il
| larguait ce boulet de compatibilité avec cet espèce
| d'assembleur amélioré qu'on appelle C.
Pour quoi faire après ?
Juste ceci : le procès d'intention peut se produire quand on entend
les propos de l'autre à la lumière de ses propres idées, sans pouvoir
s'en abstraire.
C'est une faute intellectuelle (encourue par chacun
de nous). La diffamation c'est une intention de nuire, c'est très
différent !
Juste ceci : le procès d'intention peut se produire quand on entend
les propos de l'autre à la lumière de ses propres idées, sans pouvoir
s'en abstraire.
C'est une faute intellectuelle (encourue par chacun
de nous). La diffamation c'est une intention de nuire, c'est très
différent !
Juste ceci : le procès d'intention peut se produire quand on entend
les propos de l'autre à la lumière de ses propres idées, sans pouvoir
s'en abstraire.
C'est une faute intellectuelle (encourue par chacun
de nous). La diffamation c'est une intention de nuire, c'est très
différent !
"Arnaud Debaene" a écrit dans le message news:"Alain Naigeon" wrote in message
news:<3f107896$0$10882$...
De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
l'abstraction de type et à la modélisation objet (y'a qu'à voir le
troll que cette question vient - une fois de plus - de déclencher). On
peut considérer cela comme une concession à la pratique existante et à
l'utilisabilité de vector, personnellement ce ne me choque pas du
tout.
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
D'un autre côté je me demande moi-même comment
représenter une telle propriété... après tout, cela concerne
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 ?
Tout simplement parce qu'on peut vouloir accéder aux éléments du
vector autrement que par un itérateur. L'interface de vector propose
at et operator[].
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message news:
16a4a8c7.0307150125.7ea848db@posting.google.com...
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f107896$0$10882$626a54ce@news.free.fr>...
De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
l'abstraction de type et à la modélisation objet (y'a qu'à voir le
troll que cette question vient - une fois de plus - de déclencher). On
peut considérer cela comme une concession à la pratique existante et à
l'utilisabilité de vector, personnellement ce ne me choque pas du
tout.
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
D'un autre côté je me demande moi-même comment
représenter une telle propriété... après tout, cela concerne
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 ?
Tout simplement parce qu'on peut vouloir accéder aux éléments du
vector autrement que par un itérateur. L'interface de vector propose
at et operator[].
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
"Arnaud Debaene" a écrit dans le message news:"Alain Naigeon" wrote in message
news:<3f107896$0$10882$...
De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
Beaucoup de gens considèrent en effet qu'il s'agit d'une entorse à
l'abstraction de type et à la modélisation objet (y'a qu'à voir le
troll que cette question vient - une fois de plus - de déclencher). On
peut considérer cela comme une concession à la pratique existante et à
l'utilisabilité de vector, personnellement ce ne me choque pas du
tout.
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
D'un autre côté je me demande moi-même comment
représenter une telle propriété... après tout, cela concerne
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 ?
Tout simplement parce qu'on peut vouloir accéder aux éléments du
vector autrement que par un itérateur. L'interface de vector propose
at et operator[].
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
Une première tentative de programmation objet ?
administration. Si on me déconseille vivement l'usage d'une tournure,
d'un type, etc, j'ai envie que le langage m'interdise, à terme, de les
utiliser - et ceci d'autant plus que les auteurs de l'interdiction ont plus
de bon sens ;-)
Je comprends mal une exigence de compatibilité avec
un existant jugé mauvais.
Une première tentative de programmation objet ?
administration. Si on me déconseille vivement l'usage d'une tournure,
d'un type, etc, j'ai envie que le langage m'interdise, à terme, de les
utiliser - et ceci d'autant plus que les auteurs de l'interdiction ont plus
de bon sens ;-)
Je comprends mal une exigence de compatibilité avec
un existant jugé mauvais.
Une première tentative de programmation objet ?
administration. Si on me déconseille vivement l'usage d'une tournure,
d'un type, etc, j'ai envie que le langage m'interdise, à terme, de les
utiliser - et ceci d'autant plus que les auteurs de l'interdiction ont plus
de bon sens ;-)
Je comprends mal une exigence de compatibilité avec
un existant jugé mauvais.
Gabriel Dos Reis wrote:Et puis, de toute façon quelque source qu'on puisse citer, James
niera.
Puisque j'essaye de suivre le débat, puis-je exposer la compréhension
que j'en ai afin d'être certain de n'avoir rien raté ?
Selon James, personne n'a pensé explicitement, avant l'adoption
définitive de la norme, que la mémoire d'un std::vector devait être
contigüe et pas autrement.
C'est en tout cas une façon d'interprêter ses propos. Si c'est bien
ça qu'il veut dire, effectivement, c'est de la diffamation ou, en tout
cas, du procès d'intention (au sens propre). C'est je crois ce qui est
choquant dans les propos de James.
Mais j'ai l'impression qu'il y a une autre interprétation, peut-être
plus proche de ce qu'il veut dire, mais moins choquante. C'est de
comprendre que le comité, en tant que groupe d'humain, a eu
l'intention que la mémoire des std::vector soit contigüe. En ce cas,
celà signifierait que cette intention devait êtret connue et partagée
de tous les membres du comité, ce qui n'est évidemment pas vrai (James
étant un contre-exemple). Mais James semble tout de même dénier les
intentions explicites si celles-ci n'ont pas eu de manifestation
publique (et il est vrai que si personne d'exprime ses intentions, on
ne peut prouver qu'elles ont existé).
Gabriel Dos Reis wrote:
Et puis, de toute façon quelque source qu'on puisse citer, James
niera.
Puisque j'essaye de suivre le débat, puis-je exposer la compréhension
que j'en ai afin d'être certain de n'avoir rien raté ?
Selon James, personne n'a pensé explicitement, avant l'adoption
définitive de la norme, que la mémoire d'un std::vector devait être
contigüe et pas autrement.
C'est en tout cas une façon d'interprêter ses propos. Si c'est bien
ça qu'il veut dire, effectivement, c'est de la diffamation ou, en tout
cas, du procès d'intention (au sens propre). C'est je crois ce qui est
choquant dans les propos de James.
Mais j'ai l'impression qu'il y a une autre interprétation, peut-être
plus proche de ce qu'il veut dire, mais moins choquante. C'est de
comprendre que le comité, en tant que groupe d'humain, a eu
l'intention que la mémoire des std::vector soit contigüe. En ce cas,
celà signifierait que cette intention devait êtret connue et partagée
de tous les membres du comité, ce qui n'est évidemment pas vrai (James
étant un contre-exemple). Mais James semble tout de même dénier les
intentions explicites si celles-ci n'ont pas eu de manifestation
publique (et il est vrai que si personne d'exprime ses intentions, on
ne peut prouver qu'elles ont existé).
Gabriel Dos Reis wrote:Et puis, de toute façon quelque source qu'on puisse citer, James
niera.
Puisque j'essaye de suivre le débat, puis-je exposer la compréhension
que j'en ai afin d'être certain de n'avoir rien raté ?
Selon James, personne n'a pensé explicitement, avant l'adoption
définitive de la norme, que la mémoire d'un std::vector devait être
contigüe et pas autrement.
C'est en tout cas une façon d'interprêter ses propos. Si c'est bien
ça qu'il veut dire, effectivement, c'est de la diffamation ou, en tout
cas, du procès d'intention (au sens propre). C'est je crois ce qui est
choquant dans les propos de James.
Mais j'ai l'impression qu'il y a une autre interprétation, peut-être
plus proche de ce qu'il veut dire, mais moins choquante. C'est de
comprendre que le comité, en tant que groupe d'humain, a eu
l'intention que la mémoire des std::vector soit contigüe. En ce cas,
celà signifierait que cette intention devait êtret connue et partagée
de tous les membres du comité, ce qui n'est évidemment pas vrai (James
étant un contre-exemple). Mais James semble tout de même dénier les
intentions explicites si celles-ci n'ont pas eu de manifestation
publique (et il est vrai que si personne d'exprime ses intentions, on
ne peut prouver qu'elles ont existé).
"Alain Naigeon" wrote in message news:<3f145a08$0$26591$..."Arnaud Debaene" a écrit dans le message news:"Alain Naigeon" wrote in message
news:<3f107896$0$10882$...De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
t'elle dans ton abstraction si tu n'en tiens pas compte?
Au passage, utiliser une implémentation contigue est à ma connaissance
la seule façon de garantir les "requirements" (traduction?) de vector
en ce qui concerne les performances, à savoir accès en temps constant,
recherche en O(N), ....
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
Ca c'est ton point de vue de programmeur objet dans un monde idéal et
parfait. Dans la réalité, il est certain que C++ ne connaitrait pas le
succès qu'il a aujourd'hui sans la compatibilité avec le C.
C'est justement la force du C++ d'être multi-paradigme et de permettre
aussi bien de faire des abstractions objet de haut-niveau que de
s'interfacer nativement avec le système ou de bidouiller des registres
hardware à la main.
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
Voir la remarque de Gaby : int toto[5]; Rien n'indique la contiguité,
pourtant tu pars bien du principe qu'elle existe.
"Alain Naigeon" <anaigeon@free.fr> wrote in message news:<3f145a08$0$26591$626a54ce@news.free.fr>...
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message news:
16a4a8c7.0307150125.7ea848db@posting.google.com...
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f107896$0$10882$626a54ce@news.free.fr>...
De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
t'elle dans ton abstraction si tu n'en tiens pas compte?
Au passage, utiliser une implémentation contigue est à ma connaissance
la seule façon de garantir les "requirements" (traduction?) de vector
en ce qui concerne les performances, à savoir accès en temps constant,
recherche en O(N), ....
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
Ca c'est ton point de vue de programmeur objet dans un monde idéal et
parfait. Dans la réalité, il est certain que C++ ne connaitrait pas le
succès qu'il a aujourd'hui sans la compatibilité avec le C.
C'est justement la force du C++ d'être multi-paradigme et de permettre
aussi bien de faire des abstractions objet de haut-niveau que de
s'interfacer nativement avec le système ou de bidouiller des registres
hardware à la main.
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
Voir la remarque de Gaby : int toto[5]; Rien n'indique la contiguité,
pourtant tu pars bien du principe qu'elle existe.
"Alain Naigeon" wrote in message news:<3f145a08$0$26591$..."Arnaud Debaene" a écrit dans le message news:"Alain Naigeon" wrote in message
news:<3f107896$0$10882$...De mon point de vue, la compatibilité de std::vector avec des
interfaces "C" du type read (Posix) est une justification suffisante.
Cela dépend du prix à payer...
??? Quel "prix"? En quoi cette obligation de continuité de pénalise
t'elle dans ton abstraction si tu n'en tiens pas compte?
Au passage, utiliser une implémentation contigue est à ma connaissance
la seule façon de garantir les "requirements" (traduction?) de vector
en ce qui concerne les performances, à savoir accès en temps constant,
recherche en O(N), ....
Je respecte ton choix, entre le pour et le contre !
Pour moi C++ serait bien plus séduisant et sûr s'il
larguait ce boulet de compatibilité avec cet espèce
d'assembleur amélioré qu'on appelle C.
Ca c'est ton point de vue de programmeur objet dans un monde idéal et
parfait. Dans la réalité, il est certain que C++ ne connaitrait pas le
succès qu'il a aujourd'hui sans la compatibilité avec le C.
C'est justement la force du C++ d'être multi-paradigme et de permettre
aussi bien de faire des abstractions objet de haut-niveau que de
s'interfacer nativement avec le système ou de bidouiller des registres
hardware à la main.
Ben oui mais si on parle d'interface et non d'implémentation,
ni at ni operateur[] ne représentent une contiguïté, qui ne peut
de toute façon être exprimée avec un seul indice.
Voir la remarque de Gaby : int toto[5]; Rien n'indique la contiguité,
pourtant tu pars bien du principe qu'elle existe.
