C++0x : Final Committee Draft disponible

[stardeath]

le c++0x n'a pas besoin de changer si profondément pour ne pas marcher, il a réussi à tant tarder que vs2010 est sorti ><
ça commence mal de ce coté là.

peut être qu'il faut une évolution douce, je peux pas dire le contraire, mais ça va en aucun cas simplifier le codage, maintenant on aura c, c++, c99 et c++0x mélangé en même temps. et en aucun cas ça ne résoudra le codage crade des char* que je dénonce entre autre.

personnellement ce que j'attendais c'était un assainissement du c++, et ça même si je devais tout (ou partiellement) recoder; malheureusement ça va être pire.

[Joel F]

Envoyé par Jean-Marc.Bourguet

Une norme qui ne permet pas une transition douce ne sera pas utilisée en entreprise. Et vu que ce sont elles qui financent et les gens qui sont dans le comité et les compilateurs, il y a peu de risques que ce besoin ne soit pas pris en compte.

Je dis pas de faire ça en 1 semaine. Mais avoir une période de transition de x mois en 'warning deprecated', puis 6 mois avec "error deprectaed" puis l'enlevé, ca doit etre jouable ? (je dis 6, c'ets au pif).

Envoyé par Jean-Marc.Bourguet

(Merci de confirmer en passant que Java c'est pour les programmes jetables).

quel est el sens du message

[gl]

Envoyé par Joel F

Je dis pas de faire ça en 1 semaine. Mais avoir une période de transition de x mois en 'warning deprecated', puis 6 mois avec "error deprectaed" puis l'enlevé, ca doit etre jouable ? (je dis 6, c'ets au pif).

Le problème n'est pas tant une question de temps que de faisabilité. Si le code est question est utilisé par différent programme sous différent environnement dont certain ne dispose que d'un compilateur C++98, comment fais-tu ? Je vois 4 solutions :

• Tu gardes tout en C++98 quitte à te passer des évolutions C++0x dans les programmes qui pourrait en bénéficier.
• Tu gère deux versions de la bibliothèque, avec tout ce que cela implique en terme de coût de maintenance et d'évolution.
• Tu compiles en partie en C++98 et en partie en C++0x et tu espères que l'édition de lien va passer.
• Tu fais en sorte que du code valide en C++98 reste valide en C++0x.

La solution 4 est clairement la moins couteuse à court et moyen terme.

A titre personnel, je pense que passer en deprecated certaines constructions qui ne devraient pas être utilisées auraient pu être une bonne chose. Mais de là à en enlever le support dans 6 mois, 1 an ou même dans la version suivante de la norme, cela ne me semble pas être une bonne idée.

[3DArchi]

Salut,
Pour rappel, il existe dans les entreprises des millions de lignes de code 'old style' qui ne seront jamais changées car :
1/ elles fonctionnent tant bien que mal ;
2/ personne ne veut payer un refactoring ;
3/ le risque d'une réécriture est trop important en terme de régression ;
4/ beaucoup de 'savoir' est dans le code et nulle part ailleurs (et surtout pas dans les specs).
Sortir un compilateur qui ne permettrait pas de compiler ces programmes dans XXX mois aboutira à son rejet immédiat car personne ne voudra prendre le risque d'une migration subie.
En revanche, sortir un compilateur qui propose des nouveautés et reste compatible avec l'existant permet de faire des transitions douces. En général, on propose des petits 'rafraichissements' ciblés et maitrisés dans le cadre d'une évolution moyenne ou importante ou lorsque le nombre de défauts sur une partie reste trop élevé. C'est comme ça qu'on fait vraiment évoluer la pratique du langage.

Aussi paradoxal que cela puisse paraître, aujourd'hui beaucoup d'entreprise ont encore visual 6 (alors que plus supporté par microsoft) car il y a un risque levé sur une éventuelle migration. Nous n'avons pas tous la chance d'avoir le temps d'un labo de recherche ou d'un nouveau projet from scratch.

[stardeath]

je tilte pas, on arrive très bien à mixer c et c++ sur le même projet, qu'est ce qui empêcherait de faire pareil avec c++0x. le format binaire en sortie reste le même. ça permettrait de faire un dépoussiérage de c++ en tant que c++0x tout en pouvant se lier avec c et c++.

et point de vu personnel, ceux qui se servent de visual 6 doivent de toute façon s'en tamponner de c++0x.
pareil pour ceux qui utilise gcc, vu les nombreux changements il y a pas encore si longtemps, ils ne mettent pas à jour leur compilo, donc ils sont pas concernés non plus.

les seuls concernés seront ceux qui mettent à jour leur compilo, et les compilos du marché peuvent différencier c et c++, alors rajouter c++0x serait une partie de rigolade à ce niveau.

et puis à force de pas vouloir réécrire pas mal de boites se retrouvent avec du code cobol ou assembleur que personne comprend avec toutes les conséquences qu'on connait.

[bloomenthal]

Comme il a été suggéré, ces programmes pourraient "juste" ne pas passer la compilation en c++0x, mais compiler en c++98. Une nouvelle norme n'efface pas pour autant l'ancienne. [réponse au message de 3DArchi]

Si on a un programme écrit suivant le standard C++-pierrafeu et que notre compilateur supporte encore ce standard, hé bien c'est très bien, rien n'oblige à le compiler en C++-0X (quel intéret ?), ou alors, hé bien il faut se mettre au boulot, sinon, qu'apporte le standard dans tout ça ?

Je n'ai pas vraiment le nez dans l'industrie, mais de mon modeste point de vue, j'y trouve un petit côté aberrant.
Par contre, je trouve les arguments de gl assez convaincants, mais j'aimerais bien savoir en pratique la proportion des cas cités (qui n'a accès qu'à un vieux compilo tout en utilisant des trucs compilés par un compilo récent ?). J'avoue n'avoir presque aucune expérience de programmation en dehors du monde Unix, donc je ne sais même pas si MSVC++ propose des options du style -std=c++XX sous gcc. Si ce n'est pas le cas (même si ça devrait l'être pour un compilateur qui se veut "industriel" !) ne serait-ce pas de genre de compilateurs qui dicte au comité "je ne serai pas rétro compatible, donc merci de l'assurer à ma place si vous voulez que le langage soit pérenne et que l'industrie y trouve son compte" ?

Il serait intéressant d'éplucher les discussions internes du fameux comité

Et puis, une question est peut-être à soulever aussi : est-ce que la plupart des programmeurs professionnels maîtrisent à peu près les différents standards et leurs différences ? Parce qu'autant sur ce forum, c'est facile d'être un théoricien/intégriste des standards ("hé regarde, je compile en -std=c++0x -pedantic-error -Wall -W -Werror -Wextra, la classe non ?"), autant dans la pratique, j'imagine (à tort ?) que yen a pas mal même dans le milieu pro qui en ont rien à cogner, et que nos amis du comité n'ont pas envie de faire peur à une proportion (laquelle ?) de la "communauté" C++ et/ou de renvoyer 100000 personnes en formation...

En espérant ne pas être trop à côté de la plaque, je serai ravi d'avoir de connaître l'avis de professionnels (surtout des chefs de projets) là dessus

[stardeath]

Envoyé par bloomenthal

J'avoue n'avoir presque aucune expérience de programmation en dehors du monde Unix, donc je ne sais même pas si MSVC++ propose des options du style -std=c++XX sous gcc.

ça je peux répondre, dans vs on peut choisir si on compile soit en c, soit en c++
(c'est d'ailleurs pour ça que je propose d'avoir une option en plus : c++0x)

[Jean-Marc.Bourguet]

Envoyé par stardeath

je tilte pas, on arrive très bien à mixer c et c++ sur le même projet, qu'est ce qui empêcherait de faire pareil avec c++0x. le format binaire en sortie reste le même. ça permettrait de faire un dépoussiérage de c++ en tant que c++0x tout en pouvant se lier avec c et c++.

Je suis quasiment certain que tu ne pourras pas lier du C++0X avec du C++98, et mon degré de certitude augmente si on prend la bibliothèque standard en compte. Oh, on va commencer par implémenter ce qui ne nécessite pas de changement d'ABI (ou uniquement des changements compatibles) pour se laisser le temps de tout bien analyser et ne casser qu'une fois, mais il y aura au moins un changement incompatible (je parierais même qu'il y a des non-conformités à C++98 qui n'attentent que la permission de casser l'ABI pour être fixées).

[stardeath]

là je vais demander un éclaircissement, je comprend pas trop;

les décorations de c++98 (si je me trompe pas d'année) marcheront forcément en c++0x, le c++0x étant un sur-ensemble de c++ (ce qui implique une nouvelle décoration pour c++0x effectivement, bien sur c'est ce que je concevrai, donc pas de c++0x = c++98 + ajout à la stl).

grosso modo faire comme le passage de c à c++, un "nouveau langage" avec de bon gros morceau des précédents.

(c'est un peu tard vu que c'est décidé mais bon, je trouve ça dommage d'avoir loupé le coche pour faire quelque chose de propre)

[Jean-Marc.Bourguet]

Envoyé par bloomenthal

Comme il a été suggéré, ces programmes pourraient "juste" ne pas passer la compilation en c++0x, mais compiler en c++98. Une nouvelle norme n'efface pas pour autant l'ancienne. [réponse au message de 3DArchi]

Formellement, si. (Essaie d'obtenir le texte de C90 par exemple, il faut te le procurer en tant que norme d'un pays qui l'avait adopté mais n'a pas adopté C99). En pratique non.

Si on a un programme écrit suivant le standard C++-pierrafeu et que notre compilateur supporte encore ce standard, hé bien c'est très bien, rien n'oblige à le compiler en C++-0X (quel intéret ?), ou alors, hé bien il faut se mettre au boulot, sinon, qu'apporte le standard dans tout ça ?

L'intérêt est de permettre l'utilisation des nouvelles choses pour le nouveau code sans forcer une mise à jour simultanée de tout le code. Même en admettant qu'il soit possible de lier ensemble du C++98 et du C++0X -- ce dont je doute fort --, il va vite y avoir des entêtes avec du C++0X qui seront inclus dans du C++98.

Si ce n'est pas le cas (même si ça devrait l'être pour un compilateur qui se veut "industriel" !) ne serait-ce pas de genre de compilateurs qui dicte au comité "je ne serai pas rétro compatible, donc merci de l'assurer à ma place si vous voulez que le langage soit pérenne et que l'industrie y trouve son compte" ?

Ce n'est pas des compilateurs que vient l'opposition à casser le code, mais de ceux qui ont beaucoup de code. Et ces clients des compilateurs ont une longue tradition de faire savoir clairement à leur fournisseur que casser du code qui fonctionne est exclus.

[Jean-Marc.Bourguet]

Envoyé par Joel F

Je dis pas de faire ça en 1 semaine. Mais avoir une période de transition de x mois en 'warning deprecated', puis 6 mois avec "error deprectaed" puis l'enlevé, ca doit etre jouable ? (je dis 6, c'ets au pif).

Remarque d'abord que la technique que tu suggères suppose que le code n'a pas à être changé pour être compilable mais est simplement un moyen de virer du code ayant un "mauvais style" en ayant de l'aide du compilateur.

Pour qu'il soit décider de faire ce passage, la question est qu'est-ce que ça apporte? Est-ce que ça vaut le risque? Est-ce qu'il n'y a pas une autre action qui apporterait plus pour le même coût? Mon expérience (des deux côtés, comme client je râle de devoir changer ce qui fonctionne, comme fournisseur je râle de devoir supporter des vielles features alors que maintenant il y a mieux pour arriver à un effet équivalent) est que ce genre d'actions n'est que très rarement entreprise dans les gros projets tant qu'il n'y a pas de contraintes fortes pour y pousser.

[Jean-Marc.Bourguet]

Envoyé par stardeath

les décorations de c++98 (si je me trompe pas d'année) marcheront forcément en c++0x, le c++0x étant un sur-ensemble de c++

La décoration de noms n'est qu'un aspect d'une ABI. Un des aspects les plus simples qu'on choisit de rendre incompatible quand les aspects moins visibles le deviennent pour éviter les problèmes à l'exécution.

[stardeath]

Envoyé par Jean-Marc.Bourguet

La décoration de noms n'est qu'un aspect d'une ABI. Un des aspects les plus simples qu'on choisit de rendre incompatible quand les aspects moins visibles le deviennent pour éviter les problèmes à l'exécution.

là je suis totalement incompétent, j'aurai du suivre plus attentivement mes cours de "fabrique ton compilateur c" ><

[Jean-Marc.Bourguet]

Envoyé par stardeath

là je suis totalement incompétent, j'aurai du suivre plus attentivement mes cours de "fabrique ton compilateur c" ><

L'ABI c'est tout ce qui fait qu'il n'y a pas de problèmes à l'exécution quand on lie deux objets ensemble. La décoration des noms n'est qu'un aspect, le choix de la manière dont les paramètres sont passés (dans des registres, lesquels et dans quel ordre, est-ce que this est le premier ou le dernier paramètre ou même est dans un registre qui normalement n'est pas utilisé pour les paramètres), le choix des tailles (long est-il 32 bits ou 64 bits, long double est-il sur 64, 80 ou 128 bits?) les problèmes d'alignement (un long double dont la valeur est codée sur 80 bits est-il aligné sur 80, 96 ou 128 bits?), la manière dont les exceptions sont traitées, etc, etc

Quand on fait intervenir la bibliothèque, les membres, les invariants, etc en font partie. Si la taille des stream change (par exemple pour ajouter un mutex vu qu'il me semble me souvenir y avoir des cas où on peut accéder à un stream à partir de différentes threads sans ajouter de synchro extern), l'ABI change aussi.

Oui, il y a des changements qu'on peut faire en conservant la compatibilité de l'ABI (sous condition de lier avec la dernière lib), mais plus il y a de code exposé (inline, template), plus il y a de contraintes à respecter.

[3DArchi]

Salut,

Envoyé par bloomenthal

Comme il a été suggéré, ces programmes pourraient "juste" ne pas passer la compilation en c++0x, mais compiler en c++98.

Bilan : tout serait compilé en C++98 et C++0x ne serait pas diffusé . En général, on cherche au maximum à uniformiser les chaines de productions et minimiser le nombre de différentes configurations. Je serais surpris qu'un projet se découpe en fonction de la version de la norme.

Envoyé par bloomenthal

Si on a un programme écrit suivant le standard C++-pierrafeu et que notre compilateur supporte encore ce standard, hé bien c'est très bien, rien n'oblige à le compiler en C++-0X (quel intéret ?), ou alors, hé bien il faut se mettre au boulot, sinon, qu'apporte le standard dans tout ça ?

La compatibilité permet de diffuser les nouveautés dans le code existant. Si le code C++ pierrafeu (98 pierrafeu ? c'était hier) ne compile pas avec un compilo supportant la nouvelle norme, alors on basculera probablement vers un compilo (ou une conf du compilo) qui supporte l'existant et les nouveautés ne seront jamais diffusées. Je reste persuadé que c'est cette cohabitation qui permet aux nouveautés d'être utilisées et diffusées.

Envoyé par bloomenthal

"je ne serai pas rétro compatible, donc merci de l'assurer à ma place si vous voulez que le langage soit pérenne et que l'industrie y trouve son compte" ?

D'une certaine façon c'est ce que microsoft a fait lorsqu'il a déprécié Visual 6. Le compilo a été changé pour devenir plus conforme à la norme. Et bien que c'est-il passé ? Pas mal d'entreprise ont continué à utiliser Visual 6 car le risque du portage ne voulait pas être pris.


Je serais le premier à souhaiter qu'on nous donne le temps nécessaire pour réachitecturer les softs, pour explorer les nouveautés du langages, pour virer le C with classes et le remplacer par des pratiques plus 'modernes'. C'est beaucoup plus intéressant. Mais, et c'est tout aussi intéressant, on préfère ajouter des nouveautés que 'polir' l'existant qui marche.

[stardeath]

réponse à Jean-Marc.Bourguet :

merci pour ces explications, vu comme ça, effectivement c'est loin d'être trivial.
ça m'empêchera pas d'être toujours fasciné par la non cohérence du c++ et du futur c++0x alors ><

[nikko34]

Pour revenir là dessus, comme C++ a quand même entre autre une vocation de langage pour la programmation système, je crois qu'on aura toujours des char*.

Mais oui sinon pourquoi pas dans le main utiliser directement des vector std::string en option.

[Jean-Marc.Bourguet]

Envoyé par nikko34

Pour revenir là dessus, comme C++ a quand même entre autre une vocation de langage pour la programmation système, je crois qu'on aura toujours des char*.

Mais oui sinon pourquoi pas dans le main utiliser directement des vector std::string en option.

Personne ne l'a propose dans les formes. A mon avis ce serait passe au moment ou on a ajoute des surcharges utilisant std::string aux fonctions qui avaient des char const* en parametres, toujours a mon avis, maintenant c'est trop tard.

Work around pas complique (mais loin d'etre l'ideal en situation d'apprentissage ou ce serait le plus utile)

Code :

1
2
3
4
5
 
int main(int argc, char** argv) {
   std::vector<std::string> args(argv, argv+argc);
   ...
}

(Mais vu le nombre de bibliotheques qui s'amusent avec les arguments, il faudrait quand meme vite passer a la forme normale)

[Klaim]

Ca peut toujours être suggéré pour la prochaine version. Il suffit de proposer un document expliquant la feature, non?

[Jean-Marc.Bourguet]

Envoyé par Klaim

Ca peut toujours être suggéré pour la prochaine version. Il suffit de proposer un document expliquant la feature, non?

Pour proposer, a peu pres. Si tu n'as pas quelqu'un pour suivre et militer pour cela, un document a peu de chance d'etre reellement regarde, sans meme parler de convaincre.

Quelque chose comme ceci a plus de chances a mon avis dans un paquet coherent (comme celui auquel je faisais allusion sur les surcharges) qu'isole.