Tous ces arguments sont valables.
Et pourtant on fait le même travail plus rapidement en Java.
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
Tous ces arguments sont valables.
Et pourtant on fait le même travail plus rapidement en Java.
C'est sûr, c'est tellement mécanique et bête à faire que ça en devient un peu chiant à faire à la main.
Mais c'est typiquement le genre de truc où l'éditeur de texte ou l'EDI devrait ou devrait pouvoir proposer automatiquement (et Visual C++ le fait automatiquement, je crois, mais avec un #pragma once au lieu de faire des #define).
Je pense que ça doit pas être compliqué à faire sous emacs ou vi, avec des macros.
Si c'est le plus gros reproche que tu as a faire au C++, tu ne le connais pas assez.Envoyé par BugFactory
Tous ces arguments sont valables.
Et pourtant on fait le même travail plus rapidement en Java.
Si c'est un facteur important dans ta productivite, c'est que tu ne maitrises pas assez les outils autour.
Personnellement, je ne connais certainement pas assez Java pour en parler d'autorite, mais un probleme classique avec la confusion(*) de l'interface (je sais, il y a une notion d'interface en Java, j'utilise le terme dans un sens moins formel) et de l'implementation, c'est la difficulte a separer le travail -- a utiliser une interface non encore implementee, a garantir que l'interface ne change pas sans revue plus contraignante que pour les changements d'implementations, etc.
(*) Confusion et unification designent essentiellement la meme chose, simplement la desirabilite differe.
Et comment on compile ailleurs?
Justement c'est le problème. Mais peut-être qu'il y a une option pour modifier ça. Comme tu vois je maitrises pas l'outil non plus.
Dans mes souvenirs, les wizards de VC6 rajoutaient les #ifndef et le #pragma once.
Pour vi je ne sais, cela risque d'être un peu pénible
Pour emacs, cela existe
Pour vim, je maintiens un plugin qui fait ça et bien plus encore.
Dans tous les cas, il s'agit d'utiliser un outil de qualité professionnelle et d'apprendre à s'en servir pour ce genre de choses.
De souvenir le #pragma once n'est qu'une optimisation, pas un remplacement pour les #ifndef. Ca permettrait juste d'éviter que le fichier ne soit lu inutilement (à la recherche du #endif correspondant), ou quelque chose dans ce genre.
Oh que oui.
Seulement voilà : il faut avoir été débutant avant d'être expert. Un problème qui ne se pose qu'aux débutants n'est pas pour autant négligeable.
C'est en fait probablement ce qui peut le plus comprommettre l'avenir du C++ : c'est plus facile de former un développeur à Java, donc les entreprises s'orienteront plus facilement vers ce dernier.
Oui aussi, mais la moindre perte de temps qu'on aurait pu éviter est une perte de temps de trop.
En effet, Code::Blocks par exemple dispose de wizards qui s'en occupent tout seul la plupart du temps. Mais dès que l'on essaye de faire quelque chose d'un peu compliqué, on peut se retrouver à poster un message sur developpez pour demander de l'aide parce que les wizards sont dépassés (et le développeur aussi). Eclipse fait tout, tout seul, y compris les imports, et sans erreurs.
Au bout de six mois, je suis censé avoir terminé le développement, pas le commencer
C'est le cas en Java. De plus les interfaces fonctionnent de façon simple et élégante (par héritage.) Ca permet aussi de créer plusieurs implémentations d'une interface et préciser laquelle utiliser via un fichier xml sans changer le code (utilisé par exemple par le framework Spring avec l'inversion de contrôle).
Mais ça fait beaucoup de texte au sujet de l'absence d'une vraie gestion de modules, je propose d'arrêter là. J'ai simplement évoqué ma dernière difficulté en date, je n'avais pas l'intention de faire la publicité de Java qui a ses propres inconvénients.
C'est une façon de définir des interfaces, ce n'est pas la seule (par exemple, regarder pimpl), et elle n'est pas sans inconvénients. En particulier elle impose un coût d'héritage (et de passage par pointeurs) qui peut ne pas être souhaitable dans tous les cas.
Dans un monde idéal, la partie privée d'une classe ne devrait pas faire partie de l'interface de cette classe, et le .h constituerait l'interface publique uniquement.
Pour les modules, le papier se trouve sur http://www.open-std.org/jtc1/sc22/wg...2006/n1964.pdf mais comme l'a dit Jean-Marc, il ne sera a priori pas accepté dans le standard, pour des raisons de temps, principalement.
Bonsoir,
Décidément, le blog d'Herb Sutter est riche en infos sur le futur.
Dernièrement on a eu droit à des liens vers des videos d'exposés "google talk". On y trouve une présentation des nouveautés du C++0x, un exposé sur la "concurrence", un sur les list-initialiser, un sur les concepts, et un sur le multi-threading. (chaque présentation dure environ une heure)
C'est par là: http://herbsutter.spaces.live.com/bl...51BB!239.entry
A propos de l'avenir de C++ et de la pertinence de ce langage pour développer des projets, les points de vue de Benoît Schillings et Matthias Ettrich sont intéressants je pense:
http://qt.developpez.tv/2006-devdays/#benoit-schillings
Dommage qu'actuellement la programmation générique ne soit pas assez connue.
J'espère qu'avec l'arrivée des concepts, entre autres, elle sera plus utilisé. Beaucoup (trop) de gens s'arrêtent à l'écriture, qui peut paraître compliquée, des templates.
J'ai vu aussi qu'au comité on parlait également de quelque chose pouvant faciliter l'utilisation du RAII dans C++0x. Quelqu'un aurait un lien ou un commentaire sur le sujet ?
Au fait, vous avez essayé ConceptGCC ? Votre opinion sur ce compilateur ?
Bah c'est GCC 4.3 + des patchs pour les concepts.
Oui. Je voulais plutôt demander l'avis quand à l'utilisation des concepts avec ce dernier...
En regardant les nouveautés de la nouvelle norme je vois une réutilisation du mot clé "auto". Très bien il est quasiment pas utilisé.
Mais je vois aussi l'introduction d'un nouveau mot clé : "where"...
Et là une question surgit que vont devenir les programmes qui utilisaient ce "where" comme variable ?
Je sens qu'on va être obliger de # definer tout ça pour que ça reste compilable? Non ?
Je pense qu'avec un IDE "normal", il suffit de faire un Rechercher/Remplacer : "where" -> "where_1" par exemple. Cette contrainte est vraiment négligeable par rapport à ce que va faire apporter au programmeur ce nouveau mot clé. D'ailleurs il me semble que maintenant c'est remplacé par requires<>. Mais je ne suis pas sur.
C'est peut etre un contextual keyword, comme en C++/CLI ou ref n'est pas un keyword, sauf s'il est suivit de class par exemple "ref class", ...
Il n'y a pas de mot-clé sensible au contexte en C++ ou C++0x.
Il me semble que le mot-clé n'est cependant pas 'where' mais 'requires'.
Oui oui, cf mon message du dessus. Ils l'ont remplacé depuis quelques temps. Dans un certain nombre de pdf, on lit requires mais plus where. Ca faisait trop SQL?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager