A la lecture des papiers sur les concepts, je constate que les noms de
concepts standard -- qui seront donc dans le namespace std --
commencent par une majuscule, chaque mot étant séparé par une
majscule. Par exemple std::CopyConstructible.
Je ne sais pas si c'est une tradition ou une règle absolue, mais
jusque là toute la bibliothèque standard est écrite avec la convention
de nommage C «classique» : std::un_composant_standard. Pourquoi en
serait-il autrement pour les concepts ? En tout cas l'entête
<concepts> de conceptgcc n'utilise pas la «convention classique».
J'ai l'impression qu'en C++, la mode consiste à faire débuter les noms
de classe/struct/union/[typedef] par une majuscule, aussi j'aurai eu
tendance à penser que l'usage des minuscules aurait moins cassé de
code ce genre, non ?
#include <concepts>
struct CopyConstructible;
typedef int Assignable;
using namespace std;
template <CopyConstructible T>
where Assignable<T>
void f( T t );
| > Nous avions fait circuler des copies du rapport à la réunon de | > Redmond (certains personnes impliquées directement dans GCC en avait | > connaissance). Nous n'avions pas du tout été surpris que, quelques | > mois plus tard, une analyse plus poussée ait été faite par | > Nathan. Je suis juste un peu surpris que cela déclenche une | > discussion aussi animée deux ans plus tard :-) | | Y a-t'il des traces de ce rapport de Nathan ? Je ne trouve qu'une page | TypeSystem dans le Wiki de GCC concernant cela.
Regarde aussi sur le site de CodeSourcery, section publication.
Merci.
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
[...]
| > Nous avions fait circuler des copies du rapport à la réunon de
| > Redmond (certains personnes impliquées directement dans GCC en avait
| > connaissance). Nous n'avions pas du tout été surpris que, quelques
| > mois plus tard, une analyse plus poussée ait été faite par
| > Nathan. Je suis juste un peu surpris que cela déclenche une
| > discussion aussi animée deux ans plus tard :-)
|
| Y a-t'il des traces de ce rapport de Nathan ? Je ne trouve qu'une page
| TypeSystem dans le Wiki de GCC concernant cela.
Regarde aussi sur le site de CodeSourcery, section publication.
| > Nous avions fait circuler des copies du rapport à la réunon de | > Redmond (certains personnes impliquées directement dans GCC en avait | > connaissance). Nous n'avions pas du tout été surpris que, quelques | > mois plus tard, une analyse plus poussée ait été faite par | > Nathan. Je suis juste un peu surpris que cela déclenche une | > discussion aussi animée deux ans plus tard :-) | | Y a-t'il des traces de ce rapport de Nathan ? Je ne trouve qu'une page | TypeSystem dans le Wiki de GCC concernant cela.
Regarde aussi sur le site de CodeSourcery, section publication.
Merci.
-- Fab
fabien.chene
Gabriel Dos Reis writes:
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien | > | | > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela | > | n'implique pas l'instantiation à l'édition de lien. | > | > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ? | | Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce | n'est surement pas valable pour des compilateurs qui pourraient avoir | adopter une stratégie différente. | | Concrètement, sans LTO, on a deux fichiers sources a.cpp et | b.cpp. Tout deux instancient le même template, il y a donc duplication | de l'instance dans les deux TU -- le linker tachera de n'en retenir | qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time Optimizatin », c'est de faire des optimisations au moment de l'édition de lien. Ce n'est pas quelque conçu en priorité pour C++ et les templates. Il y a pas de gens sceptiquees voire contre le fait qu'on s'en serve pour les templates. Mais, je suis du même avis que Mark Mitchell que si on a cette infrastructure, c'est bête de ne pas en profiter pour les templates.
Vu que je m'intéresse en ce moment à LLVM, je repense à cette discussion.
Issu de ce document : http://llvm.org/pubs/2004-01-30-CGO-LLVM.pdf ( §4.1.2 )
[...] Templates are fully instantiated by the C++ front end before LLVM code is generated. (True poly- morphic types in other languages would be expanded into equivalent code using non-polymorphic types in LLVM.) [...]
J'ai lu qu'il y avait des plans pour que GCC utilise à l'avenir le middle-end de LLVM. Si c'était bien le cas, j'ai du mal à voir comment il serait alors possible d'optimiser l'instantiation des templates :-/
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien
| > |
| > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela
| > | n'implique pas l'instantiation à l'édition de lien.
| >
| > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ?
|
| Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce
| n'est surement pas valable pour des compilateurs qui pourraient avoir
| adopter une stratégie différente.
|
| Concrètement, sans LTO, on a deux fichiers sources a.cpp et
| b.cpp. Tout deux instancient le même template, il y a donc duplication
| de l'instance dans les deux TU -- le linker tachera de n'en retenir
| qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time
Optimizatin », c'est de faire des optimisations au moment de l'édition
de lien. Ce n'est pas quelque conçu en priorité pour C++ et les
templates. Il y a pas de gens sceptiquees voire contre le
fait qu'on s'en serve pour les templates. Mais, je suis du même avis
que Mark Mitchell que si on a cette infrastructure, c'est bête de ne
pas en profiter pour les templates.
Vu que je m'intéresse en ce moment à LLVM, je repense à cette
discussion.
Issu de ce document : http://llvm.org/pubs/2004-01-30-CGO-LLVM.pdf
( §4.1.2 )
[...]
Templates are fully instantiated by the C++ front
end before LLVM code is generated. (True poly-
morphic types in other languages would be expanded
into equivalent code using non-polymorphic types in
LLVM.)
[...]
J'ai lu qu'il y avait des plans pour que GCC utilise à l'avenir le
middle-end de LLVM. Si c'était bien le cas, j'ai du mal à voir comment
il serait alors possible d'optimiser l'instantiation des templates :-/
| > | > L'implémentation d'« export » ou l'instantiation à l'édition de lien | > | | > | Je parlais de l'optimisation à l'édition de lien. Sauf erreur, cela | > | n'implique pas l'instantiation à l'édition de lien. | > | > Là j'avoue ne pas suivre ton raisonnement. Pourrais-tu détailler ? | | Je me réfère de mémoire aux papiers décrivant LTO pour GCC, donc ce | n'est surement pas valable pour des compilateurs qui pourraient avoir | adopter une stratégie différente. | | Concrètement, sans LTO, on a deux fichiers sources a.cpp et | b.cpp. Tout deux instancient le même template, il y a donc duplication | de l'instance dans les deux TU -- le linker tachera de n'en retenir | qu'une seule.
Oui.
Remarque bien que le but original de la LTO, qui veut dire « Link Time Optimizatin », c'est de faire des optimisations au moment de l'édition de lien. Ce n'est pas quelque conçu en priorité pour C++ et les templates. Il y a pas de gens sceptiquees voire contre le fait qu'on s'en serve pour les templates. Mais, je suis du même avis que Mark Mitchell que si on a cette infrastructure, c'est bête de ne pas en profiter pour les templates.
Vu que je m'intéresse en ce moment à LLVM, je repense à cette discussion.
Issu de ce document : http://llvm.org/pubs/2004-01-30-CGO-LLVM.pdf ( §4.1.2 )
[...] Templates are fully instantiated by the C++ front end before LLVM code is generated. (True poly- morphic types in other languages would be expanded into equivalent code using non-polymorphic types in LLVM.) [...]
J'ai lu qu'il y avait des plans pour que GCC utilise à l'avenir le middle-end de LLVM. Si c'était bien le cas, j'ai du mal à voir comment il serait alors possible d'optimiser l'instantiation des templates :-/
