Discussion :

[mintho carmo]

Tu appelles résistance au changement des outils qui datent parfois de plusieurs années avant leur entrée en STL, parce que nécessaire et utiles, ainsi portés et fonctionnels sur toutes les plateformes ?

Ok, je suis coupable d'avoir un raccourci dans mes propos, qui ne reflètent pas ce que je voulais dire : en parlant du C++11, je pensais a "C++ moderne". Et comme "moderne" est un terme vague, il faut que je precise.

Les nouvelles normes introduisent des concepts (nouveaux ou provenants d'autres langages), pour répondre à des problematiques specifiques. Beaucoup n'étudient pas (correctement) ces nouveaux concepts et continue de concevoir leur code comme il y a 20 ans. Comme si les besoins et moyens de la qualité logicielle n'avait pas évolués. Et c'est la qu'il y a de la résistance au changement.

Bien sur, cela n'inclut pas ceux qui ont appris et compris ces concepts et ont choisi, pour X raisons, de ne pas utiliser tel ou tel concept. (Mais quand on fait cela, il faut savoir se remettre en question, parce qu'on risque de le faire pour de mauvaises raisons).

Un exemple concret est que j'entends parfois des gens dire "je n'utilise pas les pointeurs intelligents, parce que j'utilise un compilateur qui ne les supportent pas". Ce qui est une erreur : un vieux compilateur ne supportera par les pointeurs intelligents de "std::". Mais cela ne veut pas dire que le concept n'est pas utilisable (boost, Qt, POCO, etc. Ou sa propre implementation).

Un autre exemple classique est la fameux argument "je n'utilise pas la STL a cause des performances", mais sans avoir fait de benchmarks pour vérifier les performances de la STL ou de son implémentation, et de l'avoir fait sur des codes simplistes non représentatifs.

la raison première est que tu dois assurer que ton code compile sur quasiememt TOUT les complilateurs. Les publics comme msvc gcc clang et autres et les privées qui sont généralement des publics modifiés pour répondre au besoin d'architecture spécifique. Et dans ce cas, faire un myOptional dans le framework plutôt que d'esperer sa presence sur 100 % des compilateurs est nécessaire.

Pour une partie de tes remarques, cf au dessus.

Par contre, le "TOUS les compilateurs" me semble étrange. Qui supporte "TOUS" les compilateurs ? Dans tous les projets sur lequel j'ai bossé, on avait une liste de compilateurs que l'on supportait, avec une version minimale. Tout simplement pour une raison pratique : on ne peut pas faire tourner le code et les tests sur tous les compilateurs, toutes les versions, tous les environnements.

Par contre, si tu parles de supporter une liste de compilateurs contenant des compilateurs ne supportant pas les dernières normes (ou les supportant depuis trop peu de temps pour etre sur de la qualité de leur implémentation), ok, cela est une raison d'implémenter ces fonctionnalités soi même. (Mais dans ce cas, je préfère utiliser les options de compilation pour utiliser l'implémentation standard par défaut et utiliser l'implémentation personnelle quand nécessaire uniquement).

Bref, quand je parlais de résistance au changement, je ne pensais pas à l'utilisation d'une implémentation particulière, mais à l'utilisation des nouveaux concepts.

[Bktero]

Pour désigner une valeur "vide" ou invalide, les pointeurs font tout de même mieux l'affaire que des références.

Oui. Mais à titre personnel, je préfère std::optional ou équivalent.

Pour aller un peu en dehors des clous C++ (surtout quand tu n'a pas C++17 sous la main), on peut aussi utiliser le pattern dit "null object" https://en.wikipedia.org/wiki/Null_Object_pattern

[Bousk]

Un autre exemple classique est la fameux argument "je n'utilise pas la STL a cause des performances", mais sans avoir fait de benchmarks pour vérifier les performances de la STL ou de son implémentation, et de l'avoir fait sur des codes simplistes non représentatifs.

http://www.developpez.net/forums/d15...onible-github/

Par contre, le "TOUS les compilateurs" me semble étrange. Qui supporte "TOUS" les compilateurs ? Dans tous les projets sur lequel j'ai bossé, on avait une liste de compilateurs que l'on supportait, avec une version minimale. Tout simplement pour une raison pratique : on ne peut pas faire tourner le code et les tests sur tous les compilateurs, toutes les versions, tous les environnements.

Ben quand tu cibles PS4 et Xbox One, éventuellement les Nintendo, ça en fait déjà 2-3 totalement différents.
Ensuite tu ajoutes les PC, dont différentes version de Windows potentiellement, différents hardwares surtout (coucou NVidia et ATI, Intel et AMD, pour compiler le game et les shaders), et si en plus tu vas sous Mac ou Linux... oui ça en fait un paquet donc on peut (et on va) parler de "tous les compilateurs". Tu auras bien entendu compris que c'est un "abus" de langage largement utilisé... non ?

Pour aller un peu en dehors des clous C++ (surtout quand tu n'a pas C++17 sous la main), on peut aussi utiliser le pattern dit "null object" https://en.wikipedia.org/wiki/Null_Object_pattern

Et l'implémentation C++ proposé est.. un pointeur nu.

[ternel]

Le problème c'est que le pointeur nu en retour de fonction, c'est pas trop mal, mais comme membre d'un objet, c'est beaucoup moins bien.

[Aurelien.Regat-Barrel]

Ben quand tu cibles PS4 et Xbox One, éventuellement les Nintendo, ça en fait déjà 2-3 totalement différents.
Ensuite tu ajoutes les PC, dont différentes version de Windows potentiellement, différents hardwares surtout (coucou NVidia et ATI, Intel et AMD, pour compiler le game et les shaders), et si en plus tu vas sous Mac ou Linux... oui ça en fait un paquet donc on peut (et on va) parler de "tous les compilateurs".

Le support cross-platform des bibliothèques est un vrai challenge en effet, et je comprends qu'on ne switch pas de sa lib maison qui marche vers std::thread.

Mais C++11, c'est aussi (surtout!) auto, le range for, les lambdas... je pense que c'est assez bien supporté aujourd'hui non?

Au dernier meeting C++ de Berlin le mois dernier, un sondage à mains levées en fin de conférence a montré que la majorité des développeurs C++ présents (600 personnes) utilisent au moins C++11 et non plus C++98.

[oodini]

Avant, j'aurais été tout à fait d'accord avec toi, car il fallait bien nous garder la possibilité d'avoir un paramètre "susceptible de ne pas exister", mais, depuis l'arriver de std::optional
je ne peux qu'être d'accord avec Ehonn

Justement : std::optional n'est pas encore arrivé.

[oodini]

Code :

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

const auto host = cmdline::extractArg(argc, argv, "-host").value_or("localhost")

En quoi ça rend le code plus complexe ?

On ne connaît pas le type de host. Or, un type, c'est de la doc.
On ne va pas revenir sur le débat, qui a déjà eu lieu maintes fois, mais ayant codé 2 ans en Python, je suis content de revenir au C++, car l'absence de typage "visible" du Python dans le Python étais à mon sens un fort manque (tout comme celui des const).

[oodini]

Un exemple qui est vrai "optionnel", ca serait un url query par exemple :

Code :

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

1
2
3
4
5
 
std::optional<std::string> Params::get(std::string const& p);
 
if (auto param = params.get("host"))
    url.append("host", param);  // ajoute "&host=param a l'url

Retourner un unique_ptr ferait l'affaire.

[oodini]

Au dernier meeting C++ de Berlin le mois dernier, un sondage à mains levées en fin de conférence a montré que la majorité des développeurs C++ présents (600 personnes) utilisent au moins C++11 et non plus C++98.

L'échantillon est très peu représentatif : les gens qui vont à ce type de conférence sont déjà au taquet sur les évolutions du C++.

[JolyLoic]

Retourner un unique_ptr ferait l'affaire.

Un unique_ptr suppose de l'allocation dynamique. Un optional non.

[Stephane7]

Bonjour à tous, je suis interressé par le C++ mais vu les critiques qu'il porte, je voudrais connaitre quel langage corrige ses défauts pour me lancer dans l'apprentissage de ce langage.
Merci d'avance, salut!

[Artemus24]

Salut Stephane7.

Il ne faut quand même pas exagérer en croyant que le langage C++ est sur le déclin.
Le concept de la programmation orientée objet n'est pas si évident que cela, surtout si l'on n'a jamais fait de programmation avant.
Commencez par vous familiariser avec les algorithmes, la programmation procédurale avant d'envisager de passer à quelque chose de supérieure.

L'important n'est pas de bien connaitre tel ou tel langage mais de comprendre les idées véhiculées par ce concept et de savoir les appliquer.

@+

[Bousk]

Un unique_ptr suppose de l'allocation dynamique. Un optional non.

Y'a un mécanisme qui empêche l'allocation dynamique pour un optional ?
Parce que sinon pour ma part un simple typedef et j'utilise déjà unique_ptr comme optional sans aucun souci du tout. Si ça retourne nullptr, c'est que rien n'est retourné, et rien n'est donc alloué non plus n'est-ce pas ?

Bonjour à tous, je suis interressé par le C++ mais vu les critiques qu'il porte, je voudrais connaitre quel langage corrige ses défauts pour me lancer dans l'apprentissage de ce langage.
Merci d'avance, salut!

Des critiques y'en a pour tous les langages. Quant aux défaults, liste-les, recherche comment les contrer ou quel langage inclue cette "correction" par défaut.

[Stephane7]

je maîtrise déjà la programmation procédurale et l'algorithmique, c'est que j'ai déjà envisagé le C++, le C et le Java en procédural mais je sais pas quel choisir, un peu d'aide.

[Artemus24]

Salut Stephane7

Et vous avez combien d'années d'expériences en ce domaine ?

@+

[Stephane7]

j'ai 13 ans et j'ai commencé il y'a environ 1 ans et j'ai rapidement continué

[Artemus24]

C'est très bien de se mettre à la programmation aussi jeune, mais ce n'est pas en 1 an que l'on peut dire que l'on maîtrise un sujet comme la programmation procédurale.
Alors vous savez, maîtriser la POO (programmation orientée objet) est un effort plus important que ce que vous avez fait jusqu'à présent.
si vous avez l'occasion de suivre des cours avec un professeur, c'est ce que je vous conseillerais de faire.
Car ce qui va vous manquer, ce sont les méthodes de travail !

[Pierre Louis Chevalier]

j'ai 13 ans et j'ai commencé il y'a environ 1 ans et j'ai rapidement continué

Pour ton age : Programmation Java pour les enfants, les parents et les grands-parents
ou le livre gratuit pour apprendre à programmer avec Python 3 par Gérard Swinnen
C'est mieux en premier langage que le C++, que tu pourra toujours apprendre plus tard si ça te chante.

[Artemus24]

Salut Pierre Louis Chevalier.

Vous n'avez rien de plus compliquer comme littérature à fournir à quelqu'un qui n'a que treize ans ?

@+

[Pierre Louis Chevalier]

Je suis certain que c'est plus simple que C++ en tout cas
Puisqu'il dit avoir un an d'expérience je ne voie pas pourquoi il tenterait pas sa chance avec Java enfants ou Python...
Évidemment il pourrais faire du C ou du Pascal en premier langage mais ça serait tellement moins amusant que Java ou Python.

Programmation Java pour les enfants, les parents et les grands-parents
Ce livre électronique sur la programmation Java est destiné à tous y compris aux enfants de 11 à 18 ans et aux professeurs enseignant l'informatique à l'école.
Ce livre électronique sur la programmation Java est destiné à tous y compris aux enfants de 11 à 18 ans et aux professeurs enseignant l'informatique à l'école. Ce cours de formation gratuit constitue une série de tutoriels idéal pour les parents qui veulent faire apprendre facilement à leur enfant le monde de la programmation des ordinateurs avec le langage Java - le vrai, pas un succédané pour le lecteur pressé et distrait.

Il peut aussi être très utile aux étudiants qui recherchent un complément abordable aux cours ou tutoriels Java exhaustifs et compliqués.

Pour résumer, ce cours de formation Java est assez facile d'accès pour convenir aux débutants en programmation de tous âges, parce qu'il est motivant et ludique, et qu'il inclus aussi des exercices très facile pour apprendre à programmer en java en s'amusant.

Si vous souhaitez donner votre avis sur le contenu de ce cours pour apprendre la programmation facilement avec Java, exprimez votre opinion, profitez de cette discussion 139 commentaires