et si le tableau tab était un tableau dynamique? est ce que les deux objets p1 et p2 vont partager le même tableau?
Merci
Si c'est un tableau dynamique version C++ (std::vector), la réponse est toujours non. Sinon (et ce ne devrait pas arriver dans un code moderne), oui (et on tueras un chaton sur l'autel de l'auteur d'une telle bêtise).
De toutes facons, une classe personne ne devrait jamais être copiable (ni assignable, d'ailleurs) car, s'il y a bien une chose que l'on veut éviter à tout prix, c'est de se retrouver, à un moment donné de l'exécution, avec deux données différentes en mémoire qui représentent exactement la même personne.
Il en va d'ailleurs de même avec des classes comme "bâtiment", "compte en banque", "voiture et plein d'autres
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
En général, si une classe a un attribut tableau statique, est ce qu'il est nécessaire d'utiliser une copie profonde comme dans le cas des tableaux déclarés avec les pointeurs (membres dynamiques)?
En C++, on n'utilise pas vraiment le terme de copie profonde, c'est utilisé dans les langages dans lesquels on ne sait pas trop ce qui est copié. En C++, la règle est simple: Faire une copie c'est copier chacun des membres. Ainsi par exemple: - un tableau membre est copié. - un pointeur membre est copié. Et comme rien ne permet de savoir que le pointeur correspond à quelque chose de dynamique y compris un tableau: on ne doit jamais avoir des pointeurs qui correspondrait à de l'allocation dynamique, on doit utiliser les objets du C++ qui savent gérer cela.
En général, si une classe a un attribut tableau statique, est ce qu'il est nécessaire d'utiliser une copie profonde comme dans le cas des tableaux déclarés avec les pointeurs (membres dynamiques)?
Merci
Tu confondrais pas "membre statique" et "tableau statique" ? Ce n'est pas du tout la même notion. Qu'est-ce qu'un "membre dynamique" pour toi ? je trouve l'expression un peu bizarre ...
En c++ on ne fait plus de tableau dynamiques avec des pointeurs depuis un moment. Les vector et compagnie sont très bien, très pratiques, très confortables...
Comme déjà dit, si tu as un tableau statique, non pas besoin d'une copie profonde...
En C++, on n'utilise pas vraiment le terme de copie profonde, c'est utilisé dans les langages dans lesquels on ne sait pas trop ce qui est copié. En C++, la règle est simple: Faire une copie c'est copier chacun des membres. Ainsi par exemple: - un tableau membre est copié. - un pointeur membre est copié. Et comme rien ne permet de savoir que le pointeur correspond à quelque chose de dynamique y compris un tableau: on ne doit jamais avoir des pointeurs qui correspondrait à de l'allocation dynamique, on doit utiliser les objets du C++ qui savent gérer cela.
Je trouve que cette formulation porte à confusion. Oui quand on copie une struct ça copie chacun des membres, mais encore faut-il savoir ce que veut dire "copier". En C++ moderne, une copie est une copie profonde, non pas car le langage l'impose (car en C/C++, c'est au contraire une shallow copy qui se produit) mais car les classes C++ implémentent la notion de copie au sens du C++, à savoir qu'en copiant A dans B, on se retrouve avec deux objets indépendants. Donc "de base" en C/C++, ça copie membre à membre bêtement mais en pratique en C++ moderne, les classes propriétaires implémentent une copie en profondeur (si la copie n'est pas delete).
koala01 a écrit:
De toutes facons, une classe personne ne devrait jamais être copiable (ni assignable, d'ailleurs) car, s'il y a bien une chose que l'on veut éviter à tout prix, c'est de se retrouver, à un moment donné de l'exécution, avec deux données différentes en mémoire qui représentent exactement la même personne.
Il en va d'ailleurs de même avec des classes comme "bâtiment", "compte en banque", "voiture et plein d'autres
Il faut faire la différence entre un concept réel et du code, d'ailleurs la POO où on représente chaque concept réel par une classe c'est pas forcément une bonne idée. Au niveau du code, on est libres, on peut transcender la réalité et donc on peut tout à fait vouloir prendre des données en mémoire et les copier, même si ça ne pourrait pas se passer dans la vraie vie. Par exemple si on fait un jeu de destruction et qu'on a un "bâtiment", on a peut être envie de laisser le joueur choisir son attaque (météorite, bombe, boule de démolition, que sais je), et lui permettre de "visualiser" le résultat, une sorte de preview de ce qui va se passer avec telle attaque, mais sans pour autant détruire le vrai bâtiment. Pour faire ça, il faut lancer l'attaque sur une copie des données originales, donc ça serait vraiment dommage que Batiment ne soit pas copiable et nous empêche de faire ça.
Il faut faire la différence entre un concept réel et du code, d'ailleurs la POO où on représente chaque concept réel par une classe c'est pas forcément une bonne idée. Au niveau du code, on est libres, on peut transcender la réalité et donc on peut tout à fait vouloir prendre des données en mémoire et les copier, même si ça ne pourrait pas se passer dans la vraie vie.
Le problème est justement là...
Trop de développeurs "plus ou moins inexpérimentés" estiment que, l'un dans l'autre, les principes de conception ne sont que des "guides de bonnes pratiques" qu'ils sont libres de choisir de ne pas suivre. Or, ce n'est absolument pas le cas.
Car le fait est que si tu prend "des libertés" par rapport aux principes de conception, cela "peut passer" pour un "petit programme jetable" qui a pour seul objectif de comprendre comment les choses fonctionnent, mais cela occasionne systématiquement une dette technique dés que le projet est susceptible de "survivre" plus de quelques jours.
Et le fait est que cette dette technique va t'obliger à trouver des solutions par rapport aux problèmes qui ne sont apparus qu'à cause des libertés prises en termes de conception qui ... provoqueront des problèmes encore plus importants par la suite.
Ce dont il faut prendre conscience, c'est que la conception fera toute la différence entre "une base saine" qui te permettra d'avancer "sans trop de problèmes" par la suite (ou, qui, du moins, te permettra de ne pas ajouter de problèmes inutiles par la suite) et "un chateau de carte" qui deviendra de plus en plus instable au fil du temps.
La conception est littéralement la première étape à ne louper sous aucun prétexte, l'écriture du code n'étant qu'un "long et fastidieux travail de traduction et de dactylographie".
Quand on sait qu'il suffit de respecter cinq principes (SOLID) et une loi (Demeter) de conception pour s'éviter 90% des problèmes liés à la maintenance et à l'évolutivité d'un projet, que le "temps perdu" à se poser les bonnes questions concernant ces différents aspects sera très largement récupéré par la suite (même s'il est difficile de chiffrer le temps que l'on n'aura pas perdu à mettre en place une solution bancale sur une situation de départ instable), on se rend compte que le meilleur calcul est -- clairement -- de "perdre ce temps" au départ.
MahometUrsufa a écrit:
Par exemple si on fait un jeu de destruction et qu'on a un "bâtiment", on a peut être envie de laisser le joueur choisir son attaque (météorite, bombe, boule de démolition, que sais je), et lui permettre de "visualiser" le résultat, une sorte de preview de ce qui va se passer avec telle attaque, mais sans pour autant détruire le vrai bâtiment.
A ceci près que le bâtiment que tu utilisera pour ta simulation se limitera à ... présenter les mêmes caractéristiques, le même état que le bâtiment original, mais que, d'une manière ou d'une autre, tu en arrivera ** forcément ** à pouvoir les distinguer.
Tu vas donc -- sans doute -- créer une fonction qui permette de récupérer les différentes caractéristiques, l'état spécifique de ton original et de les utiliser pour obtenir l'objet de la simulation.
Mais cette fonction ne peut être ni le constructeur de copie ni l'opérateur d'affectation.
MahometUrsufa a écrit:
Pour faire ça, il faut lancer l'attaque sur une copie des données originales, donc ça serait vraiment dommage que Batiment ne soit pas copiable et nous empêche de faire ça.
Non, ce n'est pas dommage, c'est juste "normal et cohérent", car le processus de simulation est un processus tout à fait à part du processus "d'exécution".
Et, s'il est -- de fait -- intéressant de dupliquer le jeu de données, cela ne doit pas se faire au mépris des règles destinées à te faciliter "ges"tion quotidienne".
Ce n'est pas parce que tu fais face à une exception (le processus de simulation étant une exception par rapport au processus d'exécution réelle) que tu dois considérer des situations "incohérentes" comme "normales et justifiées" pour le cas général.
Si tu fais face à une exception comme le besoin de simulation, tu crées une fonctionnalité bien spécifique présentant un comportement bien spécifique (comme la duplication des objets utilisés pour la simulation) et qui n'est clairmement à utiliser que dans le cadre de l'exception.
- Edité par koala01 6 février 2023 à 19:46:46
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Copie d'objets ayant des membres tableaux
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
En recherche d'emploi.
git is great because Linus did it, mercurial is better because he didn't.