Discussion :

[jouana]

SuferIX ma vision de la SSII n'est pas la même que toi.
En gros tu sorts un truc pourris en 2 jours à cause des délais (on verra plutard ou jamais).
Et quand tu as une évol tu prends les même voir pire d'autres personnes pour repondre un truc bencale sur l'existant ont repars pas du début et ensuite tu vas sur la maintenance d'une appli vieille de 10 ans et tu as tout compris ...

Ensuite Transgohan un projet c'est du temps, le temps c'est de l'argent donc un projet c'est de l'argent, tu peu être passionné mais les gens qui gère la boite c'est pas forcement leurs cas, donc tu applique ce qu'ont te demande welcome in the real world :s.

Le problème d'un projet c'est les contraintes mais sans les contraintes ont se fait chier ^^.

Le seul truc cool au bout du comptes c'est un projet prévu sur une grosse période de temps ^^

[Klaim]

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

Pas besoin de s'excuser
Note pourtant que Facebook et Google sont des entreprise totallement oriente sur le web et qui utilisent C++, Facebook de plus en plus.

Donc c'est vraiment une question de besoin specifique a un projet a un moment T, pas une question de domaine.

Et puis si Microsoft mets le paquets pour qu'Azure soit tres facilement utilisable en C++ pour faire des serveurs, je pense qu'il y a de bonnes raisons.

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

Oui en fait c'est la strategie de base pour augmenter les perfs.
Mais comme je le soulignais, ya un moment ou ajouter du hardware coute plus cher que rendre le software moins gourmand, meme pour des serveurs. Apres, tout le monde ne vas pas realiser cela, surtout pour des applis web avec juste quelques milliers d'utilisateurs. Quand ca deviens massivement utilise, c'est autre chose.

En fait on a cette hierarchie dans le dev web:

- Torcher les premieres versions en Python ou Ruby ou PHP.
- Augmenter les perfs avec de meilleurs serveurs.
- A un moment ca coute trop cher, du coup refaire l'appli en Java ou C# est plus rapide (Java et C# sont dans la meme magnitude de vitesse d'execution-meme si C# est souvent un peu plus rapide-, Python et Ruby sont loin derrirere, C++ est souvent devant mais pas toujours dans l'ordre de magnitude devant).
- Si on veut radicalement reduire le cout des serveurs (tous ces languages prennent quand meme pas mal de memoire vive qui coute cher niveau energie), on passe a une solution radicale: refaire l'appli en C++

Donc, le dernier stade est certes rare mais existe. Ya aussi les appli web ou le developpeur prefere payer ses programmeurs a faire une appli performante et peu couteuse en hardware qu'avoir a augmenter la paye du hardware tous les mois.

Facebook a realise assez vite que meme si php est plutot rapide, il bouffait trop de hardware. Du coup ils ont fait un compilateur PHP qui genere du C++.
Maintenant, ils sont passe a l'etape superieur en reecrivant reellement le code en C++ principalement parceque le code PHP convertis ne donne pas du code maintenable en C++ (donc tu dois continuer en PHP pour que ca vaille le coup, mais ca perds de son interet sur le long terme)
De plus enplus de devs Facebook passent completement au C++, il faut dire que c'est une application super gourmande et qui se doit d'etre reactive.

Pour rappel, quand ils sont passes au compilateur PHP->C++, ils ont reduis de moitier le parc hardware necessaire pour faire tourner Facebook.


C'est aussi important de comprendre les limites de son application meme sur device portable. Admettons que je fasse un jeu tres long pour Android. C'est un RPG avec une histoire bien longue, qui garanti au moins 50h de jeu. Je la fais disons en Java pour me simplifier la vie. Le souci que je vais avoir, c'est que jouer au jeu va bouffer pas mal d'energie et donc reduire la qualite de l'experience du jeu (en plus du reste). Parceque c'est un jeu long. Alors bon tous les jeux sont pas long, mais le mien l'est. Alors pour reduire les soucis, je peu toujours tenter d'optimiser mon code Java, mais si je peu reecrire le tout en C++, ca va etre drastiquememt positif niveau energie.

Au final, ca depends fortement de ce que l'ont fait, mais avec les devices et le coup du hardware en general, l'energie est super importante pour certaines applications, auquel cas c'est tentant de passer directement au bazooka. Pour peu qu'on ai des devs qui peuvent le faire.

Personellement j'ai torche des jeux iphone tres vite en C++ ya quelques mois. Pour peu qu'on ait un framework adapte au type d'appli ( et yen a des tas ) on peut facilement faire des trucs peu gourmand et tres cross-platforme ( voir l'histoire de Super Hexagon ).

Dans pas longtemps je compte m'emtrainer a faire du web avec C++ (certainement avec cppcms). Pour cela, je vais juste faire de tres petits sites dynamiques. A partir de cette experience et combine avec mes precedentes experiences avec Java, C# et Python pour le web (j'ai peu fait de Ruby), ca me donnera un vrai instinct de quand ca vaut le coup de passer au C++.

Rien ne vaut l'experience.

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

[Emmanuel Deloget]

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

[Matthieu Vergne]

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.

[r0d]

@Matthieu Vergne: en fait, ce qui a tout chamboulé c'est la prolifération d'appareils portables (iphones, consoles, etc.). En gros, et selon ce que j'ai personnellement compris du problème, les langages interprétés tels le java sont trop gourmands en ressources (en particulier la consommation d'énergie: un processeur consomme beaucoup d'énergie).
c++ offre une bonne solution, à condition que les "sdk natives" des appareils puissent s'interfacer avec, et il semble que les constructeurs aient choisi cette voie.

[Matthieu Vergne]

Donc plutôt que du cross-platform, ce serait du cross-environment.

[gbdivers]

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.

C'est le problème de répéter la même chose pendant des années. Lorsque les choses évoluent, ce que l'on dit devient progressivement des bêtises.

L'enseignement du C++ a longtemps été (et continu dans beaucoup de formations) avec être basé sur une approche "historique" (comprendre "archaïque"), orienté sur une approche bas niveau, sans prendre en compte les fonctionnalités évoluées (différent de complexe) du langage ni l'évolution des besoins des entreprises (maintenabilité, évolutivité, etc).
Sans être un spécialiste du Java, j'imagine que le langage a appris à exploiter les ressources natives des systèmes.

Idem pour la portabilité. Les différentes versions de la JVM peuvent parfois mettre à mal un programme java sur plusieurs machines. Le C++ a bénéficié d'outils de compilation et de libs portables (boost, Qt, cmake, etc) qui permet de proposer assez facilement une appli sur différentes plateforme (bien qu'un petit coup de normalisation de l'abi pourrait encore améliorer les choses)

Bref, a part pour s'amuser à troller sur le chat, rester sur des idées préconçus n'aident pas trop

[Matthieu Vergne]

Sauf que parler d'idées préconçues c'est un peu dur {'^_^}. Obsolète, d'accord, le fait est que j'ai plus touché à C++ depuis longtemps en switchant sur Java, justement pour ce côté portable et les librairies de base du langage qui permettent de rentrer dans le lard tout de suite sans avoir à retrouver telle ou telle lib. Les évolutions du C++, je n'ait suivi que ce qui voulait bien arriver devant mes yeux, autrement dit je suis loin d'être à jour. Cependant, ça ne justifie pas qu'on dise maintenant que la tendance se soit inversée, dans le sens où Java fonctionne toujours de la même manière (et donc est toujours aussi portable) en plus d'avoir tout de même gagné en rapidité (on l'utilise quand même sur des cartes à puces et des téléphones mobiles).

Dire que ça ait convergé et que maintenant il serait bon de se poser la question lequel est le mieux selon le cas qui se présente serait plus juste je trouve. Mais dire que Java fait du natif et C++ du portable... l'article est une source de troll à part entière {'^_^}.

[germinolegrand]

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

Maintenant ce ne sont plus des technical report, mais de technical specification, le namespace sera-t-il changé ? (ts2 au lieu de tr2 ?)

[Aleph69]

Bonjour,

[B][SIZE="4"]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 ».

Question bête : le problème ne va-t-il pas se résorber de lui-même, dans le sens où il est fort probable que sur le long terme le marché ne soit dominé que par un ou deux systèmes d'exploitation?

[r0d]

[...] le problème [...]

Quel problème? En tant que spécialiste c++ je ne considère pas cette situation comme un problème

[oliverparis]

Absolument pas d'accord avec ce chef de produit... c'est même très étonnant de lire cela alors que toute la profession(mobile) forme des développeurs sur l'ensemble des technos, un peu sur le web et html5/javascript (qui n'est malheureusement pas encore au niveau des performances d'une application native...).
Pour faire de la mobilité depuis les années 2000, (et oui, je suis un dinosaure, je sais... ), C++ n'a jamais été présent...ou alors peu. Allez, on peut noter à la rigueur QT et nokia... même si le client à la fin voulait que ce soit disponible sur tous les terminaux, et qu'il fallait très vite repasser à du J2ME... :-)

J'entends parler de Android et du NSDK... les gens qui en parlent l'ont t'ils déjà utilisés ?? franchement...
J'entends parler de C++ pour l'iPhone, même question ?
et je ne parle même pas des autres plate-formes, Blackberry, Windows 7 et 8, etc...
Nous avons eu un espoir à un moment avec Flash (flex, air et autres..)
Mais c'était beaucoup trop lourds et beaucoup trop gourmand en batterie pour les utilisateurs. Même chose avec Java... sauf pour les téléphone nativement en java ou avec des outils de développement prévue pour (blackberry et Android).

Pour l'iPhone, il n'y a même pas à discuter, l'environnement xCode et objectifC reste le seul viable. (si vous voulez faire autre chose que des pages de catalogues qui mettent trois heures à se recharger parce que vous utiliser une webview...).
Pour android, avec la problèmatique des écrans, des interfaces, des terminaux, il ne reste que l'environnement SDK en Java. Qui est plutôt pas mal d'ailleurs pour une plate-forme aussi jeune.
Pour Blackberry, c'est exactement la même chose, java reste la solution la plus adéquate.
Pour Windows, pourquoi donc vouloir changer C# ??? Vous avez vu ce qu'offre à un développeur l'environnement de développement ???

Alors certes, l'environnement mobile reste complexe parce que chacun à son outil. Mais, paradoxalement, c'est tellement simple. N'importe quel développeur peu prendre en compte un outil de développement natif (java, objectif-C, windows...) en deux semaines. Il suffit de bien le guider au départ.

Maintenant, comme dirait l'autre, le meilleur outil reste celui qu'on maîtrise...

Je pense très sincèrement que prendre un code C++, avoir 3000 routines et bidouilles de compilation pour le porter (quand c'est possible...) et contourner sans arrêt les nouveaux sdk et leur fonctionnalités, restera toujours plus long et plus coûteux que de prendre 3 développeurs, chacun une techno, et en avant... :-)

alors si quelqu'un aime C++, qu'il arrive à développer sur Android en gardant tous les terminaux cibles, etc.. que son code fonctionne également sur iPhone et blackberry, et windows.. whaouu.. chapeau !!! Mais bon, depuis plusieurs année de mobilité, j'ai encore jamais vu... Mais je suis prêt à voir un exemple réel... :-)

[Bousk]

Rien qu'en projet scolaire en java on se retrouvait avec du code dupliquait parce que les interfaces cest mignon, mais cest un peu naze point de vue factorisation du code. Ca ne couvre que la factorisation de service a rendre.
Alors en entreprise... ^^

Perso, j'ai toujours vu le choix de l'interdiction d'héritage multiple, mais pouvoir implémenter autant d'interface que souhaité comme le plus gros bullshit des langages java et .net
Alors certes, ca évite de rencontrer un "problème d'héritage en diamant", mais la solution retenue pour éviter ce problème aux développeurs est un leurre et une belle arnaque amha

[Klaim]

Pour faire de la mobilité depuis les années 2000, (et oui, je suis un dinosaure, je sais... ), C++ n'a jamais été présent...ou alors peu. Allez, on peut noter à la rigueur QT et nokia... même si le client à la fin voulait que ce soit disponible sur tous les terminaux, et qu'il fallait très vite repasser à du J2ME... :-)

Eh ben t'as pas du faire des masses d'applications gourmandes hein. Moi j'ai fait 1 appli Android an Java et 4 en C++ (des jeux).
Comme quoi faut pas se fier a son experience sur ce genre de chiffres...

J'entends parler de Android et du NSDK... les gens qui en parlent l'ont t'ils déjà utilisés ?? franchement...

Oui oui, et meme que le NDK a ete largement ameliore dans ses dernieres versions puisque de plus en plus de devs voulaient faire du natif mais le SDK etait un peu pourri au debut. La situation a bien evolue. Tu as aussi par exemple des outils pour integrer le NDK a Visual Studio.

J'entends parler de C++ pour l'iPhone, même question ?

J'en ai fais 4, je connais au moins 10 jeux qui sont implementes en C++ sur IOS et sans compter les jeux exclusivement iPad donc.

et je ne parle même pas des autres plate-formes, Blackberry, Windows 7 et 8, etc...

Tu plaisantes j'espere? Blackberry on pouvait pas faire du natif jusque recemment, mais les autres plateformes ont toujours incite a faire du natif. Notemment Windows 8...

Pour l'iPhone, il n'y a même pas à discuter, l'environnement xCode et objectifC reste le seul viable. (si vous voulez faire autre chose que des pages de catalogues qui mettent trois heures à se recharger parce que vous utiliser une webview...).

... mais t'es au courant qu'XCode supporte le C++ et qu'en fait Objectitve-C et C++ sont tres facilement melangeable? Parceque ya plein de gens qui font ca et ca a rien de difficile...

Pour android, avec la problèmatique des écrans, des interfaces, des terminaux, il ne reste que l'environnement SDK en Java. Qui est plutôt pas mal d'ailleurs pour une plate-forme aussi jeune.

Il n'y a strictement aucun rapport entre la resolution de l'ecran et le language utilise pour developper une app.

Pour Blackberry, c'est exactement la même chose, java reste la solution la plus adéquate.

Et donc dans leur dernier SDK ils ont tout fait pour inciter a faire du natif juste pour le plaisir?

Pour Windows, pourquoi donc vouloir changer C# ??? Vous avez vu ce qu'offre à un développeur l'environnement de développement ???

Il ne sagit pas de "changer C#" voyons. Il sagit d'un rapport cross-platform performance. Si tu n'as pas senti le besoin pour un language comme C++, ya pas de souci. Note que Windows 8 est a fond dans le natif... essentiellement parce que ses derives vont tourner sur tablettes ou smartphone donc faut quand meme inciter a faire des appli peu gourmandes.

Apple a fait de meme d'ailleurs en limitant autant que possible les appli a du natif.

Alors certes, l'environnement mobile reste complexe parce que chacun à son outil. Mais, paradoxalement, c'est tellement simple. N'importe quel développeur peu prendre en compte un outil de développement natif (java, objectif-C, windows...) en deux semaines. Il suffit de bien le guider au départ.

C'est clair! J'ai fait mon premier jeu iPhone en 2 semaines. En C++.

Maintenant, comme dirait l'autre, le meilleur outil reste celui qu'on maîtrise...

C'est un paramettre, mais parfois ce n'est pas le seul.

Je pense très sincèrement que prendre un code C++, avoir 3000 routines et bidouilles de compilation pour le porter (quand c'est possible...) et contourner sans arrêt les nouveaux sdk et leur fonctionnalités, restera toujours plus long et plus coûteux que de prendre 3 développeurs, chacun une techno, et en avant... :-)

Vu comme ca je suis d'accord. Le fait est qu'un dev C++ suffisamment forme a faire de code cross-platform va avoir tres peu de boulot a faire entre les plateformes. En particulier si il a un bon framework qui isole bien son code. Moi j'ai utilise un tel framework, il a fallu une journee pour porter le code de iPhone a android, moins pour faire tourner la meme appli sous windows.

alors si quelqu'un aime C++, qu'il arrive à développer sur Android en gardant tous les terminaux cibles, etc.. que son code fonctionne également sur iPhone et blackberry, et windows.. whaouu.. chapeau !!! Mais bon, depuis plusieurs année de mobilité, j'ai encore jamais vu... Mais je suis prêt à voir un exemple réel... :-)

Mais... yen a plein.... t'en connais vraiment aucun???