Discussion :

[_Bérenger_]

Cela dit, dans ConvertirNombreEnChaine, je regrette la baisse de lisibilité induite par l'utilisation de bounded_integer::if_less_than_then_else.

Tu peux t'en sortir avec

Code c++ :

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

1
2
3
4
5
6
7
8
        template<class Integer0, Integer0 min0, Integer0 max0>
        static constexpr bounded_integer
        unsafe_create(bounded_integer<Integer0,min0,max0> i) noexcept
        {
            assert(i.data >= min);
            assert(i.data <= max);
            return bounded_integer{i.data};
        }

Ce qui permet de remplacer les bounded_integer::if_less_than_then_else par :

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
if (0<=unEntier && unEntier<10) {
        auto i = bounded_integer<int, 0, 9>::unsafe_create(unEntier);
        return ConvertirNombreEntre0et9(i);
    }
    if (10<=unEntier && unEntier<20) {
        auto i = bounded_integer<int, 10, 19>::unsafe_create(unEntier);
        return ConvertirNombreEntre10et19(i);
    }
    if (20<=unEntier && unEntier<70) {
        auto i = bounded_integer<int, 20, 69>::unsafe_create(unEntier);
        return ConvertirNombreEntre20et69(i);
    }
    if (70<=unEntier && unEntier<80) {
        auto i = bounded_integer<int, 70, 79>::unsafe_create(unEntier,unContexte);
        return ConvertirNombreEntre70et79(i);
    }
    if (80<=unEntier && unEntier<90) {
        auto i = bounded_integer<int, 80, 89>::unsafe_create(unEntier,unContexte);
        return ConvertirNombreEntre80et89(i);
    }
    if (90<=unEntier && unEntier<100) {
        auto i = bounded_integer<int, 90, 99>::unsafe_create(unEntier,unContexte);
        return ConvertirNombreEntre90et99(i);
    }

C'est un peu mieux.

[*]Pour que l'utilisateur construise un bounded_integer en passant outre le contrôle à la compilation sur les bornes, il est obligé de passer par la fonction statique template unsafe_create.

Personnellement je trouve qu'un constructeur explicite est suffisant, mais pourquoi pas.

[*]Dans bounded_integer, j'ai ajouté les fonctions membres templates minus, divide, modulo

Ce qui me dérange c'est qu'elles induisent une syntaxe beaucoup moins élégante (je sais que tu en as besoin pour vérifier que les "- 70", "-80"... restent dans les bornes, mais c'est quand même moche).

A présent, tout est très sécurisé.

• À condition que bounded_integer soit correct. Je vois déjà un bogue avec divide si N est négatif (les bornes min et max du resultat sont inversées)
• À condition que l'utilisateur de bounded_integer aie suffisamment de discipline pour ne pas toujours utiliser [0,99] (c'était partiellement le cas dans la version précédente)
• Le jeu en vaut-il la chandelle ? De mon point de vue, non avec une telle syntaxe. Peut-être avec un raffinement de constexpr dans les nouvelles normes (typiquement surcharge avec un paramètre constexpr comme le sont "- 70", "-80"...) Et encore, je pense que l'approche est trop rigide.

[Luc Hermitte]

On en parle aussi pour le C++, peut-être en 2050 ils seront d'accord sur la façon de procéder (en étant optimiste ).

Ils ont bien avancé sur le sujet et semblent avoir convergé. A priori, cela a l'air stable pour le C++20: http://www.open-std.org/jtc1/sc22/wg...7/p0542r2.html

Il y a quelques petits défauts à mon goût:
- il n'est pas possible de relaxer des préconditions, ou de renforcer des post-conditions quand on passe par une couche intermédiaire d'indirection -- application typique: en situation d'héritage, cf le LSP
- la notion d'invariant n'est pas officiellement spécifiée, il y a juste des assertions à la place
- on ne peut pas exprimer des post-conditions (sur des fonctions) dépendant de l'état de données (ou autre) avant l'appel à la fonction

Le truc qu'il faudra faire ensuite: faire évoluer les outils d'analyse pour exploiter ces nouvelles annotations officielles lors de la compilation ou autre phase équivalente. Ca, ça va prendre plus de temps.

[marc.collin]

As-tu la référence ? Je ne sais pas à quoi faisait référence cette conversation. Je prenais l'exemple de Microsoft mais ce n'était pas pour dire que le code de Linux est particulièrement propre.

en autre le The Standish Group Report Chaos je te laisse le soin de rechercher les autres

[marc.collin]

Après, c'est aussi le contexte hyper productif que les entreprises imposent aux développeurs. Etre rapide et efficace pour tenir des délais très très serrés.

Quand je vois le programme des formations en école d'ingé... On leur apprend surtout à configurer des frameworks, à savoir lancer une chaîne de compilation. Il y a très peu de temps sur la compréhension de ce qu'ils codent. On demande beaucoup de travail personnel aux étudiants, sur des choses qui devraient être vues en cours (comme la syntaxe, le vocabulaire d'un langage...). Leur formation, c'est 45% de l'auto-formation. Et arrivé sur le terrain, on voit les dégats...

le génie logiciel commence à devenir mature, certe tu peux sans cesse réinventer la roue, mais comme les autres domaine du génie, je crois qu'il est souvent préférable d'opter pour des briques qui ont déjà fait leur preuve.

[Pyramidev]

À condition que bounded_integer soit correct. Je vois déjà un bogue avec divide si N est négatif (les bornes min et max du resultat sont inversées)

J'avais anticipé ce problème et mis une protection avec std::enable_if_t pour interdire le cas où N est négatif :

Code c++ :

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

1
2
3
4
5
template<Integer N, std::enable_if_t<(N > 0), int> = 0>
        constexpr bounded_integer<Integer, min/N, max/N>
        divide() const {
            return bounded_integer<Integer, min/N, max/N>(data / N);
        }

[el_slapper]

le génie logiciel commence à devenir mature, certe tu peux sans cesse réinventer la roue, mais comme les autres domaine du génie, je crois qu'il est souvent préférable d'opter pour des briques qui ont déjà fait leur preuve.

C'est certes une approche industrielle louable, mais est-ce idéal en termes de formation? Je veux dire, assembler des trucs sans comprendre comment ils marchent, c'est quand même toujours risqué. Les bases créatives dont parle zecreator me semblent importantes à maîtriser, même si l'informatique moderne n'en a que peu usage.

[_Bérenger_]

J'avais anticipé ce problème et mis une protection avec std::enable_if_t pour interdire le cas où N est négatif :

Pardon, je n'avais pas vu . (C'est le problème avec les enable_if, on peut les mettre un peu partout)

[zecreator]

le génie logiciel commence à devenir mature, certe tu peux sans cesse réinventer la roue, mais comme les autres domaine du génie, je crois qu'il est souvent préférable d'opter pour des briques qui ont déjà fait leur preuve.

Je suis d'accord sur l'aspect "ne pas réinventer la roue". Mais il faut au moins comprendre comment elle fonctionne et laisser de l'espace au métier de développeur. Mais être créatif, ce n'est peut-être pas ce que demande la génération actuelle de développeurs. Peut-être qu'elle a vu dans ce métier plus de débouchés qu'ailleurs. Il n'y a peut-être pas la passion chez-eux, comme j'ai pû l'avoir il y a 25 ans. Je vois des jeunes développeurs, qui on à peine 3 ans de terrain, déjà postuler pour des postes de chefs de projets. Ce comportement montre bien l'empressement des jeunes à vouloir tout tout de suite, en grillant les étapes. Après, ils ont raison, des fois ça marche.

Aujourd'hui, on mise tout sur les Frameworks. Et avec l'avancée de l'AI, je trouve que le métier de développeur est en déclin (mon avis). Tout est déjà bien automatisé. Ce que naturellement on contrôlait il y a 10 ans (surtout sur un modèle MVC), aujourd'hui on s'en cogne. On fait une confiance aveugle à l'outil. Pas le temps...

[marc.collin]

C'est certes une approche industrielle louable, mais est-ce idéal en termes de formation? Je veux dire, assembler des trucs sans comprendre comment ils marchent, c'est quand même toujours risqué. Les bases créatives dont parle zecreator me semblent importantes à maîtriser, même si l'informatique moderne n'en a que peu usage.

c'est comme ça dans la plupart des domaines... tu regardes les spec d'un composant électronique... il correspond à ce que tu désires... tu l'insères dans ton produit

le génie logiciel va arriver à cela

[marc.collin]

Je suis d'accord sur l'aspect "ne pas réinventer la roue". Mais il faut au moins comprendre comment elle fonctionne et laisser de l'espace au métier de développeur. Mais être créatif, ce n'est peut-être pas ce que demande la génération actuelle de développeurs. Peut-être qu'elle a vu dans ce métier plus de débouchés qu'ailleurs. Il n'y a peut-être pas la passion chez-eux, comme j'ai pû l'avoir il y a 25 ans. Je vois des jeunes développeurs, qui on à peine 3 ans de terrain, déjà postuler pour des postes de chefs de projets. Ce comportement montre bien l'empressement des jeunes à vouloir tout tout de suite, en grillant les étapes. Après, ils ont raison, des fois ça marche.

Aujourd'hui, on mise tout sur les Frameworks. Et avec l'avancée de l'AI, je trouve que le métier de développeur est en déclin (mon avis). Tout est déjà bien automatisé. Ce que naturellement on contrôlait il y a 10 ans (surtout sur un modèle MVC), aujourd'hui on s'en cogne. On fait une confiance aveugle à l'outil. Pas le temps...

aveugle, je crois pas...

à moins d'avoir énormément de moyen financier, ressource et de temps, arriver à juste faire un semblant de spring de risque de t'avoir fait damner le contrat par ton compétiteur

alors que si tu mises constamment sur des briques éprouvé, tu arrives à un résultat plus rapidement et surement beaucoup plus testé que si tu aurais tout fait toi même

[zecreator]

aveugle, je crois pas...

à moins d'avoir énormément de moyen financier, ressource et de temps, arriver à juste faire un semblant de spring de risque de t'avoir fait damner le contrat par ton compétiteur

alors que si tu mises constamment sur des briques éprouvé, tu arrives à un résultat plus rapidement et surement beaucoup plus testé que si tu aurais tout fait toi même

C'est étrange les coïncidences... Je viens de lire un topic sur un échange entre chefs d'entreprises, qui sont tous d'accord pour dire que la génération actuelle de jeunes travailleurs est faite de fainéants, non investis dans leur travail. Que même l’intellect y a perdu. Impossible pour eux d'écrire une phrase correcte avec un vocabulaire correct.

Je ne suis pas d'accord avec ça, mais c'est un autre débat. Mais il est intéressant de souligner la contradiction de ces patrons, qui dans un sens, refusent la liberté de penser à leurs employés, en les formatant comme des machines à produire, et de l'autre se désolent du peu d'intérêt qu'ils portent à leur métier.



Et c'est exactement ce qui se passe avec le métier de développeurs. La nouvelle génération est formatée pour être une masse de machines à produire des applis, sans la moindre réflexion, totalement asservie au "Service client".

[marc.collin]

avec un taux de réussite de projet autour des 30%, alors que la technique est rarement la cause quand même bizarre... quand on sait que les principaules cause d'échec selon par exemple la méthode pmp

planning sous-estimé
obectif imprécis
pas de visibilité sur le projet
manque de disponiblité des resources
manque de communication
manque d'implication des supérieurs...
...
...

tous des causes non lié au développeur

je rajouterais que le gars va surement pas se tiré une balle dans le pied étant lui même propriétaire d'une SSII...

[Invité]

C'est étrange les coïncidences... Je viens de lire un topic sur un échange entre chefs d'entreprises, qui sont tous d'accord pour dire que la génération actuelle de jeunes travailleurs est faite de fainéants, non investis dans leur travail. Que même l’intellect y a perdu. Impossible pour eux d'écrire une phrase correcte avec un vocabulaire correct.
...

Des vieux cons qui crachent sur les jeunes cons, il y en avait déjà du temps de Socrate. Comme dirait Brassens, le temps ne fait rien à l'affaire... Au moins les jeunes cons, leur boulot ce n'est pas d'aller vomir sur les vieux cons dans des "diners d'affaires".

[zecreator]

Sauf que là, les vieux cons, ceux sont nos boss... Tu vois le niveau des mecs.

[foetus]

Et c'est exactement ce qui se passe avec le métier de développeurs. La nouvelle génération est formatée pour être une masse de machines à produire des applis, sans la moindre réflexion, totalement asservie au "Service client".

Pour moi, il est justement là le problème : qu'il critique la formation de la nouvelle génération je n'ai rien contre.
Mais les entreprises informatiques laissent de plus en plus les formations privées (avec tous les systèmes des allocations) se charger de la formation et les entreprises demandent de plus en plus de spécialistes pour minimiser les temps et le coût des "services".
Et donc indirectement, il y a de moins en moins d'entreprises qui ont des équipes en interne, et les développeurs doivent donc passer en majorité par des SC2Is ESNs, cabinet de recrutement, chasseur de têtes, ... et autres trucs qui font leurs lois.

[zecreator]

et les développeurs doivent donc passer en majorité par des SC2Is ESNs, cabinet de recrutement, chasseur de têtes, ... et autres trucs qui font leurs lois.

Ou encore, deviennent freelance. La place de Caen, il n'y a plus beaucoup de développeurs en Interne. Ce ne sont plus que des indépendants. Et pour bouffer, ça devient très très dur tellement il y a de la concurrence. J'ai des potes qui, refusant de quitter la Région, et aussi dégoutés par ce qu'est devenu le métier, on carrément arrêter et se sont reconvertis.

En fait, je crois que pour revenir au sujet de base de ce post, les langages C/C++ existeront encore dans 20 ans, mais restera t-il des développeurs pour les utiliser ?

[thierryc]

Thierryc, je crois que :

1. Tu n'as pas d'humour
2. Si tu relis les 3 pages précédentes et que tu vois là du langage courant, utilisé dans la vie de tous les jours entre 2 personnes, tu as un problème.
3. Tu te surestimes beaucoup. Comparer ton métier à celui d'un médecin est une preuve que beaucoup de développeurs se pensent supérieurs aux autres (après tout, les autres ne sont que des utilisateurs, nous on est des dieux !). Pour info, lorsque ce sera la fin du monde, il vaut mieux avoir un médecin dans son équipe qu'un développeur... Un développeur, sans ordinateur, ça perd tout de suite de sa superbe, alors qu'un médecin...

Bref, prends du recul avec ton métier de "service".

Bonjour zecreator,
c'est vrai que j'ai l'habitude de travailler avec du logiciel critique en sureté de fonctionnement : quand il plante, des gens peuvent mourir. Pour moi, la comparaison avec les médecins est valable. Faire voler un avion, rouler un train, naviguer un bateau d'aujourd'hui sans ordinateurs... C'est bien pour cela que je n'ai pas de tout saisi ta phrase comme étant de l'humour, mais comme étant une preuve de la suffisance de beaucoup d'informaticiens par rapport à leurs clients. Ce n'est pas drôle.

Si on utilise C++ pour faire "joujou", je n'ai aucun problème. les casse-tête, c'est toujours amusant, tant que ça ne dure pas trop longtemps. Ce qui me gêne justement, c'est qu'on s'en sert pour faire des choses qui peuvent être très dangereuses. Et là, c'est une faute professionnelle lourde.

Et le fil de discussion concerne la fin de C/C++/Java, que j'espère proche, et non la fin du monde qui, espérons-le tous, sera plus lointaine ;-)

Maintenant, si tu estimes que je me surestime en étant capable de réaliser et d'auditer des logiciels critiques, étant un professionnel certifié un sureté de fonctionnement et formateur, c'est ton opinion. Je t'invite à essayer.

Delenda C++ est.

Cordialement,
Thierryc

[AoCannaille]

Bonjour zecreator,
c'est vrai que j'ai l'habitude de travailler avec du logiciel critique en sureté de fonctionnement : quand il plante, des gens peuvent mourir. [...]

Tu tournes en rond.
J'ai travaillé dans l'avionique civile, dans un environnement qualifié. On codait en "C Objet" parce qu'aucun compilateur C++ n'était qualifié pour produire notre genre de logiciel.
Et on aurait bien aimé faire du vrai objet, il y aurait eu beauuuucoup plus de controle du compilo sur ces satanés structures pleines de pointeurs de fonctions en void * (beurk). Tout ça compensé par une utilisation systématique et massive des revues de pairs. Le C++ aurait été bien plus sûr de ce que j'en ai vu.

Tu est en train de te battre contre quelque chose qui (malheureusement) reste rare

[zecreator]

Maintenant, si tu estimes que je me surestime en étant capable de réaliser et d'auditer des logiciels critiques, étant un professionnel certifié un sureté de fonctionnement et formateur, c'est ton opinion. Je t'invite à essayer.

Non merci, c'est justement pour éviter ce genre de boulot que je fuis les SSII. Je suis plutôt un créatif dans le développement informatique, et j'ai du mal à croire que dans les métiers d'audit informatique, cela soit l'éclate totale. Je m'extasie plus devant une belle scene 3D codée en javascript/webGL, que devant un process codé en C/C++ qui sert à filtrer les Entrées/Sorties de tel ou tel port.

J'espère pour toi que tu trouves un épanouissement, et surtout du plaisir dans ce que tu fais, parce que tu as tout de même été jusqu'à te certifié. J'espère que c'est pas juste pour l'alimentaire... Et j'espère également que ta certification te sera utile longtemps.

[epsilon68]

On pourrait très bien écrire des logiciels d'analyse de code pour faire des audits. Je trouve cela assez passionnant.
En plus cela ouvre aussi des portes pour fournir du support, du développement, de la formation etc
Dis toi bien un truc, le développement est fait en Inde, en Chine ou autre pays pas cher. Ce qui reste onshore, ce sont justement les métiers d'audit et de qualité.
Je comprends ce que veut dire thierryc, il est peut être même le fondateur d'une société, donc bravo à lui.
Maintenant perso, j'aime bien le C++, mais je ne l'utilise plus professionnellement, j'utilise kotlin / Java car plus rapide à coder et beaucoup de libs disponibles.
Pascal est mort, Ada survit mais pour combien de temps...