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 );
| > Je suis dans « Core Working Group » en ce moment :-) | | Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour | intégrer le core à Portland ?
On a très peu discuté des concepts à cette réunion.
OK. Sinon, vu l'intensité du traffic un peu partout, concernant «variadic templates», je suppose que cela a été discuté ... Si oui, est-ce que ça a été bien accueilli ?
Je suis dans Core pour plusieurs raisons ; en particulier, pour finaliser les expressions constantes et les template aliases.
J'aurais bien voulu ne plus en parler à la prochaine réunion, mais Core est un mamouth qui suit son propre cours :-/
Bon courage! (et merci de contribuer largement à nous concocter ce nouveau C++ si alléchant)
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
| > Je suis dans « Core Working Group » en ce moment :-)
|
| Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour
| intégrer le core à Portland ?
On a très peu discuté des concepts à cette réunion.
OK. Sinon, vu l'intensité du traffic un peu partout, concernant
«variadic templates», je suppose que cela a été discuté ... Si oui,
est-ce que ça a été bien accueilli ?
Je suis dans Core pour plusieurs raisons ; en particulier, pour
finaliser les expressions constantes et les template aliases.
J'aurais bien voulu ne plus en parler à la prochaine réunion, mais
Core est un mamouth qui suit son propre cours :-/
Bon courage! (et merci de contribuer largement à nous concocter ce
nouveau C++ si alléchant)
| > Je suis dans « Core Working Group » en ce moment :-) | | Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour | intégrer le core à Portland ?
On a très peu discuté des concepts à cette réunion.
OK. Sinon, vu l'intensité du traffic un peu partout, concernant «variadic templates», je suppose que cela a été discuté ... Si oui, est-ce que ça a été bien accueilli ?
Je suis dans Core pour plusieurs raisons ; en particulier, pour finaliser les expressions constantes et les template aliases.
J'aurais bien voulu ne plus en parler à la prochaine réunion, mais Core est un mamouth qui suit son propre cours :-/
Bon courage! (et merci de contribuer largement à nous concocter ce nouveau C++ si alléchant)
-- Fab
Gabriel Dos Reis
(Fabien Chêne) writes:
| Gabriel Dos Reis writes: | | > (Fabien Chêne) writes: | > | > | > Je suis dans « Core Working Group » en ce moment :-) | > | | > | Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour | > | intégrer le core à Portland ? | > | > On a très peu discuté des concepts à cette réunion. | | OK. Sinon, vu l'intensité du traffic un peu partout, concernant | «variadic templates», je suppose que cela a été discuté ... Si oui, | est-ce que ça a été bien accueilli ?
Oui, cela a été discuté ; mais j'étais dans Core à ce moment là.
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > fabien.chene@gmail.com (Fabien Chêne) writes:
| >
| > | > Je suis dans « Core Working Group » en ce moment :-)
| > |
| > | Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour
| > | intégrer le core à Portland ?
| >
| > On a très peu discuté des concepts à cette réunion.
|
| OK. Sinon, vu l'intensité du traffic un peu partout, concernant
| «variadic templates», je suppose que cela a été discuté ... Si oui,
| est-ce que ça a été bien accueilli ?
Oui, cela a été discuté ; mais j'étais dans Core à ce moment là.
| Gabriel Dos Reis writes: | | > (Fabien Chêne) writes: | > | > | > Je suis dans « Core Working Group » en ce moment :-) | > | | > | Ce qui signifie que les concepts (v)ont quitt(és/er) évolution pour | > | intégrer le core à Portland ? | > | > On a très peu discuté des concepts à cette réunion. | | OK. Sinon, vu l'intensité du traffic un peu partout, concernant | «variadic templates», je suppose que cela a été discuté ... Si oui, | est-ce que ça a été bien accueilli ?
Oui, cela a été discuté ; mais j'étais dans Core à ce moment là.
-- Gaby
Jean-Marc Bourguet
"meow" writes:
Ils viennent d'inventer « Boolable » Interdit de rire.
Oh, moi plutot que de me faire rire ça me fait peur... Je préssent que ces (récents ?) changements adressent une question que j'avais posée il y a quelques temps sur cette ML à propos d'un "méta typage" dans les arguments templates ? Mais où c'est y donc qu'on peut trouver de la doc lisible et compréhensible sur la question?
http://www.open-std.org/jtc1/sc22/wg21/
Il y a une implémentation qui sert à prototyper une des propositions. Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible et compréhensible, c'est une question à laquelle je ne tenterai pas de répondre.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne sortira pas avant 2009, et il faudra encore un certain temps avant que les compilateurs s'adaptent.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"meow" <schwarz.ben@gmail.com> writes:
Ils viennent d'inventer « Boolable »
Interdit de rire.
Oh, moi plutot que de me faire rire ça me fait peur... Je préssent que
ces (récents ?) changements adressent une question que j'avais posée il y
a quelques temps sur cette ML à propos d'un "méta typage" dans les
arguments templates ? Mais où c'est y donc qu'on peut trouver de la doc
lisible et compréhensible sur la question?
http://www.open-std.org/jtc1/sc22/wg21/
Il y a une implémentation qui sert à prototyper une des propositions.
Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible
et compréhensible, c'est une question à laquelle je ne tenterai pas de
répondre.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il
encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne
sortira pas avant 2009, et il faudra encore un certain temps avant que les
compilateurs s'adaptent.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ils viennent d'inventer « Boolable » Interdit de rire.
Oh, moi plutot que de me faire rire ça me fait peur... Je préssent que ces (récents ?) changements adressent une question que j'avais posée il y a quelques temps sur cette ML à propos d'un "méta typage" dans les arguments templates ? Mais où c'est y donc qu'on peut trouver de la doc lisible et compréhensible sur la question?
http://www.open-std.org/jtc1/sc22/wg21/
Il y a une implémentation qui sert à prototyper une des propositions. Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible et compréhensible, c'est une question à laquelle je ne tenterai pas de répondre.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne sortira pas avant 2009, et il faudra encore un certain temps avant que les compilateurs s'adaptent.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
fabien.chene
Jean-Marc Bourguet writes:
Il y a une implémentation qui sert à prototyper une des propositions. Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible et compréhensible, c'est une question à laquelle je ne tenterai pas de répondre.
Je me garderais bien de répondre à la question :-) mais avec conceptgcc sous la main, on assimile assez vite la chose. Après c'est un compilateur très jeune sur les concepts, il est parfois confus sur les messages d'erreurs, il est lent et prend beaucoup de mémoire; mais c'est agréable d'explorer toutes ces nouveautées.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne sortira pas avant 2009, et il faudra encore un certain temps avant que les compilateurs s'adaptent.
Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
-- Fab
Jean-Marc Bourguet <jm@bourguet.org> writes:
Il y a une implémentation qui sert à prototyper une des propositions.
Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible
et compréhensible, c'est une question à laquelle je ne tenterai pas de
répondre.
Je me garderais bien de répondre à la question :-) mais avec
conceptgcc sous la main, on assimile assez vite la chose. Après c'est
un compilateur très jeune sur les concepts, il est parfois confus sur
les messages d'erreurs, il est lent et prend beaucoup de mémoire; mais
c'est agréable d'explorer toutes ces nouveautées.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il
encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne
sortira pas avant 2009, et il faudra encore un certain temps avant que les
compilateurs s'adaptent.
Je me posais la question justement, les compilateurs ne vont-ils pas
fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a
été standardisé, avait déjà été implémenté, non ? -- export excepté ...
Il y a une implémentation qui sert à prototyper une des propositions. Cherche conceptgcc.
Je crains qu'il n'y ait pas grand chose d'autre. Savoir si c'est lisible et compréhensible, c'est une question à laquelle je ne tenterai pas de répondre.
Je me garderais bien de répondre à la question :-) mais avec conceptgcc sous la main, on assimile assez vite la chose. Après c'est un compilateur très jeune sur les concepts, il est parfois confus sur les messages d'erreurs, il est lent et prend beaucoup de mémoire; mais c'est agréable d'explorer toutes ces nouveautées.
Et le bouquin de Vandervoorde que je n'ai pas encore acheté est il encore achetable ?
Oui. Il ne sera dépassé que dans quelques années. La prochaine norme ne sortira pas avant 2009, et il faudra encore un certain temps avant que les compilateurs s'adaptent.
Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
-- Fab
Jean-Marc Bourguet
(Fabien Chêne) writes:
Jean-Marc Bourguet writes: Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà. Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir être faites aussi rapidement. Pour le reste, ça va dépendre en partie de l'organisation interne du compilateur, de l'état de finalisation des propositions et du risque perçu qu'elles changent -- je ne proposerais pas un plan maintenant pour le moment pour intégrer les concepts par exemple, mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et de l'influence sur la compatibilité binaire et du code. Les changements dans la bibliothèque devrait a priori être plus rapide.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs plus humains tel que le choix d'une politique en la matière -- comment gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui est perçu comme important par les clients? si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourtant bien partis pour ne pas être dans C++ 200X -- et de gestion de ressources -- qu'est-ce qu'il y a moyen de faire avec le budget disponible.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
fabien.chene@gmail.com (Fabien Chêne) writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
Je me posais la question justement, les compilateurs ne vont-ils pas
fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a
été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des
langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont
pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà.
Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir
être faites aussi rapidement. Pour le reste, ça va dépendre en partie de
l'organisation interne du compilateur, de l'état de finalisation des
propositions et du risque perçu qu'elles changent -- je ne proposerais pas
un plan maintenant pour le moment pour intégrer les concepts par exemple,
mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et
de l'influence sur la compatibilité binaire et du code. Les changements
dans la bibliothèque devrait a priori être plus rapide.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs
plus humains tel que le choix d'une politique en la matière -- comment
gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui
est perçu comme important par les clients? si on me demande mon avis, les
concepts le sont moins que les threads où même que les modules qui sont
pourtant bien partis pour ne pas être dans C++ 200X -- et de gestion de
ressources -- qu'est-ce qu'il y a moyen de faire avec le budget disponible.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet writes: Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà. Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir être faites aussi rapidement. Pour le reste, ça va dépendre en partie de l'organisation interne du compilateur, de l'état de finalisation des propositions et du risque perçu qu'elles changent -- je ne proposerais pas un plan maintenant pour le moment pour intégrer les concepts par exemple, mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et de l'influence sur la compatibilité binaire et du code. Les changements dans la bibliothèque devrait a priori être plus rapide.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs plus humains tel que le choix d'une politique en la matière -- comment gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui est perçu comme important par les clients? si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourtant bien partis pour ne pas être dans C++ 200X -- et de gestion de ressources -- qu'est-ce qu'il y a moyen de faire avec le budget disponible.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
fabien.chene
Jean-Marc Bourguet writes:
(Fabien Chêne) writes:
Jean-Marc Bourguet writes: Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà. Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir être faites aussi rapidement. Pour le reste, ça va dépendre en partie de l'organisation interne du compilateur, de l'état de finalisation des propositions et du risque perçu qu'elles changent -- je ne proposerais pas un plan maintenant pour le moment pour intégrer les concepts par exemple, mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et de l'influence sur la compatibilité binaire et du code. Les changements dans la bibliothèque devrait a priori être plus rapide.
Les modifications qui touchent uniquement au front-end et à la bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées que cela -- et ça m'a l'air d'être la majorité des propositions, sans doute à l'exception en particulier des threads et modules.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs plus humains tel que le choix d'une politique en la matière -- comment gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui est perçu comme important par les clients?
Il va y avoir des paris à faire pour les compilateurs qui ne reçoivent pas gracieusement des patchs des nouveautés C++0x, ça devrait être une belle lutte :-)
si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourta t bien partis pour ne pas être dans + 200X
:-(( Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée. 2) à un problème d'ordre d'initialisation statique entre différentes TU.
Ceci bien avant toute autre ajout dans la norme. Vu que les modules semblent régler ces problèmes, ce serait bien dommage de s'en priver.
-- Fab
Jean-Marc Bourguet <jm@bourguet.org> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
Je me posais la question justement, les compilateurs ne vont-ils pas
fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a
été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des
langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont
pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà.
Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir
être faites aussi rapidement. Pour le reste, ça va dépendre en partie de
l'organisation interne du compilateur, de l'état de finalisation des
propositions et du risque perçu qu'elles changent -- je ne proposerais pas
un plan maintenant pour le moment pour intégrer les concepts par exemple,
mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et
de l'influence sur la compatibilité binaire et du code. Les changements
dans la bibliothèque devrait a priori être plus rapide.
Les modifications qui touchent uniquement au front-end et à la
bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées
que cela -- et ça m'a l'air d'être la majorité des propositions, sans
doute à l'exception en particulier des threads et modules.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs
plus humains tel que le choix d'une politique en la matière -- comment
gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui
est perçu comme important par les clients?
Il va y avoir des paris à faire pour les compilateurs qui ne reçoivent
pas gracieusement des patchs des nouveautés C++0x, ça devrait être une
belle lutte :-)
si on me demande mon avis, les concepts le sont moins que les
threads où même que les modules qui sont pourta t bien partis pour
ne pas être dans + 200X
:-((
Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en
C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
2) à un problème d'ordre d'initialisation statique entre différentes
TU.
Ceci bien avant toute autre ajout dans la norme. Vu que les modules
semblent régler ces problèmes, ce serait bien dommage de s'en priver.
Jean-Marc Bourguet writes: Je me posais la question justement, les compilateurs ne vont-ils pas fournir la plupart des extensions avant 2009 ? En 1998, tout ce qui a été standardisé, avait déjà été implémenté, non ? -- export excepté ...
À mon avis -- de quelqu'un qui a travaillé sur des front-end pour des langages, mais pas pour du C++ -- ça va dépendre.
Des choses comme long long ou l'alignement du préprocesseur avec C99 vont pouvoir être fournie très vite par ceux qui ne les fournissaient pas déjà. Des choses comme permettre >> où pour le moment il faut > > doivent pouvoir être faites aussi rapidement. Pour le reste, ça va dépendre en partie de l'organisation interne du compilateur, de l'état de finalisation des propositions et du risque perçu qu'elles changent -- je ne proposerais pas un plan maintenant pour le moment pour intégrer les concepts par exemple, mais j'en tiendrais compte pour éviter de faire des choses bloquantes -- et de l'influence sur la compatibilité binaire et du code. Les changements dans la bibliothèque devrait a priori être plus rapide.
Les modifications qui touchent uniquement au front-end et à la bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées que cela -- et ça m'a l'air d'être la majorité des propositions, sans doute à l'exception en particulier des threads et modules.
Ceci c'était basé sur des facteurs techniques. Il y a aussi les facteurs plus humains tel que le choix d'une politique en la matière -- comment gérer la phase de transition? -- de gestion de priorité -- qu'est-ce qui est perçu comme important par les clients?
Il va y avoir des paris à faire pour les compilateurs qui ne reçoivent pas gracieusement des patchs des nouveautés C++0x, ça devrait être une belle lutte :-)
si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourta t bien partis pour ne pas être dans + 200X
:-(( Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée. 2) à un problème d'ordre d'initialisation statique entre différentes TU.
Ceci bien avant toute autre ajout dans la norme. Vu que les modules semblent régler ces problèmes, ce serait bien dommage de s'en priver.
-- Fab
Gabriel Dos Reis
(Fabien Chêne) writes:
[...]
| Les modifications qui touchent uniquement au front-end et à la | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | que cela
Ah bon ?
[...]
| :-(( | Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en | C++ sans avoir la peur au ventre d'une erreur liée | | 1) à une violation de l'ODR non diagnostiquée.
Il y a quelques années, ce problème était mis en avant; maintenant, plus personne n'en parle :-(
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
[...]
| Les modifications qui touchent uniquement au front-end et à la
| bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées
| que cela
Ah bon ?
[...]
| :-((
| Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en
| C++ sans avoir la peur au ventre d'une erreur liée
|
| 1) à une violation de l'ODR non diagnostiquée.
Il y a quelques années, ce problème était mis en avant; maintenant,
plus personne n'en parle :-(
| Les modifications qui touchent uniquement au front-end et à la | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | que cela
Ah bon ?
[...]
| :-(( | Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en | C++ sans avoir la peur au ventre d'une erreur liée | | 1) à une violation de l'ODR non diagnostiquée.
Il y a quelques années, ce problème était mis en avant; maintenant, plus personne n'en parle :-(
-- Gaby
fabien.chene
Gabriel Dos Reis writes:
(Fabien Chêne) writes:
| Les modifications qui touchent uniquement au front-end et à la | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | que cela
Ah bon ?
Je retire pour les modifications impactant la bibliothèque (comme les concepts le font). J'avais en tête l'ajout de nouveaux composants dans la bibliothèque standard.
Pour le front-end, disons que j'ai l'impression que les bugs de middle-end, back-end sont bien plus redoutés. Depuis toutes ces années, les tests de non régression sur le front-end C++98 doivent être assez exhaustifs. Aussi, les bugs sur le nouveau front-end seront peut-être pour la plupart contournable en se passant des nouveautés C++0x.
En fait, j'entendais «pas si risqué que cela» du point de vue utilisateur. C'était sans prendre en compte les risques de créations d'extensions involontaires qu'il faut ensuite maintenir, ou pas, etc.
-- Fab
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
| Les modifications qui touchent uniquement au front-end et à la
| bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées
| que cela
Ah bon ?
Je retire pour les modifications impactant la bibliothèque (comme les
concepts le font). J'avais en tête l'ajout de nouveaux composants dans
la bibliothèque standard.
Pour le front-end, disons que j'ai l'impression que les bugs de
middle-end, back-end sont bien plus redoutés. Depuis toutes ces
années, les tests de non régression sur le front-end C++98 doivent
être assez exhaustifs. Aussi, les bugs sur le nouveau front-end seront
peut-être pour la plupart contournable en se passant des nouveautés
C++0x.
En fait, j'entendais «pas si risqué que cela» du point de vue
utilisateur. C'était sans prendre en compte les risques de créations
d'extensions involontaires qu'il faut ensuite maintenir, ou pas, etc.
| Les modifications qui touchent uniquement au front-end et à la | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | que cela
Ah bon ?
Je retire pour les modifications impactant la bibliothèque (comme les concepts le font). J'avais en tête l'ajout de nouveaux composants dans la bibliothèque standard.
Pour le front-end, disons que j'ai l'impression que les bugs de middle-end, back-end sont bien plus redoutés. Depuis toutes ces années, les tests de non régression sur le front-end C++98 doivent être assez exhaustifs. Aussi, les bugs sur le nouveau front-end seront peut-être pour la plupart contournable en se passant des nouveautés C++0x.
En fait, j'entendais «pas si risqué que cela» du point de vue utilisateur. C'était sans prendre en compte les risques de créations d'extensions involontaires qu'il faut ensuite maintenir, ou pas, etc.
-- Fab
Gabriel Dos Reis
(Fabien Chêne) writes:
| Gabriel Dos Reis writes: | | > (Fabien Chêne) writes: | > | > | Les modifications qui touchent uniquement au front-end et à la | > | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | > | que cela | > | > Ah bon ? | | Je retire pour les modifications impactant la bibliothèque (comme les | concepts le font). J'avais en tête l'ajout de nouveaux composants dans | la bibliothèque standard. | | Pour le front-end, disons que j'ai l'impression que les bugs de | middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à ce niveau. À quoi pensais-tu en particulier ?
| Depuis toutes ces | années, les tests de non régression sur le front-end C++98 doivent | être assez exhaustifs.
Ahem. D'expérience, je serais beaucoup plus circonspet.
| Aussi, les bugs sur le nouveau front-end seront | peut-être pour la plupart contournable en se passant des nouveautés | C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Personnellement, je ne mettrais pas ma main à couper.
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > fabien.chene@gmail.com (Fabien Chêne) writes:
| >
| > | Les modifications qui touchent uniquement au front-end et à la
| > | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées
| > | que cela
| >
| > Ah bon ?
|
| Je retire pour les modifications impactant la bibliothèque (comme les
| concepts le font). J'avais en tête l'ajout de nouveaux composants dans
| la bibliothèque standard.
|
| Pour le front-end, disons que j'ai l'impression que les bugs de
| middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end
avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à
ce niveau. À quoi pensais-tu en particulier ?
| Depuis toutes ces
| années, les tests de non régression sur le front-end C++98 doivent
| être assez exhaustifs.
Ahem.
D'expérience, je serais beaucoup plus circonspet.
| Aussi, les bugs sur le nouveau front-end seront
| peut-être pour la plupart contournable en se passant des nouveautés
| C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Personnellement, je ne mettrais pas ma main à couper.
| Gabriel Dos Reis writes: | | > (Fabien Chêne) writes: | > | > | Les modifications qui touchent uniquement au front-end et à la | > | bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées | > | que cela | > | > Ah bon ? | | Je retire pour les modifications impactant la bibliothèque (comme les | concepts le font). J'avais en tête l'ajout de nouveaux composants dans | la bibliothèque standard. | | Pour le front-end, disons que j'ai l'impression que les bugs de | middle-end, back-end sont bien plus redoutés.
La plupart des compilateurs C++ partagent le middle-end et back-end avec d'autres front-ends non-C++; donc, je ne vois pas de problèmes à ce niveau. À quoi pensais-tu en particulier ?
| Depuis toutes ces | années, les tests de non régression sur le front-end C++98 doivent | être assez exhaustifs.
Ahem. D'expérience, je serais beaucoup plus circonspet.
| Aussi, les bugs sur le nouveau front-end seront | peut-être pour la plupart contournable en se passant des nouveautés | C++0x.
Spéculation ou assertion basée sur des expériences passées ?
Personnellement, je ne mettrais pas ma main à couper.
-- Gaby
Jean-Marc Bourguet
(Fabien Chêne) writes:
Jean-Marc Bourguet writes:
(Fabien Chêne) writes:
Jean-Marc Bourguet writes:
Les modifications qui touchent uniquement au front-end et à la bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées que cela
Le risque dont je parlais, c'est d'investir du temps dans une implémentation qui sera à jeter parce qu'elle sera basée sur des hypothèses fausses, c'est de mécontenter ses clients parce qu'ils seront devenus dépendant d'une sémantique qui ne sera pas celle adoptée.
Et oui, il y a encore des risques de changements, même pour ce qui est déjà dans le draft. Peut-être sur des détails, mais les détails peuvent rendre invalides une voie d'implémentation.
Quant à quelque chose comme les concepts, à mon avis il y a encore pas mal de boulot, et pour le langage et pour la bibliothèque.
si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourta t bien partis pour ne pas être dans + 200X
:-(( Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à *faire* fixer, car quand c'est arrivé aucune des deux définitions n'était sous notre responsabilité et on arrive alors dans un problème politique avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez eux.
2) à un problème d'ordre d'initialisation statique entre différentes TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours facile à trouver. La solution parfois un peu plus -- quand apparemment il y a des dépendances circulaires -- mais alors d'après mon expérience en Ada, un système de module n'aide pas: il faut de toute manière restructurer.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
fabien.chene@gmail.com (Fabien Chêne) writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
fabien.chene@gmail.com (Fabien Chêne) writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
Les modifications qui touchent uniquement au front-end et à la
bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées
que cela
Le risque dont je parlais, c'est d'investir du temps dans une
implémentation qui sera à jeter parce qu'elle sera basée sur des hypothèses
fausses, c'est de mécontenter ses clients parce qu'ils seront devenus
dépendant d'une sémantique qui ne sera pas celle adoptée.
Et oui, il y a encore des risques de changements, même pour ce qui est déjà
dans le draft. Peut-être sur des détails, mais les détails peuvent rendre
invalides une voie d'implémentation.
Quant à quelque chose comme les concepts, à mon avis il y a encore pas mal
de boulot, et pour le langage et pour la bibliothèque.
si on me demande mon avis, les concepts le sont moins que les
threads où même que les modules qui sont pourta t bien partis pour
ne pas être dans + 200X
:-((
Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en
C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à
*faire* fixer, car quand c'est arrivé aucune des deux définitions n'était
sous notre responsabilité et on arrive alors dans un problème politique
avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez
eux.
2) à un problème d'ordre d'initialisation statique entre différentes
TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours
facile à trouver. La solution parfois un peu plus -- quand apparemment il
y a des dépendances circulaires -- mais alors d'après mon expérience en
Ada, un système de module n'aide pas: il faut de toute manière
restructurer.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Les modifications qui touchent uniquement au front-end et à la bibliothèque, je crois qu'on peut dire qu'elles ne sont pas si risquées que cela
Le risque dont je parlais, c'est d'investir du temps dans une implémentation qui sera à jeter parce qu'elle sera basée sur des hypothèses fausses, c'est de mécontenter ses clients parce qu'ils seront devenus dépendant d'une sémantique qui ne sera pas celle adoptée.
Et oui, il y a encore des risques de changements, même pour ce qui est déjà dans le draft. Peut-être sur des détails, mais les détails peuvent rendre invalides une voie d'implémentation.
Quant à quelque chose comme les concepts, à mon avis il y a encore pas mal de boulot, et pour le langage et pour la bibliothèque.
si on me demande mon avis, les concepts le sont moins que les threads où même que les modules qui sont pourta t bien partis pour ne pas être dans + 200X
:-(( Mes deux centimes d'euros: J'aimerais un jour pouvoir programmer en C++ sans avoir la peur au ventre d'une erreur liée
1) à une violation de l'ODR non diagnostiquée.
D'expérience, ça peut être *très* pénible à débugger. Et encore plus à *faire* fixer, car quand c'est arrivé aucune des deux définitions n'était sous notre responsabilité et on arrive alors dans un problème politique avec deux "fournisseurs" qui considèrent qu'il n'y a pas de problème chez eux.
2) à un problème d'ordre d'initialisation statique entre différentes TU.
J'ai eu peu de problèmes avec cela, et la source du problème fut toujours facile à trouver. La solution parfois un peu plus -- quand apparemment il y a des dépendances circulaires -- mais alors d'après mon expérience en Ada, un système de module n'aide pas: il faut de toute manière restructurer.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
