Envoyé par
octal
Ces arguments sont valides seulement si votre application est la seule à fonctionner (avec ou sans OS) sur le terminal. Cela n'est pas le cas sur un smartphone. Il y a et il y aura plein de process et d'applications qui fonctionnent et devront fonctionner en parallel à votre application.
D'un autre coté, les applications natives ne sont pas forcément les bienvenues, car dans les smartphone on considère qu'une application et plus un module offrant des services aux autres applications qu'une application indépendante (au sens application PC). Cette complémentarité services<>consommateurs de services est bien gérée (et facilité) par la machine virtuelle d'Android. Quand on écrit une application native, il y a plein de services que l'on perd et si on ne se restreint pas à une certaine discipline, on risque même de casser cette interopérabilité, ce qui rendra rapidement (et facilement) le terminal inutilisable.
A ce que je sache, pour avoir bossé un peu sur des smartphones pré-iphone (et oui yen avait), l'OS décide quand il veut de tuer les applications gourmandes qui ne sont pas utilisées et donc ce n'est plus du ressort du développeur, a part le fait qu'il doit faire son maximum pour limiter la casse de son coté quand l'application est fermée.
De plus, pour peu que l'on veuille utiliser C++ pour ce genre de plateformes, justement le coup de l'application en mémoire sera réduit par rapport à la même application en Java. Donc c'est bénéfique pour la gestion de différentes applications (mais tout le monde n'a pas que ça a faire de passer en C++, evidemment).
Pour les services qu'il manque, pour Android je pensais que les derniers NDK permettaient justement d'avoir tous les services et de s'abstraire complètement du Java. M'aurais-t-on menti? (ça se peut)
Je ne vois pas en quoi il faudra connaitre le "C++ moderne" va servir (à moins que je ne comprenne pas trop ce que vous voulez dire par Moderne).
Ce qu'on appelle le "c++ moderne" c'est en gros du c++ qui exploite l'idiom RAII et par conséquent des pointeurs intélligents, qui gèrent le temps de vie des resources pour soit (dans notre cas la mémoire, mais c'est vrai pour les threads etc.). En gros, c'est la C++ idiomatique qui est différent de beaucoup de code C++ qu'on voit un peu partout, qui est plus proche du "C with classes". En C++ moderne, on se prends rarement la tete avec la gestion de la mémoire (entre autre) qui est partiellement gérée naturellement par les smart pointers.
Ce que je sous entendais, pour être clair, c'est qu'aujourd'hui (et depuis qu'on a des compilateurs plus proche du standard qu'auparavant), on peut coder plus ou moins comme dans un language managé en C++, tout en ayant à tout moment l'option de mettre les mains dans le camboui pour les micro-optmizations (qui peuvent être interessantes comme dit dans les jeux gourmands, pas tous). Ca n'améliore pas les temps de compilation mais ça permet d'éviter tous les problèmes classiques du C et du C with classes comme par exemple les memory leak, les dépassement de tableau (en utiliste boost::array ou std::array au lieu des tableaux natifs) etc.
Donc en gros, coté dev aussi a priori aujourd'hui il est plutot facile (pour peu qu'on utilise du C++ "moderne"
de ne pas avoir de problèmes de gestion de mémoire, tout en ayant une consomation de celle-ci et de l'energie somme toutes assez faible.
Hors "grosse appli" evidemment
2 |
1 |