Il y a l'air d'avoir un papier assez gros sur les concepts. Il va falloir que je lise ça à tête reposée...
-- Loïc
Gabriel Dos Reis
Loïc Joly writes:
| Gabriel Dos Reis wrote: | > Pour information : | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | falloir que je lise ça à tête reposée...
Yep :-)
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Pour information :
| >
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01
|
| Il y a l'air d'avoir un papier assez gros sur les concepts. Il va
| falloir que je lise ça à tête reposée...
| Gabriel Dos Reis wrote: | > Pour information : | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | falloir que je lise ça à tête reposée...
Yep :-)
-- Gaby
Loïc Joly
Gabriel Dos Reis wrote:
Loïc Joly writes:
| Gabriel Dos Reis wrote: | > Pour information : | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | falloir que je lise ça à tête reposée...
Yep :-)
Quelques remarques / questions :
1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La présence d'une clause where ne suffit elle pas ? La seule différence que j'y vois, c'est la clause sur les contraintes implicites, et encore, ça pourrait se réparer...
2/ Les contraintes implicites me semblent étranges : Le but initial n'était-il pas d'expliciter les contraintes ?
De plus, à ce que j'ai compris, les contraintes implicites se basent uniquement sur la signature de la fonction, ce qui me semble contre intuitif. Par exemple, si j'ai bien compris :
template<typeid U> void foo(U &u) { vector<U> v; // Pas de contrainte implicite : Le code ne compile pas }
3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue de mettre une implémentation par défaut dans les pseudo signature d'un concept.
4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls éléments qui sont à notre disposition, à savoir, les pseudo signatures, les type associés, les containtes imbriquées et les égalités de type.
Je pense qu'ajouter quelques concepts codés en dur pours lesquels le compilateur vérifie automatiquement si un type le vérifie pourrait corriger ça. Je pense en particulier au moyen d'exprimer qu'un type est un POD, ou un aggregat, que deux types sont layout-compatible, ou encore d'autres concepts qui n'apparaissent pas dans la norme, parce qu'on ne savait pas trop quoi en faire (le fait qu'un type pourrait être memcpy()able si on relachait la notion de POD, voir message et le thread qui avait suivi.).
-- Loïc
Gabriel Dos Reis wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Pour information :
| >
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01
|
| Il y a l'air d'avoir un papier assez gros sur les concepts. Il va
| falloir que je lise ça à tête reposée...
Yep :-)
Quelques remarques / questions :
1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La
présence d'une clause where ne suffit elle pas ? La seule différence que
j'y vois, c'est la clause sur les contraintes implicites, et encore, ça
pourrait se réparer...
2/ Les contraintes implicites me semblent étranges : Le but initial
n'était-il pas d'expliciter les contraintes ?
De plus, à ce que j'ai compris, les contraintes implicites se basent
uniquement sur la signature de la fonction, ce qui me semble contre
intuitif. Par exemple, si j'ai bien compris :
template<typeid U>
void foo(U &u)
{
vector<U> v; // Pas de contrainte implicite : Le code ne compile pas
}
3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue
de mettre une implémentation par défaut dans les pseudo signature d'un
concept.
4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls
éléments qui sont à notre disposition, à savoir, les pseudo signatures,
les type associés, les containtes imbriquées et les égalités de type.
Je pense qu'ajouter quelques concepts codés en dur pours lesquels le
compilateur vérifie automatiquement si un type le vérifie pourrait
corriger ça. Je pense en particulier au moyen d'exprimer qu'un type est
un POD, ou un aggregat, que deux types sont layout-compatible, ou encore
d'autres concepts qui n'apparaissent pas dans la norme, parce qu'on ne
savait pas trop quoi en faire (le fait qu'un type pourrait être
memcpy()able si on relachait la notion de POD, voir message
<987fd52d.0204030132.13e9eddd@posting.google.com> et le thread qui avait
suivi.).
| Gabriel Dos Reis wrote: | > Pour information : | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | falloir que je lise ça à tête reposée...
Yep :-)
Quelques remarques / questions :
1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La présence d'une clause where ne suffit elle pas ? La seule différence que j'y vois, c'est la clause sur les contraintes implicites, et encore, ça pourrait se réparer...
2/ Les contraintes implicites me semblent étranges : Le but initial n'était-il pas d'expliciter les contraintes ?
De plus, à ce que j'ai compris, les contraintes implicites se basent uniquement sur la signature de la fonction, ce qui me semble contre intuitif. Par exemple, si j'ai bien compris :
template<typeid U> void foo(U &u) { vector<U> v; // Pas de contrainte implicite : Le code ne compile pas }
3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue de mettre une implémentation par défaut dans les pseudo signature d'un concept.
4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls éléments qui sont à notre disposition, à savoir, les pseudo signatures, les type associés, les containtes imbriquées et les égalités de type.
Je pense qu'ajouter quelques concepts codés en dur pours lesquels le compilateur vérifie automatiquement si un type le vérifie pourrait corriger ça. Je pense en particulier au moyen d'exprimer qu'un type est un POD, ou un aggregat, que deux types sont layout-compatible, ou encore d'autres concepts qui n'apparaissent pas dans la norme, parce qu'on ne savait pas trop quoi en faire (le fait qu'un type pourrait être memcpy()able si on relachait la notion de POD, voir message et le thread qui avait suivi.).
-- Loïc
Gabriel Dos Reis
Loïc Joly writes:
| Gabriel Dos Reis wrote: | > Loïc Joly writes: | > | Gabriel Dos Reis wrote: | > | > Pour information : | > | > | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | > | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | > | falloir que je lise ça à tête reposée... | > Yep :-) | | Quelques remarques / questions :
J'avais moi-même reçu le papier seulement quelques jours avant qu'ils l'aient envoyé pour la mailing. Je suis toujours en train de le décortiquer (BS aussi). C'est un bon "follow-up" aux papiers d'il y a deux ans. Je prends note de tes remarques ; dès que j'ai fini d'étudier le papier, je répondrais plus sérieusement à ton message.
(il y a des choses que j'aime et des choses que j'aime pas dedans mais bon c'est une base).
| 1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La
Moi non plus.
| présence d'une clause where ne suffit elle pas ? La seule différence | que j'y vois, c'est la clause sur les contraintes implicites, et | encore, ça pourrait se réparer...
en fait je crois qu'il y a globalement deux écoles : celle de Indiana et celle de College Station.
À College Station, nous avons essayons de voir jusqu'où on peut pousser l'approche sans « where clause ». On a fait pareil avec l'approche avec la « where clause ». On a vu qu'il y a des chsoes qui s'écrivent plus élégamment ou naturellement avec les deux ; mais notre préférence est de faire en sorte que les « where clause » soient moins courantes.
| 2/ Les contraintes implicites me semblent étranges : Le but initial | n'était-il pas d'expliciter les contraintes ?
Si, mais chacun a sa propre idée de ce qu'un concept doit être. Note qu'il y a six auteurs pour ce papier...
| De plus, à ce que j'ai compris, les contraintes implicites se basent | uniquement sur la signature de la fonction, ce qui me semble contre | intuitif. Par exemple, si j'ai bien compris : | | template<typeid U> | void foo(vector<U>& v) // Contrainte implicite : Le code compile | { | } | | Mais : | | template<typeid U> | void foo(U &u) | { | vector<U> v; // Pas de contrainte implicite : Le code ne compile pas | } | | | | 3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue | de mettre une implémentation par défaut dans les pseudo signature d'un | concept.
oui ; c'est évident si tu fais le parallele avec les classes polymorphes et les functions virtuelles. Note que dans Aldor
http://www.aldor.org/
par exemple, tu peux mettre une implémentation par défaut dans la définition des catégories.
| 4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls | éléments qui sont à notre disposition, à savoir, les pseudo | signatures, les type associés, les containtes imbriquées et les | égalités de type.
Oui. La papier est très largement influencé par la théorie des itérateurs. À College Station, nous pensons que les concepts doivent Être testés dans au moins deux autres domaines différents. Ainsi, nous avons dégager la notion de « constantes associées » -- qui regroupe aussi bien les types que les valeurs et les fonctions associées. Aussi, nous privilégions l'approche avec les « use pattern » ; c'est théoriquement équivalent aux pseudo-signatures mais la différence est que ces dernières ont tendance à "encourager" le programmeur à trop contraindre ce qu'il écrit.
| Je pense qu'ajouter quelques concepts codés en dur pours lesquels le | compilateur vérifie automatiquement si un type le vérifie pourrait | corriger ça. Je pense en particulier au moyen d'exprimer qu'un type | est un POD, ou un aggregat, que deux types sont layout-compatible, ou | encore d'autres concepts qui n'apparaissent pas dans la norme, parce | qu'on ne savait pas trop quoi en faire (le fait qu'un type pourrait | être memcpy()able si on relachait la notion de POD, voir message | et le thread qui | avait suivi.).
Note aussi que dans le TR1 il y a des traits qui font des trucs comme ça ; à l'évidence ces traits devront être reconciliés avec les concepts.
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| > | Gabriel Dos Reis wrote:
| > | > Pour information :
| > | >
| > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01
| > | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va
| > | falloir que je lise ça à tête reposée...
| > Yep :-)
|
| Quelques remarques / questions :
J'avais moi-même reçu le papier seulement quelques jours avant qu'ils
l'aient envoyé pour la mailing. Je suis toujours en train de le
décortiquer (BS aussi). C'est un bon "follow-up" aux papiers d'il y a
deux ans. Je prends note de tes remarques ; dès que j'ai fini d'étudier
le papier, je répondrais plus sérieusement à ton message.
(il y a des choses que j'aime et des choses que j'aime pas dedans mais
bon c'est une base).
| 1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La
Moi non plus.
| présence d'une clause where ne suffit elle pas ? La seule différence
| que j'y vois, c'est la clause sur les contraintes implicites, et
| encore, ça pourrait se réparer...
en fait je crois qu'il y a globalement deux écoles : celle de
Indiana et celle de College Station.
À College Station, nous avons essayons de voir jusqu'où on peut
pousser l'approche sans « where clause ». On a fait pareil avec
l'approche avec la « where clause ». On a vu qu'il y a des chsoes qui
s'écrivent plus élégamment ou naturellement avec les deux ; mais notre
préférence est de faire en sorte que les « where clause » soient moins
courantes.
| 2/ Les contraintes implicites me semblent étranges : Le but initial
| n'était-il pas d'expliciter les contraintes ?
Si, mais chacun a sa propre idée de ce qu'un concept doit être. Note
qu'il y a six auteurs pour ce papier...
| De plus, à ce que j'ai compris, les contraintes implicites se basent
| uniquement sur la signature de la fonction, ce qui me semble contre
| intuitif. Par exemple, si j'ai bien compris :
|
| template<typeid U>
| void foo(vector<U>& v) // Contrainte implicite : Le code compile
| {
| }
|
| Mais :
|
| template<typeid U>
| void foo(U &u)
| {
| vector<U> v; // Pas de contrainte implicite : Le code ne compile pas
| }
|
|
|
| 3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue
| de mettre une implémentation par défaut dans les pseudo signature d'un
| concept.
oui ; c'est évident si tu fais le parallele avec les classes
polymorphes et les functions virtuelles. Note que dans Aldor
http://www.aldor.org/
par exemple, tu peux mettre une implémentation par défaut dans la
définition des catégories.
| 4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls
| éléments qui sont à notre disposition, à savoir, les pseudo
| signatures, les type associés, les containtes imbriquées et les
| égalités de type.
Oui. La papier est très largement influencé par la théorie des
itérateurs. À College Station, nous pensons que les concepts
doivent Être testés dans au moins deux autres domaines différents.
Ainsi, nous avons dégager la notion de « constantes associées » -- qui
regroupe aussi bien les types que les valeurs et les fonctions
associées.
Aussi, nous privilégions l'approche avec les « use pattern » ; c'est
théoriquement équivalent aux pseudo-signatures mais la différence est
que ces dernières ont tendance à "encourager" le programmeur à trop
contraindre ce qu'il écrit.
| Je pense qu'ajouter quelques concepts codés en dur pours lesquels le
| compilateur vérifie automatiquement si un type le vérifie pourrait
| corriger ça. Je pense en particulier au moyen d'exprimer qu'un type
| est un POD, ou un aggregat, que deux types sont layout-compatible, ou
| encore d'autres concepts qui n'apparaissent pas dans la norme, parce
| qu'on ne savait pas trop quoi en faire (le fait qu'un type pourrait
| être memcpy()able si on relachait la notion de POD, voir message
| <987fd52d.0204030132.13e9eddd@posting.google.com> et le thread qui
| avait suivi.).
Note aussi que dans le TR1 il y a des traits qui font des trucs comme
ça ; à l'évidence ces traits devront être reconciliés avec les
concepts.
| Gabriel Dos Reis wrote: | > Loïc Joly writes: | > | Gabriel Dos Reis wrote: | > | > Pour information : | > | > | > | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/#mailing2005-01 | > | | Il y a l'air d'avoir un papier assez gros sur les concepts. Il va | > | falloir que je lise ça à tête reposée... | > Yep :-) | | Quelques remarques / questions :
J'avais moi-même reçu le papier seulement quelques jours avant qu'ils l'aient envoyé pour la mailing. Je suis toujours en train de le décortiquer (BS aussi). C'est un bon "follow-up" aux papiers d'il y a deux ans. Je prends note de tes remarques ; dès que j'ai fini d'étudier le papier, je répondrais plus sérieusement à ton message.
(il y a des choses que j'aime et des choses que j'aime pas dedans mais bon c'est une base).
| 1/ Je ne comprend pas trop l'intérêt de typeid dans la déclaration. La
Moi non plus.
| présence d'une clause where ne suffit elle pas ? La seule différence | que j'y vois, c'est la clause sur les contraintes implicites, et | encore, ça pourrait se réparer...
en fait je crois qu'il y a globalement deux écoles : celle de Indiana et celle de College Station.
À College Station, nous avons essayons de voir jusqu'où on peut pousser l'approche sans « where clause ». On a fait pareil avec l'approche avec la « where clause ». On a vu qu'il y a des chsoes qui s'écrivent plus élégamment ou naturellement avec les deux ; mais notre préférence est de faire en sorte que les « where clause » soient moins courantes.
| 2/ Les contraintes implicites me semblent étranges : Le but initial | n'était-il pas d'expliciter les contraintes ?
Si, mais chacun a sa propre idée de ce qu'un concept doit être. Note qu'il y a six auteurs pour ce papier...
| De plus, à ce que j'ai compris, les contraintes implicites se basent | uniquement sur la signature de la fonction, ce qui me semble contre | intuitif. Par exemple, si j'ai bien compris : | | template<typeid U> | void foo(vector<U>& v) // Contrainte implicite : Le code compile | { | } | | Mais : | | template<typeid U> | void foo(U &u) | { | vector<U> v; // Pas de contrainte implicite : Le code ne compile pas | } | | | | 3/ J'aime plutôt bien l'idée qui au premier abord me semblait farfelue | de mettre une implémentation par défaut dans les pseudo signature d'un | concept.
oui ; c'est évident si tu fais le parallele avec les classes polymorphes et les functions virtuelles. Note que dans Aldor
http://www.aldor.org/
par exemple, tu peux mettre une implémentation par défaut dans la définition des catégories.
| 4/ Il y a des choses qui ne me semblent pas exprimables avec les seuls | éléments qui sont à notre disposition, à savoir, les pseudo | signatures, les type associés, les containtes imbriquées et les | égalités de type.
Oui. La papier est très largement influencé par la théorie des itérateurs. À College Station, nous pensons que les concepts doivent Être testés dans au moins deux autres domaines différents. Ainsi, nous avons dégager la notion de « constantes associées » -- qui regroupe aussi bien les types que les valeurs et les fonctions associées. Aussi, nous privilégions l'approche avec les « use pattern » ; c'est théoriquement équivalent aux pseudo-signatures mais la différence est que ces dernières ont tendance à "encourager" le programmeur à trop contraindre ce qu'il écrit.
| Je pense qu'ajouter quelques concepts codés en dur pours lesquels le | compilateur vérifie automatiquement si un type le vérifie pourrait | corriger ça. Je pense en particulier au moyen d'exprimer qu'un type | est un POD, ou un aggregat, que deux types sont layout-compatible, ou | encore d'autres concepts qui n'apparaissent pas dans la norme, parce | qu'on ne savait pas trop quoi en faire (le fait qu'un type pourrait | être memcpy()able si on relachait la notion de POD, voir message | et le thread qui | avait suivi.).
Note aussi que dans le TR1 il y a des traits qui font des trucs comme ça ; à l'évidence ces traits devront être reconciliés avec les concepts.
