Discussion :

[djarBoy]

Totalement d'accord avec ceci. Il faut arrêter avec Java.
Qt est l'avenir.

[fregolo52]

Totalement d'accord avec ceci. Il faut arrêter avec Java.
Qt est l'avenir.

Tu peux argumenter ? Pourquoi ce framework plutôt qu'un autre ?

Sur ce site il y a un déjà un grand débat C++ vs Java.

Pour le peu de Java que j'ai fait, ces 2 langages peuvent être complémentaire et non concurrentiel.
Je vois mal une unité de calcul au Cern ou CEA autre qu'en C/C++. Et j'ai tout autant de mal à voir un WebService en C++. Même si c'est possible de faire les 2 dans les 2 langages.

Pour en revenir au titre, avec Java tu fais un dév cross-plateformes, en C++ y'a toujours une adaptation du dév. Si c'est pas toi qui la fait c'est le framework.

Pour les mobiles, je n'y connais rien (j'ai fait un peu de PalmOS), chaque OS a son propre mode de fonctionnement, donc comment est-il possible de faire un code multi-plateforme ? Si Embarcadero crée un framework qui fait abstraction de toutes les spécificités des OS, je leur tire mon chapeau.

[Jbx 2.0b]

Même si chaque langage continue et continuera à avoir ses particularités, ses avantages et ses défauts, il faut avouer que la montée en puissance de Qt met un pavé dans la mare dans le monde du développement cross-platform. Avec Qt, on atteint une productivité parfois supérieure à celle qu'on peut avoir avec aux autres langages objets pourtant parfois bien plus récents, tout en continuant à bénéficier d'optimisations bas-niveau si nécessaire.

Il comble le gros soucis du langage qu'on avait il y a encore quelques années, à savoir développer rapidement tout en assurant la compatibilité multi-platformes sans efforts supplémentaires ou presque, et sans devoir empiler trente milles librairies différentes (avec les incohérences que ça suppose, rien que de devoir assurer les fonctions de conversions entre des strings et autres conteneurs de lib différentes, j'en ai soupé...).

Plus le temps passe et plus je me dis que j'ai peut-être finalement misé sur le bon cheval, les annonces sur Qt devenant de plus en plus intéressantes.

[Gugelhupf]

Qu'est-t-il possible de faire avec un autre langage par rapport au C++ ?
De la réflexion, de la sérialisation (quoi que avec Boost), et une meilleure gestion des chaines (je pense au split(), join() qui sont absent dans le standard même si présent dans Boost...)
Avec C++11, et plus tard C++17 (Modules, API : FileSystem et Networking), je pense que le C++ n'aura rien à envier aux autres langages.

Je pense qu'on pourrait très bien faire du mobile et du web en C++ (oui oui, du web), mais si on ne le fait pas trop maintenant, c'est qu'on ne le fera pas forcément plus tard non plus.

Personnellement, ce n'est pas vraiment les pointeurs et la gestion de la mémoire qui m'inquiètent, car comme dit plus haut on a les références (&), aujourd'hui les pointeurs sont nécessaires pour les collections hétérogènes ou pour les classes qui s'appellent elles-mêmes (liste chainée par exemple).
Avec "pour un new de créé, faire un delete" et le RAII il ne devrait pas y avoir de problème de mémoire.

Ce qui m'inquiète c'est plutôt la richesse du C++, moi-même j'en apprend tout les jours sur ce langage, alors que pour Java j'en ai fais le tour en quelques semaines/mois (sans compter les API).
C++ est plus "permissif" (les variables globales, l'héritage multiple par exemple), il demande plus de temps d'apprentissage et donc on est susceptible d'avoir une courbe d'apprentissage plus longue (ex: j'ai une variable au-dessus de la déclaration d'une classe, puis d'une fonction, est-ce que la variable est accessible dans la classe, et dans la fonction ? à quoi sert "::variable" dans un programme ? Différence entre un struct et une class ? Pourquoi peut-f-on faire de l'héritage privé ? etc... ).
Autre exemple, avec différentes manières de déclarer et initialiser en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::vector<std::string> v = { "xyzzy", "plugh", "abracadabra" };
std::vector<std::string> v({ "xyzzy", "plugh", "abracadabra" });
std::vector<std::string> v{ "xyzzy", "plugh", "abracadabra" }; // see "Uniform initialization" below

C'est justement cette richesse qui peut se retourner contre les développeurs qui travaillent en équipe.

Après il faut voir le bon coté des langages de "haut niveau", les langages compilés en bytecode je veux dire, si on met de coté le garbage collector.
Java avait des performances mitigés au début mais donne des performances assez proches du C++ dans certains cas aujourd'hui, même si la consommation de mémoire reste supérieur.
Je pense qu'il y a du bon dans un langage plus cadré et restrictif comme Java.

[Klaim]

Je pense qu'on pourrait très bien faire du mobile et du web en C++ (oui oui, du web), mais si on ne le fait pas trop maintenant, c'est qu'on ne le fera pas forcément plus tard non plus.

Il se trouve que c'est exactement l'inverse: on fait plus de web et de mobile avec C++ qu'auparavant (sans que ca soit super explosif comme grandissement non plus). Essentiellement parceque certaines applications gourmandes en resources sont moins cher a gerer en C++ (parceque contrairement a ce que certains pensent, les cou des serveurs ou les perfs peut parfois etre plus cher que le salaire des developpeurs... ne serait-ce que si ca rends l'application difficilement utilisable.)

Personnellement, ce n'est pas vraiment les pointeurs et la gestion de la mémoire qui m'inquiètent, car comme dit plus haut on a les références (&), aujourd'hui les pointeurs sont nécessaires pour les collections hétérogènes ou pour les classes qui s'appellent elles-mêmes (liste chainée par exemple).
Avec "pour un new de créé, faire un delete" et le RAII il ne devrait pas y avoir de problème de mémoire.

A part RAII, ce ne sont pas les arguments qu'un developpeur de C++ moderne aurait apporte........

Ce qui m'inquiète c'est plutôt la richesse du C++, moi-même j'en apprend tout les jours sur ce langage, alors que pour Java j'en ai fais le tour en quelques semaines/mois (sans compter les API).
C++ est plus "permissif" (les variables globales, l'héritage multiple par exemple), il demande plus de temps d'apprentissage et donc on est susceptible d'avoir une courbe d'apprentissage plus longue (ex: j'ai une variable au-dessus de la déclaration d'une classe, puis d'une fonction, est-ce que la variable est accessible dans la classe, et dans la fonction ? à quoi sert "::variable" dans un programme ? Différence entre un struct et une class ? Pourquoi peut-f-on faire de l'héritage privé ? etc... ).
Autre exemple, avec différentes manières de déclarer et initialiser en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::vector<std::string> v = { "xyzzy", "plugh", "abracadabra" };
std::vector<std::string> v({ "xyzzy", "plugh", "abracadabra" });
std::vector<std::string> v{ "xyzzy", "plugh", "abracadabra" }; // see "Uniform initialization" below

C'est justement cette richesse qui peut se retourner contre les développeurs qui travaillent en équipe.

Dans la pratique, je pense que c'est de la pessimization.
L'avenir nous le diras mais pour avoir ete dans des cas de fortes differences de connaissances du C++ dans l'equipe, tant qu'il y q quelqu'un pour transferere les connaissances c'est vraiment un probleme tres mineur.
Ou alors les devs veulent pas apprendre auquel cas c'est un autre probleme bien plus grave...

Après il faut voir le bon coté des langages de "haut niveau", les langages compilés en bytecode je veux dire, si on met de coté le garbage collector.

(note anexe) Deux choses bien differentes. "haut niveau" ca sous entends "loin de la machine" et C++ est aussi bien haut que bas niveau (et va meme parfois plus haut que la plupart des language courants).

[Freem]

Pour en revenir au titre, avec Java tu fais un dév cross-plateformes, en C++ y'a toujours une adaptation du dév. Si c'est pas toi qui la fait c'est le framework.

Si on veut jouer sur les mots, avec Java, c'est du dev mono plateforme: le binaire généré ne fonctionne que sur une machine virtuelle java

Si c'est le framework qui s'adapte, alors où est le problème? L'important, c'est que le programme ne soit pas modifié d'une plate-forme à l'autre, peu importe que ce soit le framework qui fasse l'abstraction!

Pour les mobiles, je n'y connais rien (j'ai fait un peu de PalmOS), chaque OS a son propre mode de fonctionnement, donc comment est-il possible de faire un code multi-plateforme ? Si Embarcadero crée un framework qui fait abstraction de toutes les spécificités des OS, je leur tire mon chapeau.

Hum... justement, ces derniers temps, le nombre d'OS à tendance à se réduire, non?
Si ils arrivent à faire un truc qui marche sur iTrucs et android, ils touchent déjà 80% du marché, je pense.

Après, côté technique, je doute fortement que le principe de fonctionnement de l'API des OS soit fondamentalement différent: déjà, beaucoup sont basés sur un UNIX, ce qui permet d'utiliser POSIX. Ca résout une bonne partie des problèmes.
Après, côté graphique, le principe est toujours le même: un buffer, des fonctions pour le manipuler, un système de coordonnées, voire, allez, un contexte openGL.

En C++, tu fait quelques templates "primitives", et tu bâtis le reste du framework dessus. Reste plus qu'a spécialiser les templates pour chaque OS que tu veux supporter, le reste s'adapte automatiquement.

Qu'est-t-il possible de faire avec un autre langage par rapport au C++ ?
De la réflexion, de la sérialisation (quoi que avec Boost), et une meilleure gestion des chaines (je pense au split(), join() qui sont absent dans le standard même si présent dans Boost...)

Comme tu le dis si bien, boost permet la serialization. La réflexion, je ne sais pas. D'ailleurs, je ne sais pas à quoi ça sert... enfin, en théorie, oui, mais dans la pratique...

Sinon, qu'est-ce qui est possible en C++ qui ne l'est pas dans les autres langages, c'est une question intéressante aussi.
Par exemple, surcharge d'opérateur que Java n'a pas aux dernières nouvelles.
Paramètres par défaut que C# n'a pas.
Héritage multiple, qui peut avoir son utilité, bien qu'a utiliser avec prudence...
Divers sites de référence propres! Genre cplusplus.com ou cppreference.com. Parce que désolé de dire ça, mais je ne parviens que difficilement à m'y retrouver dans la doc Oracle et dans la msdn.

Et surtout, des conteneurs très bien foutus et intuitifs!
Genre std::set, si on le compare à HashSet de C#, c'est plus agréable à manier je trouve, ou alors j'ai raté une étape... std::set, je n'ai eu besoin que de 5 minutes la première fois pour comprendre comment ça marche avec une classe faite par l'utilisateur. Avec HashSet, il semble que je n'ai rien commpris puisque le résultat que je veux, je ne l'ai toujours pas.
Il y a aussi les versions "multi". Je sais pas pour Java, mais .NET ne les intègre pas.

Avec C++11, et plus tard C++17 (Modules, API : FileSystem et Networking), je pense que le C++ n'aura rien à envier aux autres langages.

Vrai que filesystem manque cruellement...
Pour moi, C++ & boost permet de tenir la dragée haute aux autres langages. Manque que l'IHM, mais pour moi, les IHM ne doivent pas être intégrées au standard, ça bouge bien trop vite pour ça, et on parle de standard industriel ici, pas d'un standard pour la mode.

C'est justement cette richesse qui peut se retourner contre les développeurs qui travaillent en équipe.

Tu soulèves un sacré lièvre. C'est vrai que C++ demande probablement une meilleure coordination des gens, et il certain que l'apprentissage est plus long.

D'un autre côté, une fois maîtrisé, je pense que ce langage est plus productif que les autres. J'ai plus qu'a espérer qu'un jour j'aie un CDI dans une boîte ou les chefs pensent comme ça aussi

[fregolo52]

Hum... justement, ces derniers temps, le nombre d'OS à tendance à se réduire, non?
Si ils arrivent à faire un truc qui marche sur iTrucs et android, ils touchent déjà 80% du marché, je pense.

Aujourd'hui, sûrement.
Demain (en janvier, on verra les chiffres des ventes de noël), avec les tablettes, faudra pas oublier Windows et après demain Linux (Ubuntu).

[youtpout978]

Sujet très intéressant, mais il semble que certaine personne ne connaisse pas bien les langages que sont Java et c# (comme moi qui n'y connait pas grand chose au c++), certes le c++ évolue mais pas aussi vite que ces 2 là (je parle de la standardisation).
Et bon le cross-plateforme c'est jolie sur le papier, mais la mise en œuvre c'est pas la même chose.
Pour une classe de base sans traitement elle marchera sûrement tel quel sur tous les mobiles, mais à partir du moment où on a des traitements des interactions avec le téléphone chaque plateforme à ses librairies et ses méthodes propres, après suffit de mettre une couche d'abstraction (c'est aussi l'un des rôles des machines virtuel) mais existe-t-il une solution vraiment correcte et performante à l'heure actuelle (qui serait très proche d'un développement natif ciblant la plateforme) ?
Je pense que c'est surtout là qu'est le problème peut importe le langage.

Et surtout, des conteneurs très bien foutus et intuitifs!
Genre std::set, si on le compare à HashSet de C#, c'est plus agréable à manier je trouve, ou alors j'ai raté une étape... std::set, je n'ai eu besoin que de 5 minutes la première fois pour comprendre comment ça marche avec une classe faite par l'utilisateur. Avec HashSet, il semble que je n'ai rien commpris puisque le résultat que je veux, je ne l'ai toujours pas.
Il y a aussi les versions "multi". Je sais pas pour Java, mais .NET ne les intègre pas.

Pour le hashset c'est super simple à utiliser (toujours regarder les exemples du msdn) après faut voir ce que tu voulais faire avec.

[r0d]

Vrai que filesystem manque cruellement...

flesystem est à double tranchant, et n'a, à mon avis, pas sa place dans le standard du langage lui-même. c++ est sensé être indépendant de la plateforme sur laquelle il est compilé (processeur et os, c'est la raison pour laquelle, par exemple, la taille des types natifs n'est pas définie dans le standard). Cette indépendance vis à vis de la plateforme est, à mon avis, un bon choix, car gérer les différences entre plateforme au niveau du standard du langage serait ingérable et amènerait inévitablement à une perte de portabilité. L'inconvénient est que le programme doit être compilé sur la plateforme cible.

C'est pourquoi c'est une bonne chose que filesystem reste dans une lib tierce (boost en l'occurence, et vous remarquerez que boost::filesystem doit être compilé; on ne peut pas utiliser uniquement l'en-tête).

[Freem]

flesystem est à double tranchant, et n'a, à mon avis, pas sa place dans le standard du langage lui-même. c++ est sensé être indépendant de la plateforme sur laquelle il est compilé (processeur et os, c'est la raison pour laquelle, par exemple, la taille des types natifs n'est pas définie dans le standard). Cette indépendance vis à vis de la plateforme est, à mon avis, un bon choix, car gérer les différences entre plateforme au niveau du standard du langage serait ingérable et amènerait inévitablement à une perte de portabilité. L'inconvénient est que le programme doit être compilé sur la plateforme cible.

Et pour ouvrir un fichier?
Et pour afficher du texte?
Et pour exécuter une commande système?
Les fonctions ne sont pas compilées, pour toi? Il faut m'expliquer comment tu fais alors...
Le standard définit les résultats des appels à des fonctions sans préciser comment ce résultat doit être obtenu, et c'est ce manque qui permet d'avoir quelque chose de portable.

Tu commet une erreur de logique ici il me semble. Tu compares par l'affirmation deux éléments alors que tu avoues tout ignorer de l'un d'entre eux (ex. Je n'ai jamais mangé de pomme, mais j'affirme que la poire est meilleure que la pomme).

Il est de notoriété commune que le standard actuel, surnommé C++11, à mis près de 10 ans à naître.
C++ évolue réellement moins vite que les autres langages, et je peux dire, sans avoir goûté à une pomme, qu'elle à poussé moins vite qu'une poire, pour reprendre ton analogie.

Par contre, dire que la vitesse d'évolution des standards d'un langage type Java/C# est un avantage comparé à C++, je suis à la fois d'accord et pas d'accord.
Java, par exemple, à un standard de base (le premier je parle) assez primitif, qui n'avait même pas les template. D'un autre côté, les langages de VM ne boxent pas dans la même catégorie: là où C++ vise à être général et utilisable pour n'importe quelle application, Java et C# me semblent viser principalement les applications à faible contraintes de performance machine mais à grosses contraintes de rendement en terme d'interfaces Homme Machine.
Hors, pour l'électronique, je pense que les évolutions rapides sont moins utiles que les évolutions stables, contrairement au domaine des IHM ou il faut un peu "suivre la mode". D'où la dualité dans mon propos précédent.

Par rapport à HashSet, brièvement, parce que ce n'est pas le sujet ici (quoique), pour l'utiliser avec une classe utilisateur, il faut manifestement(cf http://badger.developpez.com/tutoriels/dotnet/hashset/ ) écrire une seconde classe implémentant IEqualityComparer. Ce n'est pas exactement très pratique, et le comportement est assez étrange, en tout cas, sur ce que j'ai tenté de faire, j'ai du commettre un impair puisque le résultat n'est pas celui attendu.
En C++, avec std::set, il suffit d'implémenter l'opérateur inférieur bool Foo::operator<(Foo const& other) et tout est géré tout seul.

[djarBoy]

Tu peux argumenter ? Pourquoi ce framework plutôt qu'un autre ?

Sur ce site il y a un déjà un grand débat C++ vs Java.

Pour le peu de Java que j'ai fait, ces 2 langages peuvent être complémentaire et non concurrentiel.
Je vois mal une unité de calcul au Cern ou CEA autre qu'en C/C++. Et j'ai tout autant de mal à voir un WebService en C++. Même si c'est possible de faire les 2 dans les 2 langages.

Pour en revenir au titre, avec Java tu fais un dév cross-plateformes, en C++ y'a toujours une adaptation du dév. Si c'est pas toi qui la fait c'est le framework.

Pour les mobiles, je n'y connais rien (j'ai fait un peu de PalmOS), chaque OS a son propre mode de fonctionnement, donc comment est-il possible de faire un code multi-plateforme ? Si Embarcadero crée un framework qui fait abstraction de toutes les spécificités des OS, je leur tire mon chapeau.

Effectivement, je trollais un peu.

Maintenant, et pour etre un peu plus sérieux, je prends tellement plaisir à coder des choses avec le C++, boost et Qt que je ne vois plus l'utilité d'employer un autre langage (excepté le temps de compilation).

Par exemple, les signaux de boost (pour le modèle et le controlleur) et ceux de Qt (pour le controlleur et la vue) m'aident beaucoup à coder un MVC que je trouve séduisant.

Après, mes souvenirs de Java ont 10 ans, j'imagine que les choses ont évoluées.

Pour le webservice, je ne connais pas bien le web, mais mon avis est que Java est sur sa fin par les choix que fait Oracle, le dernier procès avec Google en est la preuve. Je trouve par contre que GWT est une bonne solution.

[SurferIX]

En parfaite adéquation avec la création d’applications d’entreprise.

Je déteste dire ça, mais aujourd'hui, tout développement d'application doit (malheureusement) se faire vite.

Et, pour simplifier au maximum, C++ ne donne pas la possibilité de faire vite.

Encore une fois, j'insiste, aujourd'hui, malheureusement ça n'est pas la qualité et la pérennité, mais la vitesse de développement.

Aujourd'hui la mode est au code jetable : on fait vite, à l'arrache, ça prend deux jours, ça marche. Dans un mois il faut faire une évolution ? On jette l'ancien code, on fait vite, à l'arrache, ça prend deux jours, ça marche.

Le C++ n'a pas ce rapport "vitesse / ça marche" qu'ont tous les autres langages (cf tous les posts précedents) : C#, Php et même Delphi.

Je ne critique pas le C++ en tant que tel, je dis juste que ce discours n'est pas en rapport avec le marché mondial actuel. Et encore une fois : "malheureusement".

[Klaim]

Je déteste dire ça, mais aujourd'hui, tout développement d'application doit (malheureusement) se faire vite.

Generalisation fausse.

Les projets d'applications medicales, militaires, de robotique, d'infrastructure, de recherche ont pour priorite d'etre correct, pas vite fait (au risque de devenir litteralement mortel). Note que c'est la ou C++ est le plus present. La qualite dans le jeu video se fait avec du temps aussi quelque soit le language.

Donc non pas toute. La plupart.

Et, pour simplifier au maximum, C++ ne donne pas la possibilité de faire vite.

Discutable. C++ a des desavantage cote vitesse d'iteration oui. Ca ne veut pas dire que tu ne peux pas coder rapidement une appli en C++. Ca necessite certainement plsu de connaissances de base du language (entre autre) avant d'arriver a coder rapidement en C++, mais c'est loin d'etre impossible. J'ai fait des game jams de 3h ou de 2 jours en C++.

Encore une fois, j'insiste, aujourd'hui, malheureusement ça n'est pas la qualité et la pérennité, mais la vitesse de développement.

Toujours faux, ca depends des domaines. Google, Facebook et d'autres ont C++ dans leur systeme de fond (chez Facebook ils vont encore plus loin avec C++ apparemment) et ya de bonnes raisons qui n'ont pas a voir avec la vitesse de developpement parceque c'est pas la priorite.

Cela etant dis, comme il y a effectivement un ralentissement a coder en C++, ils travaillent tous avec le standard et les outils comme CLang pour ameliorer la vitesse a laquelle on itere en C++.

Aujourd'hui la mode est au code jetable : on fait vite, à l'arrache, ça prend deux jours, ça marche. Dans un mois il faut faire une évolution ? On jette l'ancien code, on fait vite, à l'arrache, ça prend deux jours, ça marche.

Je sais pas ou tu bosses mais dans toutes les boites ou j'ai bosse, tu fais ou pense comme ca, tu prends la porte dans la minute.

Le C++ n'a pas ce rapport "vitesse / ça marche" qu'ont tous les autres langages (cf tous les posts précedents) : C#, Php et même Delphi.

Et pourtant... la plupart des gros jeux sont en C++. Recemment, Super Hexagon, qui est un petit jeu mais tres rapide et cross-platform, a ete totalement recode en C++. Qu'est-ce que ca pointe?

C++ n'est actuellement pas bon pour le prototypage de concept. Coder rapidement une idee, la tester, la mettre publique, etc, tout ca c'est chaud en C++.

Faire une application de qualite en revanche, selon les resources dispo, C++ colle largement au profil.

Je ne critique pas le C++ en tant que tel, je dis juste que ce discours n'est pas en rapport avec le marché mondial actuel. Et encore une fois : "malheureusement".

C'est comme si tu disais qu'il n'y avait pas de bonne raison de choisir C++ plutot qu'una utre language. Le critere de la vitesse d'ecrtiture de code est important mais pas pour tous les projets. Donc en fait non.

[Gugelhupf]

Si on veut jouer sur les mots, avec Java, c'est du dev mono plateforme: le binaire généré ne fonctionne que sur une machine virtuelle java

C’est le bytecode qui compte, c’est lui qui est multiplateforme.
Ensuite d’après mon expérience, je peux dire que Java est plus multiplateforme que C++.
Pour la gestion des dossiers par exemple, sans bibliothèque tiers, tu n’arriveras pas à compiler ton programme avec un même code source entre Linux et Windows.

Par exemple, surcharge d'opérateur que Java n'a pas aux dernières nouvelles.
Paramètres par défaut que C# n'a pas.
Héritage multiple, qui peut avoir son utilité, bien qu'a utiliser avec prudence...

• Surcharge d’opérateur : Java n’implémente pas des concepts dont le développeur peut s’en passer.
  Par exemple tu n’as pas les types non-signés (unsigned) non plus, ça peut paraître grave pour un développeur C++ mais pas Java, car tu peux t’en passer.
• Java n’a pas les paramètres par défaut mais C# les a, ce qu’il faut voir c’est pourquoi le C++ Google Style Guide déconseille leur utilisation et pousse les développeurs à utiliser la surcharge de méthode (chose qu’on fait en Java) -> Lire ici.
• Je demande juste à voir un cas concret où on ne peut pas se passer d’héritage multiple dans une conception.

Divers sites de référence propres! Genre cplusplus.com ou cppreference.com. Parce que désolé de dire ça, mais je ne parviens que difficilement à m'y retrouver dans la doc Oracle et dans la msdn.

Je dois reconnaître que cppreference.com s’est beaucoup amélioré.
Le msdn n’est pas trop mauvais, tu as même une version française.
Pour la javadoc tu as du lire l’ancienne documentation, celle de Java 7 est mieux foutu (exemple avec la classe String).

Manque que l'IHM, mais pour moi, les IHM ne doivent pas être intégrées au standard, ça bouge bien trop vite pour ça, et on parle de standard industriel ici, pas d'un standard pour la mode.

Pas besoin de rendre les IHM standard, ça ne sert à rien, même en Java on passe de Swing à JavaFX.
Pour les IHM il faut vivre avec son temps (Qt), par contre pour les bases de données, le standard pourrait très bien mettre en place des classes abstraites pour que les SGBD implémentent eux-mêmes des fonctions. Comme ça on aurait tous la même syntaxe dans les programmes (sans passer par Qt).

D'un autre côté, une fois maîtrisé, je pense que ce langage est plus productif que les autres. J'ai plus qu'a espérer qu'un jour j'aie un CDI dans une boîte ou les chefs pensent comme ça aussi

Le temps d’apprendre à « maitriser » un langage comme le C++, oui parce qu’il y a le je sais en faire et je m’en sors plutôt pas mal et je sais tout faire tu peux pas test…

Il se trouve que c'est exactement l'inverse: on fait plus de web et de mobile avec C++ qu'auparavant (sans que ca soit super explosif comme grandissement non plus).

Je ne vois pas beaucoup d’offre d’emploi dans le développement Web en C++, j’ai créé un sujet sur ça il y a quelques temps et je n’ai eu qu’un seul message. Si tu poste ton avis ici, j'en serais ravi

A part RAII, ce ne sont pas les arguments qu'un developpeur de C++ moderne aurait apporte........

Je me considère comme un développeur C++ moderne, quels arguments aurais-je du apporter ?

Un standard, c'est validé par une équipe internationale d'experts indépendants et non lié au working group qui a écrit le standard (ce qui permet de repérer les erreurs, les incohérences, les limites, etc)

Ce n’est pas parce que le C++ est standard que GCC ne contient pas d’erreur.
Peut-être que le JSR n’est pas un standard international, mais il n'est pas mauvais, ils ne font pas n'importe quoi chez le JCP.

[Klaim]

Je ne vois pas beaucoup d’offre d’emploi dans le développement Web en C++, j’ai créé un sujet sur ça il y a quelques temps et je n’ai eu qu’un seul message. Si tu poste ton avis ici, j'en serais ravi

J'y ai tellement repondu souvent sur programmers.stackexchange.com que ca fait un peu redondant. En gros ya pas mal de boites qui commencent a s'interesser au C++ pour le web (ou le cloud, comme chez Microsoft) essentiellement pour les applis web gourmandes ou embarques. Evidemment il est plus efficace a court terme de faire son appli web dans tous les languages fais pour etre rapide a coder. Mais quand le goulot d'etranglement deviens la performance du site ou le cout du harddware pour le maintenir, les boites en question se tournent vers les outils specialises pour ca.

Encore une fois ca reste peu de boites, mais ca augmente. Ca sera jamais C++ partout evidemment, et c'est sain comme ca.

Je me considère comme un développeur C++ moderne, quels arguments aurais-je du apporter ?

Ne pas utiliser new et delete du tout, RAII c'est la base, et d'autres choses expliques couramment sur le forume C++ par des paves de reponses de nos amis developeurs c++.

Ce n’est pas parce que le C++ est standard que GCC ne contient pas d’erreur.

Cette citation n'est pas de moi.

[Emmanuel Deloget]

Cette citation n'est pas de moi.

Je confirme, c'est la mienne

[koala01]

Salut,

Je déteste dire ça, mais aujourd'hui, tout développement d'application doit (malheureusement) se faire vite.

Je dois avoir travaillé pour des extra terrestres ces deux dernières années...

Et, pour simplifier au maximum, C++ ne donne pas la possibilité de faire vite.

Encore une fois, j'insiste, aujourd'hui, malheureusement ça n'est pas la qualité et la pérennité, mais la vitesse de développement.

Aujourd'hui la mode est au code jetable : on fait vite, à l'arrache, ça prend deux jours, ça marche. Dans un mois il faut faire une évolution ? On jette l'ancien code, on fait vite, à l'arrache, ça prend deux jours, ça marche.

En fait, lorsque on travaille (comme il est souvent recommandé de le faire) par petites itérations, on se rend souvent compte que les deux premières itérations sont, si l'on veut partir sur des bases saines, sans doute effectivement beaucoup plus lentes en C++, car l'analyse de base doit être particulièrement soignée.

Par contre, si cette analyse de base est soignée, dés la troisième itération, le rythme s'accélère et l'on perd beaucoup moins de temps que s'il fallait tour rejeter à l'itération suivante.

C'est vrai pour tous les langages, y compris pour C++

Si je venais à travailler pour une SSII qui me demande de faire du "rapide et crado", je lui demanderais mon C4 après trois mois

Le C++ n'a pas ce rapport "vitesse / ça marche" qu'ont tous les autres langages (cf tous les posts précedents) : C#, Php et même Delphi.

J'ai fait des POC en moins de deux jours prouvant qu'il était possible d'ajouter une fonctionnalité complexe à une application qui n'avait pas du tout prévu ce genre d'évolution...

Il y a parfaitement moyen de faire du "rapide" en C++, mais il est très largement préférable de faire du "bien"

C’est le bytecode qui compte, c’est lui qui est multiplateforme.
Ensuite d’après mon expérience, je peux dire que Java est plus multiplateforme que C++.
Pour la gestion des dossiers par exemple, sans bibliothèque tiers, tu n’arriveras pas à compiler ton programme avec un même code source entre Linux et Windows.

Si tu te limites strictement au C++ (comprends: sans recourir aux extensions propres à chaque compilateur), tu peux parfaitement arriver à quelque chose qui compile aussi bien sous linux que sous windows, le tout sans avoir à écrire ne serait-ce qu'une instruction conditionnelle quant à la plateforme visée .

Il n'y a, en définitive que certains aspects propres à l'OS pour lesquels ce n'est pas forcément vrai (généralement liés au système de fichiers, d'ailleurs), mais, en choisissant correctement les bibliothèques avec lesquelles tu devras de toutes manières travailler (C++ en standard reste malgré tout... dépouillé ), le seul problème qui pourrait subsister tiendrait plus largement de l'absence de certains outils sur certaines plateformes (je pense, par exemple, à l'absence de MsOffice sous linux )

[LIST][*]Surcharge d’opérateur : Java n’implémente pas des concepts dont le développeur peut s’en passer.
Par exemple tu n’as pas les types non-signés (unsigned) non plus, ça peut paraître grave pour un développeur C++ mais pas Java, car tu peux t’en passer.

Puis tu t'étonneras sans doute d'avoir un résultat incohérent en tentant d'accéder à un index négatif dans un tableau

[*]Java n’a pas les paramètres par défaut mais C# les a, ce qu’il faut voir c’est pourquoi le C++ Google Style Guide déconseille leur utilisation et pousse les développeurs à utiliser la surcharge de méthode (chose qu’on fait en Java) -> Lire ici.

Tu sembles avoir occulté un passage de la règle que tu cites, et que je reproduis intégralement

We do not allow default function parameters, except in limited situations as explained below. Simulate them with function overloading instead, if appropriate.

Ils interdisent l'usage de paramètres par défaut, sauf dans certaines situations.

A choisir, je préfère aussi les éviter autant que possibles

Sauf que, parfois, il est beaucoup plus sain de passer un paramètre par défaut que de fournir une surcharge supplémentaire, car cela se répercuterais sur trop de classes ou parce que cela nécessiterait un refactoring par trop important

Je demande juste à voir un cas concret où on ne peut pas se passer d’héritage multiple dans une conception.

Soient les classes

• Générateur, qui implémente l'interface ProducteurDeCourent,
• Turbine qui implémente les interfaces DebitVolumétrique et Rotatif
• Les fabriques qui vont bien pour ces deux classes
• UtilisateurDeTurbine, qui manipule une turbine en interne
• UtilisateurDeGenerateur, qui manipule un généateur en interne

Comment créer la classe Turbo-Generateur de sorte que les classes UtilisateurDeTurbine et UtilisateurDeGenerateur puissent en profiter conjointement pour leur évolution chacun de leur coté

Sans l'héritage multiple, c'est impossible, avec, cela ne te posera aucun problème

(note que la classe Turbine utiliserait déjà l'héritage multiple pour implémenter ses deux interfaces )

[r0d]

[*]Je demande juste à voir un cas concret où on ne peut pas se passer d’héritage multiple dans une conception.

On peut toujours se passer de tout, et alors on programme en assembleur.
Mais si tu veux un bon exemple d'utilisation d'héritage multiple, regarde la classe iostream de la stl.

[SurferIX]

Generalisation fausse.

Les projets d'applications medicales, militaires, de robotique, d'infrastructure, de recherche ont pour priorite d'etre correct, pas vite fait (au risque de devenir litteralement mortel). Note que c'est la ou C++ est le plus present. La qualite dans le jeu video se fait avec du temps aussi quelque soit le language.

Donc non pas toute. La plupart.

Tu as entièrement raison, et je m'excuse : j'ai la vision brouillée par le fait que je sois orienté Web et SSII. En fait tout ce que j'ai dit n'est valable que dans le cadre de développement Web allié à société de services.

(Développement Web + SSII) c'est tout de même une bonne partie du développement, mais je ne sais pas quel pourcentage.

Accepte toutes les excuses d'un gars qui a la vision brouillée par des discours journaliers du genre "tenir les délais à n'importe quel prix quitte à faire de la merde et à devoir tout réécrire plus tard, limite c'est mieux comme ça on vend encore plus"...

Mais quand le goulot d'etranglement deviens la performance du site ou le cout du hardware pour le maintenir, les boites en question se tournent vers les outils specialises pour ca.

De ce que j'en sais les développeurs balancent tout sur le hard. Pour simplifier (et c'est à peine caricatural) : "oulah, si c'est lent c'est le hard. Un bon i7 avec 32 Go de RAM sur un Linux dépouillé de tout ce qui est superflu et votre appli tournera". Hop in ingénieur système qui monte la totale en un jour + le prix d'un gros PC c'est moins cher que 3 devs qui bossent pendant plusieurs jours pour optimiser l'application. Encore une fois, j'ai peut être la vision brouillée par les SSII : "la rapidité de livraison avant tout" .

[transgohan]

...

Cela fait vachement peur comme vision du travail...
Quelle est le nom de votre SSII que je n'y postule pas ?
Ces gens là seraient bien incapables de coder pour des cartes électroniques s'ils sont pas fichu capable de faire un logiciel pour un ordinateur.