Cette "pureté" (je n'aime pas le terme non plus), c'est ce qui apporte la portabilité du développeur.
A avoir des macros, même simplificatrices, qui s'utilisent en place des artifices officiellement fournis par le langage, on s'engage dans un sous-dialecte qui n'aide pas à la migration des développeurs.
C'est comme cela que l'on se retrouve à avoir du C++/MOC, du C++/MFC, etc
Résultat, on se retrouve avec des gens qui doivent ouvrir une nouvelle doc (propriétaire! (à un framework)) pour utiliser des structures qui sont pourtant fournies en standard, lorsqu'ils migrent sur des projets qui reposent sur d'autres frameworks (wxWidgets, Qt, MFC, ACE, ...)
Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard (je pense aux itérateurs aliens (dans le contexte C++) de Qt, à leur FOREACH, etc, et de même pour les autres frameworks qui empiètent sur la SL, ou qui poussent à l'utilisation de macros dans le code client)
Après, et cela n'engage que moi, je ne crois pas en la pérennité des sous-dialectes -- même si certains font de la résistance (-> MFC). Si TT/Nokia poussait certains des éléments de Qt dans le prochain standard, ma foi cela pourrait assurer une pérennité. Mais, AFAIK, ce n'est pas le cas. Ils m'ont l'air de rester gentiment dans leur coin avec leurs clients. A côté de ça Adobe, dont ce n'est pourtant pas le métier de fournir un framework de fenétrage, publie des articles "théoriques", et s'investit dans les communautés motrices relativement à l'avenir du C++ (au travers de 3-4 individus).
[^] # Re: gcc lave plus blanc ?
Posté par lmg HS (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 1.
A avoir des macros, même simplificatrices, qui s'utilisent en place des artifices officiellement fournis par le langage, on s'engage dans un sous-dialecte qui n'aide pas à la migration des développeurs.
C'est comme cela que l'on se retrouve à avoir du C++/MOC, du C++/MFC, etc
Résultat, on se retrouve avec des gens qui doivent ouvrir une nouvelle doc (propriétaire! (à un framework)) pour utiliser des structures qui sont pourtant fournies en standard, lorsqu'ils migrent sur des projets qui reposent sur d'autres frameworks (wxWidgets, Qt, MFC, ACE, ...)
Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard (je pense aux itérateurs aliens (dans le contexte C++) de Qt, à leur FOREACH, etc, et de même pour les autres frameworks qui empiètent sur la SL, ou qui poussent à l'utilisation de macros dans le code client)
Après, et cela n'engage que moi, je ne crois pas en la pérennité des sous-dialectes -- même si certains font de la résistance (-> MFC). Si TT/Nokia poussait certains des éléments de Qt dans le prochain standard, ma foi cela pourrait assurer une pérennité. Mais, AFAIK, ce n'est pas le cas. Ils m'ont l'air de rester gentiment dans leur coin avec leurs clients. A côté de ça Adobe, dont ce n'est pourtant pas le métier de fournir un framework de fenétrage, publie des articles "théoriques", et s'investit dans les communautés motrices relativement à l'avenir du C++ (au travers de 3-4 individus).