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 :

Méthodes virtuelles (again)


Sujet :

C++

  1. #21
    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
    En fait, je dirais que toutes les classes immuables en Java émulent une sémantique de valeur.
    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.

  2. #22
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    tech lead c++ linux
    Inscrit en
    Août 2004
    Messages
    4 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : tech lead c++ linux

    Informations forums :
    Inscription : Août 2004
    Messages : 4 262
    Points : 6 680
    Points
    6 680
    Billets dans le blog
    2
    Par défaut
    Peut-être que cette histoire entité/valeur sert juste aux développeurs c++ à se stabiliser sur leur piédestal
    « L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
    Spinoza — Éthique III, Proposition VII

  3. #23
    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
    Je dirais plutôt que c'est en C++ que ça marche le moins bien, contrairement à C# et Java, car c'est en C++ qu'une même classe peut servir dans les deux modes.
    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.

  4. #24
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    @Koala : en fait c'était surtout la relation de cause à effet que je ne comprenais pas entre l'héritage et une non-sémantique de valeur.

    Si je comprend bien, le polymorphisme va nécessiter de transmettre les instances par références/pointeurs ce qui est incompatible avec la sémantique de valeur.

    Là je serais plutôt de l'avis de r0d pour les références constantes afin d'éviter la copie.

    Mais quid du passage par référence/pointeur non constant ?
    J'ai un peu du mal à voir pourquoi on se l'interdit pour les sémantiques de valeurs. N'est-ce pas plutôt une question de "préférence"/comportement par défaut ? On préfère passer les valeurs par copie par opposition aux entité qu'on ne copie jamais (on les clone) et qu'on passe toujours par référence/pointeurs ?

  5. #25
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Neckara Voir le message
    @Koala : en fait c'était surtout la relation de cause à effet que je ne comprenais pas entre l'héritage et une non-sémantique de valeur.

    Si je comprend bien, le polymorphisme va nécessiter de transmettre les instances par références/pointeurs ce qui est incompatible avec la sémantique de valeur.
    Il y a effectivement le problème que le polymorphisme va nécessiter l'utilisation de pointeurs et ou de références, mais il y a surtout le fait que, dés le moment où tu rentre dans une logique d'héritage, tu te retrouves avec une contrainte que tu n'as pas (forcément) lorsque tu n'utilises pas cet héritage: le fait que chaque objet est a priori unique, car non copiable, car tu dois avoir la certitude, dans les pires circonstances, qu'un objet passant pour être du type de base sera, malgré tout, l'objet sur lequel tu penses travailler.

    Ce qui implique que:
    le type réel de l'objet pointé (ou référencé, je ne fais aucune différence ici) soit celui auquel tu t'attends
    même si deux objets distincts ont des valeurs strictement égales, tu puisses déterminer exactement avec lequel tu vas travailler.

    Là je serais plutôt de l'avis de r0d pour les références constantes afin d'éviter la copie.
    Les références (constantes ou non) sont bel et bien un moyen d'éviter la copie mais l'idée est d'interdire la copie pour les classes ayant sémantique d'entité (ce qui implique que nous ne pourrons les transmettre d'office que sous forme de référence ou de pointeur, je te l'accorde ) pour être sur que toutes les modifications qui pourraient être apportées à un objet particulier soient bel et bien... appliquées à cet objet particulier
    Mais quid du passage par référence/pointeur non constant ?
    J'ai un peu du mal à voir pourquoi on se l'interdit pour les sémantiques de valeurs. N'est-ce pas plutôt une question de "préférence"/comportement par défaut ? On préfère passer les valeurs par copie par opposition aux entité qu'on ne copie jamais (on les clone) et qu'on passe toujours par référence/pointeurs ?
    Prends peut etre deux exemples simples : une classe Point, qui représente des coordonnées en abscisse et en ordonnée ou une classe Couleur qui représente les taux de rouge, de vert et de bleu.

    Si tu modifies un tant soit peu les valeurs d'une de ces classes, tu obtiens... une nouvelle valeur.

    Le point se trouvant en x = 12.0, y = 13.0 n'est, définitivement, pas le même point que celui qui se trouverait en x = 12.5 y = 13.0 ou la couleur R=125 G= 45 B = 63 a beau être très proche de la couleur R=125 G= 45 B = 64, on ne peut décidément pas les considérer comme égales.

    On peut d'ailleurs suivre exactement le même raisonnement pour les valeurs entières (ou réelles) représentées par les types primitifs dont on dispose : 12 n'est, quoi qu'il arrive, jamais égal à 13: ce sont bel et bien des valeurs totalement différentes

    A partir de ces constatations, il est aisé (et tout à fait cohérent) d'estimer qu'une classe ayant sémantique de valeur est a priori constante.

    Que l'on passe un objet dont le type a sémantique de valeur par référence constante ou non ne va pas importer énormément.

    C'est surtout le fait de ne pas prévoir de comportement qui occasionnerait la modification de l'objet qui rentre dans la "logique des choses", sachant que, si tu crées une fonction qui prend un objet ayant sémantique de valeur par référence non constante, et que cette fonction (c'est son droit, vu qu'elle ne s'engage pas à ne pas modifier l'objet en question) vient à modifier la référence, cela passera par... l'affectation d'un nouvel objet
    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

  6. #26
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par koala01 Voir le message
    tu te retrouves avec une contrainte que tu n'as pas (forcément) lorsque tu n'utilises pas cet héritage: le fait que chaque objet est a priori unique, car non copiable, car tu dois avoir la certitude, dans les pires circonstances, qu'un objet passant pour être du type de base sera, malgré tout, l'objet sur lequel tu penses travailler.
    Je vois c'est pour rendre le code plus idiot-proof.
    On "signale" que le pointeur peut pointer sur des objets de différents types en empêchant la copie. Et dans le cas d'une sémantique de valeur, une copie signifierais de créer un nouvel objet "non-égal" à l'objet d'origine.
    Mais ne peux-t-on pas envisager de redéfinir le constructeur par copie et l'opérateur d'affectation pour permettre une copie avec des instances de même type et l'empêcher si on a des types différents quand on a une sémantique de valeur ?

    Citation Envoyé par koala01 Voir le message
    A partir de ces constatations, il est aisé (et tout à fait cohérent) d'estimer qu'une classe ayant sémantique de valeur est a priori constante.
    Je ne suis pas d'accord avec ce raisonnement : avec la sémantique de valeur, on dissocie "l'identité" de l'instance de l'adresse mémoire où elle se trouve : deux instances sont égales si elles ont même valeur pas si elles sont dans le même espace mémoire (mais à un temps différent).
    Sinon la modification par copie d'une instance créée spécialement au lieu d'une classe constante permettre la réaffectation me plaît mieux pour conserver la cohérence mais dans le cas là pourquoi ne pas faire une méthode de "réaffectation", une sorte de "pseudo destructeur-constructeur" afin d'éviter la copie d'une instance temporaire ?
    A partir de là on peut aussi envisager que le "pseudo destructeur-constructeur" prend des valeurs par défaut pour certains paramètres qui seront la valeur de l'ancienne instance ?

    Sinon je pensais à une chose, imaginons qu'on ai un serveur multi-thread de MMORPG (c'est à la mode en plus), il travaille sur une liste de client (sémantique d'entité) mais pour plus de performance, il copie cette liste et son contenu pour éviter de passer trop de temps avec l'accès partagé.
    On considère alors que la liste principale contient des instances d'une classe à sémantique d'entité et que les autres listes contiennent des instances d'une classe "allégée" à sémantique de valeur ?
    Mais les deux classes auront des choses en communs et on peut envisager un héritage (?)

  7. #27
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Je vois c'est pour rendre le code plus idiot-proof.

    On "signale" que le pointeur peut pointer sur des objets de différents types en empêchant la copie. Et dans le cas d'une sémantique de valeur, une copie signifierais de créer un nouvel objet "non-égal" à l'objet d'origine.
    Il ne s'agit pas de rendre le code "idiot-proof", il s'agit d'assurer le respect d'une restriction claire et précise qui a trait à l'"unicité référentielle": comme il n'y aura jamais qu'un et un seul koala01 (encore heureux diront sans doute certains ), on ne peut en aucun cas permettre qu'il soit ne serait-ce que envisageable d'en créer une copie.

    Tout le reste ne découle que de cette restriction imposée par la nature même de ce que modélise la classe!

    Mais ne peux-t-on pas envisager de redéfinir le constructeur par copie et l'opérateur d'affectation pour permettre une copie avec des instances de même type et l'empêcher si on a des types différents quand on a une sémantique de valeur ?
    L'opérateur d'affectation et le constructeur par copie font partie des quatre comportements qu'il faut implémenter pour une classe ayant sémantique de valeur!
    Je ne suis pas d'accord avec ce raisonnement : avec la sémantique de valeur, on dissocie "l'identité" de l'instance de l'adresse mémoire où elle se trouve : deux instances sont égales si elles ont même valeur pas si elles sont dans le même espace (mais à un temps différent).
    Nous sommes bien d'accord là dessus: ce qui importe, c'est l'ensemble des valeurs qu'elles représentent et non l'adresse mémoire à laquelle elles se trouvent
    Sinon la modification par copie d'une instance créée spécialement au lieu d'une classe constante permettre la réaffectation me plaît mieux pour conserver la cohérence mais dans le cas là pourquoi ne pas faire une méthode de "réaffectation", une sorte de "pseudo destructeur-constructeur" afin d'éviter la copie d'une instance temporaire ?
    Mais c'est en gros ce qui est fait avec le principe NRVO.

    Cependant, il y a effectivement quelques cas où l'on ne peut pas se contenter d'une copie simple, et où il faut s'assurer de la destruction correcte de certains éléments.

    std::string est, typiquement, une classe ayant sémantique de valeur, car tu peux très bien avoir deux chaines de caractères représentant le même terme à deux adresses mémoires différentes.

    Mais, lorsque l'on affecte une nouvelle valeur à une chaine existante, il faut s'assurer que la mémoire allouée à la représentation interne de la valeur d'origine soit correctement libérée

    A partir de là on peut aussi envisager que le "pseudo destructeur-constructeur" prend des valeurs par défaut pour certains paramètres qui seront la valeur de l'ancienne instance ?
    Attends...

    Tu as, typiquement:
    1. un constructeur ne prenant aucun argument, qui va initialiser les valeurs à des valeurs par défaut (bien qu'il puisse etre absent)
    2. un constructeur par copie qui va copier les valeurs une à une
    3. un constructeur prenant un ou plusieurs argument qui va te permettre de définir les valeurs au moment de la création.
    4. un opérateur d'affectation qui s'assurera, si besoin en est, que la mémoire allouée à la représentation interne des données sera correctement libérée
    Tu ne crois pas qu'il y a largement tout ce qu'il faut pour faire tout ce que l'on veut

    Si tu veux déplacer un objet en agissant sur le point qui représente son coin supérieur gauche (mettons que ce soit le seul point qui existe pour la facilité ), soit tu affecte directement un nouveau point
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    void MyClass::setPosition(Point const & newpoint)
    {
        topLeftCorner = newpoint;
    }
    Soit, tu calcule un nouveau point en fonction de la position actuel de l'objet
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    void MyClass::move(int distanceX, int distanceY)
    {
        topLeftCorner = Point(x()+ distanceX,y()+distanceY);
    }
    Il n'y a vraiment que si distanceX et distanceY valent 0 que tu fais du travail pour rien, autrement, NRVO aidant, tu n'as à chaque fois qu'une affectation
    Sinon je pensais à une chose, imaginons qu'on ai un serveur multi-thread de MMORPG (c'est à la mode en plus), il travaille sur une liste de client (sémantique d'entité) mais pour plus de performance, il copie cette liste et son contenu pour éviter de passer trop de temps avec l'accès partagé.
    On considère alors que la liste principale contient des instances d'une classe à sémantique d'entité et que les autres listes contiennent des instances d'une classe "allégée" à sémantique de valeur ?
    Mais les deux classes auront des choses en communs et on peut envisager un héritage (?)
    La classe client a sémantique d'entité, point barre!!!

    Si tu veux dupliquer la liste de tes clients, il faudra travailler de manière à tout ce qui peut arriver à un client quelconque arrive bel et bien au client qu'il représente.

    Autrement dit, si duplication de liste il doit y avoir, c'est une copie contenant des pointeurs qui doit être effectuée

    Sinon, pour être sur que chaque joueur voie bel et bien ce qui se rapporte à lui, tu devras en arriver à mettre une sorte de proxy en place qui fera le lien entre ce qui arrive aux "copies" et ce qui arrive aux "originaux", et ca deviendra rapidement ingérable.

    Une autre solution consiste à avoir "simplement" un certain nombre de listes clairement distinctes, en "splittant" la liste en autant de sous listes que tu as de threads, par exemple
    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

  8. #28
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Apparement je ne suis pas le seul à avoir des problème de clavier qui envoit la réponse avant d'avoir fini d'écrire

    Citation Envoyé par koala01 Voir le message
    Il ne s'agit pas de rendre le code "idiot-proof", il s'agit d'assurer le respect d'une restriction claire et précise qui a trait à l'"unicité référentielle": comme il n'y aura jamais qu'un et un seul koala01 (encore heureux diront sans doute certains ), on ne peut en aucun cas permettre qu'il soit ne serait-ce que envisageable d'en créer une copie.

    Tout le reste ne découle que de cette restriction imposée par la nature même de ce que modélise la classe!
    Mais quid des classes à sémantiques de valeur ? Si j'ai bien compris c'est à cause de la copie incompatible avec l'héritage qu'on ne peut pas faire hériter les classes à sémentiques de valeurs. Mais si on fait en sorte de ne pouvoir affecter/copier qu'avec des instances ayant strictement le même type ?


    Citation Envoyé par koala01 Voir le message
    Mais c'est en gros ce qui est fait avec le principe NRVO.
    Encore un autre sigle il en existe combien ??
    Si je comprend bien, c'est le fait de retourner la même instance que celle passée par l'utilisateur mais en ayant modifié que quelques champs ?

    Citation Envoyé par koala01 Voir le message
    Mais, lorsque l'on affecte une nouvelle valeur à une chaine existante, il faut s'assurer que la mémoire allouée à la représentation interne de la valeur d'origine soit correctement libérée
    mais si la nouvelle chaîne est plus petite que l'ancienne on peut parfaitement ne pas réallouer et réécrire par dessus.


    Citation Envoyé par koala01 Voir le message
    Si tu veux déplacer un objet en agissant sur le point qui représente son coin supérieur gauche (mettons que ce soit le seul point qui existe pour la facilité ), soit tu affecte directement un nouveau point
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    void MyClass::setPosition(Point const & newpoint)
    {
        topLeftCorner = newpoint;
    }
    Soit, tu calcule un nouveau point en fonction de la position actuel de l'objet
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    void MyClass::move(int distanceX, int distanceY)
    {
        topLeftCorner = Point(x()+ distanceX,y()+distanceY);
    }
    Il n'y a vraiment que si distanceX et distanceY valent 0 que tu fais du travail pour rien, autrement, NRVO aidant, tu n'as à chaque fois qu'une affectation
    J'ai du mal comprendre NRVO
    Il n'y a pas de "glossaire/dictionnaire des sigles" sur DVP ?

    Citation Envoyé par koala01 Voir le message
    Si tu veux dupliquer la liste de tes clients, il faudra travailler de manière à tout ce qui peut arriver à un client quelconque arrive bel et bien au client qu'il représente.

    Autrement dit, si duplication de liste il doit y avoir, c'est une copie contenant des pointeurs qui doit être effectuée

    Sinon, pour être sur que chaque joueur voie bel et bien ce qui se rapporte à lui, tu devras en arriver à mettre une sorte de proxy en place qui fera le lien entre ce qui arrive aux "copies" et ce qui arrive aux "originaux", et ca deviendra rapidement ingérable.
    Je pensais par exemple pour certains attributs ne les mettre à jour non pas à chaque modifications ni à chaque accès à l'attribut mais régulièrement à chaque cycle de X secondes.
    Un peu comme on fait sur différents serveurs où on ne met à jour les classements qu'à minuit.

    Mais on a tout de même une classe à sémantique d'entité copiable ici non ?

    Citation Envoyé par koala01 Voir le message
    Une autre solution consiste à avoir "simplement" un certain nombre de listes clairement distinctes, en "splittant" la liste en autant de sous listes que tu as de threads, par exemple
    C'est une idée assez intéressante il faut que je la retienne^^

  9. #29
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Apparement je ne suis pas le seul à avoir des problème de clavier qui envoit la réponse avant d'avoir fini d'écrire
    Oui, la tabulation est décidément trop proche du a pour mes gros doigts
    Mais quid des classes à sémantiques de valeur ? Si j'ai bien compris c'est à cause de la copie incompatible avec l'héritage qu'on ne peut pas faire hériter les classes à sémentiques de valeurs. Mais si on fait en sorte de ne pouvoir affecter/copier qu'avec des instances ayant strictement le même type ?
    Atternds, je te propose de reprendre dans l'ordre...

    1- Jusqu'à preuve du contraire, tout ce qui entre dans une hiérarchie de classe a sémantique d'entité car il faut assurer une unicité référentielle (il faut pouvoir s'assurer que tout ce qui arrive à un objet clairement identifié sera répercuté sur cet objet clairement identifié, quel que soit le nombre de références (ou de pointeurs vers) à cet objet sur lesquelles on puisse travailler)

    2- on doit rendre les classes ayant sémantique d'entité non copiables (et non affectable) cette unicité référentielle

    3- En partant du principe que l'on a rendu ces classes non copiables et non assignables, le seul moyen qu'il nous reste pour transmettre les objets est de passer par des pointeurs ou par des références (éventuellement constantes), ce qui tombe bien: c'est requis pour profiter du polymorphisme

    4- Certains éléments (ceux qui, en dehors de l'adresse mémoire qui est définitivement trop "volatile", permettront d'identifier l'objet de manière unique et non ambigüe) seront "immuables" (aucun comportement ne permettra jamais de modifier les valeurs qu'ils représentent), mais les autres peuvent être modifiés en passant par les comportements adéquats (ex: le numéro de compte d'un compte en banque est constant, mais le solde peut évoluer en fonction des opérations effectuées sur ce compte )

    5- Les classes ayant sémantique de valeur n'ont que faire d'une unicité référentielle: ce qui importe, c'est les valeurs qu'elles représente (on se fout de savoir si la couleur vient de gauche, de droite ou du centre, du moment que c'est la bonne couleur )

    6- Comme il n'y a pas besoin d'unicité référentielle, il n'y a aucun problème à ce que les classes ayant sémantique de valeur soient copiables et affectable et elles le sont généralement

    7-Comme ce qui importe pour les classes ayant sémantique de valeur, c'est les valeurs qu'elles représentent, il est "cohérent" de permettre au minimum la comparaison par égalité de ces classes (et peut etre plus petit, à évaluer selon la classe envisagée ).

    8- Si on modifie une seule valeur d'une classe ayant sémantique de valeur, on obtient une nouvelle valeur (cf l'exemple avec le point ou la couleur de mon intervention précédante). Il n'y a donc pas vraiment lieu de prévoir un comportement qui puisse modifier les valeurs en interne: si on veut une obtenir une instance avec de nouvelle valeurs, on crée simplement une nouvelle instance avec les dites valeurs et on l'assigne à la variable qu'on veut modifier

    Encore un autre sigle il en existe combien ??
    Si je comprend bien, c'est le fait de retourner la même instance que celle passée par l'utilisateur mais en ayant modifié que quelques champs ?
    Beaucoup

    (N)RVO est l'acronyme de Return Value Optimisation.

    L'idée est que si tu essaye d'affecter le retour d'une fonction qui renvoie une valeur à une variable, on va éviter d'avoir un cycle de création + copie + affectation, qui serait faire trois fois le meme job
    mais si la nouvelle chaîne est plus petite que l'ancienne on peut parfaitement ne pas réallouer et réécrire par dessus.
    On peut...

    Mais comme ce n'est possible que pour des chaines plus petites, il faut prévoir le fait que l'on puisse aussi tenter d'affecter une chaine plus grande
    Je pensais par exemple pour certains attributs ne les mettre à jour non pas à chaque modifications ni à chaque accès à l'attribut mais régulièrement à chaque cycle de X secondes.
    Un peu comme on fait sur différents serveurs où on ne met à jour les classements qu'à minuit.
    Et tu te baladerais avec des objets incomplets

    Ca me semble pour le moins risqué

    Mais on a tout de même une classe à sémantique d'entité copiable ici non ?
    Non, pas du tout...

    La liste a -- sauf avis contraire de notre part, entre autre si on décide d'y placer des objets dont le type a sémantique d'entité-- sémantique de valeur et est donc, a priori, copiable.

    Mais les clients de ton serveur sont tous identifiés de manière unique et non ambigüe, ne serait-ce que par leur pseudo (en plus de l'adresse mémoire à laquelle ils se trouvent)

    Tu pourrais, a priori, envisager de copier une liste (si son contenu était copiable), mais comme le contenu n'est pas copiable... comment veux tu arriver à la copier

    C'est la raison pour laquelle la seule solution passe par... quelque chos qui est copiable: le pointeur (de préférence intelligent) car ce n'est jamais qu'une valeur numérique non signée qui correspond à une adresse mémoire, et ca, c'est copiable (sans provoquer néanmoins la copie de l'objet pointé pour la cause)

    C'est une idée assez intéressante il faut que je la retienne^^
    Elle m'est venue sur l'instant
    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

  10. #30
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par koala01 Voir le message
    1- Jusqu'à preuve du contraire, tout ce qui entre dans une hiérarchie de classe a sémantique d'entité car il faut assurer une unicité référentielle (il faut pouvoir s'assurer que tout ce qui arrive à un objet clairement identifié sera répercuté sur cet objet clairement identifié, quel que soit le nombre de références (ou de pointeurs vers) à cet objet sur lesquelles on puisse travailler)
    Je comprend mal ce point là.
    J'ai un entier qui est un nombre, qu'est-ce qui empêche mon entier d'avoir une sémantique de valeur ?

    Citation Envoyé par koala01 Voir le message
    8- Si on modifie une seule valeur d'une classe ayant sémantique de valeur, on obtient une nouvelle valeur (cf l'exemple avec le point ou la couleur de mon intervention précédante). Il n'y a donc pas vraiment lieu de prévoir un comportement qui puisse modifier les valeurs en interne: si on veut une obtenir une instance avec de nouvelle valeurs, on crée simplement une nouvelle instance avec les dites valeurs et on l'assigne à la variable qu'on veut modifier
    Beaucoup
    Comme tu l'a dit, les listes ont une sémantique de valeur (?) or quand on insère ou supprime des éléments, on ne recréé pas entièrement la liste.

  11. #31
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Comme tu l'a dit, les listes ont une sémantique de valeur (?) or quand on insère ou supprime des éléments, on ne recréé pas entièrement la liste.
    Les listes ont sémantiques de valeur oui, mais il s'agit juste de stockage et donc je les placerais à part.
    Si tu prends 2 listes identiques, ajoutes un élement à l'une d'elles, elles ne sont plus identiques. C'est ça qui représente la sémantique de valeur.

    Comme tout, il existe des cas particuliers, et on peut en trouver autant qu'on veut. Mais le concept initial n'en est pas moins intéressant et à respecter.

    Btw... peut-être faudrait-il découper la discussion quitte à partir en guerre des tranchées..
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  12. #32
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Je ne vois pas trop le rapport entre héritage et une non-sémantique de valeur :
    - un entier est un nombre relatif qui est un nombre rationnel qui est un nombre réel qui est un nombre complexe.
    - une suite linéaire est une suite affine.

    Je vois mal un cas où une hiérarchie de classe serait incompatible avec une sémantique de valeur.
    Il y a deux soucis avec polymorphisme, entités, et valeurs.
    - Souvent un soucis sémantique: il est très fréquent qu'une classe appartenant à une hiérarchie polymorphe ait à respecter les principes d'identités exposés par Koala. En réfléchissant on voit vite quand on rencontre ce genre de situation. On a parlé des services plus tôt, c'est un excellent exemple.

    - Toujours un soucis technique. Soit on se retrouve avec du slicing, soit on se prend un problème de covariance/contravariance (il faudrait que je retrouve la doc sur le sujet pour ne pas dire de bêtises)

    Ici, le soucis avec ces modélisations est avant-tout technique parce que l'on cherche à avoir un polymorphisme d'inclusion (avec héritage).
    On a beau avoir ZZ + ZZ -> ZZ, si on dérive, en C++, on ne pourra que avoir IN + IN -> ZZ. Et pas -> IN.
    <edit>
    Le cas de la division est encore plus sournois car lui touche à la sémantique: La division entière n'est pas comparable à la division dans ZZ.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    struct ZZ { ... virtual ZZ operator/(ZZ const& rhs) const; ...};
     
    void f(ZZ const& lhs, ZZ const& rhs) {
        const ZZ div = lhs / rhs;
        assert(div * rhs == lhs);
    }
    ....
    f(ZZ(1,0), ZZ(2,0));
    f(IN(1), IN(2));
    Vous voyez les soucis ? Et même si le polymorphisme permettait techniquement de passer de façon dynamique de ZZ / ZZ -> ZZ à IN / IN -> IN en C++, nous aurions un problème de rupture de post-condition sur la division. Car la division dans ZZ n'est pas la division entière.
    En moins tarabiscoté, et qui fonctionne relativement aux tentatives de substituabilité technique en C++, operator/=() ne peut pas être le même entre ZZ et IN.

    Et on peut aussi remarquer qu'il y a beaucoup d'infos dans l'objet ZZ qui ne sont plus pertinentes pour un entier.
    Bref, les contrats sont violés à un autre endroit, mais on a toujours un soucis de carré (non-immuable) qui n'est pas un rectangle (non-immuable).
    </edit>


    Heureusement, je ne vois pas beaucoup de situations où l'on a besoin de ça en dynamique, et on peut s'en sortir avec les polymorphismes paramétriques et les surcharges.
    Pour moi, pas d'héritage entre IN et ZZ. A la limite entre les modèles associés -- et encore avec la division... -- mais le C++11 n'a pas validé les modèles.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  13. #33
    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
    En fait, je dirais plutôt d'une liste qu'elle a une sémantique d'entité, mais c'est peut-être mon expérience des collections Java/.Net qui parle.
    Personnellement, je vois très peu de types qui ont une sémantique de valeur, et je les vois tous immuables (car j'ai vu le bord... en C# avec des types valeur modifiables).

    Note: Immuables, mais écrasables: On n'est pas censé modifier un composant d'une valeur indépendamment du reste, mais on devrait pouvoir l'écraser avec une autre, comme on écrase un pointeur non-constant vers un objet constant. Cela est implicite en C#, mais en C++ nécessite de restreindre explicitement la modification:
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    class Coord2D
    {
    private:
    	int x;
    	int y;
    public:
    	int getx() const { return x; }
    	int gety() const { return y; }
    	Coord2D() : x(), y() {}
    	Coord2D(int x, int y) : x(x), y(y) {}
     
    	//Méthodes "de modification", qui retournent toutes un nouvel objet Coord2D
    	//...
    };
    Ce qui se fait plus simplement en C#, les types valeurs étant tous écrasables:
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    struct Coord2D
    {
    	public readonly int x;
    	public readonly int y;
     
    	public Coord2D(int x, int y)
    	{
    		this.x = x;
    		this.y = y;
    	}
     
    	//Méthodes "de modification", qui retournent toutes un nouvel objet Coord2D
    	//...
    };
    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.

  14. #34
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    - Toujours un soucis technique. Soit on se retrouve avec du slicing, soit on se prend un problème de covariance/contravariance (il faudrait que je retrouve la doc sur le sujet pour ne pas dire de bêtises)
    Si j'ai bien compris tu parles du fait que si dans une fonction on tente de faire une copie de N -> Z, alors la copie n'est "pas égale" à l'original, mais il suffit alors d'encapsuler les données et d'autoriser uniquement la copie/affectation vers les types strictement identiques.

    ZZ et IN sont ici l'ensemble des entiers relatif Z et l'ensemble des entiers positifs N ?
    Citation Envoyé par Luc Hermitte Voir le message
    Ici, le soucis avec ces modélisations est avant-tout technique parce que l'on cherche à avoir un polymorphisme d'inclusion (avec héritage).
    On a beau avoir ZZ + ZZ -> ZZ, si on dérive, en C++, on ne pourra que avoir IN + IN -> ZZ. Et pas -> IN.
    J'ai montré un peu plus haut qu'il était possible de définir les opérateurs pour justement avoir N + N -> N


    Citation Envoyé par Luc Hermitte Voir le message
    Vous voyez les soucis ? Et même si le polymorphisme permettait techniquement de passer de façon dynamique de ZZ / ZZ -> ZZ à IN / IN -> IN en C++, nous aurions un problème de rupture de post-condition sur la division. Car la division dans ZZ n'est pas la division entière.
    N héritant de Z, je ne vois pas vraiment où est le problème.

    Citation Envoyé par Luc Hermitte Voir le message
    Et on peut aussi remarquer qu'il y a beaucoup d'infos dans l'objet ZZ qui ne sont plus pertinentes pour un entier.
    Bref, les contrats sont violés à un autre endroit, mais on a toujours un soucis de carré (non-immuable) qui n'est pas un rectangle (non-immuable).
    L'autre alternative à l'héritage est de définir des opérateurs de conversion mais on va effectuer de multiples copies inutiles ou définir autant de conversion qu'il y a de types

  15. #35
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 704
    Points
    2 704
    Par défaut
    J'ai décidément du mal à être un zélote de ces histoires de sémantique de valeur et d'entité. Probablement parce que la connaissance que j'en ai ne s'est acquise que par bribes, au fil de sujet sur ce forum.

    Je pense qu'il faudrait que je lise un bon ouvrage qui traite du sujet en profondeur pour bien saisir l'intérêt d'autant se soucier de ces problématiques, et de m'en imprégner.

    Quelqu'un aurait-il des références à me donner ?

  16. #36
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Je comprend mal ce point là.
    J'ai un entier qui est un nombre, qu'est-ce qui empêche mon entier d'avoir une sémantique de valeur ?
    Mais il A sémantique de valeur!!!

    Tu peux, a priori, avoir deux nombres identiques qui se trouvent à des adresses mémoire différentes, tu peux le copier, l'affecter, le comparer par égalité (et par inégalité d'ailleurs) et tu te fous pas mal de savoir, quand tu utilise le nombre 128, de savoir s'il se trouve à l'adresse mémoire 120000 ou à l'adresse mémoire 15000.
    Comme tu l'a dit, les listes ont une sémantique de valeur (?) or quand on insère ou supprime des éléments, on ne recréé pas entièrement la liste.
    La liste a effectivement sémantique de valeur.

    Tu peux très bien avoir les chiffres 4,7,9 et 10 dans deux listes différentes et tu peux les comparer par égalité.

    Maintenant, j'ai dit que tu n'avais a priori aucune raison de fournir des comportements qui auraient pour but de modifier tes objets qui ont sémantique de valeur.

    Cet a priori est, effectivement, faux pour ce qui concerne les collection de stockage, car on placera d'autres obligations sur ce genre d'objets (comme le fait de pouvoir faire une insertion en temps constant, ce qui serait impossible si l'on venait à recréer une nouvelle liste à chaque fois).

    Cependant, le fait reste: si tu n'as pas énormément de situations dans lesquels un comportement de modification aura un sens dans une classe ayant sémantique de valeur, tu ne pourras jamais éviter un tel comportement dans une classe ayant sémantique d'entité (à moins, bien sur, d'avoir une restriction du genre de "une fois créé, il n'est plus modifié", ce qui est toujours possible )
    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

  17. #37
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    tech lead c++ linux
    Inscrit en
    Août 2004
    Messages
    4 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : tech lead c++ linux

    Informations forums :
    Inscription : Août 2004
    Messages : 4 262
    Points : 6 680
    Points
    6 680
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par oodini Voir le message
    Quelqu'un aurait-il des références à me donner ?
    Je crains que cette requête ne reste vaine. Cela fait des mois que je cherche de telles références, et je suis bredouille.

    En fait, dès le début il y a quelque chose qui cloche dans cette histoire: une classe à sémantique de valeur est sensée être immuable.
    1. Qu'est-ce que cela signifie au juste? Qu'elle ne doit être instanciée que sous forme constante? (const Maclasse instance( params ); )
    2. Concrètement, est-ce que quelqu'un a déjà vu cela? (moi non, mais j'avoue que ça ne démontre rien).
    3. Quel peut bien être l'intérêt d'un tel animal?

    Comme je disais, je ne parviens pas à trouver quoi que ce soit sur le sujet. A part sur le blog d'Emmanuel Deloget ou la FAQ de dvp. En anglais, quelques discussions par-ci par là, dont la plupart posent le même genre de questions que nous nous posons ici, comme par exemple ici où il est question de classe polymorphes avec sémantique de valeur. Dans les livres, rien. parashift parle de sémantique de valeur dans le sens de "passage par valeur en paramètre de fonction". Etc.

    Bon, le ton de ce message est un peu agressif, mais c'est juste dans le but faire réagir ceux qui en savent plus. J'ai une intuition: l'utilisation de la classe std::string pourrait peut-être aider à y voir plus clair. Je suis en train d'y réfléchir.

    Edit: et je pense aussi qu'il n'est pas raisonnable de considérer que les développeurs java ne comprennent rien à la poo. Je connais des javaistes qui en connaissent bien plus que moi sur le sujet, et de façon générale, le java a aussi ses gourous qui n'ont, à mon avis, rien à envier à ceux du c++.
    « L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
    Spinoza — Éthique III, Proposition VII

  18. #38
    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
    Et comme je l'ai dit, il y a un équivalent de la sémantique de valeur en Java. Impliquant des classes immuables, généralement dérivées de Object et marquées final. String est l'exemple principal, mais il y en a d'autres, comme les classes basées sur les types primitifs.
    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.

  19. #39
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par Neckara Voir le message
    a- Si j'ai bien compris tu parles du fait que si dans une fonction on tente de faire une copie de N -> Z, alors la copie n'est "pas égale" à l'original, mais il suffit alors d'encapsuler les données et d'autoriser uniquement la copie/affectation vers les types strictement identiques.

    b- ZZ et IN sont ici l'ensemble des entiers relatif Z et l'ensemble des entiers positifs N ?
    c- J'ai montré un peu plus haut qu'il était possible de définir les opérateurs pour justement avoir N + N -> N


    d- N héritant de Z, je ne vois pas vraiment où est le problème.

    e- L'autre alternative à l'héritage est de définir des opérateurs de conversion mais on va effectuer de multiples copies inutiles ou définir autant de conversion qu'il y a de types
    a- Non, le soucis que je mets en avant est inverse: retomber sur le IN que l'opération aurait dû produire et quelle ne peut pas produire.

    b- Oui. Je pensais à IR au départ, mais ici, IN ne change rien au discours.

    c- Ce n'est pas possible dynamiquement. Si le type dynamique de tes objets est IN malgré que leur type réel est ZZ, tu peux faire ce que tu veux, tu ne pourras pas récupérer autre chose qu'un ZZ car tu ne pourras appeler que op+(ZZ, ZZ), (ou ZZ::op+(ZZ)) qui renvoie un ZZ.

    d- L'héritage n'est pas valide, il viole le LSP. Car la division entière a un résidu (le modulo) que la division des relatifs ne produit pas. D'où que si tu reprends mon exemple tu verras une rupture de contrat sur la réversibilité. On se retrouve avec une fonction dont on change le comportement. Pas bon ça.

    e- Non, c'est de modéliser les divers ensembles via des templates et des surcharges pour les spécialisations.

    Le "aïe", c'est qu'une modélisation propre des divers ensembles numériques n'est juste pas possible dans le paradigme OO tel qu'il est supporté dans les langages mainstreams.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  20. #40
    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
    ^Par contre, on doit avoir une chance avec d'autres paradigmes, comme la programmation générique, avec des classes de traits qui vont bien...
    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.

Discussions similaires

  1. Appel d'une méthode virtuelles
    Par BIPBIP59 dans le forum C++Builder
    Réponses: 4
    Dernier message: 24/03/2006, 15h00
  2. Méthodes virtuelle et implémentation
    Par slate dans le forum C++
    Réponses: 2
    Dernier message: 16/02/2006, 18h16
  3. méthodes virtuelles
    Par ep31 dans le forum C++
    Réponses: 2
    Dernier message: 09/11/2005, 18h21
  4. Comment l'appel à une méthode virtuelle....
    Par Blobette dans le forum C++
    Réponses: 7
    Dernier message: 07/12/2004, 14h55
  5. [C#] Méthode virtuelle
    Par jacma dans le forum Windows Forms
    Réponses: 4
    Dernier message: 07/11/2004, 09h18

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