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 :

Conversion d'un void *objet


Sujet :

C++

  1. #21
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    L'avantage de reinterpret_cast, c'est qu'il est facile de trouver toutes ses occurrences dans un programme en faisant une simple recherche, contrairement au C-style cast.

    Citation Envoyé par Bousk Voir le message
    Et si tu forces un cast via un C-style cast qui est impossible, et qu'un static t'aurait signalé, tu ne peux t'en prendre qu'à toi-même. Et ouais c'est une merde à débuguer et retrouver ce genre de problème, ça tombe bien c'est notre boulot.
    Hélas, ce n'est pas toujours celui qui fait des conneries dans un programme qui en subit les corrections. Et nettoyer la merde des autres n'est pas la partie la plus passionnante de notre boulot.

    Citation Envoyé par Bousk Voir le message
    De même qu'utiliser new[] quand on veut allouer un espace et non des objets au lieu de malloc n'apporte rien. Alors pourquoi faire un new uint8[...] ? Parce que new est du C++ et malloc du C ? Ridicule.
    Parce qu'on a sous la main un wrapper RAII standard qui fait delete[], à savoir la spécialisation de unique_ptr pour les tableaux.
    Pour faire la même chose avec malloc, c'est plus lourd. Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    template<class T>
    struct free_deleter {
        void operator()(T* p) { if(p) free(p); }
    };
     
    int main()
    {
        std::unique_ptr<char,free_deleter<char>> foo((char*) malloc(4));
        if(!foo) return -1;
        strcpy(foo.get(), "bar");
        std::cout << foo.get() << std::endl;
        return 0;
    } // Le destructeur de foo fait un free.

  2. #22
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2011
    Messages
    739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Juin 2011
    Messages : 739
    Points : 3 627
    Points
    3 627
    Par défaut
    (C'est grave si on continue de dériver ou il faut arrêter ?)

    Je suis d'accord pour dire que les cast C sont rapides à écrire, a contrario, ils sont difficilement greppable. Mais les utiliser sachant que le résultat est peut-être une erreur est de mon point vu vraiment pernicieux. Pendant l'écriture ça passe plutôt bien, on sait ce qu'on fait, il n'y a pas de problème. Mais c'est le genre de truc qui pète après les refactoring alors que des erreurs du compilateur serait bien plus appréciable. Perso, je considère le débogage plus comme un échec et une plaie que mon véritable boulot, surtout quand des mécanismes du langage permettent de l'éviter.

    Citation Envoyé par Bousk Voir le message
    De même qu'utiliser new[] quand on veut allouer un espace et non des objets au lieu de malloc n'apporte rien. Alors pourquoi faire un new uint8[...] ? Parce que new est du C++ et malloc du C ? Ridicule.
    Oui et non.
    Oui parce que c'est natif C++ et qu'il n'y a pas besoin d'un quelconque header. Et non parce que je ne trouve pas utile d'utiliser 2 mécanismes d'allocations alors que new fonctionne toujours bien.
    (Dans les faits je n'utilise pas directement l'un ou l'autre, mais un ensemble de pointeurs intelligents/fonctions de construction qui apportent beaucoup plus de sémantique et de souplesse.)

    De toute façon, on pourra lister les bien fait de l'un ou de l'autre, j'ai bien l'impression que chacun campera sur sa position .

    EDIT: je n'avais pas vu la réponse de Pyramidev. Déjà la seconde page ^^.

  3. #23
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 042
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 042
    Points : 2 232
    Points
    2 232
    Par défaut
    En attendant, tu n'as n'as toujours pas donné un seul argument contre les casts C++ (sauf un problème de compatibilité avec les compilateurs d'il y a 20 ans qu'on se fout pas mal).
    Ni un seul argument en faveur du cast C.
    Comme la dis bousk c'est long et chiant. Pour un résultat identique, c'est limite de la torture de lire un code avec plein de reinterpret_cast, const_cast, static_cast...
    Quand je vois ca:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    const_cast<D *>(static_cast<D const *>(q))
    Alors que je pourrais avoir ca:
    Bas ya pas photo perso

    Il y a le mauvais codeur et le bon codeur. Le mauvais il cast, le bon il cast, mais c'est un bon codeur.

    PS: Ca fait du bien de troller un peu :p
    Homer J. Simpson


  4. #24
    Expert éminent sénior

    Avatar de dragonjoker59
    Homme Profil pro
    Software Developer
    Inscrit en
    Juin 2005
    Messages
    2 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Software Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 2 045
    Points : 11 368
    Points
    11 368
    Billets dans le blog
    10
    Par défaut
    Pour avoir débogué une application de plusieurs centaines de milliers de lignes, qui utilisait des unions (avec plein de cochonneries à l'intérieur, et surtout des trucs de tailles diffférentes), et des C-Cast entre des types qui n'avaient rien à voir entre eux (parmi ceux dispo dans cette union), pour moi la plaie c'est le C-Cast. Il m'a fallu des semaines pour en trouver la majorité, et encore maintenant on en a qui pètent de temps en temps.
    En C++ on a des cast "propres" qui nous fournissent un meilleur contrôle de ce que l'on fait, utilisons les, pas uniquement pour nous, mais aussi pour ceux qui vont maintenir le code par la suite...
    Si vous ne trouvez plus rien, cherchez autre chose...

    Vous trouverez ici des tutoriels OpenGL moderne.
    Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
    Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).

  5. #25
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par Astraya Voir le message
    Quand je vois ca:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    const_cast<D *>(static_cast<D const *>(q))
    Alors que je pourrais avoir ca:
    Bas ya pas photo perso
    J'avais pensé à ce cas théorique. Mais l'as-tu rencontré, ne serait-ce qu'une seule fois, en pratique ?
    Sinon, dans quel cas risquerait-on de le rencontrer ?

  6. #26
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Dans tout code qualifié d'erreur de conception (?)

  7. #27
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Finalement, je viens de créer un exemple, mais il faut y aller fort :
    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
    /////////////////////////////////////////////////////////
    // Code accessible uniquement en lecture (niark niark) //
    /////////////////////////////////////////////////////////
     
    class Carensac : public Bonbon {
    public:
        // Fonction non virtuelle absente de la classe Bonbon :
        Couleur getCouleur(); // L'auteur a oublié le const.
        // ...
    };
     
    class PacketDeBonbons {
    public:
        virtual const Bonbon& operator[](size_t indice) const = 0;
        // ...
        // pas de fonction "void ajouter(Bonbon&)" car un bonbon n'est pas forcément un carensac.
    };
     
    class PacketDeCarensacs : public PacketDeBonbons {
    public:
        const Bonbon& operator[](size_t indice) const override;
            // Problème : devrait retourner const Carensac&.
            // Mais l'auteur ne connaît pas les types de retour covariants.
        // ...
    };
     
    ///////////////////////////
    // Code de l'utilisateur //
    ///////////////////////////
     
    Couleur couleurDuPremierCarensac(const PacketDeCarensacs& paquet) {
        assert(paquet.nbElements() > 0);
        return const_cast<Carensac&>(static_cast<const Carensac&>(paquet[0])).getCouleur();
    }
    EDIT : oubli d'un mot-clé public.

  8. #28
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 042
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 042
    Points : 2 232
    Points
    2 232
    Par défaut
    Dans tout code qualifié d'erreur de conception (?)
    'avais pensé à ce cas théorique. Mais l'as-tu rencontré, ne serait-ce qu'une seule fois, en pratique ?
    Dans boost.
    Travaillant moi même dans un milieu n'utilisant pas la stl, on peut rencontrer très souvent ce genre de chose, tout comme des mallocs.

    Quand au fait de chercher tout les reinterpret_cast pour savoir ou est l'erreur c'est que de base il y a un gros souci de lisibilité du code à la base.

    Pour avoir débogué une application de plusieurs centaines de milliers de lignes, qui utilisait des unions (avec plein de cochonneries à l'intérieur, et surtout des trucs de tailles diffférentes), et des C-Cast entre des types qui n'avaient rien à voir entre eux (parmi ceux dispo dans cette union)
    Le souci est peut-être le codeur et pas le cast non?... Tu peux faire le même bordel avec que des cast C++ ça n'arrange rien au souci et au fait que le code est du n'importe quoi.
    Homer J. Simpson


  9. #29
    Expert éminent sénior

    Avatar de dragonjoker59
    Homme Profil pro
    Software Developer
    Inscrit en
    Juin 2005
    Messages
    2 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Software Developer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 2 045
    Points : 11 368
    Points
    11 368
    Billets dans le blog
    10
    Par défaut
    Citation Envoyé par Astraya Voir le message
    Le souci est peut-être le codeur et pas le cast non?... Tu peux faire le même bordel avec que des cast C++ ça n'arrange rien au souci et au fait que le code est du n'importe quoi.
    Je ne dis pas le contraire, mais je dirais que ce sont les codeurs, c'est une appli qui a 30 ans de vie, et je ne sais même pas combien de développeurs ont travaillé dessus, mais le problème était là, et il a bien fallu le résoudre.
    Le fait que ce soient des C-Cast ne m'a pas permis de faire une recherche exhaustive de tous les endroits où on faisait n'importe quoi...
    Si vous ne trouvez plus rien, cherchez autre chose...

    Vous trouverez ici des tutoriels OpenGL moderne.
    Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
    Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).

  10. #30
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

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

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Franchement, quand je travaille avec COM, les casts en void**, je les fais C-Style, principalement par paresse. Mais je suis très à-cheval sur la const-correctness, et si je dois absolument caster pour virer un const, j'utilise systématiquement un const_cast, notamment parce que c'est cherchable (contrairement aux casts C-style).
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Conversion de XML en objet (JAXB en Java) ?
    Par elgaied dans le forum Qt
    Réponses: 0
    Dernier message: 11/02/2013, 16h10
  2. Cast void* - Objet C++
    Par LaMainSurLeKatana dans le forum C++
    Réponses: 5
    Dernier message: 24/08/2010, 14h09
  3. Conversion de string en Objet (zone de texte)
    Par Secco dans le forum VBA Access
    Réponses: 3
    Dernier message: 07/05/2008, 21h17
  4. Question bateau sur la conversion si possible d'objets
    Par kenny49 dans le forum Langage
    Réponses: 1
    Dernier message: 08/08/2007, 20h20
  5. Socket (SMTP) vers objet MimeMessage : conversion ?
    Par Loicb dans le forum Entrée/Sortie
    Réponses: 2
    Dernier message: 06/12/2004, 19h21

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