j'ai une classe Objet, et une classe TabObjet qui contient un
vector<Objet>
chaque Objet à pour membre :
un unsigned int ID, que le caractérise facilement.
un string Name, sorte d'id mais pour l'utilisateur.
et quelques autres paramètres pas très importants...
bref, le constructeur de Objet demande entre autre, l'ID et le Name, et
le constructeur par défaut lui, fixe un ID qui est égal à
l'incrémentation de un, d'une vairable statique initialisée a 0, ainsi
qu'un Name par défaut.
Objet::Objet()
:Name("SansNom"),ID(nb++) //avec static unsigned int nb = 0; dans la
classe
{
}
alors là, ça va bien lorsque j'appelle le constructeur "manuellement",
cependant je ne comprends pas ce qui se passe lorsque j'apelle le
constructeur de TabObjet.
TabObjet::TabObjet():mon_tab(100)
{
}
va créer un vector de 100 Objet, mais comment ceux-ci vont-ils être
crées ? par le constructeur par défaut ?
je me demande en fait, si les Objet de mon vector auront bien des bons
ID
On Sat, 07 Feb 2004 17:59:40 +0100, Nicolas Aunai wrote: [...]
quelles complications ça apporte ? incrémenter une variable statique a chaque construction, définir un membre ID, un accesseur en lecture, un en écriture... et voila. [...]
je le fais pour que les particules ne soient pas "anonymes",
En gros, tu veux donner une sémantique d'identité (ou d'entité) à tes objets. C'est un point de vue assez courant, mais loin d'être anodin. Ta méthode est peut-être un bon début, [...]
En C++, si je veux donner une sémentique d'identité, j'utilises plutôt des pointeurs, l'adresse servant alors d'identifiant unique. Le seul intérêt que je peux voir à dupliquer ça avec un champ id est si on veux s'interfacer avec des gens qui ne peuvent avoir accès directement à nos objet (autres process sur une autre machine, interfaçage avec une bibliothèque SQL,...).
-- Loïc
Fabien LE LEZ wrote:
On Sat, 07 Feb 2004 17:59:40 +0100, Nicolas Aunai
<nicolas.aunai@free.fr> wrote:
[...]
quelles complications ça apporte ? incrémenter
une variable statique a chaque construction, définir un membre ID, un
accesseur en lecture, un en écriture... et voila.
[...]
je le fais pour que les particules ne soient pas "anonymes",
En gros, tu veux donner une sémantique d'identité (ou d'entité) à tes
objets. C'est un point de vue assez courant, mais loin d'être anodin.
Ta méthode est peut-être un bon début,
[...]
En C++, si je veux donner une sémentique d'identité, j'utilises plutôt
des pointeurs, l'adresse servant alors d'identifiant unique. Le seul
intérêt que je peux voir à dupliquer ça avec un champ id est si on veux
s'interfacer avec des gens qui ne peuvent avoir accès directement à nos
objet (autres process sur une autre machine, interfaçage avec une
bibliothèque SQL,...).
On Sat, 07 Feb 2004 17:59:40 +0100, Nicolas Aunai wrote: [...]
quelles complications ça apporte ? incrémenter une variable statique a chaque construction, définir un membre ID, un accesseur en lecture, un en écriture... et voila. [...]
je le fais pour que les particules ne soient pas "anonymes",
En gros, tu veux donner une sémantique d'identité (ou d'entité) à tes objets. C'est un point de vue assez courant, mais loin d'être anodin. Ta méthode est peut-être un bon début, [...]
En C++, si je veux donner une sémentique d'identité, j'utilises plutôt des pointeurs, l'adresse servant alors d'identifiant unique. Le seul intérêt que je peux voir à dupliquer ça avec un champ id est si on veux s'interfacer avec des gens qui ne peuvent avoir accès directement à nos objet (autres process sur une autre machine, interfaçage avec une bibliothèque SQL,...).
-- Loïc
Loïc Joly
Nicolas Aunai wrote:
Tu peux par contre utiliser un vector<> de pointeurs -- et allouer tes objets dynamiquement, à la main.
commet ça ? qu'est-ce que ça change... je piges pas bien
vector<*Objet> tab; vector<Object*> tab;
Ou souvent mieux : vector<boost::shared_ptr<Object> > tab;
Objet::Objet() { for(unsigned int i=0; i<nb; i++) tab.push_back(new Objet); }
Euh, tu crées un tableau d'Objet dans le constructeur d'Objet ? C'est un appel récursif sans fin, là...
-- Loïc
Nicolas Aunai wrote:
Tu peux par contre utiliser un
vector<> de pointeurs -- et allouer tes objets dynamiquement, à la
main.
commet ça ? qu'est-ce que ça change... je piges pas bien
vector<*Objet> tab;
vector<Object*> tab;
Ou souvent mieux :
vector<boost::shared_ptr<Object> > tab;
Objet::Objet()
{
for(unsigned int i=0; i<nb; i++)
tab.push_back(new Objet);
}
Euh, tu crées un tableau d'Objet dans le constructeur d'Objet ? C'est un
appel récursif sans fin, là...
Tu peux par contre utiliser un vector<> de pointeurs -- et allouer tes objets dynamiquement, à la main.
commet ça ? qu'est-ce que ça change... je piges pas bien
vector<*Objet> tab; vector<Object*> tab;
Ou souvent mieux : vector<boost::shared_ptr<Object> > tab;
Objet::Objet() { for(unsigned int i=0; i<nb; i++) tab.push_back(new Objet); }
Euh, tu crées un tableau d'Objet dans le constructeur d'Objet ? C'est un appel récursif sans fin, là...
-- Loïc
James Kanze
Nicolas Aunai writes:
|> j'ai une classe Objet, et une classe TabObjet qui contient un |> vector<Objet>
|> chaque Objet à pour membre :
|> un unsigned int ID, que le caractérise facilement. |> un string Name, sorte d'id mais pour l'utilisateur.
|> et quelques autres paramètres pas très importants...
|> bref, le constructeur de Objet demande entre autre, l'ID et le Name, |> et le constructeur par défaut lui, fixe un ID qui est égal |> à l'incrémentation de un, d'une vairable statique |> initialisée a 0, ainsi qu'un Name par défaut.
|> Objet::Objet() |> :Name("SansNom"),ID(nb++) //avec static unsigned int nb = 0; dans la |> classe |> { |> }
|> alors là, ça va bien lorsque j'appelle le constructeur |> "manuellement", cependant je ne comprends pas ce qui se passe |> lorsque j'apelle le constructeur de TabObjet.
|> TabObjet::TabObjet():mon_tab(100) |> { |> }
|> va créer un vector de 100 Objet, mais comment ceux-ci vont-ils |> être crées ? par le constructeur par défaut ?
Par le constructeur de copie.
|> je me demande en fait, si les Objet de mon vector auront bien des |> bons ID
Ça dépend ce que tu considères les bons ID. Tous les éléments dans le tableau seront une copie d'un objet unique, le seul construit par ton constructeur de copie.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Nicolas Aunai <nicolas.aunai@free.fr> writes:
|> j'ai une classe Objet, et une classe TabObjet qui contient un
|> vector<Objet>
|> chaque Objet à pour membre :
|> un unsigned int ID, que le caractérise facilement.
|> un string Name, sorte d'id mais pour l'utilisateur.
|> et quelques autres paramètres pas très importants...
|> bref, le constructeur de Objet demande entre autre, l'ID et le Name,
|> et le constructeur par défaut lui, fixe un ID qui est égal
|> à l'incrémentation de un, d'une vairable statique
|> initialisée a 0, ainsi qu'un Name par défaut.
|> Objet::Objet()
|> :Name("SansNom"),ID(nb++) //avec static unsigned int nb = 0; dans la
|> classe
|> {
|> }
|> alors là, ça va bien lorsque j'appelle le constructeur
|> "manuellement", cependant je ne comprends pas ce qui se passe
|> lorsque j'apelle le constructeur de TabObjet.
|> TabObjet::TabObjet():mon_tab(100)
|> {
|> }
|> va créer un vector de 100 Objet, mais comment ceux-ci vont-ils
|> être crées ? par le constructeur par défaut ?
Par le constructeur de copie.
|> je me demande en fait, si les Objet de mon vector auront bien des
|> bons ID
Ça dépend ce que tu considères les bons ID. Tous les
éléments dans le tableau seront une copie d'un objet unique, le
seul construit par ton constructeur de copie.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> j'ai une classe Objet, et une classe TabObjet qui contient un |> vector<Objet>
|> chaque Objet à pour membre :
|> un unsigned int ID, que le caractérise facilement. |> un string Name, sorte d'id mais pour l'utilisateur.
|> et quelques autres paramètres pas très importants...
|> bref, le constructeur de Objet demande entre autre, l'ID et le Name, |> et le constructeur par défaut lui, fixe un ID qui est égal |> à l'incrémentation de un, d'une vairable statique |> initialisée a 0, ainsi qu'un Name par défaut.
|> Objet::Objet() |> :Name("SansNom"),ID(nb++) //avec static unsigned int nb = 0; dans la |> classe |> { |> }
|> alors là, ça va bien lorsque j'appelle le constructeur |> "manuellement", cependant je ne comprends pas ce qui se passe |> lorsque j'apelle le constructeur de TabObjet.
|> TabObjet::TabObjet():mon_tab(100) |> { |> }
|> va créer un vector de 100 Objet, mais comment ceux-ci vont-ils |> être crées ? par le constructeur par défaut ?
Par le constructeur de copie.
|> je me demande en fait, si les Objet de mon vector auront bien des |> bons ID
Ça dépend ce que tu considères les bons ID. Tous les éléments dans le tableau seront une copie d'un objet unique, le seul construit par ton constructeur de copie.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
James Kanze
Nicolas Aunai writes:
|> Fabien LE LEZ a formulé la demande :
|> > Justement, il faut savoir se limiter dans ses prévisions, et se |> > contenter de ce qui apporte plus de fonctionnalités utiles que |> > de problèmes.
|> c'est justement parce que plus tard j'aurai peut-etre envie de faire |> quelque chose a laquelle j'avais pas pensé avant que bâtir les |> bases d'un programme de manière la plus "généraliste" |> possible me semble une bonne idée, et ça implique donner une |> identité a mes particules. C'est l'utilisation de bibliotheques |> c++ pour programmation graphique evennementielle qui m'en a donné |> l'idée, dans ce genre de truc, chaque composant d'un formulaire, |> un objet, est caractérisé par un ID, ce qui permet de lui |> appliquer tout un tas de choses...
|> > En gros, tu veux donner une sémantique d'identité (ou |> > d'entité) à tes objets. C'est un point de vue assez courant, |> > mais loin d'être anodin. Ta méthode est peut-être un bon |> > début, mais n'est pas complète : tu dois définir le |> > constructeur par copie (et l'opérateur de copie qui "va avec"), |> > pour t'assurer que deux objets différents ne peuvent pas avoir |> > le même ID (le constructeur par copie généré par le |> > compilateur se contente de copier membre à membre, ce qui ne |> > convient pas ici -- la preuve, ton erreur - qui a déclenché |> > le présent thread - n'a pas été repérée par le |> > compilo). Une technique classique est d'interdire l'usage du |> > constructeur de copie et de l'opérateur =, en les déclarant |> > privés.
|> mais c'est pas parce que j'en avais pas parlé que je l'avais pas |> fait :) mon constructeur par copie recopie membre a membre sauf l'ID |> qui est toujours le nombre_de_particules++. quant à |> l'opérateur d'assignation je l'ai mis en privé, mais il ne |> fait rien.
Il fait que tu ne peux pas faire un vecteur de de tels objets.
En fait, si les objets doivent avoir une identité, c'est prèsque certainement un vector<T*> (ou smart_ptr<T> -- mais tous les smart_ptr n'en conviennent pas non plus) qu'il te faut, et non un vector<T>.
|> > D'autre part, std::vector<> ne convient pas du tout, puisqu'il |> > n'accepte que des objets ayant une sémantique de valeur (il se |> > permet de copier allègrement les objets).
|> alors là... j'y pensais pas.
|> > Tu peux par contre utiliser un vector<> de pointeurs -- et allouer |> > tes objets dynamiquement, à la main.
|> commet ça ? qu'est-ce que ça change... je piges pas bien
Quand tu travailles avec des pointeurs, tu n'as qu'un seul instance de l'objet. Celui qui en définit son identité.
|> > Bon, je fatigue, donc je m'en tiens à ces explications |> > superficielles. Et j'attends que les vrais spécialistes du C++ |> > donnent leur avis sur la question -- j'avoue que, n'ayant aucune |> > expérience objet en-dehors du C++, j'ai tendance à éviter |> > au maximum d'utiliser des objets à sémantique d'entité.
Et cependant...
C'est une question de sémantique. Quand la sémantique donne une identité à l'objet, il FAUT utiliser un objet à sémantique d'identité (les objets dits « entité »). Quand la sémantique donne une valeur (et non une identité) à l'objet, on peut utiliser aussi des pointeurs, mais c'est lourd, et au moins en C++, c'est beaucoup plus idiomatique de travailler avec les valeurs.
|> > Mais tu as en tout cas raison sur un point : si tu as _vraiment_ |> > besoin d'une sémantique d'entité, mets-la en place tout de |> > suite, car ça va modifier profondément ton programme.
|> merci des explications, je sais pas si j'en ai besoin,
Alors, tu n'es pas encore assez avancé dans la conception pour commencer à écrire du code. Avant de commencer à écrire du code, il faut savoir ce que doit faire le code.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Nicolas Aunai <nicolas.aunai@free.fr> writes:
|> Fabien LE LEZ a formulé la demande :
|> > Justement, il faut savoir se limiter dans ses prévisions, et se
|> > contenter de ce qui apporte plus de fonctionnalités utiles que
|> > de problèmes.
|> c'est justement parce que plus tard j'aurai peut-etre envie de faire
|> quelque chose a laquelle j'avais pas pensé avant que bâtir les
|> bases d'un programme de manière la plus "généraliste"
|> possible me semble une bonne idée, et ça implique donner une
|> identité a mes particules. C'est l'utilisation de bibliotheques
|> c++ pour programmation graphique evennementielle qui m'en a donné
|> l'idée, dans ce genre de truc, chaque composant d'un formulaire,
|> un objet, est caractérisé par un ID, ce qui permet de lui
|> appliquer tout un tas de choses...
|> > En gros, tu veux donner une sémantique d'identité (ou
|> > d'entité) à tes objets. C'est un point de vue assez courant,
|> > mais loin d'être anodin. Ta méthode est peut-être un bon
|> > début, mais n'est pas complète : tu dois définir le
|> > constructeur par copie (et l'opérateur de copie qui "va avec"),
|> > pour t'assurer que deux objets différents ne peuvent pas avoir
|> > le même ID (le constructeur par copie généré par le
|> > compilateur se contente de copier membre à membre, ce qui ne
|> > convient pas ici -- la preuve, ton erreur - qui a déclenché
|> > le présent thread - n'a pas été repérée par le
|> > compilo). Une technique classique est d'interdire l'usage du
|> > constructeur de copie et de l'opérateur =, en les déclarant
|> > privés.
|> mais c'est pas parce que j'en avais pas parlé que je l'avais pas
|> fait :) mon constructeur par copie recopie membre a membre sauf l'ID
|> qui est toujours le nombre_de_particules++. quant à
|> l'opérateur d'assignation je l'ai mis en privé, mais il ne
|> fait rien.
Il fait que tu ne peux pas faire un vecteur de de tels objets.
En fait, si les objets doivent avoir une identité, c'est prèsque
certainement un vector<T*> (ou smart_ptr<T> -- mais tous les smart_ptr
n'en conviennent pas non plus) qu'il te faut, et non un vector<T>.
|> > D'autre part, std::vector<> ne convient pas du tout, puisqu'il
|> > n'accepte que des objets ayant une sémantique de valeur (il se
|> > permet de copier allègrement les objets).
|> alors là... j'y pensais pas.
|> > Tu peux par contre utiliser un vector<> de pointeurs -- et allouer
|> > tes objets dynamiquement, à la main.
|> commet ça ? qu'est-ce que ça change... je piges pas bien
Quand tu travailles avec des pointeurs, tu n'as qu'un seul instance de
l'objet. Celui qui en définit son identité.
|> > Bon, je fatigue, donc je m'en tiens à ces explications
|> > superficielles. Et j'attends que les vrais spécialistes du C++
|> > donnent leur avis sur la question -- j'avoue que, n'ayant aucune
|> > expérience objet en-dehors du C++, j'ai tendance à éviter
|> > au maximum d'utiliser des objets à sémantique d'entité.
Et cependant...
C'est une question de sémantique. Quand la sémantique donne une
identité à l'objet, il FAUT utiliser un objet à sémantique
d'identité (les objets dits « entité »). Quand la
sémantique donne une valeur (et non une identité) à l'objet, on
peut utiliser aussi des pointeurs, mais c'est lourd, et au moins en C++,
c'est beaucoup plus idiomatique de travailler avec les valeurs.
|> > Mais tu as en tout cas raison sur un point : si tu as _vraiment_
|> > besoin d'une sémantique d'entité, mets-la en place tout de
|> > suite, car ça va modifier profondément ton programme.
|> merci des explications, je sais pas si j'en ai besoin,
Alors, tu n'es pas encore assez avancé dans la conception pour
commencer à écrire du code. Avant de commencer à écrire du
code, il faut savoir ce que doit faire le code.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > Justement, il faut savoir se limiter dans ses prévisions, et se |> > contenter de ce qui apporte plus de fonctionnalités utiles que |> > de problèmes.
|> c'est justement parce que plus tard j'aurai peut-etre envie de faire |> quelque chose a laquelle j'avais pas pensé avant que bâtir les |> bases d'un programme de manière la plus "généraliste" |> possible me semble une bonne idée, et ça implique donner une |> identité a mes particules. C'est l'utilisation de bibliotheques |> c++ pour programmation graphique evennementielle qui m'en a donné |> l'idée, dans ce genre de truc, chaque composant d'un formulaire, |> un objet, est caractérisé par un ID, ce qui permet de lui |> appliquer tout un tas de choses...
|> > En gros, tu veux donner une sémantique d'identité (ou |> > d'entité) à tes objets. C'est un point de vue assez courant, |> > mais loin d'être anodin. Ta méthode est peut-être un bon |> > début, mais n'est pas complète : tu dois définir le |> > constructeur par copie (et l'opérateur de copie qui "va avec"), |> > pour t'assurer que deux objets différents ne peuvent pas avoir |> > le même ID (le constructeur par copie généré par le |> > compilateur se contente de copier membre à membre, ce qui ne |> > convient pas ici -- la preuve, ton erreur - qui a déclenché |> > le présent thread - n'a pas été repérée par le |> > compilo). Une technique classique est d'interdire l'usage du |> > constructeur de copie et de l'opérateur =, en les déclarant |> > privés.
|> mais c'est pas parce que j'en avais pas parlé que je l'avais pas |> fait :) mon constructeur par copie recopie membre a membre sauf l'ID |> qui est toujours le nombre_de_particules++. quant à |> l'opérateur d'assignation je l'ai mis en privé, mais il ne |> fait rien.
Il fait que tu ne peux pas faire un vecteur de de tels objets.
En fait, si les objets doivent avoir une identité, c'est prèsque certainement un vector<T*> (ou smart_ptr<T> -- mais tous les smart_ptr n'en conviennent pas non plus) qu'il te faut, et non un vector<T>.
|> > D'autre part, std::vector<> ne convient pas du tout, puisqu'il |> > n'accepte que des objets ayant une sémantique de valeur (il se |> > permet de copier allègrement les objets).
|> alors là... j'y pensais pas.
|> > Tu peux par contre utiliser un vector<> de pointeurs -- et allouer |> > tes objets dynamiquement, à la main.
|> commet ça ? qu'est-ce que ça change... je piges pas bien
Quand tu travailles avec des pointeurs, tu n'as qu'un seul instance de l'objet. Celui qui en définit son identité.
|> > Bon, je fatigue, donc je m'en tiens à ces explications |> > superficielles. Et j'attends que les vrais spécialistes du C++ |> > donnent leur avis sur la question -- j'avoue que, n'ayant aucune |> > expérience objet en-dehors du C++, j'ai tendance à éviter |> > au maximum d'utiliser des objets à sémantique d'entité.
Et cependant...
C'est une question de sémantique. Quand la sémantique donne une identité à l'objet, il FAUT utiliser un objet à sémantique d'identité (les objets dits « entité »). Quand la sémantique donne une valeur (et non une identité) à l'objet, on peut utiliser aussi des pointeurs, mais c'est lourd, et au moins en C++, c'est beaucoup plus idiomatique de travailler avec les valeurs.
|> > Mais tu as en tout cas raison sur un point : si tu as _vraiment_ |> > besoin d'une sémantique d'entité, mets-la en place tout de |> > suite, car ça va modifier profondément ton programme.
|> merci des explications, je sais pas si j'en ai besoin,
Alors, tu n'es pas encore assez avancé dans la conception pour commencer à écrire du code. Avant de commencer à écrire du code, il faut savoir ce que doit faire le code.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
