Discussion :

[super_navide]

J'ai développer un moteur 3D a base de cube comme minecraft , exemple du rendu

Et je pense sérieusement passé au C++ pour justement les performances et la puissance du langage pour les raisons suivante :
1) creer des donnees sur la pile d'execution donc pas d'allocation mémoire a faire.
2) utilisation de bibliotheque de math ultra puissante comme glm
3) la surcharge des operateurs pour ecrire du code plus simple et lisible qui utilise des vecteurs.
4) le niveau d'abstraction offert par les templates.
5) pas de machine virtual a installé , un simple excutable plus facile pour diffuser des programmes.

Donc non le C++ est pas dépassé pour l'instant le seul truc qui manque c de pouvoir avoir un garbage collector optionnel intégré au langage et de l'introspection.

[dourouc05]

Je me demande s'il est possible de réécrire une fonction comme int str2int(std::string str, bool * ok = nullptr) (*) avec des pointeurs intelligents. Des avis sur la question?

Justement, le mécanisme d'exceptions est prévu pour ce genre de cas : le code appelant sera beaucoup plus léger qu'une vérification de ce pointeur… Ce genre de code me rappelle beaucoup trop le C .

le seul truc qui manque c de pouvoir avoir un garbage collector optionnel intégré au langage

C'est l'objectif des pointeurs intelligents : gérer la mémoire à ta place, s'assurer que les objets sont bien détruits une seule fois, avec une garantie de l'endroit où le destructeur est appelé. La différence avec les ramasse-miettes, c'est que la mémoire est libérée dès que possible, pas lorsque l'algorithme effectue une passe pour vérifier ce qui est encore utilisé ou pas (donc libérer un gros paquet de mémoire d'un coup, ce qui pourrait être plus efficace).

Sinon, C++11 (la norme) intègre un ramasse-miettes (http://www.open-std.org/jtc1/sc22/wg...2008/n2670.htm), mais à ma connaissance aucun compilateur ne l'implémente…

[mintho carmo]

Justement, le mécanisme d'exceptions est prévu pour ce genre de cas : le code appelant sera beaucoup plus léger qu'une vérification de ce pointeur… Ce genre de code me rappelle beaucoup trop le C

Cela peut effectivement être une solution.

Cependant, cette fonction est souvent utilisée pour tester si une chaîne est convertible en nombre. Du coup, avoir une conversion invalide n'est plus une "exception", mais une utilisation normale de cette fonction.
Du coup, même si on propose une fonction sans pointeur (qui peut lancer une exception), je proposerais aussi une fonction qui permet de retourner un bool (sans lancer d'exception).
Je crois que ce sont 2 use-cases différents.

En pratique, c'est assez simple a faire, il suffit d'encapsuler l'appel a cette fonction dans 2 fonctions sans pointeur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
int str2int(std::string const& str) {
    bool ok {};
    const auto result = str2int(str, &ok);
    if (!ok)
        throw std::exception("pas bon...");
    return result;
}
 
int str2int(std::string const& str, bool & ok) {
    return str2int(str, &ok);
}

[nikau6]

Pas mal la classe std::optional. Je ne connaissais pas. C'est du c++ 14 ou 17 je suppose.

Donc non le C++ est pas dépassé pour l'instant le seul truc qui manque c de pouvoir avoir un garbage collector optionnel intégré au langage et de l'introspection.

Un garbage collector pourrait être pratique dans certains cas, mais il ne faut pas oublier que la gestion manuelle de la mémoire est l'un des points fort du C++ en comparaison avec Java.
Sinon, ton moteur a un rendu sympa. Beau travail :-)

[boero-teyssier Greg]

Pas mal la classe std::optional. Je ne connaissais pas. C'est du c++ 14 ou 17 je suppose.

oui optional fait partie de c++ 17 .

Un garbage collector pourrait être pratique dans certains cas, mais il ne faut pas oublier que la gestion manuelle de la mémoire est l'un des points fort du C++ en comparaison avec Java.

l'utilisation d'un GC a la java en c++ n'est à mon avis pas la solution car le problème du java est la consommation en ressources de sont GC donc il fraudait que le GC c++ soit optionnel et activable que dans des cas d'utilisation spécifiques :
- Compétence technique insuffisant pour garantir la protection contre les fuit mémoire
- la récupération / migration d'ancien source et que cela demanderait trop jour/homme pour la correction...

[Stabia]

La notion d'objet, et la programmation qui va avec, la recherche du'ne modularité introuvable sauf au prix fort, les "patrons" ou archétypes (templates), j'ai toujours trouvé qu'il s'agissait de masturbations intellectuelles imposées par des non-programmeurs aux programmeurs ; vous savez l'adage méchant "quand on connait un métier on l'exerce, sinon on l'enseigne ...".

[boumchalet]

La notion d'objet, et la programmation qui va avec, la recherche du'ne modularité introuvable sauf au prix fort, les "patrons" ou archétypes (templates), j'ai toujours trouvé qu'il s'agissait de masturbations intellectuelles imposées par des non-programmeurs aux programmeurs ; vous savez l'adage méchant "quand on connait un métier on l'exerce, sinon on l'enseigne ...".

Le problème est simple, pour être rapide et efficace, il faut écrire à l'économie avec le nombre de lignes les plus courtes.
=> il ne faut écrire que ses spécifications et pas l'implémentation: exemple :
il ne faut pas ecrire :

Code :

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

1
2
3
4
T tab[20];
for (int i=0;i < 20;++i){
  f(tab[i]);
}

mais

Code :

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

1
2
3
std::array<int, 20> Donnees;
for (auto v: Donnees)
   f(v);

C’est plus simple avec moins de risques d'erreurs. Le début du tableau ainsi que sa fin ne sont que de l'implémentation. Les spécifications n’indiquent que d'appeler f pour chaque élément du conteneur. => Je n'écrire que cela.


Si tu arrives à écrire que tes spécifications, tes méthodes ne dépasserons par 7 lignes.
Si tes méthodes dépassent 7 lignes alors tu as encore beaucoup de choses passionnantes à apprendre.

[Bousk]

Le problème est simple, pour être rapide et efficace, il faut écrire à l'économie avec le nombre de lignes les plus courtes.
=> il ne faut écrire que ses spécifications et pas l'implémentation: exemple :
il ne faut pas ecrire :

Code :

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

1
2
3
4
T tab[20];
for (int i=0;i < 20;++i){
  f(tab[i]);
}

mais

Code :

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

1
2
3
std::array<int, 20> Donnees;
for (auto v: Donnees)
   f(v);

C’est plus simple avec moins de risques d'erreurs. Le début du tableau ainsi que sa fin ne sont que de l'implémentation. Les spécifications n’indiquent que d'appeler f pour chaque élément du conteneur. => Je n'écrire que cela.

Et tu fais une copie de chaque élément, donc niveau rapidité et efficacité.. t'as de la chance que ce ne soit qu'un int.

[loupium]

@ Pierre Louis Chevalier
En effet, j'avais oublié android.

Mais sur Desktop, c'est pas aussi flagrant.
Bien-sure tu pourra toujours sortir quelques noms d'entreprise pour chaque langages et heureusement. Le problème est plus une question de proportion d'utilisation. Car fait la liste des logiciels que tu utilises au quotidien et regarde la proportion codé en java. Suis je le seul dans cette situation ?

Pire, ce n'est pas parce-que une application est développées quelle est utilisées ensuite.
Cas concret dans ma boite par exemple, qui a externalisé le développement d'une application (faite en windev par le prestataire, quelle idée aussi) et qui est inutilisable. Donc à refaire complétement en c++. D'où ma sensation d'applications jetables.

[Pierre Louis Chevalier]

Tu te focalises semble-t-il sur les "logiciels PC". Effectivement beaucoup d'entre eux sont fait en C++, mais il y à pas que les PC, il y à les mobiles, les serveurs web etc. Et il y à pas que les applications grand public, il y à aussi énormément d'applications d'entreprise dont certaines sont mêmes faites encore en Cobol, donc toujours pas du C++.
Je vais te donner un exemple, il y à quelques dizaines de développeurs qui travaillent sur Windev, donc écrit en C++, et pendant ce temps le nombre de développeurs Windev pour faire des applications de gestion PME c'est des dizaines de milliers (150000 selon l'éditeur mais c'est sans doute exagéré), donc beaucoup plus. Donc dans le cas de Windev on à par exemple une proportion d'environ 1000 développeurs gestion L4G contre 1 développeur C++.
Donc oui un très grand nombre logiciels PC sont faits en C++ entre autres pour des raisons de performance et de portabilité. Cependant au delà de ça il existe un marché colossal pour les autres développeurs, qui font des application web, serveur, entreprise, pme, mobiles, etc. Les applications des grandes entreprises sont le plus souvent faites en Java ou en C#, pas en C++, parce que c'est généralement plus facile de développer et de maintenir des applications en Java ou en C# qu'en C++.

[guillaume07]

Et tu fais une copie de chaque élément, donc niveau rapidité et efficacité.. t'as de la chance que ce ne soit qu'un int.

Il y a une différence de perf/de code généré entre ces deux boucles for ?

[RyzenOC]

Il y a une différence de perf/de code généré entre ces deux boucles for ?

En générale pour ce genre de chose "simple" c'est le compilateur qui optimise.

[Artemus24]

Salut user019.

Ce n'est pas machin mais Winston Churchill qui est l'auteur de la phrase suivante :

La démocratie est le pire des régimes - à l'exception de tous les autres déjà essayés dans le passé.

@+

[jblecanard]

Ce Henrique est un troll.

[VBurel]

Ce Henrique est un troll.

C'est bien possible car autant la question posée permet de s’interroger sur l’évolutions des langages, autant ses arguments sont complètement débiles (« La vitesse est telle que si deux octets sont envoyés au même moment depuis deux canaux adjacents, ils vont probablement se désynchroniser après avoir parcouru moins d’un mètre. » quel rapport ? :-)).

[RyzenOC]

C'est bien possible car autant la question posée permet de s’interroger sur l’évolutions des langages, autant ses arguments sont complètement débiles (« La vitesse est telle que si deux octets sont envoyés au même moment depuis deux canaux adjacents, ils vont probablement se désynchroniser après avoir parcouru moins d’un mètre. » quel rapport ? :-)).

Je suis entièrement d'accord avec l'auteur, nous sommes tous confronté chaque jour à ce problème, franchement c'est le genre de problème qui rend le c++ inutilisable...

Plus sérieusement, +1, ces arguments sont bidons, ce problème doit toucher que 0.1% des dev c++, et puis si on en arrive à faire de tels programmes avec de tels contraintes, faut utiliser des outils spécialisé.

[athlon64]

Bonjour,

l'auteur met en avant (en ce qui le concerne) des insuffisances qui le poussent à trouver d'autres alternatives.

Modern C++ has become a game of academic circlejerk and a big waste of time. The 20/80 rule concludes we should move to learn something more productive.

Par exemple quand il parle de désynchronisation, c'est compréhensible dans le trading haute fréquence, vous jouez avec des délais en µS, et que votre programme tourne sur des OS qui gèrent l'ordonnancement, c'est pas étonnant d'avoir des signaux qui n'arrivent pas à la µS près. En passant directement par des opérations codées dans le hardware on a pas cette latence.

La difficulté d'un langage comme C++ c'est qu'il ne suffit pas de bien connaitre le langage, il faut aussi bien connaitre le compilateur utilisé pour réussir ses optimisations. Dommage, il ne cite pas son compilo dans son article original, qu'il faut lire pour comprendre qu'il n'est pas en dénigrement pur et simple de C++...

C++ is awesome, my main tool, but just not enough anymore.

Bref, Henrique Bucher veut passer au calcul codé en hard pour aller plus vite en exécution, c'est tout à son avantage, un mix eventuel CPU&FPGA peut s’avérer intéressant, mais pas un tout hard pour le moment...
Ça me fait penser à un article que j'avais lu il y a un moment sur Neurogridcircuit de taille d'un ipad, qui affiche une vitesse d’exécution 9 000 fois plus rapide que la meilleure simulation de cerveau humain sur ordinateur, pour une consommation énergétique 40 000 fois moindre...

[mintho carmo]

Il a finalement archive son article, pour le reecrire. Pour etre plus proche de sa pensee. Et il a ecrit un article sur les reactions a son premier article : https://www.linkedin.com/pulse/rippl...enrique-bucher .

Il y a peut etre effectivement un probleme dans la premiere version. Critiquer un langage generaliste comme le C++ en prenant un exemple domaine-specifique et une solution encore plus domaine specifique, on perd le message qu'il voulait faire passer ("le comite C++ s'eloigne de plus en plus de la pratique quotidienne").

Cela semble plus etre un "coup de gueule" qui suit les nombreux autres reaction du meme type, suite aux choix du comite C++ (cf http://www.developpez.net/forums/d15...grera-concepts).

Et sur ce point... je ne suis pas d'accord non plus. Il est vrai que le comite C++ ajoute pas mal de choses inspirees de la programmation fonctionnelle (<troll>qui est avant tout un langage pour que les chercheurs puissent faire joujou, pas un vrai langage de programmation...</troll>). Mais il y a beaucoup de choses egalement qui visent a ameliorer la lecture du code, la gestion des ressources, la recherche d'erreur, la prog concurrente, enrichir la lib standard, etc. Pleins de choses qui ont un impact concret (en particulier sur la qualite logicielle) sur le dev "industriel" de tous les jours.

Bref, le comite C++ est critiquable (p'tin, pourquoi ils ont pas acceptes les concepts !!!), mais cela ne part pas dans un C++ qui serait trop theorique (a mon sens).

[VBurel]

Par exemple quand il parle de désynchronisation, c'est compréhensible dans le trading haute fréquence, vous jouez avec des délais en µS, et que votre programme tourne sur des OS qui gèrent l'ordonnancement, c'est pas étonnant d'avoir des signaux qui n'arrivent pas à la µS près. En passant directement par des opérations codées dans le hardware on a pas cette latence.

la micro seconde aujour'hui c'est déjà long. le trading hyperfréquence est de toute manière limité par les outils de communication, c'est du processus « tortue » par rapport à ce qu'on peut avoir dans le calcul parallèle de rendu graphique ou plus généralement en traitement du signal... et quand bien même, ces questions ne sont pas réellement "langage dépendent". ca n'a aucun sens.

[Orabig]

(...)de plus petits octets de code peuvent être compilés, débogués et optimisés(...)

Je ne savais pas qu'il y avait des petits et des grands octets de code. Ca fait quelle taille un "petit octet" ? 7 bits ?
Plus sérieusement, cette phrase (et plusieurs autres) ne veut strictement rien dire. Messieurs de developpez.net, merci de soit soigner la traduction (on dirait une traduction Google en fait), soit laisser les phrases en anglais...

Edit : Excusez-moi, j'ai été mauvaise langue. Il ne s'agit pas d'une traduction automatique Google, puisque même Google arrive à traduire correctement "smaller bits of code" par "Petits morceaux de code"...