Le meilleur langage pour le développement cross-platform est-il le C++ ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

11/12/2012, 14h25
Hinault Romaric

Le meilleur langage pour le développement cross-platform est-il le C++ ?

Le meilleur langage pour le développement cross-platform est-il le C++ ?
Embarcadero prévoit une résurgence du C++ dans le mobile

Lorsqu’il s’agit de développement mobile, les langages mis en avant pour la création d’applications multiplateformes sont couramment HTML et JavaScript.

Pour le développement natif, en fonction des écosystèmes, les développeurs s’orientent le plus souvent vers objective-c ou Java.

Pourtant, ceux qui cherchent à créer des applications cross-platform tout en bénéficiant d’une approche efficace pour la réduction des couts peuvent trouver leur bonheur au sein du C++.

C’est en tout cas ce que pense John Thomas, directeur de gestion des produits chez Embarcadero Technologies, qui a présenté les atouts du langage pour le développement mobile lors d’une session intitulée « le regain du C++ pour le développement d’app mobile » pendant la conférence DevCon5 de San Francisco.

C++ peut être utilisé pour développer des applications natives pour Android, iOS, Windows Phone, Windows RT et Blackberry 10, selon John Thomas, qui estime que « les développeurs commencent à réaliser que l’utilisation d’outils natifs pour chacun de ces écosystèmes est trop chère, et ceux-ci sont à la recherche d’une solution ».

En effet, le compilateur LLVM d’Apple pour son outil de développement Xcode prend entièrement en charge C++. Android offre le NDK pour la création d’applications C++. Windows Phone 8 introduit également la prise en charge en natif du C++ et le SDK pour BlackBerry 10 dispose d’un Framework permettant le développement d’interface utilisateur en C++.

En dehors du domaine des jeux où le langage excelle, John Thomas trouve que C++ est également en parfaite adéquation avec la création d’applications d’entreprise.

Dans sa feuille de route pour 2013, Embarcadero envisage d’intégrer dans ses outils de développement la prise en charge de la création d’applications pour Android et iOS en C++.

Source : Embarcadero

Et vous ?

:fleche: Que pensez-vous du langage C++ dans le mobile ? Meilleur choix pour le développement multiplateforme ?
11/12/2012, 14h51
octal

Franchement, en le combinant avec un framework aussi bien fait que Qt, ça marche très bien.
Après, il est clair que si l'on ne rivalisera jamais avec la vitesse de développement et le confort obtenue avec un langage genre C# qui gère les allocations/désallocations dynamiquement et décharge grandement le développeurs de pleins de points noir en débug (même si le C++ a comblé partiellement son retard avec les smart pointers offer par boost ou autre).
11/12/2012, 14h58
Invité

Houla ! J'entends les trolls rappliquer à grands pas x)

Non, plus sérieusement, je pense effectivement que le C++ peut-être une bonne solution pour des applications cross plateforme sur mobile. Surtout si on veut profiter des avantages du natif sans avoir le budget pour développer une appli pour chaque OS. Cependant, il manque peut-être des outils pour ça. Comme l'a dit Octal, Qt pourrait être une bonne solution s'ils approfondissaient leur support des différents OS et s'ils intégraient des simulateurs dans leur IDE.

Ce qui me fait peur par contre, c'est que beaucoup de développeurs fraichement formés ne sont plus sensibilisés aux problématiques "bas niveau" (tout est relatif). Je pense notamment à la gestion manuelle de la mémoire. Venant moi-même de recevoir mon diplôme d'ingénieur, je sais que sans ma passion pour la programmation qui m'a poussé à être curieux et a approfondir des notions que l'on a juste effleuré, j'aurais pu obtenir ce diplôme sans savoir ce qu'est un pointeur ou un destructeur.
Donc, j'ai peur qu'on mette sur du C++ des développeurs habitués à programmer à plus haut niveau et qu'on obtienne des résultats catastrophiques.
11/12/2012, 15h20
JavaBean

C++??
11/12/2012, 15h25
Bousk

Citation:

Envoyé par octal

Après, il est clair que si l'on ne rivalisera jamais avec la vitesse de développement et le confort obtenue avec un langage genre C# qui gère les allocations/désallocations dynamiquement et décharge grandement le développeurs de pleins de points noir en débug (même si le C++ a comblé partiellement son retard avec les smart pointers offer par boost ou autre).

Je suis d'accord pour la "vitesse de développement" que peut offrir C#. Encore que, c'est plus une question d'habitude que du langage en lui-même.
Autant vouloir s'affranchir totalement de la gestion mémoire, je n'y vois aucune évolution réelle. Oui le C++ permet de gérer la mémoire aux petits oignons, mais je n'apelle pas ça un retard, pas plus que l'utilisation des smart pointer n'est une obligation. Je suis beaucoup plus géné par le Garbage Collector "qui passe un peu quand il veut" (bien qu'on peut le forcer il me semble) que par maîtriser la responsabilité et la durée de vie de mes objets et pouvoir les supprimer (et tout ce que ça implique - fermer un fichier etc) quand je le souhaite.

Citation:

Envoyé par Enerian

Ce qui me fait peur par contre, c'est que beaucoup de développeurs fraichement formés ne sont plus sensibilisés aux problématiques "bas niveau" (tout est relatif). Je pense notamment à la gestion manuelle de la mémoire. Venant moi-même de recevoir mon diplôme d'ingénieur, je sais que sans ma passion pour la programmation qui m'a poussé à être curieux et a approfondir des notions que l'on a juste effleuré, j'aurais pu obtenir ce diplôme sans savoir ce qu'est un pointeur ou un destructeur.
Donc, j'ai peur qu'on mette sur du C++ des développeurs habitués à programmer à plus haut niveau et qu'on obtienne des résultats catastrophiques.

S'il fallait attendre les futurs jeunes développeurs pour pondre du code imbuvable :( ce serait le paradis !
Malheureusement tu retrouveras souvent en entreprise dans des équipes des canards boiteux, parfois là depuis des années. :(
11/12/2012, 15h27
zackel

Citation:

le compilateur LLVM d’Apple

Dis comme ça j'ai eu vraiment l'impression que LLVM était la propriété d'Apple :calim2:
Or LLVM c'est un compilateur libre utilisé par Apple.
11/12/2012, 15h34
Vinorcola

De là à dire que C++ sera omniprésent, je ne sais pas, notamment par rapport à la facilité de développer des langages plus haut niveau. Par contre, une chose qui est sûre, c'est que le C++ ne disparaîtra jamais (en tout cas, je le penses très fortement).

Moi je préfère développer en C++ plutôt qu'en Java, je penses que c'est surtout une histoire d'habitude. J'aime bien pouvoir contrôler si je passe une copie ou une référence en paramètres.

Et le framework Qt est en très bonne voie, notamment avec la refonte du système d'affichage dans sa version 5. Cela permettra de le porter sur une nouvelle plateforme très facilement.
11/12/2012, 15h48
r0d

La récente multiplication des plateformes a donné un coup de fouet au langage, c'est un fait. De plus, l'évolution constante de c++ en fait un langage "dans l'air du temps", pour ainsi dire; et "être dans l'air du temps" ne signifie pas seulement "être à la mode", cela signifie aussi "utiliser des idiomes et paradigmes récents", et donc gagner en efficacité sur plusieurs fronts à la fois.

Je ne sais pas quel est l'avenir de c++, mais nous avons tous remarqué qu'il a le vent en poupe en ce moment. Le rouleau-compresseur c# a écrasé java, puis a été lui-même stoppé net par la multiplication des plateformes. Certains "jeunes" langages ont des arguments - je pense par exemple à Haskell - mais ils peinent à s'imposer.
11/12/2012, 15h51
olivier.pitton

Je ne pense pas que le C++ arrivera à s'imposer dans l'univers du mobile. Attention, je ne dis pas que l'on ne peut pas développer de bonnes applications en C++, mais je pars simplement du principe que la quasi totalité des sociétés développant dans le mobile ne le font pas en C++, donc que son adoption sera difficile.

A voir dans quelques temps.
11/12/2012, 15h52
air-dex

Au niveau performances, le C++ est loin devant les applis HTML 5 et Java et c'est toujours bon à prendre sur les terminaux mobiles.

Après il reste le problème de la portabilité. Embarcadero fait ici sa promo ("le C++ revient fort dans le dev mobile et comme par enchantement, on en fera en 2013 :aie: !") mais ce n'est pas eux qui résolveront le problème. Qt est plus que jamais là pour ça. La stratégie de Qt a évolué depuis son départ de Nokia et ne se cantonne plus aux OS morts (Symbian, Maemo, MeeGo) ou jamais annoncés (Meltemi) de ce dernier. Qt va maintenant sur iOS, Android, BlackBerry et Sailfish OS et cela peut en effet relancer le C++ dans le developpement mobile. Qt permettra d'avoir des applications pouvant marcher plus rapidement sur plusieurs grosses plateformes avec plus de qualités que le HTML5 et pour moins cher. En effet, le développement d'une appli Qt coûtera sûrement moins cher que le développement de 1°) Une appli Objective-C pour iPhone et iPad et 2°) Une appli Java pour Android et 3°) Plus si affinités. Il coutera peut-être aussi cher qu'une application HTML5 et son adaptation aux différentes plateformes mais la qualité des appli Qt sera plus élevée que celle des applis HTML5.
11/12/2012, 15h53
Freem

Je pense que la faiblesse de C++ par rapport aux autres langages, c'est l'absence de support d'IHM, que ce soit pour une interface type HTML ou une interface plus lourde.
Il y a également quelques autres manques dans le standard, mais l'on peut grandement résoudre ce problème grâce à boost.

Par contre, dire que l'on développe plus vite en C#, par exemple, me semble un peu... erroné. Bon, je suis habitué au C++, donc je suis parti pris, naturellement.

Mais je suis actuellement sur un programme ou une multimap m'aiderait bien. Il semble que C# n'offre pas ce genre d'outil, contrairement au C++.

Ensuite, la gestion mémoire, c'est vrai, elle est contraignante en C, mais en C++ ne n'est pas aussi vrai. Le seul point noir restant qui contraint à user des pointeurs, c'est les collections et le polymorphisme, vu que les associations peuvent très bien se faire via des références (bien que cela empêche les associations nulles, chose que l'on peut avoir avec les pointeurs).
En plus je trouve qu'il est plus simple de savoir si l'on fait une copie en C++ plutôt qu'un partage de référence.

Je pense que la RAII du C++ est un avantage de taille, comparé aux langages à la mode qui promeuvent les garbage collectors.

C++ à aussi l'inconvénient d'être un "tantinet" (d'aucuns auraient dit nettement) plus complexe à maîtriser que les autres, de pars son côté de liberté de paradigme, et le côté "on ne paye que ce que l'on utilise" qui implique de choisir ce que l'on va utiliser.

Malheureusement, ces points sont des points techniques. Le problème, ce sont les décideurs...
11/12/2012, 15h54
Klaim

Citation:

Envoyé par zackel

Dis comme ça j'ai eu vraiment l'impression que LLVM était la propriété d'Apple :calim2:
Or LLVM c'est un compilateur libre utilisé par Apple.

Pour etre precis:

* LLVM n'appartiens pas a Apple
* LLVM est finance par Apple
* LLVM est essentiellement developpe par Apple

Notez d'ailleurs qu'ils cherchent des gens pour ameliorer(voir rendre tout simplement possible) son utilisation sur Windows...
11/12/2012, 15h56
Klaim

Citation:

Envoyé par olivier.pitton

Je ne pense pas que le C++ arrivera à s'imposer dans l'univers du mobile. Attention, je ne dis pas que l'on ne peut pas développer de bonnes applications en C++, mais je pars simplement du principe que la quasi totalité des sociétés développant dans le mobile ne le font pas en C++, donc que son adoption sera difficile.

A voir dans quelques temps.

En fait la situation pourrait tourner comme pour le web: la plu parts des productions ne vont pas utiliser C++ mais les plus notables (pour des raisons de performance ou d'omnipresence) le seront, comme Google, Facebook etc.
11/12/2012, 16h17
Drawingrom

Je me demande pourquoi on irait vers du C++ pour du cross platform et pas sur des langages de plus haut niveau, comme Python, Ruby, etc... .

Pour les performances ? OK mais étant donné la puissance dispo sur les terminaux mobiles aujourd'hui, a-t-on besoin d'une gestion aussi fine que du C++ dans la majorité des cas ? Il faudrait pouvoir choisir entre les deux : haut niveau intrinsèquement moins performant mais avec peut-être moins de risque d'erreurs liées à l'alloc de ressources ou C++ voire C pour une gestion fine des ressources au prix d'une phase de test plus importante.
11/12/2012, 16h27
r0d

Citation:

Envoyé par Drawingrom

étant donné la puissance dispo sur les terminaux mobiles aujourd'hui

Puissance toute relative.
Les managers de adobe rêvent de faire tourner premiere sur iphone. Si tu vois où je veux en venir...

Les langages interprétés (python, ruby, java, c#...) nécessitent une machine virtuelle, ce qui pose beaucoup de problèmes en embarqué (dont la place et la perte de performance).
11/12/2012, 16h32
Niark13

Citation:

Envoyé par Drawingrom

Je me demande pourquoi on irait vers du C++ pour du cross platform et pas sur des langages de plus haut niveau, comme Python, Ruby, etc... .

Pour les performances ? OK mais étant donné la puissance dispo sur les terminaux mobiles aujourd'hui, a-t-on besoin d'une gestion aussi fine que du C++ dans la majorité des cas ?

Je pense que c'est plus une contrainte liée à l'autonomie qu'un problème de puissance de calcul. Une interprétation de code ou une machine virtuelle avec du JIT, ça consomme des cycles qui tirent plus sur la batterie.
11/12/2012, 16h59
grunk

Le C++ n'a d'intérêt que dans certains contexte.

Si le but c'est de faire un formulaire qui envoi trois infos à un web service , une appli cross plateforme en html/ javascript sera nettement plus adapté.

A contrario, pour un jeu, le C++ est plus qu'adapté puisque de toute manière on ne pourra pas avoir quelque chose de cross plateforme et performant.

Pour chaque plateforme , en C++ , on à accès facilement aux différentes API du device (photos, gps, commnunication ...) ?
11/12/2012, 17h18
doderic

Salut à tous,
Le développement mobile cross plateforme a été rendu possible depuis par le framework MoSync de la société suédoise MoSync AB. Juste avec le C++, développez pour Android, iOS, Windows phone, J2ME, Symbian. Faites un tour sur leur site http://www.mosync.com. Soit vous utilisez juste du C ou du C++ parce que les deux sont dispo. Entre temps ils ont ajouté le HTML 5 à leur arc. J'avais écris un tuto de découverte de ce framework ici http://eric-gbofu.developpez.com/tut...-et-cplusplus/
11/12/2012, 17h49
Emmanuel Deloget

Citation:

Envoyé par olivier.pitton

Je ne pense pas que le C++ arrivera à s'imposer dans l'univers du mobile. Attention, je ne dis pas que l'on ne peut pas développer de bonnes applications en C++, mais je pars simplement du principe que la quasi totalité des sociétés développant dans le mobile ne le font pas en C++, donc que son adoption sera difficile.

A voir dans quelques temps.

C'est une question de point de vue. Le C et le C++ sont utilisés pour les librairies bas niveau, ainsi que pour les librairies importantes (Unity 3D n'est pas développé en Java, ni le Unreal SDK). Du coup, il n'est pas nécessairement utile pour un développeur d'applications mobiles d'utiliser C++.

Ceci dit, ça ne me choquerait pas d'apprendre qu'une bonne partie des applications iPhone sont développées en C++, avec une couche ObjectiveC pour le lien avec le système. D'un point de vue business, c'est logique - ObjectiveC étant moins répandu que C++, il est préférable de l'utiliser le moins possible. Dans le monde Android, le langage de choix est Java, mais le NDK permet de développer en C++. Chez Windows Phone, on parle en C# et je ne sais pas s'il est possible de travailler en C++ natif (il doit être possible de travailler en C++/CLI).
11/12/2012, 21h20
moldavi

Bonjour

Citation:

Envoyé par Niark13

Je pense que c'est plus une contrainte liée à l'autonomie qu'une problème de puissance de calcul. Une interprétation de code ou une machine virtuelle avec du JIT, ça consomme des cycles qui tirent plus sur la batterie.

Je pense que tu pointes le vrai futur nerf de la guerre...

En effet j'imagine les futurs slogan marketing : "vous voyez, notre application, vous pouvez l'utiliser pendant X heures sans recharger l'appareil. Chez les concurrents, au bout de X-Y heure(s) vous ne pouvez plus travailler sur l'application."

Ben les concurrents, soit ils ont une application en or que les clients affectionnent malgré le défaut, soit ils passent au C++ pour s'aligner.

PS : tout ceci n'est que pure hypothèse de ma part, je ne suis pas socio-informaticologue.
11/12/2012, 22h26
djarBoy

Totalement d'accord avec ceci. Il faut arrêter avec Java.
Qt est l'avenir.
12/12/2012, 08h32
fregolo52

Citation:

Envoyé par djarBoy

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.
12/12/2012, 10h31
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.

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:

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.

12/12/2012, 11h08
Freem

Citation:

Envoyé par fregolo52

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!

Citation:

Envoyé par fregolo52

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.

Citation:

Envoyé par 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...)

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.

Citation:

Envoyé par Gugelhupf

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.

Citation:

Envoyé par Gugelhupf

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 :D
12/12/2012, 11h21
fregolo52

Citation:

Envoyé par Freem

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).
12/12/2012, 11h42
r0d

Citation:

Envoyé par Freem

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).
12/12/2012, 11h55
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.

Citation:

Envoyé par Freem

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.

Citation:

Envoyé par Gugelhupf

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

Citation:

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........
Citation:
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:

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

Citation:

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

12/12/2012, 12h01
r0d

Citation:

Envoyé par youtpout978

[...] moi qui n'y connait rien au c++), certes le c++ évolue mais pas aussi vite que [...]

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).
12/12/2012, 13h37
youtpout978

je parlais de la standardisation chose que j'ai pu voir sur le portail de développer mais après sur l'utilisation du langage en lui même :aie:
12/12/2012, 14h01
Freem

Citation:

Envoyé par r0d

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.

Citation:

Envoyé par r0d

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.
12/12/2012, 14h04
Emmanuel Deloget

Citation:

Envoyé par youtpout978

je parlais de la standardisation chose que j'ai pu voir sur le portail de développer mais après sur l'utilisation du langage en lui même :aie:

Difficile de comparer C++ à d'autres langages typiquement utilisés, vu que (à ma connaissance) seul C++, C et C# sont standardisés - et C# est standardisé par ECMA, c'est donc plus un approval du document fournit par MS qu'un véritable standard internationnal. Parmi les langages de programmation usuels, bien peu font l'objet d'un standard ISO (et ces choses là, ça n'évolue pas nécessairement très vite).

Citation:

Envoyé par r0d

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.

T'inquiète ; std::tr2::filesystem arrive ! (et oui, c'est indépendant de la plateforme ; ça met à contribution l'opérateur /, et les path sont notés avec / ; reste le problème des volumes, mais il doit existe une alternative).

Citation:

Envoyé par Freem

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.

Je ne suis pas trop d'accord. Je suis personnellement pour que les IHM soient intégrés au standard - le modèle de développement d'une IHM ne varie pas d'une plateforme à l'autre (on est toujours sur un système fenêtre + contrôles). L'apparence varie, mais le principe de base reste suffisamment semblable pour qu'il existe déjà des solutions multi plateformes (Qt, GTK+, wxwidget...). S'il est possible de concevoir ces librairies, alors il est possible de concevoir une librairie standard s'appuyant sur des principes similaires.
12/12/2012, 14h09
SurferIX

Citation:

Envoyé par Hinault Romaric

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".
12/12/2012, 14h10
Freem

Citation:

Envoyé par Emmanuel Deloget

Je ne suis pas trop d'accord. Je suis personnellement pour que les IHM soient intégrés au standard - le modèle de développement d'une IHM ne varie pas d'une plateforme à l'autre (on est toujours sur un système fenêtre + contrôles). L'apparence varie, mais le principe de base reste suffisamment semblable pour qu'il existe déjà des solutions multi plateformes (Qt, GTK+, wxwidget...). S'il est possible de concevoir ces librairies, alors il est possible de concevoir une librairie standard s'appuyant sur des principes similaires.

Pour être honnête, je suis assez mitigé, mon avis n'est pas aussi tranché que ce que j'ai écrit précédemment.
D'un côté, effectivement, le modèle, l'architecture du code, est toujours la même, mais d'un autre côté, les recommandations par rapport à l'interface changent selon l'OS.
Le souci que rencontre wxWidgets est d'ailleurs lié à ça: jongler avec les différences d'une API à l'autre est loin d'être aisé, surtout en respectant l'esprit derrière (histoire que ça s'intègre proprement).
12/12/2012, 14h37
Emmanuel Deloget

Citation:

Envoyé par Freem

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.

Il me semble moi que définir les préconditions et les postconditions, ça permet justement de faire en sorte que toute implémentation de la norme respecte ça - plutôt qu'une implémentation interne qui est, par définition, liée à la machine sur laquelle le code s'exécute. Par exemple, si je dis que std::thread() DOIT utiliser la fonction Win32 CreateThreadEx(), comment est-ce que je peux proposer std::thread sur Linux ?

Savoir comment les choses sont fait n'a pas d'intérêt.

Citation:

Envoyé par Freem

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.

C'est sûr, on ne peux pas le nier :)

Citation:

Envoyé par Freem

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.

Java ? Un standard ? Ah bon ?

Non. Il y a un comité, piloté par Oracle, qui dit comment le langage doit évoluer, et qui fait la surprise à tout le monde après en ajoutant des choses qui n'étaient pas prévues (mais qui facilitent les développements de leurs équipes ; ok, troll inside). Ce n'est pas ça, un standard. 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). Puis il est validé, et voté par un organisme indépendant international (par exemple, ISO). Rien que ces étapes, ça demande environ 2 ans.

Java n'a jamais été standardisé, et ne le sera jamais, parce que ça obligerait Oracle à permettre des implémentations concurrente sans limite d'usage (ce qui n'est pas le cas aujourd'hui, cf. le procès retentissant contre Google), et ça limiterait sa "capacité à innover" (lire : à faire des procès aux autres).

Et Java n'a toujours pas les templates - il y a des generic, dont la puissance est infime comparée aux template du C++.

C# est effectivement un standard (ECMA-334), mais (pour parler poliment) c'est un standard du pauvre. L'organisme ECMA est certes reconnu par ISO (et de fait, les standard ECMA peuvent devenir, sur demande, des standard ISO, et ce phénomène s'est reproduit deux fois pour C#), mais il n'en reste pas moins que le process de standardisation ECMA est nettement plus simple que le process ISO. En gros, vous venez avec votre proposition de norme, vous indiquez clairement que c'est royalty free (ou quelque chose de proche ; FRAND par exemple), et hop, c'est dans la poche. C'est pour ça que les entreprises passent par ECMA pour faire standardiser leurs solutions. Une fois la solution bien établie, vous pouvez demander une standardisation ISO, qui n'est rien de plus qu'un vote (le standard ECMA et le standard ISO étant alors identique).

Le problème qui se pointe, c'est que seules les versions 1.0 et 2.0 sont standardisées - pas les versions 3.0 et 4.0, ni la nouvelle version 5.0. La dernière version ne fait même pas l'objet d'un document de design par MS, si ma mémoire est bonne (je peux me tromper).

Du point de vue du process utilisé pour le développement, comparer Java, C# et C++ n'est pas possible. Maintenant, si tu donnes la responsabilité des évolutions de C++ à une seule entreprise (disons Google ; Apple a ObjectiveC, Oracle a Java, MS a C#), alors le langage va évoluer plus vite (mais les évolutions seront peut-être moins pertinente).

Citation:

Envoyé par Freem

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.
12/12/2012, 16h09
danielfr40

j'aimerai bien

oui, c++ j'aime bien
mais je trouve cet avis bizarre de la part des repreneurs de borland d'un système de développement principalement pascal (delphi) dont le c++ est depuis longtemps le parent pauvre.
12/12/2012, 17h32
Emmanuel Deloget

Citation:

Envoyé par danielfr40

oui, c++ j'aime bien
mais je trouve cet avis bizarre de la part des repreneurs de borland d'un système de développement principalement pascal (delphi) dont le c++ est depuis longtemps le parent pauvre.

En même temps, ce n'est pas comme si Delphi allait avoir un avenir brillant :)
12/12/2012, 17h40
Jean-Marc.Bourguet

Citation:

Envoyé par Freem

Il est de notoriété commune que le standard actuel, surnommé C++11, à mis près de 10 ans à naître.

A peut pres la moitie. Il faut retirer la periode jusque 2003-2004 ou le sujet n'etait pas l'evolution du langage mais sa stabilisation. Et la fin ou le langage etait fixe et on en etait a la procedure ISO d'approbation.
12/12/2012, 17h51
Matthieu Vergne

Citation:

Pour le développement natif, en fonction des écosystèmes, les développeurs s’orientent le plus souvent vers objective-c ou Java.

Pourtant, ceux qui cherchent à créer des applications cross-platform tout en bénéficiant d’une approche efficace pour la réduction des couts peuvent trouver leur bonheur au sein du C++.

C'est moi où on vente le contraire de ce qu'on nous dit depuis des années : Java est connu pour son côté multi-plateformes grâce à sa machine virtuelle, là où C et C++ sont bons pour exploiter les ressources natives de la machine du fait de leur langage bas niveau... Et maintenant on nous dit le contraire ?

Perso je ne suis plus.

Voir 40 message(s) de cette discussion en une page