IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez C++ Discussion :

C++0x : Final Committee Draft disponible


Sujet :

Contribuez C++

  1. #21
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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 chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2002
    Messages : 918
    Points : 1 921
    Points
    1 921
    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

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

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    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
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    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é

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Avril 2010
    Messages
    27
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2010
    Messages : 27
    Points : 25
    Points
    25
    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é

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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é

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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é

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    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é

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    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 éprouvé
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    780
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2006
    Messages : 780
    Points : 1 176
    Points
    1 176
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 717
    Points : 3 344
    Points
    3 344
    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 éminent

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    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.

Discussions similaires

  1. Final Committee Draft disponible
    Par Jean-Marc.Bourguet dans le forum C++
    Réponses: 3
    Dernier message: 31/03/2010, 13h18
  2. Silverlight 3 disponible en version finale
    Par Jérôme Lambert dans le forum Silverlight
    Réponses: 29
    Dernier message: 01/10/2009, 12h25
  3. Gajim version 0.12 finale disponible
    Par aodix dans le forum Internet
    Réponses: 0
    Dernier message: 19/12/2008, 19h05
  4. mandriva est il disponible dans sa version finale ?
    Par kerkennah dans le forum Mandriva / Mageia
    Réponses: 7
    Dernier message: 25/05/2007, 23h37
  5. [Info] Virtual PC 2007 disponible en version finale
    Par al1_24 dans le forum Autres Logiciels
    Réponses: 8
    Dernier message: 23/03/2007, 09h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo