std::map<AnsiString,DS_Edit_Video*> map;
est-ce nécessaire de passer par un delete ite->second
std::map<AnsiString,DS_Edit_Video*> map;
est-ce nécessaire de passer par un delete ite->second
std::map<AnsiString,DS_Edit_Video*> map;
est-ce nécessaire de passer par un delete ite->second
Bonsoir à tous,
voici ma question:
j'ai la map suivante:
std::map<AnsiString,DS_Edit_Video*> map;
Je la remplis comme ceci:
map[nom_cle] = new DS_Edit_Video;
Avant de la remplir, je veux la vider de certains éléments:
for (int i=0; i < nbre_joueurs; i++)
{
AnsiString nom_cle = Liste_Joueurs->Items->Strings[i];
it ite = timelines_joueurs.fin(nom_cle);
if (ite != timelines_joueurs.end())
{
delete ite->second;
timelines_joueurs.erase(ite);
}
}
est-ce nécessaire de passer par un delete ite->second, ou bien est-ce que
la ligne qui suit le fait également?
Merci d'avance...
Bonsoir à tous,
voici ma question:
j'ai la map suivante:
std::map<AnsiString,DS_Edit_Video*> map;
Je la remplis comme ceci:
map[nom_cle] = new DS_Edit_Video;
Avant de la remplir, je veux la vider de certains éléments:
for (int i=0; i < nbre_joueurs; i++)
{
AnsiString nom_cle = Liste_Joueurs->Items->Strings[i];
it ite = timelines_joueurs.fin(nom_cle);
if (ite != timelines_joueurs.end())
{
delete ite->second;
timelines_joueurs.erase(ite);
}
}
est-ce nécessaire de passer par un delete ite->second, ou bien est-ce que
la ligne qui suit le fait également?
Merci d'avance...
Bonsoir à tous,
voici ma question:
j'ai la map suivante:
std::map<AnsiString,DS_Edit_Video*> map;
Je la remplis comme ceci:
map[nom_cle] = new DS_Edit_Video;
Avant de la remplir, je veux la vider de certains éléments:
for (int i=0; i < nbre_joueurs; i++)
{
AnsiString nom_cle = Liste_Joueurs->Items->Strings[i];
it ite = timelines_joueurs.fin(nom_cle);
if (ite != timelines_joueurs.end())
{
delete ite->second;
timelines_joueurs.erase(ite);
}
}
est-ce nécessaire de passer par un delete ite->second, ou bien est-ce que
la ligne qui suit le fait également?
Merci d'avance...
On 26 Dec 2003 23:16:18 GMT, "Michaël Delva"
wrote:std::map<AnsiString,DS_Edit_Video*> map;
Appeler une variable par le même nom qu'un type est toujours
dangereux, même si tu es ici protégé par le namespace.
est-ce nécessaire de passer par un delete ite->second
Oui, parce que tu as choisi de mettre des pointeurs nus et pas des
objets ou des pointeurs intelligents dans ta map. Du coup, à chaque
fois que tu enlèves un élément de la map, ou que la map est détruite,
tu dois penser à appeler delete sur chaque élément enlevé.
Ce qui cause bien sûr deux problèmes :
- c'est fastidieux
- tu risques d'oublier des cas (en particulier, quand la map est
supprimée suite à une exception).
Ce qui conduit à ma question habituelle : es-tu bien sûr de ne pas
pouvoir mettre carrément des objets dans ta map ?
Si tu as une raison valable de passer par des pointeurs, utilise au
moins des pointeurs intelligents.
A noter que certaines classes de Borland (celles d'OWL dérivant de
TWindow, et sans doute l'équivalent dans la VCL) ont le fonctionnement
de pointeurs intelligents : on ne peut les créer que dynamiquement
(par new), et il n'est pas nécessaire d'appeler delete, ils
s'auto-détruisent.
Question subsidiaire : as-tu une bonne raison d'utiliser AnsiString à
la place de std::string ?
Pour info, AnsiString est une classe "chaîne
de caractères" spécifique à Borland ; Microsoft a l'équivalent avec
CString. Les deux ont été créées pour pallier à l'absence d'une telle
classe dans la SL, à l'époque où std::string n'existait pas. Pour ma
part, je n'ai jamais utilisé AnsiString car quand j'ai commencé le
C++, std::string existait déjà.
On 26 Dec 2003 23:16:18 GMT, "Michaël Delva" <zoubidaman@hotmail.com>
wrote:
std::map<AnsiString,DS_Edit_Video*> map;
Appeler une variable par le même nom qu'un type est toujours
dangereux, même si tu es ici protégé par le namespace.
est-ce nécessaire de passer par un delete ite->second
Oui, parce que tu as choisi de mettre des pointeurs nus et pas des
objets ou des pointeurs intelligents dans ta map. Du coup, à chaque
fois que tu enlèves un élément de la map, ou que la map est détruite,
tu dois penser à appeler delete sur chaque élément enlevé.
Ce qui cause bien sûr deux problèmes :
- c'est fastidieux
- tu risques d'oublier des cas (en particulier, quand la map est
supprimée suite à une exception).
Ce qui conduit à ma question habituelle : es-tu bien sûr de ne pas
pouvoir mettre carrément des objets dans ta map ?
Si tu as une raison valable de passer par des pointeurs, utilise au
moins des pointeurs intelligents.
A noter que certaines classes de Borland (celles d'OWL dérivant de
TWindow, et sans doute l'équivalent dans la VCL) ont le fonctionnement
de pointeurs intelligents : on ne peut les créer que dynamiquement
(par new), et il n'est pas nécessaire d'appeler delete, ils
s'auto-détruisent.
Question subsidiaire : as-tu une bonne raison d'utiliser AnsiString à
la place de std::string ?
Pour info, AnsiString est une classe "chaîne
de caractères" spécifique à Borland ; Microsoft a l'équivalent avec
CString. Les deux ont été créées pour pallier à l'absence d'une telle
classe dans la SL, à l'époque où std::string n'existait pas. Pour ma
part, je n'ai jamais utilisé AnsiString car quand j'ai commencé le
C++, std::string existait déjà.
On 26 Dec 2003 23:16:18 GMT, "Michaël Delva"
wrote:std::map<AnsiString,DS_Edit_Video*> map;
Appeler une variable par le même nom qu'un type est toujours
dangereux, même si tu es ici protégé par le namespace.
est-ce nécessaire de passer par un delete ite->second
Oui, parce que tu as choisi de mettre des pointeurs nus et pas des
objets ou des pointeurs intelligents dans ta map. Du coup, à chaque
fois que tu enlèves un élément de la map, ou que la map est détruite,
tu dois penser à appeler delete sur chaque élément enlevé.
Ce qui cause bien sûr deux problèmes :
- c'est fastidieux
- tu risques d'oublier des cas (en particulier, quand la map est
supprimée suite à une exception).
Ce qui conduit à ma question habituelle : es-tu bien sûr de ne pas
pouvoir mettre carrément des objets dans ta map ?
Si tu as une raison valable de passer par des pointeurs, utilise au
moins des pointeurs intelligents.
A noter que certaines classes de Borland (celles d'OWL dérivant de
TWindow, et sans doute l'équivalent dans la VCL) ont le fonctionnement
de pointeurs intelligents : on ne peut les créer que dynamiquement
(par new), et il n'est pas nécessaire d'appeler delete, ils
s'auto-détruisent.
Question subsidiaire : as-tu une bonne raison d'utiliser AnsiString à
la place de std::string ?
Pour info, AnsiString est une classe "chaîne
de caractères" spécifique à Borland ; Microsoft a l'équivalent avec
CString. Les deux ont été créées pour pallier à l'absence d'une telle
classe dans la SL, à l'époque où std::string n'existait pas. Pour ma
part, je n'ai jamais utilisé AnsiString car quand j'ai commencé le
C++, std::string existait déjà.
"Michaël Delva" writes:
|> Fabien LE LEZ wrote in
|> news::
|> > Ce qui conduit à ma question habituelle : es-tu bien sûr de
|> > ne pas pouvoir mettre carrément des objets dans ta map ?
À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
|> J'en ai aucune idée... Comment je peux savoir ce qu'il vaut mieux
|> utiliser?
En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
|> Pour info, DS_Edit_Video* est une classe me permettant de gérer
|> une édition vidéo avec DirectShow.
Sans en savoir plus sur la conception générale, on ne peut rien
dire, mais a priori, je ne vois pas de problème avec un pointeur ici.
|> > Si tu as une raison valable de passer par des pointeurs, utilise
|> > au moins des pointeurs intelligents.
|> On m'en a déjà parlé, mais je ne sais pas encore les utiliser...
T'en fais pas, moi non plus :-).
Sérieusement, les pointeurs intelligents sont un outil utile, mais
ils ne sont pas un « silver bullet », et je me retrouve avec
beaucoup de pointeurs bruts dans mes programmes aussi.
En ce qui concerne l'émoticon dans la première phrase, en fait,
même si j'étais un des premiers à pousser à l'utilisation
des pointeurs intelligents, il y plus de dix ans, dans comp.lang.c++,
je n'arrive toujours pas à décider quelle rôle ils doivent
réelement joués. Ils font à la fois trop et pas assez :
- En ce qui concerne la gestion de la mémoire, c'est
préférrable de carrément utiliser une ramasse-miettes. Les
pointeurs intelligents exigent toujours beaucoup d'attention
(éviter les cycles, etc.), avec des possibilités
correspondantes d'erreur. En plus, avec certaines conceptions (par
exemple, celui de Barton et Nackman, ainsi que boost), c'est
possible, et même assez facile, d'obtenir deux compteurs pour le
même objet, et avec d'autres (celle que j'utilise moi-même, et
qui se trouve dans Scott Meyers), on ne peut pas s'en servir sur
des types qui n'étaient pas conçus pour être comptés. Les
pointeurs intelligents actuels de Boost offre les deux
possibilités, mais il faut toujours en choisir un ou l'autre pour
un objet donné.
- En ce qui concerne les pointeurs faibles (« weak pointer »),
ça permet à résoudre le problème des cycles, au moyen
d'un analyse approfondi (c-à-d beaucoup de travail, et beaucoup
de possibilités d'erreur), mais la plupart de temps, je me suis
rendu compte qu'il me fallait une notification plus directe
(simplement invalider le pointeur n'était pas suffisant).
En plus, je me suis rendu compte qu'il y a un bon nombre d'objets dont
la durée de vie devait être explicite, selon la conception du
programme. Tu ne veux pas qu'une fenêtre sur l'écran se ferme en
fonction des pointeurs vers l'objet, quand même -- ce qu'il faut,
c'est que l'objet soit supprimé explicitement en fonction d'un
évenemment externe, et que dans son destructeur, il s'occupe de
notifier tous les clients de sa disparition. Or, si dans certains cas,
simplement invalider le pointeur chez le client est notification
suffisante, c'est loin d'être toujours le cas.
Ceci dit, quand on veut gérer des objets dans une collection, les
pointeurs intelligents sont souvent une bonne solution. C'est un des
cas où ils marchent le mieux.
"Michaël Delva" <zoubidaman@hotmail.com> writes:
|> Fabien LE LEZ <gramster@gramster.com> wrote in
|> news:8hgpuvcijuf5nbf1tb78uvvo2j9dm8j4dl@4ax.com:
|> > Ce qui conduit à ma question habituelle : es-tu bien sûr de
|> > ne pas pouvoir mettre carrément des objets dans ta map ?
À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
|> J'en ai aucune idée... Comment je peux savoir ce qu'il vaut mieux
|> utiliser?
En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
|> Pour info, DS_Edit_Video* est une classe me permettant de gérer
|> une édition vidéo avec DirectShow.
Sans en savoir plus sur la conception générale, on ne peut rien
dire, mais a priori, je ne vois pas de problème avec un pointeur ici.
|> > Si tu as une raison valable de passer par des pointeurs, utilise
|> > au moins des pointeurs intelligents.
|> On m'en a déjà parlé, mais je ne sais pas encore les utiliser...
T'en fais pas, moi non plus :-).
Sérieusement, les pointeurs intelligents sont un outil utile, mais
ils ne sont pas un « silver bullet », et je me retrouve avec
beaucoup de pointeurs bruts dans mes programmes aussi.
En ce qui concerne l'émoticon dans la première phrase, en fait,
même si j'étais un des premiers à pousser à l'utilisation
des pointeurs intelligents, il y plus de dix ans, dans comp.lang.c++,
je n'arrive toujours pas à décider quelle rôle ils doivent
réelement joués. Ils font à la fois trop et pas assez :
- En ce qui concerne la gestion de la mémoire, c'est
préférrable de carrément utiliser une ramasse-miettes. Les
pointeurs intelligents exigent toujours beaucoup d'attention
(éviter les cycles, etc.), avec des possibilités
correspondantes d'erreur. En plus, avec certaines conceptions (par
exemple, celui de Barton et Nackman, ainsi que boost), c'est
possible, et même assez facile, d'obtenir deux compteurs pour le
même objet, et avec d'autres (celle que j'utilise moi-même, et
qui se trouve dans Scott Meyers), on ne peut pas s'en servir sur
des types qui n'étaient pas conçus pour être comptés. Les
pointeurs intelligents actuels de Boost offre les deux
possibilités, mais il faut toujours en choisir un ou l'autre pour
un objet donné.
- En ce qui concerne les pointeurs faibles (« weak pointer »),
ça permet à résoudre le problème des cycles, au moyen
d'un analyse approfondi (c-à-d beaucoup de travail, et beaucoup
de possibilités d'erreur), mais la plupart de temps, je me suis
rendu compte qu'il me fallait une notification plus directe
(simplement invalider le pointeur n'était pas suffisant).
En plus, je me suis rendu compte qu'il y a un bon nombre d'objets dont
la durée de vie devait être explicite, selon la conception du
programme. Tu ne veux pas qu'une fenêtre sur l'écran se ferme en
fonction des pointeurs vers l'objet, quand même -- ce qu'il faut,
c'est que l'objet soit supprimé explicitement en fonction d'un
évenemment externe, et que dans son destructeur, il s'occupe de
notifier tous les clients de sa disparition. Or, si dans certains cas,
simplement invalider le pointeur chez le client est notification
suffisante, c'est loin d'être toujours le cas.
Ceci dit, quand on veut gérer des objets dans une collection, les
pointeurs intelligents sont souvent une bonne solution. C'est un des
cas où ils marchent le mieux.
"Michaël Delva" writes:
|> Fabien LE LEZ wrote in
|> news::
|> > Ce qui conduit à ma question habituelle : es-tu bien sûr de
|> > ne pas pouvoir mettre carrément des objets dans ta map ?
À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
|> J'en ai aucune idée... Comment je peux savoir ce qu'il vaut mieux
|> utiliser?
En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
|> Pour info, DS_Edit_Video* est une classe me permettant de gérer
|> une édition vidéo avec DirectShow.
Sans en savoir plus sur la conception générale, on ne peut rien
dire, mais a priori, je ne vois pas de problème avec un pointeur ici.
|> > Si tu as une raison valable de passer par des pointeurs, utilise
|> > au moins des pointeurs intelligents.
|> On m'en a déjà parlé, mais je ne sais pas encore les utiliser...
T'en fais pas, moi non plus :-).
Sérieusement, les pointeurs intelligents sont un outil utile, mais
ils ne sont pas un « silver bullet », et je me retrouve avec
beaucoup de pointeurs bruts dans mes programmes aussi.
En ce qui concerne l'émoticon dans la première phrase, en fait,
même si j'étais un des premiers à pousser à l'utilisation
des pointeurs intelligents, il y plus de dix ans, dans comp.lang.c++,
je n'arrive toujours pas à décider quelle rôle ils doivent
réelement joués. Ils font à la fois trop et pas assez :
- En ce qui concerne la gestion de la mémoire, c'est
préférrable de carrément utiliser une ramasse-miettes. Les
pointeurs intelligents exigent toujours beaucoup d'attention
(éviter les cycles, etc.), avec des possibilités
correspondantes d'erreur. En plus, avec certaines conceptions (par
exemple, celui de Barton et Nackman, ainsi que boost), c'est
possible, et même assez facile, d'obtenir deux compteurs pour le
même objet, et avec d'autres (celle que j'utilise moi-même, et
qui se trouve dans Scott Meyers), on ne peut pas s'en servir sur
des types qui n'étaient pas conçus pour être comptés. Les
pointeurs intelligents actuels de Boost offre les deux
possibilités, mais il faut toujours en choisir un ou l'autre pour
un objet donné.
- En ce qui concerne les pointeurs faibles (« weak pointer »),
ça permet à résoudre le problème des cycles, au moyen
d'un analyse approfondi (c-à-d beaucoup de travail, et beaucoup
de possibilités d'erreur), mais la plupart de temps, je me suis
rendu compte qu'il me fallait une notification plus directe
(simplement invalider le pointeur n'était pas suffisant).
En plus, je me suis rendu compte qu'il y a un bon nombre d'objets dont
la durée de vie devait être explicite, selon la conception du
programme. Tu ne veux pas qu'une fenêtre sur l'écran se ferme en
fonction des pointeurs vers l'objet, quand même -- ce qu'il faut,
c'est que l'objet soit supprimé explicitement en fonction d'un
évenemment externe, et que dans son destructeur, il s'occupe de
notifier tous les clients de sa disparition. Or, si dans certains cas,
simplement invalider le pointeur chez le client est notification
suffisante, c'est loin d'être toujours le cas.
Ceci dit, quand on veut gérer des objets dans une collection, les
pointeurs intelligents sont souvent une bonne solution. C'est un des
cas où ils marchent le mieux.
James Kanze wrote in
news::À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
On entre dans un domaine qui se complexifie pour moi, notamment du
fait de l'utilisation de vocabulaire que je ne connais et comprends
pas encore.
Qu'est-ce que tu appelles la sémantique d'un objet?En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
Idem, malgré la précision que tu apportes...
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
James Kanze <kanze@alex.gabi-soft.fr> wrote in
news:86ad5ehafg.fsf@alex.gabi-soft.fr:
À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
On entre dans un domaine qui se complexifie pour moi, notamment du
fait de l'utilisation de vocabulaire que je ne connais et comprends
pas encore.
Qu'est-ce que tu appelles la sémantique d'un objet?
En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
Idem, malgré la précision que tu apportes...
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
James Kanze wrote in
news::À vrai dire, je dirais que la question ne se justifie que si on a au
moins une petite idée de la sémantique de l'objet. Dans mon propre
code, je crois que la plupart des map ont des pointeurs comme
deuxième type.
On entre dans un domaine qui se complexifie pour moi, notamment du
fait de l'utilisation de vocabulaire que je ne connais et comprends
pas encore.
Qu'est-ce que tu appelles la sémantique d'un objet?En sachant la sémantique de l'objet en question. S'il a une
sémantique de valeur, on utilise des valeurs ; s'il a une
sémantique de référence (type d'entité, par exemple), on
utilise des pointeurs.
Idem, malgré la précision que tu apportes...
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
La notion de valeur a-t-elle une quelconque signification pour tes
objets ? Si oui, en général, il est possible de les copier, de leur
affecter une autre valeur. Deux objets peuvent être considérés comme
identiques si ils possèdent la même valeur. Dans le cas contraire, les
objets ne sont pas caractérisés par une valeur, mais par une identité.
Cette identité est caractérisée par un ID qui peut être une clé
primaire dans une base de données, un identifiant unique quelconque,
ou plus simplement l'adresse mémoire de l'objet dans le cas d'objets
volatiles (ou non persistents, qui ne survivent pas après la fin de
l'exécution du programme).
En général, les objets avec une sémantique de valeur offrent moins de
contraintes et sont donc plus faciles à utiliser. On peut faire un
parallèle entre types de base(*) ou pointeurs avec sémantique de
valeur ou de référence.
(*) le terme "type de base" n'est pas forcément le plus adapté : je
parle ici des types comme int, char, std::string, double par
opposition aux pointeurs. Les pointeurs ont beau être aussi des types
de base, je ne connais pas de terme plus précis.
Les objets gérés par le système ont rarement une sémantique de valeur.
La notion d'identité se fait via un handle ou, dans ton cas, une
adresse.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Je grouve que la phrase de James n'est pas très claire. Je crois qu'il
veut dire qu'il y a des cas où tu utilises des pointeurs sans vouloir
pour autant une sémantique d'identité (ou de référence). C'est
notemment le cas en C++ quand tu utilises des objets polymorphes, ce
qui n'est possible que via leur adresse (à travers un pointeur ou une
référence). Quand tu es obligé d'utiliser des pointeurs et que tu
souhaites que tes objets conservent une sémantique de valeur
(supportent librement la copie ou l'affectation), il faut fournir un
travail supplémentaire en les encapsulant dans une classe qui définit
ces opérations.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
Connais pas...
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo, je
doute qu'il soit souhaitable de les copier fréquemment, ce qui rend
l'utilité d'une sémantique de valeur peu probable.
La question restante concerne la durée de vie de ces objets. Si tu
sais à quel moment ils sont créés et à quels moments ils sont
détruits, le plus simple consiste à les utiliser comme tu le fais, via
des pointeurs. Dans le cas contraire, des pointeurs intelligents sont
un plus, notemment avec un comptage de références dans le cas de
références multiples.
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete ; erase ne supprimant que leur référence dans le
map, comme il t'a déjà été précisé dans un autre post. Du reste, tu
peux peut-être te faire une petite fonction qui fasse les deux...
Chris
La notion de valeur a-t-elle une quelconque signification pour tes
objets ? Si oui, en général, il est possible de les copier, de leur
affecter une autre valeur. Deux objets peuvent être considérés comme
identiques si ils possèdent la même valeur. Dans le cas contraire, les
objets ne sont pas caractérisés par une valeur, mais par une identité.
Cette identité est caractérisée par un ID qui peut être une clé
primaire dans une base de données, un identifiant unique quelconque,
ou plus simplement l'adresse mémoire de l'objet dans le cas d'objets
volatiles (ou non persistents, qui ne survivent pas après la fin de
l'exécution du programme).
En général, les objets avec une sémantique de valeur offrent moins de
contraintes et sont donc plus faciles à utiliser. On peut faire un
parallèle entre types de base(*) ou pointeurs avec sémantique de
valeur ou de référence.
(*) le terme "type de base" n'est pas forcément le plus adapté : je
parle ici des types comme int, char, std::string, double par
opposition aux pointeurs. Les pointeurs ont beau être aussi des types
de base, je ne connais pas de terme plus précis.
Les objets gérés par le système ont rarement une sémantique de valeur.
La notion d'identité se fait via un handle ou, dans ton cas, une
adresse.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Je grouve que la phrase de James n'est pas très claire. Je crois qu'il
veut dire qu'il y a des cas où tu utilises des pointeurs sans vouloir
pour autant une sémantique d'identité (ou de référence). C'est
notemment le cas en C++ quand tu utilises des objets polymorphes, ce
qui n'est possible que via leur adresse (à travers un pointeur ou une
référence). Quand tu es obligé d'utiliser des pointeurs et que tu
souhaites que tes objets conservent une sémantique de valeur
(supportent librement la copie ou l'affectation), il faut fournir un
travail supplémentaire en les encapsulant dans une classe qui définit
ces opérations.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
Connais pas...
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo, je
doute qu'il soit souhaitable de les copier fréquemment, ce qui rend
l'utilité d'une sémantique de valeur peu probable.
La question restante concerne la durée de vie de ces objets. Si tu
sais à quel moment ils sont créés et à quels moments ils sont
détruits, le plus simple consiste à les utiliser comme tu le fais, via
des pointeurs. Dans le cas contraire, des pointeurs intelligents sont
un plus, notemment avec un comptage de références dans le cas de
références multiples.
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete ; erase ne supprimant que leur référence dans le
map, comme il t'a déjà été précisé dans un autre post. Du reste, tu
peux peut-être te faire une petite fonction qui fasse les deux...
Chris
La notion de valeur a-t-elle une quelconque signification pour tes
objets ? Si oui, en général, il est possible de les copier, de leur
affecter une autre valeur. Deux objets peuvent être considérés comme
identiques si ils possèdent la même valeur. Dans le cas contraire, les
objets ne sont pas caractérisés par une valeur, mais par une identité.
Cette identité est caractérisée par un ID qui peut être une clé
primaire dans une base de données, un identifiant unique quelconque,
ou plus simplement l'adresse mémoire de l'objet dans le cas d'objets
volatiles (ou non persistents, qui ne survivent pas après la fin de
l'exécution du programme).
En général, les objets avec une sémantique de valeur offrent moins de
contraintes et sont donc plus faciles à utiliser. On peut faire un
parallèle entre types de base(*) ou pointeurs avec sémantique de
valeur ou de référence.
(*) le terme "type de base" n'est pas forcément le plus adapté : je
parle ici des types comme int, char, std::string, double par
opposition aux pointeurs. Les pointeurs ont beau être aussi des types
de base, je ne connais pas de terme plus précis.
Les objets gérés par le système ont rarement une sémantique de valeur.
La notion d'identité se fait via un handle ou, dans ton cas, une
adresse.
En première approximation, parce qu'on peut être amené à
utiliser des pointeurs pour d'autres raisons aussi, et dans certains
cas, c'est intéressant d'emballer un type d'entité dans un
envellope dont les valeurs ont une sémantique de référence.
Je grouve que la phrase de James n'est pas très claire. Je crois qu'il
veut dire qu'il y a des cas où tu utilises des pointeurs sans vouloir
pour autant une sémantique d'identité (ou de référence). C'est
notemment le cas en C++ quand tu utilises des objets polymorphes, ce
qui n'est possible que via leur adresse (à travers un pointeur ou une
référence). Quand tu es obligé d'utiliser des pointeurs et que tu
souhaites que tes objets conservent une sémantique de valeur
(supportent librement la copie ou l'affectation), il faut fournir un
travail supplémentaire en les encapsulant dans une classe qui définit
ces opérations.
Pour info, DS_Edit_Video* est une classe me permettant de gérer
une édition vidéo avec DirectShow.
Connais pas...
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo, je
doute qu'il soit souhaitable de les copier fréquemment, ce qui rend
l'utilité d'une sémantique de valeur peu probable.
La question restante concerne la durée de vie de ces objets. Si tu
sais à quel moment ils sont créés et à quels moments ils sont
détruits, le plus simple consiste à les utiliser comme tu le fais, via
des pointeurs. Dans le cas contraire, des pointeurs intelligents sont
un plus, notemment avec un comptage de références dans le cas de
références multiples.
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete ; erase ne supprimant que leur référence dans le
map, comme il t'a déjà été précisé dans un autre post. Du reste, tu
peux peut-être te faire une petite fonction qui fasse les deux...
Chris
(*) le terme "type de base" n'est pas forcément le plus adapté : je parle
ici des types comme int, char, std::string, double par opposition aux
pointeurs. Les pointeurs ont beau être aussi des types de base, je ne
connais pas de terme plus précis.
D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete
(*) le terme "type de base" n'est pas forcément le plus adapté : je parle
ici des types comme int, char, std::string, double par opposition aux
pointeurs. Les pointeurs ont beau être aussi des types de base, je ne
connais pas de terme plus précis.
D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete
(*) le terme "type de base" n'est pas forcément le plus adapté : je parle
ici des types comme int, char, std::string, double par opposition aux
pointeurs. Les pointeurs ont beau être aussi des types de base, je ne
connais pas de terme plus précis.
D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer tes
objets avec delete
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo,
je doute qu'il soit souhaitable de les copier fréquemment, ce qui
rend l'utilité d'une sémantique de valeur peu probable.
En fait elles ne sont jamais copiées... Dès qu'elles sont stockées
dans la map, j'y accède uniquement pour rajouter des pistes audio ou
vidéo, puis à la fin pour créer le fichier vidéo...
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer
tes objets avec delete ; erase ne supprimant que leur référence dans
le map, comme il t'a déjà été précisé dans un autre post. Du reste,
tu peux peut-être te faire une petite fonction qui fasse les deux...
Alors là on aborde un autre point de questionnement:
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
Je m'interroge là dessus... Personnellement je ne le fais jamais, car
ça m'oblige à naviguer trop souvent dans le code source pour
retrouver leur utilité...
M'enfin, peut-être ai-je tort??
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo,
je doute qu'il soit souhaitable de les copier fréquemment, ce qui
rend l'utilité d'une sémantique de valeur peu probable.
En fait elles ne sont jamais copiées... Dès qu'elles sont stockées
dans la map, j'y accède uniquement pour rajouter des pistes audio ou
vidéo, puis à la fin pour créer le fichier vidéo...
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer
tes objets avec delete ; erase ne supprimant que leur référence dans
le map, comme il t'a déjà été précisé dans un autre post. Du reste,
tu peux peut-être te faire une petite fonction qui fasse les deux...
Alors là on aborde un autre point de questionnement:
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
Je m'interroge là dessus... Personnellement je ne le fais jamais, car
ça m'oblige à naviguer trop souvent dans le code source pour
retrouver leur utilité...
M'enfin, peut-être ai-je tort??
Ceci dit, vu la quantité de données impliquée dans l'édition vidéo,
je doute qu'il soit souhaitable de les copier fréquemment, ce qui
rend l'utilité d'une sémantique de valeur peu probable.
En fait elles ne sont jamais copiées... Dès qu'elles sont stockées
dans la map, j'y accède uniquement pour rajouter des pistes audio ou
vidéo, puis à la fin pour créer le fichier vidéo...
Pour conclure, c'est juste un petit topo théorique. D'un point de vue
pratique, ne changes rien, si ce n'est de ne pas oublier d'effacer
tes objets avec delete ; erase ne supprimant que leur référence dans
le map, comme il t'a déjà été précisé dans un autre post. Du reste,
tu peux peut-être te faire une petite fonction qui fasse les deux...
Alors là on aborde un autre point de questionnement:
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
Je m'interroge là dessus... Personnellement je ne le fais jamais, car
ça m'oblige à naviguer trop souvent dans le code source pour
retrouver leur utilité...
M'enfin, peut-être ai-je tort??
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
est-ce vraiment nécessaire de créer des fonctions pour d'aussi petites
instructions?
