De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes:
|
| > De sa propre bouche, il a apprit beaucoup de choses de Ada, en
| > particulier de ne pas copier Ada. De plus, selon ses propres
| > termes, lorsqu'il a proposé les paramètres « non-type », il a
| > rencontré *beaucoup* de résistance.
|
| La conjonction de ces deux phrases est amusante: Ada a des paramètres non
| types depuis au moins Ada83. Je viens d'aller vérifier car je me demandais
| si ma mémoire était bonne.
Je n'impliquais pas que BS ne savait pas que les paramètres « non-types »
existaient avant (je ne crois pas qu'il revendique avoir inventé cela).
Ce qu'il ne voulait pas faire comme Ada -- entre autres -- c'est le
modèle d'instantiation. Alex Stepanov (entre autres) avait fait un
lobbying très fort pour que les instantiations soient explicites. Si BS
s'était laissé convaincre, on n'aurait probablement pas la STL --
ironiquement :-)
Je ne connais pas très bien Ada, mais l'un des problèmes avec les
paramètres non-types, c'est la conjonction de déduction d'arguments
template et la réduction de leurs valeurs. (Ce qui a été la source
d'une discussion fameuse entre BS et Dave MacQueen).
Considère
template<int N> struct X { };
template<int I, int J> X<I+J> f(X<I>, X<J>);
template<int I, int J> X<I-J> f(X<I>, X<J>);
La question est comment distinguer ces deux functions, en particulier
lorsqu'elles ont des types qui coincident (imagine les deux fonctions
sont dans des unités de traduction différentes). Selon ce que j'ai
compris, BS proposait le modèle actuel, mais d'autres soutenaient que
2+3 ne devrait pas être la même chose que 5.
Est-ce que Ada a des
problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > De sa propre bouche, il a apprit beaucoup de choses de Ada, en
| > particulier de ne pas copier Ada. De plus, selon ses propres
| > termes, lorsqu'il a proposé les paramètres « non-type », il a
| > rencontré *beaucoup* de résistance.
|
| La conjonction de ces deux phrases est amusante: Ada a des paramètres non
| types depuis au moins Ada83. Je viens d'aller vérifier car je me demandais
| si ma mémoire était bonne.
Je n'impliquais pas que BS ne savait pas que les paramètres « non-types »
existaient avant (je ne crois pas qu'il revendique avoir inventé cela).
Ce qu'il ne voulait pas faire comme Ada -- entre autres -- c'est le
modèle d'instantiation. Alex Stepanov (entre autres) avait fait un
lobbying très fort pour que les instantiations soient explicites. Si BS
s'était laissé convaincre, on n'aurait probablement pas la STL --
ironiquement :-)
Je ne connais pas très bien Ada, mais l'un des problèmes avec les
paramètres non-types, c'est la conjonction de déduction d'arguments
template et la réduction de leurs valeurs. (Ce qui a été la source
d'une discussion fameuse entre BS et Dave MacQueen).
Considère
template<int N> struct X { };
template<int I, int J> X<I+J> f(X<I>, X<J>);
template<int I, int J> X<I-J> f(X<I>, X<J>);
La question est comment distinguer ces deux functions, en particulier
lorsqu'elles ont des types qui coincident (imagine les deux fonctions
sont dans des unités de traduction différentes). Selon ce que j'ai
compris, BS proposait le modèle actuel, mais d'autres soutenaient que
2+3 ne devrait pas être la même chose que 5.
Est-ce que Ada a des
problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes:
|
| > De sa propre bouche, il a apprit beaucoup de choses de Ada, en
| > particulier de ne pas copier Ada. De plus, selon ses propres
| > termes, lorsqu'il a proposé les paramètres « non-type », il a
| > rencontré *beaucoup* de résistance.
|
| La conjonction de ces deux phrases est amusante: Ada a des paramètres non
| types depuis au moins Ada83. Je viens d'aller vérifier car je me demandais
| si ma mémoire était bonne.
Je n'impliquais pas que BS ne savait pas que les paramètres « non-types »
existaient avant (je ne crois pas qu'il revendique avoir inventé cela).
Ce qu'il ne voulait pas faire comme Ada -- entre autres -- c'est le
modèle d'instantiation. Alex Stepanov (entre autres) avait fait un
lobbying très fort pour que les instantiations soient explicites. Si BS
s'était laissé convaincre, on n'aurait probablement pas la STL --
ironiquement :-)
Je ne connais pas très bien Ada, mais l'un des problèmes avec les
paramètres non-types, c'est la conjonction de déduction d'arguments
template et la réduction de leurs valeurs. (Ce qui a été la source
d'une discussion fameuse entre BS et Dave MacQueen).
Considère
template<int N> struct X { };
template<int I, int J> X<I+J> f(X<I>, X<J>);
template<int I, int J> X<I-J> f(X<I>, X<J>);
La question est comment distinguer ces deux functions, en particulier
lorsqu'elles ont des types qui coincident (imagine les deux fonctions
sont dans des unités de traduction différentes). Selon ce que j'ai
compris, BS proposait le modèle actuel, mais d'autres soutenaient que
2+3 ne devrait pas être la même chose que 5.
Est-ce que Ada a des
problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
Jean-Marc Bourguet writes:
[...]
| > Je ne connais pas très bien Ada, mais l'un des problèmes avec les
| > paramètres non-types, c'est la conjonction de déduction d'arguments
| > template et la réduction de leurs valeurs. (Ce qui a été la source
| > d'une discussion fameuse entre BS et Dave MacQueen).
| >
| > Considère
| >
| > template<int N> struct X { };
| >
| > template<int I, int J> X<I+J> f(X<I>, X<J>);
| > template<int I, int J> X<I-J> f(X<I>, X<J>);
| >
| > La question est comment distinguer ces deux functions, en particulier
| > lorsqu'elles ont des types qui coincident (imagine les deux fonctions
| > sont dans des unités de traduction différentes). Selon ce que j'ai
| > compris, BS proposait le modèle actuel, mais d'autres soutenaient que
| > 2+3 ne devrait pas être la même chose que 5.
|
| Je me demande quel modèle ils avaient.
Ben "2+3" et "5" ne designent pas la même valeur -- ce qui veut dire
qu'on ne peut pas faire des joujoux avec des « meta-programes » :-)
| > Est-ce que Ada a des
| > problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
|
| Le problème ne se pose pas: toutes les "spécialisations" sont explicites et
| nommées. L'effet est un peu comme si en C++ tu n'avais qu'un paramètre
| template et que tu emploies systématiquement des traits, que tu ais besoin
| de plusieurs paramètres ou pas. Tu peux donc instancier plusieurs fois
| avec les mêmes paramètres en donnant des noms différents; des choses comme
| les membres statiques ne sont pas partagées.
OK.
L'un des problèmes qui se posent pour C++, c'est que ce passe-t-il
avec
X<0> x, y;
f(x, y);
les deux instantiations donnent I=0 et J=0 -- donc, ont même type.
Si les deux déclarations se trouvent dans la même unité de traduction,
alors la résolution de surcharge dit qu'il y a ambiguité.
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > Je ne connais pas très bien Ada, mais l'un des problèmes avec les
| > paramètres non-types, c'est la conjonction de déduction d'arguments
| > template et la réduction de leurs valeurs. (Ce qui a été la source
| > d'une discussion fameuse entre BS et Dave MacQueen).
| >
| > Considère
| >
| > template<int N> struct X { };
| >
| > template<int I, int J> X<I+J> f(X<I>, X<J>);
| > template<int I, int J> X<I-J> f(X<I>, X<J>);
| >
| > La question est comment distinguer ces deux functions, en particulier
| > lorsqu'elles ont des types qui coincident (imagine les deux fonctions
| > sont dans des unités de traduction différentes). Selon ce que j'ai
| > compris, BS proposait le modèle actuel, mais d'autres soutenaient que
| > 2+3 ne devrait pas être la même chose que 5.
|
| Je me demande quel modèle ils avaient.
Ben "2+3" et "5" ne designent pas la même valeur -- ce qui veut dire
qu'on ne peut pas faire des joujoux avec des « meta-programes » :-)
| > Est-ce que Ada a des
| > problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
|
| Le problème ne se pose pas: toutes les "spécialisations" sont explicites et
| nommées. L'effet est un peu comme si en C++ tu n'avais qu'un paramètre
| template et que tu emploies systématiquement des traits, que tu ais besoin
| de plusieurs paramètres ou pas. Tu peux donc instancier plusieurs fois
| avec les mêmes paramètres en donnant des noms différents; des choses comme
| les membres statiques ne sont pas partagées.
OK.
L'un des problèmes qui se posent pour C++, c'est que ce passe-t-il
avec
X<0> x, y;
f(x, y);
les deux instantiations donnent I=0 et J=0 -- donc, ont même type.
Si les deux déclarations se trouvent dans la même unité de traduction,
alors la résolution de surcharge dit qu'il y a ambiguité.
Jean-Marc Bourguet writes:
[...]
| > Je ne connais pas très bien Ada, mais l'un des problèmes avec les
| > paramètres non-types, c'est la conjonction de déduction d'arguments
| > template et la réduction de leurs valeurs. (Ce qui a été la source
| > d'une discussion fameuse entre BS et Dave MacQueen).
| >
| > Considère
| >
| > template<int N> struct X { };
| >
| > template<int I, int J> X<I+J> f(X<I>, X<J>);
| > template<int I, int J> X<I-J> f(X<I>, X<J>);
| >
| > La question est comment distinguer ces deux functions, en particulier
| > lorsqu'elles ont des types qui coincident (imagine les deux fonctions
| > sont dans des unités de traduction différentes). Selon ce que j'ai
| > compris, BS proposait le modèle actuel, mais d'autres soutenaient que
| > 2+3 ne devrait pas être la même chose que 5.
|
| Je me demande quel modèle ils avaient.
Ben "2+3" et "5" ne designent pas la même valeur -- ce qui veut dire
qu'on ne peut pas faire des joujoux avec des « meta-programes » :-)
| > Est-ce que Ada a des
| > problèmes similaires ? Si oui, comment est-ce que c'est résolu ?
|
| Le problème ne se pose pas: toutes les "spécialisations" sont explicites et
| nommées. L'effet est un peu comme si en C++ tu n'avais qu'un paramètre
| template et que tu emploies systématiquement des traits, que tu ais besoin
| de plusieurs paramètres ou pas. Tu peux donc instancier plusieurs fois
| avec les mêmes paramètres en donnant des noms différents; des choses comme
| les membres statiques ne sont pas partagées.
OK.
L'un des problèmes qui se posent pour C++, c'est que ce passe-t-il
avec
X<0> x, y;
f(x, y);
les deux instantiations donnent I=0 et J=0 -- donc, ont même type.
Si les deux déclarations se trouvent dans la même unité de traduction,
alors la résolution de surcharge dit qu'il y a ambiguité.
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Illustration de "tout correctif d'un bug ajoute un bug".
Marc Boyer
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Illustration de "tout correctif d'un bug ajoute un bug".
Marc Boyer
Non sommes bien d'accord sur ce point.
Lire: Nous somme bien d'accord sur ce point
Illustration de "tout correctif d'un bug ajoute un bug".
Marc Boyer
