IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Pourquoi C et C++ auraient-ils encore de nombreuses années devant eux ?

Votants
75. Vous ne pouvez pas participer à ce sondage.
  • C et C++ permettent d'avoir plus de contrôle sur le matériel

    41 54,67%
  • C et C++ vous permettent d'écrire du code très efficace

    38 50,67%
  • Les langages C et C++ sont portables

    35 46,67%
  • C et C++ sont des langages qui évoluent

    19 25,33%
  • C et C++ sont largement utilisés

    48 64,00%
  • C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C

    8 10,67%
  • C a peut-être de l'avenir, mais je doute que ça soit le cas de C++

    3 4,00%
  • Je pense qu'ils n'ont plus beaucoup d'années devant eux

    6 8,00%
  • Autre (à préciser)

    3 4,00%
  • Pas d'avis

    3 4,00%
Sondage à choix multiple
Langages de programmation Discussion :

Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ?


Sujet :

Langages de programmation

  1. #381
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par wolinn Voir le message
    sur un point qui est fondamental pour mon usage.
    Bonjour wolinn,
    Quel est le point fondamental pour votre usage? Avez-vous un cas d'usage ou un algorithme pour élaborer une comparaison? Quel est votre problème-type? Peut-être puis-voud t'aider? quels sont vos critères? Si je comprends bien, si les performances sont équivalentes à +/-10% près, vous aurez intérêt à migrer vers Ada, ne serait-ce que pour bénéficier des autres avantages du langage... qu'en pensez-vous?

    Si vous visez Ada (au moins Ada2012), faites-vous aider par Jean-Pierre Rosen, il vous montrera les moyens pour utiliser Ada au mieux.

    Bien cordialement,
    ThierryC

  2. #382
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Mai 2016
    Messages
    313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2016
    Messages : 313
    Points : 1 237
    Points
    1 237
    Par défaut
    Le critère fondamental est l'efficacité du code compilé pour des calculs intensifs.
    Je ne suis pas disposé à changer de langage si cela se traduit par une chute de 50% des performances, avec les compilateurs effectivement disponibles, quand bien même cet autre langage serait plus confortable en développement.
    Dans les exemples que j'ai fournis, il y avait dix programmes de calcul écrits en Ada et en C++, avec codes sources disponibles. Pour quatre de ces programmes, les performances du code compilé étaient comparables entre la version C++ et la version Ada, et les six autres étaient nettement plus lents pour la version Ada, jusqu'à un rapport deux.
    Ca parait plutôt défavorable à Ada, mais comme j'estime que c'est insuffisant pour conclure, je vais faire un test plus significatif pour mes applications. Un programme de calcul d'image de synthèse simplifié.
    Pas d'IHM, juste un fichier de définition géométrique en entrée, avec les propriétés optiques, et un fichier image multispectrale en sortie.
    L'opération fondamentale est le calcul d'intersection entre rayons et entités géométriques, il faut en calculer des centaines de millions pour construire une image, avec des propagations.
    En C++, il me faut typiquement une semaine pour écrire un tel programme, même sans utiliser de bibliothèques, sans IHM, et si je me limite à des primitives géométriques simples, donc je ne devrais pas mettre beaucoup plus de temps en Ada (après une petite autoformation au langage évidemment, mais je ne suis pas très inquiet là dessus, les notions de base sont les mêmes qu'en C++).
    Je n'ai pas le temps de tout faire maintenant d'une traite, trop occupé par ailleurs, mais c'est dans ma pile TODO, section veille technologique, une demi-journée par semaine.

  3. #383
    Invité
    Invité(e)
    Par défaut
    @wolinn : pourquoi ne regarde-tu pas rust ou julia ? Au boulot, on utilise de plus en plus Julia et on est même pas 30% plus lent que du C/C++/fortran, pour un effort de programmation bien moindre.

  4. #384
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2017
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2017
    Messages : 36
    Points : 95
    Points
    95
    Par défaut
    Trois remarques:

    1) Sur la version "orientée composants" de ThierryC:
    • Je n'ai qu'un temps limité à y consacrer donc désolé de répondre rapidement
    • Comme c'est du Delphi je suppose qu'il m'est impossible de compiler directement à moins d'acheter la licence
    • Je ne connais pas l'arborescence habituelle de Delphi mais là je dois dire que je m'y perds complètement. Sur un projet, je m'attends à 3 répertoires: source/tests unitaires, doc/tests fonctionnels, build/install. Tout le reste, c'est de l'accessoire et ne devrait pas être placé au même niveau
    • Au niveau du répertoire source, je m'attends à trouver des sources, pas des .ico, __recovery et .xml
    • Si je regarde Source/Common, qui semble être le répertoire principal pour la conversion nombre en lettres:
      - je n'appelerais pas ça "Common", ça n'apporte aucune information
      - je vois des choses qui n'ont rien à voir avec la conversion chiffre/lettre (N2L.AnalyzeOptions.pas, N2L.TST.FMainFormTestDisplay.pas)
    • Du coup comme la structure des répertoires n'isole pas clairement une fonction de type "convert_from_number_to_string(number, language) -> string", je ne vois pas la structure de composant. Peut-être qu'elle existe dans l'IDE Delphi, mais pas dans les dossiers.
    • Si demain je veux réutiliser "convert_from_number_to_string", je ne sais pas où est la fonction, quelles sont ses dépendances, et comment packager tout ça dans un répertoire indépendant que je peux compiler et linker avec mon application. La structure ne l'indique pas et il n'y a pas de documentation associée (en tout cas je ne la vois pas)
    • Je me suis concentré sur les points qui me gênaient, mais je reconnais un gros travail sur les spécifications et je vois des tests unitaires. Mais concrètement Thierry, comment pouvez-vous espérer nous convaincre avec un projet qu'on ne sait même pas comment installer ?


    2) En ce qui concerne les possibilités d'Ada de créer des composants logiciels :
    • De mon expérience, une bibliothèque d'algèbre linéaire est un des composants les plus compliqué à spécifier et implémenter
    • Concentrons nous sur la partie matrices/vecteurs de taille fixe. Soit X, Y et Z trois vecteurs et M une matrice (disons de dimension 3)
    • Je veux pouvoir écrire Z = X + M*Y et que le code généré soit équivalent à
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      Z_0 = X_0 + M_00*Y_0 + M_01*Y_1 + M_02*Y_2
      Z_1 = X_1 + M_10*Y_0 + M_11*Y_1 + M_12*Y_2
      Z_2 = X_2 + M_20*Y_0 + M_21*Y_1 + M_22*Y_2
      En d'autres termes, il faut faire de l'évaluation paresseuse. En C++, on a un seul moyen de faire: les expressions templates. En dehors du C++, à part les langages qui s'en inspirent (D par exemple), je ne pense pas que cela soit possible. J'ai cherché avec Ada, et je ne trouve aucun article qui mentionne l'évaluation paresseuse ou un bibliothèque d'algèbre linéaire Ada (il y a les bindings BLAS, mais je n'ai rien vu d'autre).



    3) En ce qui concerne la performance, je vous propose de partir sur l'algorithme de tri rapide de Wikipédia. Sur un vecteur avec valeurs aléatoires, on devrait avoir une complexité N logN. Voici mon implémentation

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    g++ -std=c++14 -O3 tri_rapide.cpp && ./a.out
    Code : 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
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    #include <random>
    #include <iostream>
    #include <limits>
    
    #include <chrono>
    #include <ctime>
    #include <vector>
    #include <string>
    #include <algorithm>
    
    // utility
    auto
    now() -> std::string {
        auto t = std::chrono::system_clock::to_time_t(std::chrono::system_clock::now());
        std::string formatted_now = std::ctime(&t);
        formatted_now.pop_back(); // remove newline 
        return formatted_now;
    }
    
    auto
    write_vector(const std::vector<int>& x, const std::string& msg) -> void {
        std::cout << msg << ":\n";
        for (int n=0; n<x.size(); ++n) {
            std::cout << x[n] << "\n";
        }
        std::cout << "\n";
    }
    
    auto random_vector(int size) {
        std::random_device rd;  //Will be used to obtain a seed for the random number engine
        std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
    
        auto imin = std::numeric_limits<int>::min();
        auto imax = std::numeric_limits<int>::max();
        std::uniform_int_distribution<> dis(imin,imax);
    
        std::vector<int> x(size);
     
        for (int n=0; n<size; ++n) {
            //Use dis to transform the random unsigned int generated by gen into an int in [imin,imax]
            x[n] = dis(gen);
        }
        return x;
    }
    
    
    
    
    // algorithms
    
    template<class I, class Pred> inline auto
    // requires I is bidirectional iterator
    bidirectional_partition(I first, I last, Pred p) -> I {
      if (first == last) return last;
    
      auto from_begin = first;
      auto from_end = --last;
    
      while (from_begin != from_end) {
        while ( (from_begin != from_end) &&  p(*from_begin) ) { ++from_begin; }
        while ( (from_begin != from_end) && !p(*from_end)   ) { --from_end; }
        std::iter_swap(from_begin,from_end);
      }
      if (p(*from_begin)) { ++from_begin; }
      return from_begin;
    }
    
    
    
    
    template<class I> auto
    // requires I is iterator
    swap_pivot_with_first(I first, I) {
      return *first;
      // nothing to swap since the chosen pivot is first
    }
    
    
    
    
    template<class I> auto
    // requires I is bidirectional iterator
    quick_sort(I first, I last) -> void {
      I next = std::next(first);
    
      if (first == last) return;
      if (next  == last) return;
    
      auto pivot = swap_pivot_with_first(first,last);
      auto less_than_pivot = [&pivot](const auto& value){ return value < pivot; };
    
      auto partition_point = bidirectional_partition(next,last,less_than_pivot);
      I one_before_partition_point = std::prev(partition_point);
    
      std::iter_swap(first,one_before_partition_point);
      quick_sort(first, one_before_partition_point);
      quick_sort(partition_point,last);
    }
    
    
    enum kind_of_sort {
      handmade_quicksort,
      stl_introsort,
      stl_mergesort
    };
    
    
    int main() {
      const int size = 100'000'000;
      //const int size = 100;
      const kind_of_sort type_de_tri = handmade_quicksort;
    
      auto x = random_vector(size);
    
      //write_vector(x,"Tableau non trié");
    
      std::cout << now() << " - Tri ...\n";
      
      switch(type_de_tri) {
        case handmade_quicksort: {
          quick_sort(x.begin(),x.end());
          break;
        }
        case stl_introsort: {
          sort(x.begin(),x.end());
          break;
        }
        case stl_mergesort: {
          stable_sort(x.begin(),x.end());
          break;
        }
      }
    
      std::cout << now() << " - Tri, fin.\n";
    
      //write_vector(x,"Tableau trié");
    }
    Sans avoir fait rien de spécial, j'obtiens les mêmes performances que la librairie standard (bien sûr je serais N^2 dans le pire des cas mais ce n'est pas la question). Je serais curieux de voir un code similaire en Pascal ou Ada. En particulier en ce qui concerne les points suivants:
    • + le code est (à ma connaissance) quasi-optimal si on ne s'intéresse pas au cache et au parallélisme
    • + le code est générique dans le sens où dès qu'on a une séquence avec begin()/end() et un opérateur < sur les éléments, l'algorithme est utilisable
    • + du point de vue de l'implémentation, on ne peut pas faire plus simple: on manipule directement la mémoire. On peut se prendre des segfault, mais je ne vois pas l'avantage de renvoyer une exception à la place: si on fait des bêtises, il faut les corriger, tester... etc. Pas demander au langage l'impossible ou remplacer un problème (segfault) par un autre (exception). Et en dehors des exceptions, le compilateur ne peut rien pour nous.
    • - On utilise le "duck typing" pour les paramètres templates, donc il n'y a pas de spécification d'interface vérifiée par le compilateur (devrait être possible avec les concepts). [pour l’anecdote, je me suis rendu compte que j'avais seulement besoin d'itérateurs bidirectionnels, pas random-access]
    • - Je ne peux pas faire de vrai packaging (devrait être possible avec les modules + un éventuel gestionnaire de paquets)

  5. #385
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Encore un qui laisse le gant à terre. Ces développeurs C++ n'ont que de la tchatche.
    Je viens de vous dire que j'utilise différents langages et que mon usage du C++ est anecdotique.

    Citation Envoyé par thierryc Voir le message
    Le seul argument qui reste est celui de la popularité.
    Ah oui, comme pour la popularité d'Ada dans l'aéronautique et le spatial.

    Citation Envoyé par thierryc Voir le message
    Cher Simon, Si je compare C++ à Pascal, Ada et Eiffel, c'est effectivement que les paradigmes sont proches, mais que les réalisations sont meilleures. Ce fil de discussion concerne bien l'avenir de C++ que je souhaite le plus bref possible. Faites œuvre citoyenne et aidez-nous à détruire l'utilisation de C++ qui ne répond à plus aucun besoin et qui est nuisible en soi. Ainsi que tous ces autres langages qui ont le même type de syntaxe et la même absence de lisibilité.
    Cher Thierry, Pour moi les langages de programmation sont des outils qu'il faut choisir en fonction du problème à résoudre et non des religions qu'il faut embrasser ou combattre.

    Citation Envoyé par thierryc Voir le message
    Par ailleurs, vous utilisez de nombreux autres langages, comme moi. Et sans doute, vous les mélangez dans le même projet en fonction des besoins, comme moi. Et peut-être même inventez-vous des DSL si nécessaire, comme moi. Je vous en félicite. Vous avez visiblement toutes les alternatives à votre disposition. Laissez tomber le C++, sauf les projets "legacy", le temps de pourvoir à leur remplacement.
    Oui, moi aussi je connais plein d'expressions pompeuses. Le DSL n'est plus trop à la mode mais pour impressionner les copines au bingo, rien ne vaut un "il faut définir un monoide d'endofoncteurs qui parse le stream de façon lazy". Je vous le conseille.

  6. #386
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    J non des religions qu'il faut embrasser
    Cher Simon, c'est bien pour cela qu'il faut détruire le C++, car ses promoteurs en ont fait une religion. Je vous félicite que votre usage en soit anecdotique, et que vous utilisiez d'autres technologies. Et oui, il faut la combattre, car cette religion du C++ est dangereuse pour notre métier.

    J'espère en revanche que vous ne choisissez pas vos technologies en fonction de la mode et que vous avez des critères plus rationnels. Que le DSL soit à la mode importe peu, qu'il soit efficace lorsqu'il est nécessaire, voilà l'important.

    Bien cordialement,
    ThierryC

  7. #387
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Cher Simon, c'est bien pour cela qu'il faut détruire le C++, car ses promoteurs en ont fait une religion. Je vous félicite que votre usage en soit anecdotique, et que vous utilisiez d'autres technologies. Et oui, il faut la combattre, car cette religion du C++ est dangereuse pour notre métier.
    Ainsi soit-il, amen.

  8. #388
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Ainsi soit-il, amen.
    Mode et religion, voilà vos critères pour choisir vos technologies? Bravo.

    Je n'ai utilisé que des argument de productivité, de sécurité de fiabilité, de performance, de formation, tous critères où la technologie C++ est inférieure...

  9. #389
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Mode et religion, voilà vos critères pour choisir vos technologies? Bravo.
    Je n'ai utilisé que des argument de productivité, de sécurité de fiabilité, de performance, de formation, tous critères où la technologie C++ est inférieure...
    en fait non, je trouve que vous êtes pro pascal / ada, et vous essayez de convaincre tout le monde à quel point c'est génial et à quel point le C++ est nul.
    Perso je n'ai pas pu compiler votre programme, j'aurais par ailleurs préféré une version ADA mais bon... qui compile du pascal / delphi sur mac?

    Le code que j'ai lu ne m'a pas impressionné plus que ca, j'ai pensé répondre en c++ mais punaise j'ai juste d'autres choses à faire. D'autre part, je ne vois pas l'intérêt du tout de vouloir detecter un nombre d'un certain range à la compile. Je doute même que Pascal puisse le faire, mais pas moyen de le vérifier par moi même, mais bon si Thierry le dit...

    Thierryc, ce que vous n'avez pas dit, c'est votre experience si/quand vous avez audité des programmes écrits en Java, Pascal voire meme ADA?
    J'ai vu tellement de cas de gens qui ne savaient pas faire évoluer leur soft et ca devenait la pagaille. Des gens aussi qui ne savaient pas bien modéliser les objects et leurs interactions.

    En plus vous pourriez avouer que c'est plus facile d'arriver à la fin pour refaire le programme de 0 avec toute la spec toute faite. J'imagine la pression de l'équipe (d'expert?, de juniors pas cher?, d'équipe mixte offshore/onshore?) qui essayait de faire le projet, puis vous venez avec vos outils et vos experts. Vous n'avez pas de changement de cahier des charges, pas la direction qui vous prend des resources etc.

    Bref, je vous rejoins sur le fait que le boulot se fera offshore parce que c'est hyper moins cher, et que je vois que les clients ne font plus attention à la qualité du code à ce prix. C'est aberrant, j'espère que ca va changer mais ca n'a fait que s'empirer ces 10 dernières années.

  10. #390
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Encore un qui laisse le gant à terre. Ces développeurs C++ n'ont que de la tchatche.
    Mais pourquoi vous nous ne montreriez pas comment bien coder en C++? vous le maitrisez super bien d'après vos dires, j'aimerais bien voir en fait et la je pourrais bien le compiler et vous donner mon avis.

  11. #391
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par _Bérenger_ Voir le message
    Trois remarques:
    Bonjour Bérenger,
    Merci pour ces commentaires. Cela va prendre du temps pour y répondre, c'est vrai que l'architecture des répertoires est organisée pour Delphi. En Delphi, on charge le projet et les composants s'installent pas simple clic. Je m'aperçois qu'il faut que je produise une version avec beaucoup plus de documentation à destination de ceux qui n'utilisent pas Delphi habituellement. Je l'ajoute à ma liste et je reviens vers vous avec une version beaucoup plus documentée. A commencer par un "readme". :-)

    Pour information, il existe une version gratuite de Delphi, elle est beaucoup moins poussée que la version Architecte que j'utilise mais doit compiler ce que j'ai fourni. On la trouvera ici : https://www.embarcadero.com/products.../free-download.

    Pour les exemples fournis concernant les matrices et le calcul intensif, je reviens vers vous avec des solutions Ada et/ou Pascal, suivant ce que je peux mettre au point, et mes disponibilités IRL.

    Bien cordialement,
    ThierryC

  12. #392
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par epsilon68 Voir le message
    Mais pourquoi vous nous ne montreriez pas comment bien coder en C++? vous le maitrisez super bien d'après vos dires, j'aimerais bien voir en fait et la je pourrais bien le compiler et vous donner mon avis.
    C'est bien le problème. C'est trop long. Et certaines des choses que j'ai faites dans le composant sont tout simplement impossibles tout en restant lisibles.

    Par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    type TMonIntervalle = 0..99;
    : il n'y a pas d'intervalles sécurisés en C++. On peut y pallier avec des templates, mais au détriment de la lisibilité.

    Ou:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    type TMonComposant = class(TComponent);
    : il n'y a pas d'équivalent, sauf en C++ Builder.

    ou la structure d'une unité Pascal:
    Code : 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
    unit UnitName;
    
    interface
    uses 
      otherunits, ....;
    
    types
    fonctions
    var
    const
    
    implementation
    uses
      implunits;
    types
    fonctions
    var
    const
    
    initialization
      code d'initialization
    finalization
      code de finalization
    end.
    Cette structure d'unité n'existe pas en C++. On y pallie avec le fichiers .h et .cpp, mais sans les vérifications. Par exemple, le graphe de dépendances des clauses uses de la partie interface ne peut pas être cyclique. Le compilateur y veille. En compilation, une unité n'est compilé qu'une fois. Sur un gros projet, le nombre de fois qu'un fichier .h est compilé est énorme, sans compter le risque d'une dépendance cyclique. En ada, la structure est encore plus solide car les deux parties sont dans deux fichiers différents.

    Donc la recommandation est plutôt d'abandonner le C++ pour les nouveaux projets. Personnellement, je m'en sers sur les projets existants qu'il faut améliorer ou auditer.

    Sinon, j'utilise les bonnes pratiques de Scott Meyers (2 bouquins), avec une vérification toute particulière de deux points: l'héritage en diamant, et le graphe des dépendences. L'un est interdit et l'autre est acyclique.

    Cdt
    ThierryC

  13. #393
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par epsilon68 Voir le message
    en fait non, je trouve que vous êtes pro pascal / ada, et vous essayez de convaincre tout le monde à quel point c'est génial et à quel point le C++ est nul.
    Effectivement j'aime bien Pascal et Ada, Eiffel et Oberon, Prolog et Lisp, OCaml. J'utilise des exemples en Pascal/Ada car ce sont des langages généralistes qui ont une communauté active et qui peuvent vous aider à porter vos projets C++ vers ces langages.

    Effectivement, au vu des dégâts provoqués par C++, je suis anti-C++ (et anti-Java) : Mon propos est clair : l'utilisation de ces langages par des développeurs "normaux" sur un projet "normal" conduit presque toujours à une catastrophe. C'est moins le cas des alternatives, mais il est toujours possible de foirer un projet, je vous l'accorde.

    Citation Envoyé par epsilon68 Voir le message
    Le code que j'ai lu ne m'a pas impressionné plus que ca, j'ai pensé répondre en c++ mais punaise j'ai juste d'autres choses à faire.
    Si vous avez des remarques sur mes sources, je suis toujours preneur pour m'améliorer.

    Citation Envoyé par epsilon68 Voir le message
    D'autre part, je ne vois pas l'intérêt du tout de vouloir detecter un nombre d'un certain range à la compile. Je doute même que Pascal puisse le faire, mais pas moyen de le vérifier par moi même, mais bon si Thierry le dit.
    Le système fonctionne ainsi: il existe une option de détection des vérification d'intervalles à la compilation. Si cette option est activée, ce que je fais par défaut, la vérification est effectué, sinon il n'y a aucune vérification des intervalles. Si la vérification est activée, il y a 2 situations : soit le compilateur peut détecter le viol de l'intervalle dès la compilation et il lève une erreur: il faut corriger avant de compiler. Soit le développeur "trompe" le compilateur ou bien la donnée vient de l'extérieur et une conversion de données à lieu : à ce moment, une exception est levée ... Pour Ada, c'est pareil, mais le compilateur détecte bien plus de situations à la compilation et pas à l'exécution, d'où la sécurité accrue.
    D'un point de vue théorique, la limitation des intervalles fait partie de l'analyse du domaine, que l'on cherche à contraindre au maximum (safety by design).

    Citation Envoyé par epsilon68 Voir le message
    Thierryc, ce que vous n'avez pas dit, c'est votre experience si/quand vous avez audité des programmes écrits en Java, Pascal voire meme ADA?
    J'ai vu tellement de cas de gens qui ne savaient pas faire évoluer leur soft et ca devenait la pagaille. Des gens aussi qui ne savaient pas bien modéliser les objects et leurs interactions.
    J'ai 39 ans d'expérience dans mon métier. Dont 12 en audit. J'ai audité des sources Ada, C++, Java, Pascal, Fortran, Lisp de 4 à 57 millions de lignes de code.
    Auparavant j'ai dirigé des équipes en Fortran, C++, Java, Lisp et Pascal qui ont produit des logiciels d'un 1/2 million à 12 millions de lignes de code.

    La difficulté n'est pas l'audit, les développeurs ont une claire conscience de l'état réel du projet. La difficulté, ce sont les managers qui ont une vue
    très déformée (et souvent optimiste) du projet. J'audite les sources, les processus, et parfois les données. J'essaye le plus souvent de ne pas jeter les projets. Les recommandations sont souvent de faire de la reconstruction du logiciel ("refactoring"), de la documentation (exigences et modèles UML), des tests (unitaires et intégration), et une gestion de projet réaliste (dont tripler les budgets...). Il m'est arrivé de proposer des surcouches pour cacher la complexité du C++, en VB, TCL/TK ou un autre outil GUI pour générer le C++ cible. Souvent, je recommande un gros travail sur le copier/coller, très présent. Sur certains projets, il y a de 30% à 50% du projet qui est copié...
    Les résultats d'audit obéissent à la loi de Pareto: 80% des problèmes se collent dans 20% du source. Si les managers ont de la volonté, il est vraiment possible d'améliorer un projet. Il reste cher, mais au moins, il est de bonne qualité.

    Citation Envoyé par epsilon68 Voir le message
    J'ai vu tellement de cas de gens qui ne savaient pas faire évoluer leur soft et ca devenait la pagaille. Des gens aussi qui ne savaient pas bien modéliser les objects et leurs interactions.
    C'est ce qu'on appelle la dette technique et que je préfère appeler l'entropie logicielle : plus le projet vieillit, sans contrôle, l'entropie augmente et le projet devient ingérable. Je regrette comme vous qu'on n'enseigne pas la modélisation. Enseigner UML n'est pas enseigner la modélisation. On n'enseigne pas Rumbaugh, Booch, Coad (UML in colors), l'utilisation raisonnées des design patterns, et surtout les critères d'arrêt : quand sait-on qu'une modélisation est achevée. On n'enseigne pas l'écriture de cahier des charges modernes, en utilisant les cas d'utilisation, ou même mieux, SysML.

    Citation Envoyé par epsilon68 Voir le message
    En plus vous pourriez avouer que c'est plus facile d'arriver à la fin pour refaire le programme de 0 avec toute la spec toute faite. J'imagine la pression de l'équipe (d'expert?, de juniors pas cher?, d'équipe mixte offshore/onshore?) qui essayait de faire le projet, puis vous venez avec vos outils et vos experts. Vous n'avez pas de changement de cahier des charges, pas la direction qui vous prend des resources etc.
    En tant qu'auditeur, il m'est évidemment interdit de prendre le projet en charge. Nous avons les mêmes managers sur le dos qui voudraient que nous produisions un rapport qui dit que tout va bien est que tout est de la faute du client/développeur/sous-traitant (suivant qui m'engage). Par ailleurs, il y a énormément de projets que j'audite qui ont un bon vécu et toujours pas de spécs....
    Dans la plupart des cas, les recommandations de l'audit ne prend les exemples de mauvais code que comme un symptôme de processus déficients que les managers n'ont pas mis en place: formation, revues par les pairs, tests unitaires, modélisation, vraie mise en place des méthode agiles, etc. C'est très rare de cibler les développeurs qui font de leur mieux avec les (faibles) moyens mis à leur disposition. Toutefois, cela peut arriver.
    Nous ignorons toutes ces pressions et nous basons nos rapports d'audit sur les preuves recueillies, avec une règle particulière : si, dans le temps de l'audit, des éléments ne sont pas disponibles, l'absence de preuve est la preuve de l'absence.
    Si nous auditons un projet, nous nous éliminons d'office de la participation ultérieure au projet. Nous ne pouvons pas être juge et partie.

    Citation Envoyé par epsilon68 Voir le message
    Bref, je vous rejoins sur le fait que le boulot se fera offshore parce que c'est hyper moins cher, et que je vois que les clients ne font plus attention à la qualité du code à ce prix. C'est aberrant, j'espère que ca va changer mais ca n'a fait que s'empirer ces 10 dernières années.
    Je vous rejoins complétement sur le diagnostic, et c'est d'autant plus triste que les équipes françaises travaillent très bien, sont plutôt bien formées, ont une certaine éthique pour produire du source de bonne qualité qui répond au vrai besoin. J'ai vu des équipes Indiennes, par exemple, qui codaient le cahier des charges littéralement, avec toutes les fautes de frappes, sans jamais réfléchir à ce qui est demandé. Avec des résultats prévisibles. Mais c'est apparemment beaucoup moins cher, dans un premier temps. Ces temps-ci, on voit même les équipes migrer de l'Inde ou de la Chine, trop chères (!), vers le Vietnam ou les Philippines. On peut espérer qu'avec la RGPD et d'autres exigences sur la sureté de fonctionnement, cela change la donne.

    Mais c'est bien pourquoi je recommande de changer de technologies, vers des technologies "BIEN ET VITE". En Delphi, on a un RAD très performant, on est à côté de son client, il a des résultats tout de suite, il aura moins tendance à sous-traiter en Inde (avec des livraisons toutes les 3 semaines), et derrière, on peut faire une conception orientée composant extrêmement sophistiquée, documentée automatiquement, avec beaucoup de composants réutilisés pour baisser ses prix et augmenter sa qualité, tout en se payant un bon salaire. Toujours travailler au forfait, sur un cahier des charges. L'écrire s'il le faut.

    Cordialement,
    ThierryC

  14. #394
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Cette structure d'unité n'existe pas en C++. On y pallie avec le fichiers .h et .cpp, mais sans les vérifications. Par exemple, le graphe de dépendances des clauses uses de la partie interface ne peut pas être cyclique. Le compilateur y veille.
    Il est très courant d'utiliser un define ou un pragma pour éviter très facilement ce genre de problème,

    Citation Envoyé par thierryc Voir le message
    En compilation, une unité n'est compilé qu'une fois. Sur un gros projet, le nombre de fois qu'un fichier .h est compilé est énorme, sans compter le risque d'une dépendance cyclique. En ada, la structure est encore plus solide car les deux parties sont dans deux fichiers différents.
    N'importe quoi. En C++ le code est placé dans les cpp et n'est compilé qu'une fois. Les h sont principalement des déclarations. Les h ne posent problème que s'il y a beaucoup de fonctions inline ou de templates et dans ce cas il est possible de précompiler les entètes.

    Citation Envoyé par thierryc Voir le message
    Sinon, j'utilise les bonnes pratiques de Scott Meyers (2 bouquins), avec une vérification toute particulière de deux points: l'héritage en diamant, et le graphe des dépendences. L'un est interdit et l'autre est acyclique.
    L'héritage en diamant est un faux problème répandu par les langages qui ne gèrent pas l'héritage multiple. En 15 ans, j'ai dû faire de l'héritage multiple deux fois et du diamant jamais. Mais si j'avais eu à le faire j'aurais pu.

  15. #395
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Il est très courant d'utiliser un define ou un pragma pour éviter très facilement ce genre de problème,
    Le pragma auquel vous faites référence ne résout en rien le problème d'architecture. Ce pragma évite juste de compiler plusieurs fois le même .h, lorsqu'il est répété dans les clauses include. Rien à voir.

    Citation Envoyé par SimonDecoline Voir le message
    N'importe quoi. En C++ le code est placé dans les cpp et n'est compilé qu'une fois. Les h sont principalement des déclarations. Les h ne posent problème que s'il y a beaucoup de fonctions inline ou de templates et dans ce cas il est possible de précompiler les entètes.
    Ce n'est pas vrai: les .h sont également compilés, et le compilateur passe du temps, beaucoup de temps, à lier déclaration et définition. Plus les .h sont vue, plus le compilateur travaille...
    C'est vrai qu'il existe un palliatif avec les entêtes précompilées, mais cela n'est valable que si les interfaces ne changent pas. Et ça, ça ne marche pas dans une démarche Agile. Car on modifie les interfaces (les .h) au fur et à mesure que l'on ajoute de la fonctionnalité. Résultat. Grosse perte de temps. Pré-compiler une application à 20 millions de lignes de code => cela prend du temps... beaucoup de temps. Au lieu de la minute ou deux en Pascal.

    Citation Envoyé par SimonDecoline Voir le message
    L'héritage en diamant est un faux problème répandu par les langages qui ne gèrent pas l'héritage multiple. En 15 ans, j'ai dû faire de l'héritage multiple deux fois et du diamant jamais. Mais si j'avais eu à le faire j'aurais pu.
    Je vous félicite pour votre sagesse. Je recommande une telle démarche. Mais dans les projets que j'audite avec des développeurs et concepteurs "moyens", l'héritage en diamant est très répandu et provoque plein de soucis. Et comme il n'y a pas de différences entre les interfaces et les classes en C++, l'héritage en diamant est en fait, de plus en plus répandu. Le compilateur ne protège de rien. Il est de la responsabilité du développeur de définir des classes pure abstraites et de les garder ainsi tout au long du projet.
    Un langage moderne fait la distinction entre interface et classe et gère, bien sûr, l'implémentation multiple d'interfaces par une classe et les conflits éventuels.

    Bien cordialement,
    ThierryC

  16. #396
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Ce n'est pas vrai: les .h sont également compilés, et le compilateur passe du temps, beaucoup de temps, à lier déclaration et définition. Plus les .h sont vue, plus le compilateur travaille...
    C'est vrai qu'il existe un palliatif avec les entêtes précompilées, mais cela n'est valable que si les interfaces ne changent pas. Et ça, ça ne marche pas dans une démarche Agile. Car on modifie les interfaces (les .h) au fur et à mesure que l'on ajoute de la fonctionnalité. Résultat. Grosse perte de temps. Pré-compiler une application à 20 millions de lignes de code => cela prend du temps... beaucoup de temps. Au lieu de la minute ou deux en Pascal.
    Les h contiennent des déclarations et ne produisent pas de code machine (hormi les inlines et templates). Un projet agile qui demande de recompiler 20 millions de lignes ce n'est pas un projet agile. Dans un projet correctement organisé, avec compilation séparée des sources, une modification nécessite généralement de recompiler très peu de fichiers. Et un projet un peu sérieux est généralement découpé en modules ou bibliothèques pour simplifier sa conception et sa compilation. Même les noyaux des OS actuels ont des architectures modulaires voire micro-noyau+services. Après il existe effectivement des bibliothèques headers-only à base de template qui sont lourdes à utiliser mais on s'en sort sans trop de problème en organisant un peu le code.

    Citation Envoyé par thierryc Voir le message
    Mais dans les projets que j'audite avec des développeurs et concepteurs "moyens", l'héritage en diamant est très répandu et provoque plein de soucis. Et comme il n'y a pas de différences entre les interfaces et les classes en C++, l'héritage en diamant est en fait, de plus en plus répandu. Le compilateur ne protège de rien. Il est de la responsabilité du développeur de définir des classes pure abstraites et de les garder ainsi tout au long du projet.
    Ah je commence à comprendre : vous devez surement travailler soit avec des développeurs Ada experts soit avec des développeurs C++ étudiants en 1re année. A peu près tous les livres de C++ du monde recommandent d'utiliser l'héritage multiple avec parcimonie voire le déconseillent. Parmi toutes les bibliothèques tierces que j'ai pu utiliser, je pense que l'héritage multiple y est rarissime alors le diamant...

  17. #397
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Les h contiennent des déclarations et ne produisent pas de code machine (hormi les inlines et templates). Un projet agile qui demande de recompiler 20 millions de lignes ce n'est pas un projet agile. Dans un projet correctement organisé, avec compilation séparée des sources, une modification nécessite généralement de recompiler très peu de fichiers. Et un projet un peu sérieux est généralement découpé en modules ou bibliothèques pour simplifier sa conception et sa compilation. Même les noyaux des OS actuels ont des architectures modulaires voire micro-noyau+services. Après il existe effectivement des bibliothèques headers-only à base de template qui sont lourdes à utiliser mais on s'en sort sans trop de problème en organisant un peu le code.


    Ah je commence à comprendre : vous devez surement travailler soit avec des développeurs Ada experts soit avec des développeurs C++ étudiants en 1re année. A peu près tous les livres de C++ du monde recommandent d'utiliser l'héritage multiple avec parcimonie voire le déconseillent. Parmi toutes les bibliothèques tierces que j'ai pu utiliser, je pense que l'héritage multiple y est rarissime alors le diamant...
    Quant à réorganiser le code, vous savez comme moi que les développeurs n'ont pas le temps, que les managers sont sur leur dos pour leur demander plus de fonctionnalités et qu'ils n'en ont rien à f...e de la bonne organisation du projet. Nous y voilà : un projet C++ d'une taille conséquente n'est plus agile... CQFD. Il suffisait de le dire : vous êtes d'accord avec moi.

    Quant aux livres, il va s'en écrire encore beaucoup du style "promis juré, cette fois-ci, en suivant mes conseils, vous aurez enfin un projet qui marche en C++....".LOL. Depuis Scott Meyer, il ne s'est pas arrêté d'en écrire des livres comme ça. Et sur les vrais projets, bizarrement, on ne retrouve pas les meilleures pratiques promises...

    Et j'audite tout le monde. Peut-être aurais-je la chance de tomber sur l'un de vos magnifiques projets où tout va bien dans le meilleur des mondes possibles? Mes outils et mes yeux me diront la vérité. J'ai eu une fois la mission d'auditer, à la demande du client, un maître d’œuvre qui venait de réaliser un superbe logiciel de calcul. Magnifique, je n'avais jamais vu du C++ écrit comme cela, documenté comme cela, etc. Mais pourquoi le client était-il fâché et pourquoi m'avait-il missionné? La réponse fut simple à trouver. Nos braves développeurs, experts, savaient que le C++ était compliqué et avaient donc tout mis en œuvre pour le traiter correctement. Seulement, ce faisant, ils en avaient oublié les utilisateurs. Le mot utilisateur apparaît à la page 200 du dossier de conception. Le logiciel est magnifiquement fait, mais inutilisable, car les cas d'usage sont complétement à côté des besoins des utilisateurs. C'est ça la difficulté du C++ : il y a 2 problèmes à résoudre, celui du client et celui du C++. L'un d'entre eux est toujours privilégié et l'autre ... Bizarrement, ni le client, ni la maîtrise d’œuvre n'étaient contents du rapport d'audit... LOL.

    Mais je note que vous ne m'avez pas répondu sur les dépendances cycliques : en C++, comme en Java, soient A et B deux modules, soit -> la relation d'utilisation, alors A->B et B->A est possible en même temps. Ça compile! Même pas un "warning". Ce genre de laxisme est criminel. Rien que cette propriété devrait condamner l'emploi de ces langages, et on ne devrait réserver l'emploi du C++ et du Java qu'à des projets "legacy" en attendant leur mort tranquille. Ou à des joujoux...

    Quant au diamant, si j'audite des Adaistes experts qui se mettent en danger en C++ en tentant de reproduire ce qu'ils font parfaitement et avec une très haute fiabilité en Ada, le problème est peut-être ailleurs, non? Dans le C++ peut-être?

    Voyez, je suis d'accord avec vous: c'est également criminel d'utiliser le C++ comme premier langage d'enseignement, vu le laxisme et la manque de lisibilité. Ces pauvres 1ère année ne peuvent courir qu'à la catastrophe, d'après vous ... et moi. Voilà un point d'accord.


    Cdt
    ThierryC

  18. #398
    Membre régulier
    Inscrit en
    Décembre 2004
    Messages
    123
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 123
    Points : 97
    Points
    97
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Ah oui, comme pour la popularité d'Ada dans l'aéronautique et le spatial.
    Mais, mon cher Simon, ce n'est pas du tout la même chose. Ada sur Ariane 6 a été choisi après un concours où les différentes alternatives ont été passées en revue. Ce n'est pas de la popularité, c'est de la rationalité.
    Descartes a écrit un très bel ouvrage que je vous recomande : "Règles pour la direction de l'esprit", c'est une méthode d'analyse et de résolution de problèmes. Ça peut vous aider. Plus récemment, on a même inventé la table de décision. Ça marche très bien pour choisir le bon langage sur un projet... à condition de ne pas truander les poids... :-).

    Cdt
    ThierryC

  19. #399
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par thierryc Voir le message
    Mais je note que vous ne m'avez pas répondu sur les dépendances cycliques : en C++, comme en Java, soient A et B deux modules, soit -> la relation d'utilisation, alors A->B et B->A est possible en même temps. Ça compile! Même pas un "warning".
    Je n'ai pas le temps de répondre à tous vos trolls mais juste sur ce point : bien sûr que C++ détecte les dépendances cycliques. Où alors on se comprend mal et dans ce cas donnez-nous un exemple minimal de code C++ illustrant le problème.

  20. #400
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Mai 2016
    Messages
    313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2016
    Messages : 313
    Points : 1 237
    Points
    1 237
    Par défaut
    Moi, je trouve qu'il y a un peu de progrès, thierryc reconnait avoir vu un magnifique projet en C++
    Reste à reconnaitre que le fait que le logiciel final ne réponde pas aux besoins du client ici n'est pas imputable au langage utilisé, et que pour un logiciel de calcul, C++ était même le meilleur choix

Discussions similaires

  1. Pourquoi les langages interprétés sont-ils préférés pour l'analyse de données ?
    Par User23 dans le forum Statistiques, Data Mining et Data Science
    Réponses: 1
    Dernier message: 12/05/2016, 21h18
  2. Les langages statiques sont-ils trop sophistiqués et complexes ?
    Par Katleen Erna dans le forum Actualités
    Réponses: 53
    Dernier message: 20/01/2013, 10h06
  3. Réponses: 2
    Dernier message: 11/05/2010, 19h36
  4. Réponses: 2
    Dernier message: 06/05/2007, 22h37
  5. Pourquoi les mails ne sont ils pas envoyés?
    Par Sunsawe dans le forum Développement
    Réponses: 3
    Dernier message: 12/04/2007, 23h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo