et mettre dans le constructeur
a = maClass0() ;
b = maClass1() ;
oups, j'ai oublié les "new"....
a = new maClass0() ;
b = new maClass1() ;
ok
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
et mettre dans le constructeur
a = maClass0() ;
b = maClass1() ;
oups, j'ai oublié les "new"....
a = new maClass0() ;
b = new maClass1() ;
ok
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
et mettre dans le constructeur
a = maClass0() ;
b = maClass1() ;
oups, j'ai oublié les "new"....
a = new maClass0() ;
b = new maClass1() ;
ok
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
En programmation événementielle, beacoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
C'est justement le fait de pas structurer le code que je trouve
archaique.. question de gout quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur new
dans ce cas ?
Quand et comment les ressources associées à l'objet "jeté" dans
le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode innaplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'éxécution du programme (ou
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
En programmation événementielle, beacoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
C'est justement le fait de pas structurer le code que je trouve
archaique.. question de gout quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur new
dans ce cas ?
Quand et comment les ressources associées à l'objet "jeté" dans
le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode innaplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'éxécution du programme (ou
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
En programmation événementielle, beacoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
C'est justement le fait de pas structurer le code que je trouve
archaique.. question de gout quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur new
dans ce cas ?
Quand et comment les ressources associées à l'objet "jeté" dans
le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode innaplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'éxécution du programme (ou
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Malheureusement, tout ce qui est utile est laid ;
Malheureusement, tout ce qui est utile est laid ;
Malheureusement, tout ce qui est utile est laid ;
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
C'est justement le fait de pas structurer le code que je trouve
archaïque.. question de goût quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
C'est justement le fait de pas structurer le code que je trouve
archaïque.. question de goût quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
C'est justement le fait de pas structurer le code que je trouve
archaïque.. question de goût quoi ...
Un peu de logique terrienne :
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
Le beau n'est pas universel mon ami. Tu trouves peut être une voiture
belle mais elle ne l'est pas pour le commun des mortels. Heureusement
d'ailleurs. Si il y avait une notion du beau commune à tous les individus
il n'y aurait pas de diversité et point de recherche sur de nouvelles
techniques d'art, l'art n'évoluerait quasiment pas.
Pour répondre au rapport beau/utile/efficace: Je ne suis pas d'accord
quand tu dis qu'une fiat est aussi utile qu'une jaguar mais est moche. Une
Jaguar est inutile en soi, dumoins ce qu'elle a en plus qu'une Fiat ne
l'est pas, ce qui rend l'objet complètement dénué d'intêret. Mais ça
c'est le propre du bonheur des riches: avoir un objet d'une inutilité
complète et la faire passer pour indispensables. Des exemples? Les gros
4X4 dans les villes (j'habite en montagne et habité en station je n'ai
jamais eu de problème pour monter une côte avec une 405 TD), avoir le
dernier PC à 3 000¤ pour regarder ses mails, surfer et taper trois mots
sous words, avoir une grosse maison de 250m² avec 1ha de terrain... Tous
les objets que je viens de citer son "beaux" ou "réputé beaux" mais
d'une parfaite inutilité.
--
Pensez à enlever "-nospam" pour me répondre.
-+-
D'après une étude récente, 5 personnes sur 4 ne comprennent rien aux
fractions
-+-
Le beau n'est pas universel mon ami. Tu trouves peut être une voiture
belle mais elle ne l'est pas pour le commun des mortels. Heureusement
d'ailleurs. Si il y avait une notion du beau commune à tous les individus
il n'y aurait pas de diversité et point de recherche sur de nouvelles
techniques d'art, l'art n'évoluerait quasiment pas.
Pour répondre au rapport beau/utile/efficace: Je ne suis pas d'accord
quand tu dis qu'une fiat est aussi utile qu'une jaguar mais est moche. Une
Jaguar est inutile en soi, dumoins ce qu'elle a en plus qu'une Fiat ne
l'est pas, ce qui rend l'objet complètement dénué d'intêret. Mais ça
c'est le propre du bonheur des riches: avoir un objet d'une inutilité
complète et la faire passer pour indispensables. Des exemples? Les gros
4X4 dans les villes (j'habite en montagne et habité en station je n'ai
jamais eu de problème pour monter une côte avec une 405 TD), avoir le
dernier PC à 3 000¤ pour regarder ses mails, surfer et taper trois mots
sous words, avoir une grosse maison de 250m² avec 1ha de terrain... Tous
les objets que je viens de citer son "beaux" ou "réputé beaux" mais
d'une parfaite inutilité.
--
Pensez à enlever "-nospam" pour me répondre.
-+-
D'après une étude récente, 5 personnes sur 4 ne comprennent rien aux
fractions
-+-
Le beau n'est pas universel mon ami. Tu trouves peut être une voiture
belle mais elle ne l'est pas pour le commun des mortels. Heureusement
d'ailleurs. Si il y avait une notion du beau commune à tous les individus
il n'y aurait pas de diversité et point de recherche sur de nouvelles
techniques d'art, l'art n'évoluerait quasiment pas.
Pour répondre au rapport beau/utile/efficace: Je ne suis pas d'accord
quand tu dis qu'une fiat est aussi utile qu'une jaguar mais est moche. Une
Jaguar est inutile en soi, dumoins ce qu'elle a en plus qu'une Fiat ne
l'est pas, ce qui rend l'objet complètement dénué d'intêret. Mais ça
c'est le propre du bonheur des riches: avoir un objet d'une inutilité
complète et la faire passer pour indispensables. Des exemples? Les gros
4X4 dans les villes (j'habite en montagne et habité en station je n'ai
jamais eu de problème pour monter une côte avec une 405 TD), avoir le
dernier PC à 3 000¤ pour regarder ses mails, surfer et taper trois mots
sous words, avoir une grosse maison de 250m² avec 1ha de terrain... Tous
les objets que je viens de citer son "beaux" ou "réputé beaux" mais
d'une parfaite inutilité.
--
Pensez à enlever "-nospam" pour me répondre.
-+-
D'après une étude récente, 5 personnes sur 4 ne comprennent rien aux
fractions
-+-
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Comment ça, non ???
Le non, c'est pour la notion d'accolade hors sujet.
Chaque appel à la fonction de dispatching de la boucle des messages
produit un appel à la fonction de traitement des messages de la
classe (au sens Win32) de la fenêtre concernée par le message courant.
Idem pour les messages synchrones ne passant pas par la boucle.
Bilan : entre deux événements, aucune donnée stockée dans la
portée de cette fonction ne peut survivre (sauf à utiliser
des variables 'static', mais c'est MAL). Dans ce cas, les auto-pointer
ne sont d'aucune utilité.
Pas besoin de pointeurs tout court.
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
Voilà. Merci de ton soutien. Cette déclaration sera une déclaration
de pointeur.
Non. Un objet n'implique pas forcément un pointeur.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
Mais, on parle d'allouer des ressources et de laisser le langage et
les portées de blocs les libérer automatiquement, pour éviter les
fuites mémoires, non ? Donc quand tu dis "y'a des mécanisme de
synchro pour ça", c'est QUOI le "pour ça" ???
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
Primo, c'est assez simple d'encapsuler la notion de thread dans une
classe. Deuxio, si C/C++ ne connaissent pas la notion de thread, c'est
oui, c'est ce que j'utilise.
juste un indice de plus que ce sont des langages préhistoriques. Tertio,
tu confirmes donc que les auto-pointers en particulier, et la notion de
portée en général, ne sont d'aucune utilité quand il s'agit de partager
des ressources entre threads.
Je peux même t'affirmer que les pointeurs ne sont d'aucune utilité
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
Mettons qu'on pourrait peut être trouver un compromis. Je dirais que
la méthodologie dont tu parles a le gros avantages d'automatiser
la gestion de la mémoire "locale" en permettant d'omettre les
instructions explicite de libération. Mais je dis que quand tu te
forces à employer cette méthode partout, tu te retrouves obligés de
faire remonter les allocations automatiques dans les couches
supérieures, ce qui a aussi de gros inconvénients, pour ne pas parler
des cas où c'est tout simplement impossible.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Ok, mais il me semble que refuser l'allocation dynamique avec
gestion manuelle des libérations peut être un sérieux frein à
"autonomes et indépendantes".
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Et comment donc vas-tu obtenir l'objet que tu ajoutes dans le
conteneur, si ce n'est pas avec un new !?!
MaClasse {...};
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
:-)
Je parlais du cadre théorique là, le cas "par définition".
C'est exactement un des cas de figure envisagés par ce brave Bjarne
quand il dit : "memory leaks are quite acceptable in many applications".
En effet, quand l'application s'arrête, la mémoire est libérée, donc s'il
manque certains "free/delete" dans l'application, ce n'est pas grave A
Nan, parce que le conteneur appelle le destructeur de la classe (le
CONDITION que la quantité de mémoire gaspillée ne dépendent pas du
temps d'utilisation de l'application ou du volume des données traitées.
En gros, l'idée peut se défendre (ça se discute) quand ces fuites sont
de tailles constantes, genre ne pas libérer quelques ressources allouées
à l'initialisation par exemple.
C'est par contre complètement indéfendable quand il s'agit de dire qu'un
conteneur va grossir indéfiniment au fur et à mesure qu'on va utiliser
l'application !
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
Pas compris.
Je m'en doute, c'est une notion que j'ai toujours du mal à exprimer..
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Heu... Comment tu les libères avant la destruction du conteneur, si
ce n'est manuellement ?!?
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Je sais, je parle du cas ou tu dois libérer le contenu à la main.
S'il y a une bug dans ton code, il y a memory leak.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
friend, c'est une bidouille pour s'amuser avec les attributs
public/protected/private. Rien à voir avec le débat en cours.
J'ai du mal comprendre le sens de ta prose alors (ca fait un partout
Ce que je veux dire c'est, PAR EXEMPLE, que si tu déclares une
variable membre de type pointeurs, tu pourras instancier un objet
qui sera de plusieurs classes possibles au RunTime. Si tu utilises
une variable de type instance, tu dois connaître au compile time la
classe qui sera instanciée.
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Comment ça, non ???
Le non, c'est pour la notion d'accolade hors sujet.
Chaque appel à la fonction de dispatching de la boucle des messages
produit un appel à la fonction de traitement des messages de la
classe (au sens Win32) de la fenêtre concernée par le message courant.
Idem pour les messages synchrones ne passant pas par la boucle.
Bilan : entre deux événements, aucune donnée stockée dans la
portée de cette fonction ne peut survivre (sauf à utiliser
des variables 'static', mais c'est MAL). Dans ce cas, les auto-pointer
ne sont d'aucune utilité.
Pas besoin de pointeurs tout court.
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
Voilà. Merci de ton soutien. Cette déclaration sera une déclaration
de pointeur.
Non. Un objet n'implique pas forcément un pointeur.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
Mais, on parle d'allouer des ressources et de laisser le langage et
les portées de blocs les libérer automatiquement, pour éviter les
fuites mémoires, non ? Donc quand tu dis "y'a des mécanisme de
synchro pour ça", c'est QUOI le "pour ça" ???
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
Primo, c'est assez simple d'encapsuler la notion de thread dans une
classe. Deuxio, si C/C++ ne connaissent pas la notion de thread, c'est
oui, c'est ce que j'utilise.
juste un indice de plus que ce sont des langages préhistoriques. Tertio,
tu confirmes donc que les auto-pointers en particulier, et la notion de
portée en général, ne sont d'aucune utilité quand il s'agit de partager
des ressources entre threads.
Je peux même t'affirmer que les pointeurs ne sont d'aucune utilité
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
Mettons qu'on pourrait peut être trouver un compromis. Je dirais que
la méthodologie dont tu parles a le gros avantages d'automatiser
la gestion de la mémoire "locale" en permettant d'omettre les
instructions explicite de libération. Mais je dis que quand tu te
forces à employer cette méthode partout, tu te retrouves obligés de
faire remonter les allocations automatiques dans les couches
supérieures, ce qui a aussi de gros inconvénients, pour ne pas parler
des cas où c'est tout simplement impossible.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Ok, mais il me semble que refuser l'allocation dynamique avec
gestion manuelle des libérations peut être un sérieux frein à
"autonomes et indépendantes".
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Et comment donc vas-tu obtenir l'objet que tu ajoutes dans le
conteneur, si ce n'est pas avec un new !?!
MaClasse {...};
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
:-)
Je parlais du cadre théorique là, le cas "par définition".
C'est exactement un des cas de figure envisagés par ce brave Bjarne
quand il dit : "memory leaks are quite acceptable in many applications".
En effet, quand l'application s'arrête, la mémoire est libérée, donc s'il
manque certains "free/delete" dans l'application, ce n'est pas grave A
Nan, parce que le conteneur appelle le destructeur de la classe (le
CONDITION que la quantité de mémoire gaspillée ne dépendent pas du
temps d'utilisation de l'application ou du volume des données traitées.
En gros, l'idée peut se défendre (ça se discute) quand ces fuites sont
de tailles constantes, genre ne pas libérer quelques ressources allouées
à l'initialisation par exemple.
C'est par contre complètement indéfendable quand il s'agit de dire qu'un
conteneur va grossir indéfiniment au fur et à mesure qu'on va utiliser
l'application !
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
Pas compris.
Je m'en doute, c'est une notion que j'ai toujours du mal à exprimer..
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Heu... Comment tu les libères avant la destruction du conteneur, si
ce n'est manuellement ?!?
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Je sais, je parle du cas ou tu dois libérer le contenu à la main.
S'il y a une bug dans ton code, il y a memory leak.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
friend, c'est une bidouille pour s'amuser avec les attributs
public/protected/private. Rien à voir avec le débat en cours.
J'ai du mal comprendre le sens de ta prose alors (ca fait un partout
Ce que je veux dire c'est, PAR EXEMPLE, que si tu déclares une
variable membre de type pointeurs, tu pourras instancier un objet
qui sera de plusieurs classes possibles au RunTime. Si tu utilises
une variable de type instance, tu dois connaître au compile time la
classe qui sera instanciée.
En programmation événementielle, beaucoup de fonctions traitent des
événements (surprise !).
Chaque fois qu'un événement doit donner lieu à l'allocation d'une
ressource qui sera libérée on ne sait quand (lors d'un autre
événement, par exemple ?), la notion d'accolade dans les sources
est complètement hors sujet.
Non. Tout part d'une fonction Main ou WinMain (suivant le système).
Sous Win, la notion d'événement est traitée par une boucle des
messages qui aboutit sur un switch (donc "entre deux accolades").
Comment ça, non ???
Le non, c'est pour la notion d'accolade hors sujet.
Chaque appel à la fonction de dispatching de la boucle des messages
produit un appel à la fonction de traitement des messages de la
classe (au sens Win32) de la fenêtre concernée par le message courant.
Idem pour les messages synchrones ne passant pas par la boucle.
Bilan : entre deux événements, aucune donnée stockée dans la
portée de cette fonction ne peut survivre (sauf à utiliser
des variables 'static', mais c'est MAL). Dans ce cas, les auto-pointer
ne sont d'aucune utilité.
Pas besoin de pointeurs tout court.
Par exemple
Dans les frameworks windows (VCL et MFC), une fenêtre est un objet,
avec diverses propriétés et méthodes. Rien ne t'empêche dans les
déclaration de la fenêtre de rajouter un objet (une autre fenêtre
par exemple) et de décider de l'instancier avec les différents
événements propre à la fenêtre (les clicks des différents boutons
par exemple..)
Voilà. Merci de ton soutien. Cette déclaration sera une déclaration
de pointeur.
Non. Un objet n'implique pas forcément un pointeur.
et multi tâches surtout).
Même combat. Si un thread commence à travailler en utilisant des
ressources allouées dans un autre thread, rien ne permet au
thread allocateur de gentiment attendre que le second thread
ait terminé pour pouvoir sortir de son bloc courant (si ce
n'est en se bloquant en attente et alors il va falloir
m'expliquer l'intérêt d'avoir deux threads !)
Du multi threads sous unix, je sais pas, j'en ai jamais fait. Sous Win,
y'a des mécanisme de synchro pour ça.
Mais, on parle d'allouer des ressources et de laisser le langage et
les portées de blocs les libérer automatiquement, pour éviter les
fuites mémoires, non ? Donc quand tu dis "y'a des mécanisme de
synchro pour ça", c'est QUOI le "pour ça" ???
De toute manière, les threads sont implantés par le système
d'exploitation, pas par le langage.
Primo, c'est assez simple d'encapsuler la notion de thread dans une
classe. Deuxio, si C/C++ ne connaissent pas la notion de thread, c'est
oui, c'est ce que j'utilise.
juste un indice de plus que ce sont des langages préhistoriques. Tertio,
tu confirmes donc que les auto-pointers en particulier, et la notion de
portée en général, ne sont d'aucune utilité quand il s'agit de partager
des ressources entre threads.
Je peux même t'affirmer que les pointeurs ne sont d'aucune utilité
1) "code utilisant des pointeurs" N'est PAS équivalent à "code
pas structuré"
D'accord avec toi.
Mais ça y contribue fortement et ça n'empêche pas le code spaghetti.
Alors que coder sans, ça implique une méthodologie qui forcément
aboutie à une forme structurée.
Mettons qu'on pourrait peut être trouver un compromis. Je dirais que
la méthodologie dont tu parles a le gros avantages d'automatiser
la gestion de la mémoire "locale" en permettant d'omettre les
instructions explicite de libération. Mais je dis que quand tu te
forces à employer cette méthode partout, tu te retrouves obligés de
faire remonter les allocations automatiques dans les couches
supérieures, ce qui a aussi de gros inconvénients, pour ne pas parler
des cas où c'est tout simplement impossible.
2) "structurer" N'est PAS équivalent à "structurer comme l'entend
Laurent BERNE"
A mon humble avis à moi que j'ai, "structurer" signifie :
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples."
Je complète juste un peu ta définition
"définir un ensemble de règles cohérentes entre elles et
permettant de décomposer un ensemble complexe en parties
individuellement plus simples, autonomes et indépendantes."
Ok, mais il me semble que refuser l'allocation dynamique avec
gestion manuelle des libérations peut être un sérieux frein à
"autonomes et indépendantes".
Tiens, au fait, pourquoi donc n'utilise-t-on pas l'opérateur
new dans ce cas ?
Parce que objet ne veut pas dire systématiquement pointeur.
Et comment donc vas-tu obtenir l'objet que tu ajoutes dans le
conteneur, si ce n'est pas avec un new !?!
MaClasse {...};
Quand et comment les ressources associées à l'objet "jeté"
dans le conteneur sont-elles libérées ?
quand le conteneur est détruit
C'est une méthode inapplicable quand la durée de vie utile des
ressources allouées est variable.
Elle n'est jamais plus longue que la durée d'exécution du programme
(ou alors problème...)
:-)
Je parlais du cadre théorique là, le cas "par définition".
C'est exactement un des cas de figure envisagés par ce brave Bjarne
quand il dit : "memory leaks are quite acceptable in many applications".
En effet, quand l'application s'arrête, la mémoire est libérée, donc s'il
manque certains "free/delete" dans l'application, ce n'est pas grave A
Nan, parce que le conteneur appelle le destructeur de la classe (le
CONDITION que la quantité de mémoire gaspillée ne dépendent pas du
temps d'utilisation de l'application ou du volume des données traitées.
En gros, l'idée peut se défendre (ça se discute) quand ces fuites sont
de tailles constantes, genre ne pas libérer quelques ressources allouées
à l'initialisation par exemple.
C'est par contre complètement indéfendable quand il s'agit de dire qu'un
conteneur va grossir indéfiniment au fur et à mesure qu'on va utiliser
l'application !
La question judicieuse est de savoir quand déclarer ces variables et
dans quel "espace d'exécution" elles interviennent.
Pas compris.
Je m'en doute, c'est une notion que j'ai toujours du mal à exprimer..
(à moins qu'on lui demande spécifiquement de virer un élément par
la méthode erase ou clear du container)
Voila. Merci de ton soutien.
Tu dis qu'on peut remplacer les pointeurs par des objets dont
la destruction est pris en charge par le langage, ce qui évite
soit disant les fuites mémoires, mais quand on te demande comment
traiter le cas des objets qui survivent à la portée de leur
allocation, tu réponds qu'il faut libérer explicitement !
Ce n'est pas ce que j'ai dit.
J'ai dit qu'on peut choisir de les libérer avant la destruction du
conteneur. En aucun cas j'ai spécifier qu'il fallait les libérer
manuellement. C'est un choix supplémentaire.
Heu... Comment tu les libères avant la destruction du conteneur, si
ce n'est manuellement ?!?
Donc désolé, ce n'est pas une question de "pointeur", et il est
manifestement possible de coder SANS pointeurs et AVEC fuites
mémoires.
Non, le conteneur détruit systématiquement tous les objets qu'il
contient au moment de sa propre destruction.
Je sais, je parle du cas ou tu dois libérer le contenu à la main.
S'il y a une bug dans ton code, il y a memory leak.
Par ailleurs, tu as snippé donc je répète : "Et puis, il faut du
coup faire remonter les détails d'implémentations dans les
fonctions appelantes, jusqu'à 'main' tant qu'on y est."
Car dans ton approche de la structuration par portée des sources,
la survie d'un objet en dehors de la fonction qui l'instancie
va te conduire à rendre explicite la présence de cette objet dans
la couche supérieure. Cela favorise le monolithisme par diffusion
du modèle de données, en opposition à la modularité par séparation
des fonctions. Je me comprends, c'est déjà ça.
Pas obligatoirement. Ca n'est valable que si le dit objet est utilisé
dans Main.
On peut par exemple utiliser le concept des classes amies(ça sert à ça
d'ailleurs..)
friend, c'est une bidouille pour s'amuser avec les attributs
public/protected/private. Rien à voir avec le débat en cours.
J'ai du mal comprendre le sens de ta prose alors (ca fait un partout
Ce que je veux dire c'est, PAR EXEMPLE, que si tu déclares une
variable membre de type pointeurs, tu pourras instancier un objet
qui sera de plusieurs classes possibles au RunTime. Si tu utilises
une variable de type instance, tu dois connaître au compile time la
classe qui sera instanciée.
class MaClasse1 {void foo();}
class MaClasse2
{
private
MaClasse1 Object; // ce n'est pas un pointeur
public void DoEvent(UINT Message);
}
void MaClasse2::DoEvent(UINT Message)
{
switch(Message)
{
case 0 :
{ Object = MaClasse1(); //init
break;
}
default :
{
Object.foo(); //utilisation
break;
}
}
}
class MaClasse1 {void foo();}
class MaClasse2
{
private
MaClasse1 Object; // ce n'est pas un pointeur
public void DoEvent(UINT Message);
}
void MaClasse2::DoEvent(UINT Message)
{
switch(Message)
{
case 0 :
{ Object = MaClasse1(); //init
break;
}
default :
{
Object.foo(); //utilisation
break;
}
}
}
class MaClasse1 {void foo();}
class MaClasse2
{
private
MaClasse1 Object; // ce n'est pas un pointeur
public void DoEvent(UINT Message);
}
void MaClasse2::DoEvent(UINT Message)
{
switch(Message)
{
case 0 :
{ Object = MaClasse1(); //init
break;
}
default :
{
Object.foo(); //utilisation
break;
}
}
}
supposons que maclass1 fasse une addition par exemple et s'appelle
calculatrice
n'est' il pas plus simple de creer un ogj calculatrice "obj MaClasse1"
et de passer cet obj a tous les autres obj "MaClasse2
qui ont besoin de faire une addition
si bien sur.
ou faut'il creer une calculatrice dans l'obj chaque fois
que l'on veut faire une addtition
Oui, mais là, on était dans le cas "gestion des évenéments" d'un objet
supposons que maclass1 fasse une addition par exemple et s'appelle
calculatrice
n'est' il pas plus simple de creer un ogj calculatrice "obj MaClasse1"
et de passer cet obj a tous les autres obj "MaClasse2
qui ont besoin de faire une addition
si bien sur.
ou faut'il creer une calculatrice dans l'obj chaque fois
que l'on veut faire une addtition
Oui, mais là, on était dans le cas "gestion des évenéments" d'un objet
supposons que maclass1 fasse une addition par exemple et s'appelle
calculatrice
n'est' il pas plus simple de creer un ogj calculatrice "obj MaClasse1"
et de passer cet obj a tous les autres obj "MaClasse2
qui ont besoin de faire une addition
si bien sur.
ou faut'il creer une calculatrice dans l'obj chaque fois
que l'on veut faire une addtition
Oui, mais là, on était dans le cas "gestion des évenéments" d'un objet
Au moins avec tk on est sur d'avaoir une interface graphique aussi moche
sur tous les systèmes ;)
Au moins avec tk on est sur d'avaoir une interface graphique aussi moche
sur tous les systèmes ;)
Au moins avec tk on est sur d'avaoir une interface graphique aussi moche
sur tous les systèmes ;)
