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

C++ Discussion :

Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que Rust et Swift


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre extrêmement actif

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 408
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 408
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Bon dieu, qu'on commence par former correctement les gens, de manière à ce qu'ils soient capables d'utiliser correctement les outils qui leur sont donnés malgré toutes les faiblesses dont ils peuvent souffrir!

    Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!

    C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!
    du fait qu'un humain est faillible, on créé des outils pour justement tenter de juguler le coté aléatoire de la défaillance humaine.
    peu importe le niveau de compétence de quiconque, un outil sera toujours plus performant pour effectuer une vérification d'un pattern qu'on aura jugé incorrect.

    Citation Envoyé par koala01 Voir le message
    Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt

    Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention
    d'où le fait d'utiliser un outil qui coupera le saucisson à ta place, une meilleure qualité de découpe, une plus grande rapidité etc. etc. et on laisse le cuisinier faire des choses pour lesquelles une machine est encore inadéquate. (enfin si la chose qu'on veut est une amélioration de la qualité globale d'un code, sinon, pas d'outils, pas de guidelines, etc. et dans 2 mois on a un code que personne comprend...)

    Citation Envoyé par koala01 Voir le message
    Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!
    plus le "couteau" sera avancé, moins tu auras de chance de te couper un doigt.

    Citation Envoyé par koala01 Voir le message
    Faut il te faire remarquer que même les programmes codés en Rust (je pense nottemment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?
    si on va par là, pourquoi faire du c++, retournons à l'assembleur.

    Citation Envoyé par koala01 Voir le message
    Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter . Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant
    pareil que précédemment, je me demande pourquoi on s'amuse à améliorer les choses, je devrais couper mon saucisson au silex, là j'aurais des sensations pures...

    bref, il y a tellement à dire, je sais pas si c'est une bonne chose.

  2. #2
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 690
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Tu peux tourner les choses comme tu le veux, mes utilisations de operator[] sont safes
    En effet c'est tout a fait safe :
    - dans le premier cas tu fais la même chose qu'avec un itérateur. Les langages "safe" font eux aussi ça sans contrôle de dépassement.
    - dans le second cas tu fais le contrôle de dépassement manuellement.
    Au final tu fais la même chose qu'un langage safe, avec plus de code et sans la garantie que ta règle sera bien respectée partout.

    Citation Envoyé par koala01 Voir le message
    Heu... tu veux parler de la fonction membre at() de std::vector
    Voilà bel et bien une des rares fonctions qui n'auraient jamais du trouver sa place dans la bibliothèque standard; du moins, dans sa version actuelle.
    Car il est totalement incohérent d'avoir recours à une exception pour signaler une erreur de logique qui aurait du être corrigée bien avant d'arriver au stade de la production.
    Si elle avait utilisé une assertion, susceptible d'être supprimée du code binaire exécutable en production, les choses auraient été différentes
    Sauf que c'est encore partir du principe que les développeurs sont parfait et ne laissent jamais passer un bug en production. La pratique a prouvé maintes et maintes fois que c'est faux. Et une erreur de mémoire pouvant se transformer en faille de sécurité, avoir la possibilité de lever une exception pour empêcher un comportement potentiellement dangereux en production fait tout à fait sens.

    Citation Envoyé par koala01 Voir le message
    On a toujours bien dit qu'il fallait être particulièrement attentif lorsque l'on décide de coder en C et en C++, car ce sont des langages qui, contrairement à d'autres, mettent énormément le développeur face à ses responsabilités.
    Est-ce que le fait de dire "on vous avais prévenu" est suffisant sachant que l'on sait que l'humain est faillible ?
    Dans certains cas peut-être. Quand on vise une certaine de sécurité on veut avoir des garanties, pas uniquement des responsables a blâmer en cas d'erreur.

    Citation Envoyé par koala01 Voir le message
    On peut également inverser le raisonnement : bien sur, il n'est pas nécessaire d'utiliser un lance-flammes pour allumer un incendie, un briquet suffit amplement.
    Dés lors, ce n'est pas parce que certains langages sont "moins sécurisés" (par rapport aux conneries que les gens sont susceptibles de faire en les utilisant) qu'il faut absolument en chercher d'autres!
    Heu désolé, mais j'accroche pas du tout au raisonnement dans ce sens. Tu as essayé d'allumer un incendie avec un briquet seul ? A moins de faire exprès, c'est pas si facile que ça, alors qu'avec un lance flamme c'est de ne pas provoquer un incendie qui est difficile.

    Donc oui, même si j'ai un lance-flamme a disposition, je vais demander a mon voisin s'il a un briquet pour allumer ma cigarette. Et même si j'ai un langage qui fait le boulot, je ne m'interdit clairement pas de regarder si il y en a un qui peut faire la même chose avec moins de risques.

    Citation Envoyé par koala01 Voir le message
    Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!
    C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!
    C'est un outil, mais tous les outils ne se valent pas. Si on a un outil qui permet de faire la tache de manière de manière plus sure, il n'y a pas de raison de le mépriser.

    Citation Envoyé par koala01 Voir le message
    Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt
    Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention
    Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!
    J'ai croisé pas mal de vieux menuisiers qui avaient perdu des doigts à la scie circulaire. C'est beaucoup plus rare chez les jeunes artisans depuis que l'on a installé des gardes lames sur les scies circulaires.
    Le responsable de l'erreur est clairement l’utilisateur de l’outil, mais une fois que tu as désigné ton coupable, ton problème est toujours là.

    Citation Envoyé par koala01 Voir le message
    Faut il te faire remarquer que même les programmes codés en Rust (je pense notamment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?
    Il y a certes quelques parties de code en Rust qui ont été introduite dans Gecko ces dernières années, mais il est toujours très majoritairement codé en C++.
    Mais c'est vrai qu'il serait intéressant de comparer le nombre de failles reportées par langage dans Gecko. Cependant, l'introduction de Rust dans le moteur étant plutôt récente, donc je suis pas certain que la quantité et l'historique soient suffisants pour que les chiffres soient représentatif.

    Rust prétend empêcher totalement certains types d'erreur (hors code "unsafe") comme les erreurs mémoire ou les data races et fournit beaucoup de comportement par défaut qui limitent les risques, mais il ne prétends pas éliminer tous les risques de faille.

    Citation Envoyé par koala01 Voir le message
    Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter . Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant
    La encore c'est un raisonnement en tout ou rien. Ce n'est pas parce qu'une technologie ne résout pas tous les problèmes du monde qu'elle n'est pas intéressante.

    Citation Envoyé par koala01 Voir le message
    Et que penses tu du premier conseil pour gagner du temps qui est ... de prendre son temps, justement lorsque l'on développe quelque chose
    Je dirais que c'est un bon conseil, mais que dans la pratique on a jamais le temps de tout faire parfaitement et qu'il y aura forcément a un moment un arbitrage entre le niveau de qualité attendu et le temps a allouer. Et si un langage peut faire gagner du temps en garantissant que certains type d'erreurs sont impossibles, ce temps peut être utilisé pour améliorer la sécurité sur d'autre points.

  3. #3
    Membre éprouvé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 453
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 453
    Par défaut
    Citation Envoyé par archqt Voir le message
    Oui et non car comme C est le plus utilisé, forcément c'est aussi celui qui va montrer le plus de failles.
    Un peu comme windows qui est nettement moins sécurisé que linux car il a plus de virus...Cela ne prouve rien. Ce qui est plus utilisé montrera forcément plus rapidement et plus souvent des failles.
    Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)

  4. #4
    Membre éclairé
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    863
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 863
    Par défaut
    Citation Envoyé par AoCannaille Voir le message
    Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)
    Bien sûr, sauf qu'avec "l'obligation" d'utiliser des pointeurs nus en C, cela facilite l'arrivée de failles. Ce sera plus difficile d'avoir cela en C++ (si on évite les pointeurs nus).
    Idem pour les débordements de buffers, en passant par la STL ce sont des problèmes connus et gérés....

  5. #5
    Invité de passage
    Inscrit en
    Juillet 2002
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : Juillet 2002
    Messages : 1
    Par défaut moi jai ma theorie qui ne tient qu'a moi
    au moins tu depends du systeme dexploitation
    au moins c chiant a deployer au plus c'est long a développer

    maintenant pour faire un simple hello faut avoir la derniere version de dll truc muche :p

    deuxieme coup de gueule on apprend plus au dev pour la base de données de nommé correctement leurs tables
    c'est pourtant simple
    exemple VST_NOM = voiture nom en stock
    non eux ils vont mettre ca en stock alors que stock existe pour pieces détachées

    rien ne vaut la methode a lancienne, quitte a faire plus ligne de code, et ca peu depend le langage, c'est surtout comment on te lapprend desfois c'est dur a récupérer :p

  6. #6
    Membre expérimenté
    Homme Profil pro
    Développeur multiplateformes
    Inscrit en
    Mars 2003
    Messages
    277
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur multiplateformes
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2003
    Messages : 277
    Par défaut
    A chaque langage son usage.
    La question n'est pas d'être sauvé ou non par un C++ dit moderne, mais d'être sauvé par le langage qui correspond à ses besoins.
    Le C++ a fait ses preuves depuis longtemps dans des domaines et contextes bien précis qui ne sont pas comparables avec ceux d'autres langages.
    On constate par contre une multiplication des langages à des fins surtout commerciales sans qu'il y ait d'innovations vraiment significatives.

  7. #7
    Invité de passage
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2019
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2019
    Messages : 1
    Par défaut
    Hello, je me suis inscrit juste pour répondre à ce message.

    A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

    Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    #if _DEBUG 
    	#define _CRTDBG_MAP_ALLOC
    	#include <crtdbg.h>
     
            #ifdef _DEBUG
                  #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
            #else
                  #define DBG_NEW new
    #endif

    Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.
    Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.

    A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.
    Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser. Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne. Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java. Ce qui n'est plus possible avec du C++ moderne, selon moi. Même pour un programmeur C ca va devenir compliqué.

    Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions. Je trouve qu'il ajoute de la complexité à la complexité. Sans parler des messages d'erreurs qui font 3 pages. J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité, des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib, des property comme le C# et pourquoi pas une lib graphique plutôt que de charger la lib de notions de plus en plus techniques. Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.

    Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C. Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?

    Bonne programmation à tous
    Cordialement,

  8. #8
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par yrazet Voir le message
    Hello, je me suis inscrit juste pour répondre à ce message.
    Bienvenue sur le forum

    A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

    Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    #if _DEBUG 
    	#define _CRTDBG_MAP_ALLOC
    	#include <crtdbg.h>
     
            #ifdef _DEBUG
                  #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
            #else
                  #define DBG_NEW new
    #endif
    On l'a tous fait au moins une fois

    Mais, pour être honnête, il y a "à boire et à manger" dans la pratique...

    Il y a, en effet, d'énormes avantages à utiliser un tel système (ne serait-ce que le fait que l'on puisse suivre les allocations de mémoire), mais il y a d'énormes inconvénients, qui découlent tous d'un fait tout bête : tu utilises une fonction qui t'est propre (DBG_NEW), ce qui implique:
    1. que les allocations "tièrces" (comprends : exécutée en dehors de ton projet) ne sont pas prises en compte
    2. qu'il est impossible, même si ton projet est correctement "saucissonné", de ne récupérer qu'une seule classe, une seule paire de fichiers d'en-tête (*.h / *.hpp) et d'implémentation (*.cpp) pour "autre chose" sans soit avoir besoin d'y ajouter <crtdb.h> (quid si un autre système similaire existe déjà dans l'autre projet ) ou sans avoir besoin d'en modifier le code pour pouvoir l'utiliser

    Ce n'est -- bien sur -- absolument pas catastrophique, mais, disons que cela présente malgré tout un frein de taille à la réutilisation potentielle de ton code

    Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.
    Tu as raison, mais le fait est que, de toutes façons, le couple std::shared_ptr et std::weak_ptr ne devrait pas être ton choix "par défaut".

    "Par défaut" (comprends: si tu n'as aucune raison de faire autrement), le meilleur choix de pointeur intelligent est d'utiilser std::unique_ptr, ne serait-ce que pour ne pas avoir à payer le coût d'un comptage de référence qui s'avère bien souvent inutile

    En outre, "la logique" voudrait que l'on n'utilise l'allocation dynamique que pour les classes dites "à sémantique d'entité", étant donné que l'on dispose déjà de deux classes (std::vector et std::array) pour représenter la notion de "tableaux", et que ces deux classes fournissent (lorsqu'elles sont correctement utilisées, cela va de soi) toutes les garanties nécessaires.

    Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.
    Tu as raison sur ce point de vue.

    Malheureusement, les choses ne sont pas aussi simples que cela, pour une simple et bonne raison : C++ est un langage à exception.

    Un code aussi simple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    std::cout<<"hello world";
    pouvant parfaitemet lancer une exception, il est très difficile de prévoir tous les chemins d'exécution qui pourraient nécessiter la libération d'une ressource allouée de manière dynamique.

    C'est la raison de la mise en place de ce que l'on appelle des "capsules RAII" (dans la catégorie desquelles on trouve std::unique_ptr et std::shared_ptr): ce sont des données qui se trouvent -- a priori -- sur la pile, qui sont donc automatiquement détruite lorsque l'on sort de la portée dans laquelle elles ont déclarées (comme n'importe quelle donnée sur la pile), et provoquent donc automatiquement la libération de la ressource allouée de manière dynamique.
    A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.
    A l'exception des pointeurs intelligents, dont on vient de parler, c'est une approche que l'on peut comprendre, mais qu'on ne va sans doute pas plébiciter

    La plupart des fonctionnalités apportées par C++11 et ultérieures permettent en effet de rendre le code plus sur (là où il y avait un manque flagrant de sécurité) et au compilateur de générer du code plus rapide.

    La déclaration des fonctions membre comme étant delete, par exemple, nous permet d'écrire un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class MyEntity{
    public:
        /* une classe ayant sémantique d'entité ne peut être ni copiée ni assignée */
        MyEntity(MyEntity const &) = delete;
        MyEntity& operator=(MyEnity const &) = delete;
        /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit 
         * protected et non virtuel 
         */
        virtual ~MyEntity() /* = default */;
    };
    là où il aurait fallu attendre l'édition de liens pour se rendre compte d'un éventuel problème avec un code proche de
    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
    /* Avant C++11, on aurait travaillé de la sorte */
    class MyEntity{
    public:
        /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit 
         * protected et non virtuel 
         */
        virtual ~MyEntity() 
    private:
        /* on aurait déclaré le constructeur de copie et l'opérateur d'affectation
         * dans l'accessibilité privée, et ON NE LES AURAIT SURTOUT PAS
         * IMPLEMENTES
         */
        MyEntity(MyEntity const &);
        MyEntity & operator=(MyEntity const &);
    }
    Pire encore, si, par distraction, le développeur de MyEntity venait à fournir une implémentation du constructeur de copie et / ou de l'opérateur d'affectation, cela aurait pu occasionner quelques bugs très spécifiques

    De même, les mots clé override et final obligent le compilateur à s'assurer que les fonctions pour lesquelles ont redéfini le comportement existent bel et bien dans la classe de base, et qu'elles sont bel et bien virtuelles.

    Il suffit de "si peu" (une étoile ou une esperluette en plus ou en moins pour le type de retour ou pour la déclaration d'un paramètre, par exemple) pour que l'on assiste à une surcharge de la fonction (qui n'est pas virtuelle) au lieu d'assister à une redéfinition de la fonction virtuelle que ce serait vraiment très dommage de ne pas forcer le compilateur à faire cette vérification

    Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser.
    Là encore, c'est une approche que l'on peut comprendre...

    Après tout, nous nous en sommes passé pendant 13 ans, en créant au besoin un foncteur spécifique à l'intérieur d'une fonction hein

    Cependant, le système avait malgré tout ses limites... Et ce sont ces limites qui ont été repoussées grâce aux expressions lambda

    Il est -- encore une fois -- dommage que tu restes "bloqué" par des limites qui ont pu être abolies par la nouvelle norme

    Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne.
    Ca, c'est sans doute le plus gros problème!!!

    Le C with classes n'a été développé à la base que pour servir de "fondation" au C++, parce qu'il fallait bien avoir "quelque chose" qui soit susceptible d'être compris par un compilateur C pour pouvoir générer le compilateur C++.

    Mais, dés le départ, C et C++ ont été des langages différents, même si les premiers utilisateurs de C++ n'en avaient pas forcément conscience. Et, même si C++ a tout fait (du moins, au début) pour assurer une "certaine compatibilité" avec le C, la différence entre les deux langages n'a pu que s'amplifier avec le temps
    Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java.
    Et tu as encore une fois bien raison!

    Seulement, la manière dont tu t'y prend n'est peut-être pas la bonne
    Ce qui n'est plus possible avec du C++ moderne, selon moi.
    C'est là que tu te trompe

    Les expression lambda (par exemple) sont apparues en 2006 en java. Tu ne dois donc pas avoir peur qu'un développeur java ne comprenne pas une expression proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    [](Type t)->bool{/* ce qu'il faut faire */};
    , même s'il y a une paire de crochets en plus

    Même pour un programmeur C ca va devenir compliqué.
    Ah oui, en C, les expressions lambda n'existent à mon sens pas encore

    Mais C++ est beaucoup plus proche (malgré toutes les différences qu'il a par rapport à java) de java que de C, contrairement à ce que l'on croit

    Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions.
    Chaqun verra midi à sa porte

    Je trouve qu'il ajoute de la complexité à la complexité.
    Au contraire, je te dirais bien que les versions de C++ d'après 2011 font tout pour essayer de supprimer une partie de la complexité, ou, du moins, pour arriver à en cacher une grosse partie

    Sans parler des messages d'erreurs qui font 3 pages.
    Les messages d'erreurs qui font trois pages ont toujours été dus à l'approche générique du C++. Enfin, je vais préciser:

    Quand une seule erreur provoque un message d'erreur de trois pages, tu dois t'attendre à ce que ce soit du à une erreur en programmation générique.

    Que tu aies 120 "faux positifs" après la seule erreur réelle de ton code, parce que le compilateur a "perdu les pédales" mais qu'il a malgré tout essayé de terminer le traitement de ton fichier d'implémentation, ca ca a toujours été

    Mais même là, les nouvelles fonctionnalités tendent de résoudre le problème (je pense, entre autres, au static_assert) en faisant apparaitre en priorité un message plus clair et plus précis .

    J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité,
    Je suis mal réveillé, je ne vois pas trop de quoi tu parles...
    des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib,
    Cela existe depuis toujours, même si ce n'est pas très utilisé
    des property comme le C#
    Quoi des get et des set automatiques Quelle horreur !!!!
    et pourquoi pas une lib graphique
    Figure toi qu'il semblerait que ce soit en cours
    plutôt que de charger la lib de notions de plus en plus techniques.
    La seule notion spécifique à la bibliothèque qui ait été rajoutée (en dehors de certaines classes dont on avait un réel besoin, comme les thread, la gestion du temps ou l'alléatoire), ca a été la sémantique de déplacement.

    Et même la sémantique de déplacement représentait un besoin vraiment réel en termes de performances

    Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.
    Encore une fois, chacun verra midi à sa porte, mais LPCSTR
    1. c'est du C
    2. c'est absolument non portable

    Dans un monde où windows n'est clairement plus le seul système d'exploitation utilisé, le deuxième point est particulièrement dommage

    Au passage, pourquoi ne pas te tourner vers Qt, si tu fait des applications graphiques Il te suffirait d'avoir un compilateur croisé pour que tes applications fonctionnent également sous linux et ou sous mac... cela ne t'intéresse pas
    Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C.
    Et tu te retrouveras avec un tas de problèmes encore bien pire que ceux auxquels tu es confronté avec java ou avec C++

    C a l'énorme avantage d'être la "franqua lingua" du développement. Mais, si tu a l'habitude du C#, ce n'est vraiment pas pareil

    Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?
    Et pourtant, tu choisirais le seul langage qui ne propose à la base ni classes ni espaces de noms
    Bonne programmation à tous
    Cordialement,
    Pareillement
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  9. #9
    Membre éclairé Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    Avril 2015
    Messages
    294
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Avril 2015
    Messages : 294
    Par défaut
    C'est marrant, maintenant que je vous ai lu je ne peux pas m’empêcher de m'imaginer avec les 20 doigts en moins tronçonnés par une mauvaise utilisation de la sémantique de déplacement, et des phalanges sanguinolentes qui traînent un peu partout dans une mémoire encombrées par des tranches de saucissons desséchées et des tartines de lambdas, au milieu des miettes d'un chronomètre atomisé par une mécompréhension de la STL.
    Pour autant, je peux pas m’empêcher de penser que c'est juste une phase d'adolescence programmée, et que quand je serai grand ...

  10. #10
    Membre très actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    891
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 891
    Par défaut C++ est UNIX il fait une seul chose et le fait bien
    C++ est un langage informatique pour convertir du code écrit par un humain en Assembleur efficace. Et il le fait bien, même très bien. Demander d'intégrer de la sécurité se fait généralement au détriment des performances ou de la fonctionnalité bas niveau. Bien des langages ont essayer de faire mieux que C++, jusqu'ici ils ont tous échoués. Le seul véritable challenger est Rust mais il est très récent, pas encore parfaitement éprouvé et un poil moins bon en performances (du moins cela se discute). Et puis ce n'est pas en quelques années que tous va basculer.
    Demander du code propre, sécurisé et facile/rapide a écrire c'est demander l'impossible. Les compilateurs et langages s'améliorent. Mais cela prends du temps et révolutionner le système avec un nième langage ne marche pas car l'on se rends compte au bout d'un moment qu'il a de nouveaux défaut que l'ancien n'avait pas.
    Sécuriser un programme demande du temps, un temps que l'on a jamais en quantité suffisante. Le tout c'est de trouver le bon compromis entre bug/rapidité de développement/efficacité machine... la réponse donne les bonnes méthodes et le bon langage.

  11. #11
    Membre émérite
    Avatar de emixam16
    Homme Profil pro
    Chercheur en sécurité
    Inscrit en
    Juin 2013
    Messages
    335
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Chercheur en sécurité

    Informations forums :
    Inscription : Juin 2013
    Messages : 335
    Par défaut
    Comme tout langage, le C++ à ses avantages et ses inconvénients. Par exemple le C++ est très performant, a une grosse base de code et est très bien supporté mais il laisse la responsabilité de la sécurité au développeur et peut s'avérer fastidieux à écrire.

    Donc il y a des domaines ou il est très bon et d'autre très mauvais. Et c'est un peu simpliste de le critiquer "absolument" ce langage car il y a des domaines ou il est très pertinent.

    C'est comme les gens qui disent "Pour des raisons de sécurité, n’utilisez pas le C!". Ça serait oublier que presque tous les OS sont codés en C et qu'il est bien plus simple de sécuriser du C que des réécrire des bases de codes énormes comme Linux.

    En somme ce n'est pas parce qu'un couteau est moins efficace pour creuser un trou que c'est un outil inutile!

Discussions similaires

  1. tuer un process quand il nous rend pas la main
    Par lerab51 dans le forum Débuter avec Java
    Réponses: 7
    Dernier message: 06/08/2008, 11h35
  2. fichier qui ne se supprime pas car utilisé par un processus
    Par icicmoi dans le forum Windows Forms
    Réponses: 5
    Dernier message: 01/04/2008, 15h16
  3. Réponses: 8
    Dernier message: 28/02/2008, 13h41
  4. Réponses: 4
    Dernier message: 11/05/2007, 17h37
  5. Réponses: 5
    Dernier message: 14/04/2007, 18h47

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