Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 21 à 40 sur 64
  1. #21
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    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.

  2. #22
    Membre Expert
    Avatar de Joel F
    Homme Profil pro Joel Falcou
    Chercheur en informatique
    Inscrit en
    septembre 2002
    Messages
    919
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Falcou
    Âge : 34
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 919
    Points : 1 899
    Points
    1 899

    Par défaut

    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    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).

    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    (Merci de confirmer en passant que Java c'est pour les programmes jetables).
    quel est el sens du message

  3. #23
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 089
    Points : 3 924
    Points
    3 924

    Par défaut

    Citation Envoyé par Joel F Voir le message
    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.

  4. #24
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    Par défaut

    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.

  5. #25
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    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.

  6. #26
    Membre à l'essai
    Inscrit en
    avril 2010
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : avril 2010
    Messages : 27
    Points : 20
    Points
    20

    Par défaut

    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

  7. #27
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    Citation Envoyé par bloomenthal Voir le message
    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)

  8. #28
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par stardeath Voir le message
    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).
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  9. #29
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    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)

  10. #30
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par bloomenthal Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  11. #31
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par Joel F Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  12. #32
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par stardeath Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  13. #33
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    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" ><

  14. #34
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par stardeath Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  15. #35
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 672
    Points
    11 672

    Par défaut

    Salut,
    Citation Envoyé par bloomenthal Voir le message
    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.
    Citation Envoyé par bloomenthal Voir le message
    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.

    Citation Envoyé par bloomenthal Voir le message
    "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.

  16. #36
    Expert Confirmé

    Inscrit en
    février 2006
    Messages
    1 923
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 1 923
    Points : 2 904
    Points
    2 904

    Par défaut

    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 ><

  17. #37
    Membre émérite
    Profil pro
    Inscrit en
    mai 2006
    Messages
    718
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mai 2006
    Messages : 718
    Points : 817
    Points
    817

    Par défaut

    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.

  18. #38
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par nikko34 Voir le message
    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)
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  19. #39
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 718
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 718
    Points : 3 026
    Points
    3 026

    Par défaut

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

  20. #40
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 104
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 104
    Points : 5 985
    Points
    5 985

    Par défaut

    Citation Envoyé par Klaim Voir le message
    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.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •