Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien,
mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien,
mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien,
mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien , mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Marc
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien , mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Marc
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans l es classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *thi s; }
Dans certaines classes dérivées, cette définition me va très bien , mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et l à je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Marc
On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bi en (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *t his; }
Dans certaines classes dérivées, cette définition me va très bi en, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
On 23 nov, 08:52, "Marc G" <mgueg...@metrica.fr> wrote:
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bi en (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *t his; }
Dans certaines classes dérivées, cette définition me va très bi en, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bi en (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *t his; }
Dans certaines classes dérivées, cette définition me va très bi en, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
wrote:On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = da ns les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *this; }
Dans certaines classes dérivées, cette définition me va très bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marc he.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. E t là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
dieu.tout.puiss...@gmail.com wrote:
On 23 nov, 08:52, "Marc G" <mgueg...@metrica.fr> wrote:
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = da ns les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *this; }
Dans certaines classes dérivées, cette définition me va très bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marc he.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. E t là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
wrote:On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = da ns les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe très bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ return *this; }
Dans certaines classes dérivées, cette définition me va très bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça marc he.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. E t là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
On 23 nov, 22:16, "James Kanze" wrote:wrote:On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe trè s bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ retur n *this; }
Dans certaines classes dérivées, cette définition me va trè s bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça ma rche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
Ma réponse précédente montre simplement de manière succinte que
operator= est traité spécialement (le ctor / dtor / op= sont
qualifiées de "fonctions membres spéciales"), réponse qui contient
d'ailleurs quelques imprécisions :
1 "possède" ici est très immatériel et ne signifie pas grand chose
2 "possède toutes les fonctions membres ..." : sans tenir compte de
l'acces specifier (private public protected)
Cela dit, sémantiquement, les fonctions membres de la classe de base
étant cachées, sont-elles considérées comme des fonctions membres
de la classe dérivée ?
Le standard ne dit pas grand chose à ce sujet :
A member name f in one subobject B hides a member name f in a
sub-object A if A is a base class sub-object of B. Any declarations
that are so hidden are eliminated from consideration.
La dernière phrase tenderait à prouver que de telles fonctions
cachées ne sont pas considérées comme des fonctions membres de la
classe dérivée dans le processus de "member function lookup".
Mais cela reste très subjectif.
On 23 nov, 22:16, "James Kanze" <james.ka...@gmail.com> wrote:
dieu.tout.puiss...@gmail.com wrote:
On 23 nov, 08:52, "Marc G" <mgueg...@metrica.fr> wrote:
Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe trè s bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ retur n *this; }
Dans certaines classes dérivées, cette définition me va trè s bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça ma rche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
Ma réponse précédente montre simplement de manière succinte que
operator= est traité spécialement (le ctor / dtor / op= sont
qualifiées de "fonctions membres spéciales"), réponse qui contient
d'ailleurs quelques imprécisions :
1 "possède" ici est très immatériel et ne signifie pas grand chose
2 "possède toutes les fonctions membres ..." : sans tenir compte de
l'acces specifier (private public protected)
Cela dit, sémantiquement, les fonctions membres de la classe de base
étant cachées, sont-elles considérées comme des fonctions membres
de la classe dérivée ?
Le standard ne dit pas grand chose à ce sujet :
A member name f in one subobject B hides a member name f in a
sub-object A if A is a base class sub-object of B. Any declarations
that are so hidden are eliminated from consideration.
La dernière phrase tenderait à prouver que de telles fonctions
cachées ne sont pas considérées comme des fonctions membres de la
classe dérivée dans le processus de "member function lookup".
Mais cela reste très subjectif.
On 23 nov, 22:16, "James Kanze" wrote:wrote:On 23 nov, 08:52, "Marc G" wrote:Mon compilateur m'oblige à redéfinir l'opérateur virtuel = dans les classes
dérivées. Est-ce normal ?
Par contre, pour les autres opérateurs virtuels, ça passe trè s bien (ex :
operator +=())
L'imbrication de mes classes est un peu compliquée, mais j'ai
schématiquement :
Dans la classe de base
virtual CVariant& operator=(CVariant const& right) { /* */ retur n *this; }
Dans certaines classes dérivées, cette définition me va trè s bien, mais le
compilateur me dit que operator= n'est pas définit.
Un copier/coller de la définition de la classe de base et ça ma rche.
Mais pour operator+=, qui modifie lui aussi l'objet, ça marche. Et là je
vois pas pourquoi dans un cas et pas dans l'autre ...
Il y a une "règle" là dessus ?
Oui. Une classe dérivée possède toutes les fonctions membres de sa
classe de base excepté 3 :
- le constructeur
- le destructeur
- opérator=.
Il les possède aussi. Seulement, elles sont cachées par celles
généraient par le compilateur.
Ma réponse précédente montre simplement de manière succinte que
operator= est traité spécialement (le ctor / dtor / op= sont
qualifiées de "fonctions membres spéciales"), réponse qui contient
d'ailleurs quelques imprécisions :
1 "possède" ici est très immatériel et ne signifie pas grand chose
2 "possède toutes les fonctions membres ..." : sans tenir compte de
l'acces specifier (private public protected)
Cela dit, sémantiquement, les fonctions membres de la classe de base
étant cachées, sont-elles considérées comme des fonctions membres
de la classe dérivée ?
Le standard ne dit pas grand chose à ce sujet :
A member name f in one subobject B hides a member name f in a
sub-object A if A is a base class sub-object of B. Any declarations
that are so hidden are eliminated from consideration.
La dernière phrase tenderait à prouver que de telles fonctions
cachées ne sont pas considérées comme des fonctions membres de la
classe dérivée dans le processus de "member function lookup".
Mais cela reste très subjectif.
Mais je serais intéressé à voir du code qui présente le problème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Mais je serais intéressé à voir du code qui présente le problème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Mais je serais intéressé à voir du code qui présente le problème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Mais je serais intéressé à voir du code qui présente le probl ème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Je n'ai pas fait d'études informatiques et suis donc entièrement auto didacte
dans cette matière.
Je veux dire par là que c'est très possible que je
commette parfois (j'espère pas trop quand même) de grosses erreurs...
Mais
bon, si je fais un programme qui marche bien et qui me statisfait
intellectuellement, et même si je me trompe conceptuellement sans le sa voir,
ça me fait plaisir. Mais je préfère quand même ne pas me tromper :-)
Mon problème en général
Je développe un interpréteur pour un langage que j'ai défini moi-m ême et
destiné à des traitements statistiques. Dans ce langage, il y a des " objets"
dont je voudrais accéder simplement aux propriétés (j'avais posté à ce sujet
il y a environ 2 semaines).
ex :
table a("une_ table");
propriétés :
a.name
a.size
a.label
a.contents
etc...
je cherche à me simplifier la tâche au niveau de la programmation de
l'interpréteur (et si possible en "externalisant" la plupart des messag es
d'erreur dans les objets eux-mêmes).
Au départ je me suis dit que le plus pratique pour accéder aux propri étés
était de retourner des CVariant (je pouvais pas changer le type de reto ur) à
partir d'une méthode get_property(std::string const&) implémentée d ans les
objets eux-même.
Comme cette méthode retourne des objets CVariant, je me suis finalement dit
que ce serais encore mieux si l'interpréteur ne manipulait QUE (ou pres que)
des objets CVariant. Evidemment, dans un langage normal, ce serait
drammatique au niveau de la performance. Mais c'est pas le cas ici, parce
que le temps d'interprétation est le plus souvent "infinitésimal" par
rapport au temps d'exécution !
Je veux dire que le langage manipule en général de "gros" objets et q ue les
données des champs de la table par exemple sont bien sûr des types
primaires.
En gros, j'ai la hiérarchie de classes suivante :
class CVariant {
template<typename T> inline explicit CVariant(T const&);
etc...
// les opérateurs (virtuels ou non)
CVariant *_variant;
};
template<typename T>
class CVariantSpecifique : public CVariant
{
// CVariantSpecifique à partir d'un type quelconque
explicit CVariantSpecifique(T const& t)
: CVariant(Empty()), // _variant=NULL
_t(new T(t))
{}
T* _t;
};
à ma connaissance, c'est l'implémentation "classique" des variants...
Note que dans CVariantSpecifique, je redéfinis l'opérateur virtuel
d'affectation =
Ensuite, ce que j'ai fait de plus particulier (enfin je l'ai trouvé tout
seul :-)), c'est de dériver d'autres classes de CVariant pour impléme nter
les contantes, les variables, les propriétés, etc... qui seront manip ulés
par l'interpréteur uniquement comme des CVariant
voilà, j'en suis à ce niveau pour l'instant...et peut-être que je f ais
fausse route !
mon problème était que dans la classe CVariable, le compilateur voula it
impérativement disposer d'une définition de l'opérateur =.
j'ai simplement recopié la définition implémentée dans CVariant
virtual CVariant& operator=(CVariant const& right)
{
if (&right!=this)
{
delete _variant;
_variant=right.duplicate();
}
return *this;
}
et ça marche
Mais je comprends pourquoi maintenant.
Je serais intéressé de savoir ce que tu penses de ce modèle...(voir à
t'envoyer le code si tu es intéressé mais là il faut quand même a voir un peu
de temps pour "l'étudier")
Mais je serais intéressé à voir du code qui présente le probl ème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Je n'ai pas fait d'études informatiques et suis donc entièrement auto didacte
dans cette matière.
Je veux dire par là que c'est très possible que je
commette parfois (j'espère pas trop quand même) de grosses erreurs...
Mais
bon, si je fais un programme qui marche bien et qui me statisfait
intellectuellement, et même si je me trompe conceptuellement sans le sa voir,
ça me fait plaisir. Mais je préfère quand même ne pas me tromper :-)
Mon problème en général
Je développe un interpréteur pour un langage que j'ai défini moi-m ême et
destiné à des traitements statistiques. Dans ce langage, il y a des " objets"
dont je voudrais accéder simplement aux propriétés (j'avais posté à ce sujet
il y a environ 2 semaines).
ex :
table a("une_ table");
propriétés :
a.name
a.size
a.label
a.contents
etc...
je cherche à me simplifier la tâche au niveau de la programmation de
l'interpréteur (et si possible en "externalisant" la plupart des messag es
d'erreur dans les objets eux-mêmes).
Au départ je me suis dit que le plus pratique pour accéder aux propri étés
était de retourner des CVariant (je pouvais pas changer le type de reto ur) à
partir d'une méthode get_property(std::string const&) implémentée d ans les
objets eux-même.
Comme cette méthode retourne des objets CVariant, je me suis finalement dit
que ce serais encore mieux si l'interpréteur ne manipulait QUE (ou pres que)
des objets CVariant. Evidemment, dans un langage normal, ce serait
drammatique au niveau de la performance. Mais c'est pas le cas ici, parce
que le temps d'interprétation est le plus souvent "infinitésimal" par
rapport au temps d'exécution !
Je veux dire que le langage manipule en général de "gros" objets et q ue les
données des champs de la table par exemple sont bien sûr des types
primaires.
En gros, j'ai la hiérarchie de classes suivante :
class CVariant {
template<typename T> inline explicit CVariant(T const&);
etc...
// les opérateurs (virtuels ou non)
CVariant *_variant;
};
template<typename T>
class CVariantSpecifique : public CVariant
{
// CVariantSpecifique à partir d'un type quelconque
explicit CVariantSpecifique(T const& t)
: CVariant(Empty()), // _variant=NULL
_t(new T(t))
{}
T* _t;
};
à ma connaissance, c'est l'implémentation "classique" des variants...
Note que dans CVariantSpecifique, je redéfinis l'opérateur virtuel
d'affectation =
Ensuite, ce que j'ai fait de plus particulier (enfin je l'ai trouvé tout
seul :-)), c'est de dériver d'autres classes de CVariant pour impléme nter
les contantes, les variables, les propriétés, etc... qui seront manip ulés
par l'interpréteur uniquement comme des CVariant
voilà, j'en suis à ce niveau pour l'instant...et peut-être que je f ais
fausse route !
mon problème était que dans la classe CVariable, le compilateur voula it
impérativement disposer d'une définition de l'opérateur =.
j'ai simplement recopié la définition implémentée dans CVariant
virtual CVariant& operator=(CVariant const& right)
{
if (&right!=this)
{
delete _variant;
_variant=right.duplicate();
}
return *this;
}
et ça marche
Mais je comprends pourquoi maintenant.
Je serais intéressé de savoir ce que tu penses de ce modèle...(voir à
t'envoyer le code si tu es intéressé mais là il faut quand même a voir un peu
de temps pour "l'étudier")
Mais je serais intéressé à voir du code qui présente le probl ème
dont tu parles. De même que je serais intéressé à voir un cas
où un opérator d'affectation virtuel n'est pas une erreur de
conception.
Je n'ai pas fait d'études informatiques et suis donc entièrement auto didacte
dans cette matière.
Je veux dire par là que c'est très possible que je
commette parfois (j'espère pas trop quand même) de grosses erreurs...
Mais
bon, si je fais un programme qui marche bien et qui me statisfait
intellectuellement, et même si je me trompe conceptuellement sans le sa voir,
ça me fait plaisir. Mais je préfère quand même ne pas me tromper :-)
Mon problème en général
Je développe un interpréteur pour un langage que j'ai défini moi-m ême et
destiné à des traitements statistiques. Dans ce langage, il y a des " objets"
dont je voudrais accéder simplement aux propriétés (j'avais posté à ce sujet
il y a environ 2 semaines).
ex :
table a("une_ table");
propriétés :
a.name
a.size
a.label
a.contents
etc...
je cherche à me simplifier la tâche au niveau de la programmation de
l'interpréteur (et si possible en "externalisant" la plupart des messag es
d'erreur dans les objets eux-mêmes).
Au départ je me suis dit que le plus pratique pour accéder aux propri étés
était de retourner des CVariant (je pouvais pas changer le type de reto ur) à
partir d'une méthode get_property(std::string const&) implémentée d ans les
objets eux-même.
Comme cette méthode retourne des objets CVariant, je me suis finalement dit
que ce serais encore mieux si l'interpréteur ne manipulait QUE (ou pres que)
des objets CVariant. Evidemment, dans un langage normal, ce serait
drammatique au niveau de la performance. Mais c'est pas le cas ici, parce
que le temps d'interprétation est le plus souvent "infinitésimal" par
rapport au temps d'exécution !
Je veux dire que le langage manipule en général de "gros" objets et q ue les
données des champs de la table par exemple sont bien sûr des types
primaires.
En gros, j'ai la hiérarchie de classes suivante :
class CVariant {
template<typename T> inline explicit CVariant(T const&);
etc...
// les opérateurs (virtuels ou non)
CVariant *_variant;
};
template<typename T>
class CVariantSpecifique : public CVariant
{
// CVariantSpecifique à partir d'un type quelconque
explicit CVariantSpecifique(T const& t)
: CVariant(Empty()), // _variant=NULL
_t(new T(t))
{}
T* _t;
};
à ma connaissance, c'est l'implémentation "classique" des variants...
Note que dans CVariantSpecifique, je redéfinis l'opérateur virtuel
d'affectation =
Ensuite, ce que j'ai fait de plus particulier (enfin je l'ai trouvé tout
seul :-)), c'est de dériver d'autres classes de CVariant pour impléme nter
les contantes, les variables, les propriétés, etc... qui seront manip ulés
par l'interpréteur uniquement comme des CVariant
voilà, j'en suis à ce niveau pour l'instant...et peut-être que je f ais
fausse route !
mon problème était que dans la classe CVariable, le compilateur voula it
impérativement disposer d'une définition de l'opérateur =.
j'ai simplement recopié la définition implémentée dans CVariant
virtual CVariant& operator=(CVariant const& right)
{
if (&right!=this)
{
delete _variant;
_variant=right.duplicate();
}
return *this;
}
et ça marche
Mais je comprends pourquoi maintenant.
Je serais intéressé de savoir ce que tu penses de ce modèle...(voir à
t'envoyer le code si tu es intéressé mais là il faut quand même a voir un peu
de temps pour "l'étudier")
Une première question : quel est le rÔle de ces objets dans ton
programme ?
(t)); }
global_macro(specific_macro)
Une première question : quel est le rÔle de ces objets dans ton
programme ?
(t)); }
global_macro(specific_macro)
Une première question : quel est le rÔle de ces objets dans ton
programme ?
(t)); }
global_macro(specific_macro)
Une première question : quel est le rÔle de ces objets dans ton
programme ?
Je développe un logiciel destiné à effectuer des traitements statistiques
sur des données.
Une première question : quel est le rÔle de ces objets dans ton
programme ?
Je développe un logiciel destiné à effectuer des traitements statistiques
sur des données.
Une première question : quel est le rÔle de ces objets dans ton
programme ?
Je développe un logiciel destiné à effectuer des traitements statistiques
sur des données.