Quelqu'un peut il me dire si il est choquant d'avoir un référence en
tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça
sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit
d'une bonne manière ou d'une mauvaise habitude.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
franco bevilacqua
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Je pense qu'il faut privilégier les références par rapport aux pointeurs, car on ne peut pas detruire un référence. Par contre cela suppose que l'objet referencé soit créé et maintenu à part, ce qui demande plus de travail. Voila mon avis. @+
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en
tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça
sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit
d'une bonne manière ou d'une mauvaise habitude.
Je pense qu'il faut privilégier les références par rapport aux
pointeurs, car on ne peut pas detruire un référence. Par contre cela
suppose que l'objet referencé soit créé et maintenu à part, ce qui
demande plus de travail.
Voila mon avis.
@+
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Je pense qu'il faut privilégier les références par rapport aux pointeurs, car on ne peut pas detruire un référence. Par contre cela suppose que l'objet referencé soit créé et maintenu à part, ce qui demande plus de travail. Voila mon avis. @+
adebaene
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, Pourqoi cela? Si un objet A doit référencer un objet B et que cette
référence doit rester constante durant toute la durée de vie de l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude. Pour moi il n'y a aucun souçi si on s'assure extérieurement que
l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le même problème avec un pointeur).
Arnaud MVP - VC
Quelqu'un peut il me dire si il est choquant d'avoir un référence en
tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop,
Pourqoi cela? Si un objet A doit référencer un objet B et que cette
référence doit rester constante durant toute la durée de vie de
l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te
choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça
sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit
d'une bonne manière ou d'une mauvaise habitude.
Pour moi il n'y a aucun souçi si on s'assure extérieurement que
l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le
même problème avec un pointeur).
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, Pourqoi cela? Si un objet A doit référencer un objet B et que cette
référence doit rester constante durant toute la durée de vie de l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude. Pour moi il n'y a aucun souçi si on s'assure extérieurement que
l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le même problème avec un pointeur).
Arnaud MVP - VC
Sébastien Sénégas
wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop,
Pourqoi cela? Si un objet A doit référencer un objet B et que cette référence doit rester constante durant toute la durée de vie de l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Pour moi il n'y a aucun souçi si on s'assure extérieurement que l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le même problème avec un pointeur).
Arnaud MVP - VC
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
adebaene@club-internet.fr wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en
tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop,
Pourqoi cela? Si un objet A doit référencer un objet B et que cette
référence doit rester constante durant toute la durée de vie de
l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te
choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça
sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit
d'une bonne manière ou d'une mauvaise habitude.
Pour moi il n'y a aucun souçi si on s'assure extérieurement que
l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le
même problème avec un pointeur).
Arnaud
MVP - VC
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation
des références dans la littérature, y a t'il une explication à cela?
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop,
Pourqoi cela? Si un objet A doit référencer un objet B et que cette référence doit rester constante durant toute la durée de vie de l'objet A, c'est la solution idéale il me semble. Qu'est ce qui te choque là dedans exactement?
mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Pour moi il n'y a aucun souçi si on s'assure extérieurement que l'objet B vit au moins aussi longtemps que l'objet A (mais on aurait le même problème avec un pointeur).
Arnaud MVP - VC
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
adebaene
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les objets qui implémentent l'idiome RAII (les "lockers" sur un mutex ou une section critique, les "libérateurs de ressources" de tout poil, etc...) ont généralement une référence sur la ressource qu'ils doivent libérer dans leur destructeur.
Arnaud
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation
des références dans la littérature, y a t'il une explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les objets qui
implémentent l'idiome RAII (les "lockers" sur un mutex ou une section
critique, les "libérateurs de ressources" de tout poil, etc...) ont
généralement une référence sur la ressource qu'ils doivent libérer
dans leur destructeur.
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les objets qui implémentent l'idiome RAII (les "lockers" sur un mutex ou une section critique, les "libérateurs de ressources" de tout poil, etc...) ont généralement une référence sur la ressource qu'ils doivent libérer dans leur destructeur.
Arnaud
kanze
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des classes entité, qui ne supporte ni la copie, ni surtout l'affectation. En revanche, je l'évite dans les classes de valeur, ou les agents pour la STL (genre Predicate, BinOp, etc.). Précisement parce qu'avec une référence, on a un petit problème à définir l'affectation. Il y a des exceptions, évidemment, où l'attribute implémentée par la référence n'entre pas en ligne de compte dans l'affectation, mais elles ne sont pas particulièrement fréquentes. Dans de tels cas, j'ai souvent quelque chose du genre :
class C { public : C( B& b ) : myB( &b ) {}
private: B* myB ; } ;
La référence comme paramètre du constructeur dit bien que je ne veux pas de pointeur nul. En revanche, le pointeur comme attribute fait que je peux avoir un opérateur d'affectation. (J'ai souvent ce genre de chose dans les objets fonctionnels pour la STL. Dans ces cas-là, si la classe est définie dans l'espace référentiel anonyme dans le fichier source, ce qui est souvent le cas, j'utilise même l'opérateur d'affectation par défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien documenté que la classe ne supportait pas l'affectation, ou qu'elle avait une sémantique d'affectation particulière. Sinon, je dirais que c'est simplement une erreur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un
référence en tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop, mais j'ai certains collégues qui
utilisent ça sans sourciller, j'aimerais des arguments clairs
justifiant s'il s'agit d'une bonne manière ou d'une mauvaise
habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des
classes entité, qui ne supporte ni la copie, ni surtout
l'affectation. En revanche, je l'évite dans les classes de
valeur, ou les agents pour la STL (genre Predicate, BinOp,
etc.). Précisement parce qu'avec une référence, on a un petit
problème à définir l'affectation. Il y a des exceptions,
évidemment, où l'attribute implémentée par la référence n'entre
pas en ligne de compte dans l'affectation, mais elles ne sont
pas particulièrement fréquentes. Dans de tels cas, j'ai souvent
quelque chose du genre :
class C
{
public :
C( B& b ) : myB( &b ) {}
private:
B* myB ;
} ;
La référence comme paramètre du constructeur dit bien que je ne
veux pas de pointeur nul. En revanche, le pointeur comme
attribute fait que je peux avoir un opérateur d'affectation.
(J'ai souvent ce genre de chose dans les objets fonctionnels
pour la STL. Dans ces cas-là, si la classe est définie dans
l'espace référentiel anonyme dans le fichier source, ce qui est
souvent le cas, j'utilise même l'opérateur d'affectation par
défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien
documenté que la classe ne supportait pas l'affectation, ou
qu'elle avait une sémantique d'affectation particulière. Sinon,
je dirais que c'est simplement une erreur.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des classes entité, qui ne supporte ni la copie, ni surtout l'affectation. En revanche, je l'évite dans les classes de valeur, ou les agents pour la STL (genre Predicate, BinOp, etc.). Précisement parce qu'avec une référence, on a un petit problème à définir l'affectation. Il y a des exceptions, évidemment, où l'attribute implémentée par la référence n'entre pas en ligne de compte dans l'affectation, mais elles ne sont pas particulièrement fréquentes. Dans de tels cas, j'ai souvent quelque chose du genre :
class C { public : C( B& b ) : myB( &b ) {}
private: B* myB ; } ;
La référence comme paramètre du constructeur dit bien que je ne veux pas de pointeur nul. En revanche, le pointeur comme attribute fait que je peux avoir un opérateur d'affectation. (J'ai souvent ce genre de chose dans les objets fonctionnels pour la STL. Dans ces cas-là, si la classe est définie dans l'espace référentiel anonyme dans le fichier source, ce qui est souvent le cas, j'utilise même l'opérateur d'affectation par défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien documenté que la classe ne supportait pas l'affectation, ou qu'elle avait une sémantique d'affectation particulière. Sinon, je dirais que c'est simplement une erreur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sébastien Sénégas
wrote:
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des classes entité, qui ne supporte ni la copie, ni surtout l'affectation. En revanche, je l'évite dans les classes de valeur, ou les agents pour la STL (genre Predicate, BinOp, etc.). Précisement parce qu'avec une référence, on a un petit problème à définir l'affectation. Il y a des exceptions, évidemment, où l'attribute implémentée par la référence n'entre pas en ligne de compte dans l'affectation, mais elles ne sont pas particulièrement fréquentes. Dans de tels cas, j'ai souvent quelque chose du genre :
class C { public : C( B& b ) : myB( &b ) {}
private: B* myB ; } ;
La référence comme paramètre du constructeur dit bien que je ne veux pas de pointeur nul. En revanche, le pointeur comme attribute fait que je peux avoir un opérateur d'affectation. (J'ai souvent ce genre de chose dans les objets fonctionnels pour la STL. Dans ces cas-là, si la classe est définie dans l'espace référentiel anonyme dans le fichier source, ce qui est souvent le cas, j'utilise même l'opérateur d'affectation par défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien documenté que la classe ne supportait pas l'affectation, ou qu'elle avait une sémantique d'affectation particulière. Sinon, je dirais que c'est simplement une erreur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
merci pour votre réponse ;)
kanze@gabi-soft.fr wrote:
Sébastien Sénégas wrote:
Quelqu'un peut il me dire si il est choquant d'avoir un
référence en tant qu'attribut.
e.g.
class B;
class A
{
public:
A( B& b ) : _b( b ) {};
~A() {};
...
private:
B &_b;
}
Perso j'aime pas trop, mais j'ai certains collégues qui
utilisent ça sans sourciller, j'aimerais des arguments clairs
justifiant s'il s'agit d'une bonne manière ou d'une mauvaise
habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des
classes entité, qui ne supporte ni la copie, ni surtout
l'affectation. En revanche, je l'évite dans les classes de
valeur, ou les agents pour la STL (genre Predicate, BinOp,
etc.). Précisement parce qu'avec une référence, on a un petit
problème à définir l'affectation. Il y a des exceptions,
évidemment, où l'attribute implémentée par la référence n'entre
pas en ligne de compte dans l'affectation, mais elles ne sont
pas particulièrement fréquentes. Dans de tels cas, j'ai souvent
quelque chose du genre :
class C
{
public :
C( B& b ) : myB( &b ) {}
private:
B* myB ;
} ;
La référence comme paramètre du constructeur dit bien que je ne
veux pas de pointeur nul. En revanche, le pointeur comme
attribute fait que je peux avoir un opérateur d'affectation.
(J'ai souvent ce genre de chose dans les objets fonctionnels
pour la STL. Dans ces cas-là, si la classe est définie dans
l'espace référentiel anonyme dans le fichier source, ce qui est
souvent le cas, j'utilise même l'opérateur d'affectation par
défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien
documenté que la classe ne supportait pas l'affectation, ou
qu'elle avait une sémantique d'affectation particulière. Sinon,
je dirais que c'est simplement une erreur.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quelqu'un peut il me dire si il est choquant d'avoir un référence en tant qu'attribut.
e.g.
class B;
class A { public: A( B& b ) : _b( b ) {}; ~A() {};
...
private: B &_b; }
Perso j'aime pas trop, mais j'ai certains collégues qui utilisent ça sans sourciller, j'aimerais des arguments clairs justifiant s'il s'agit d'une bonne manière ou d'une mauvaise habitude.
Comme souvent, tout dépend. Je m'en sers volentier dans des classes entité, qui ne supporte ni la copie, ni surtout l'affectation. En revanche, je l'évite dans les classes de valeur, ou les agents pour la STL (genre Predicate, BinOp, etc.). Précisement parce qu'avec une référence, on a un petit problème à définir l'affectation. Il y a des exceptions, évidemment, où l'attribute implémentée par la référence n'entre pas en ligne de compte dans l'affectation, mais elles ne sont pas particulièrement fréquentes. Dans de tels cas, j'ai souvent quelque chose du genre :
class C { public : C( B& b ) : myB( &b ) {}
private: B* myB ; } ;
La référence comme paramètre du constructeur dit bien que je ne veux pas de pointeur nul. En revanche, le pointeur comme attribute fait que je peux avoir un opérateur d'affectation. (J'ai souvent ce genre de chose dans les objets fonctionnels pour la STL. Dans ces cas-là, si la classe est définie dans l'espace référentiel anonyme dans le fichier source, ce qui est souvent le cas, j'utilise même l'opérateur d'affectation par défaut que me donne le compilateur.)
Je suppose que quand vos collègues s'en sont servi, ils ont bien documenté que la classe ne supportait pas l'affectation, ou qu'elle avait une sémantique d'affectation particulière. Sinon, je dirais que c'est simplement une erreur.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
merci pour votre réponse ;)
James Kanze
wrote:
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les objets qui implémentent l'idiome RAII (les "lockers" sur un mutex ou une section critique, les "libérateurs de ressources" de tout poil, etc...) ont généralement une référence sur la ressource qu'ils doivent libérer dans leur destructeur.
Tout à fait. Comme ils ont tous aussi des constructeurs de copie et les opérateurs d'affectation privés.
Comme j'ai expliqué dans une autre réponse, tout dépend de l'objet. La clé, c'est si l'objet doit ou non supporter l'affectation ; l'implémentation de l'affectation quand il y a des références n'est pas sans problèmes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
adebaene@club-internet.fr wrote:
Comment se fait-il alors qu'on ne retrouve jamais ce genre
d'utilisation des références dans la littérature, y a t'il une
explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les
objets qui implémentent l'idiome RAII (les "lockers" sur un
mutex ou une section critique, les "libérateurs de ressources"
de tout poil, etc...) ont généralement une référence sur la
ressource qu'ils doivent libérer dans leur destructeur.
Tout à fait. Comme ils ont tous aussi des constructeurs de copie
et les opérateurs d'affectation privés.
Comme j'ai expliqué dans une autre réponse, tout dépend de
l'objet. La clé, c'est si l'objet doit ou non supporter
l'affectation ; l'implémentation de l'affectation quand il y a
des références n'est pas sans problèmes.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Comment se fait-il alors qu'on ne retrouve jamais ce genre d'utilisation des références dans la littérature, y a t'il une explication à cela?
Ben, moi je le vois régulièrement... Par exemple tous les objets qui implémentent l'idiome RAII (les "lockers" sur un mutex ou une section critique, les "libérateurs de ressources" de tout poil, etc...) ont généralement une référence sur la ressource qu'ils doivent libérer dans leur destructeur.
Tout à fait. Comme ils ont tous aussi des constructeurs de copie et les opérateurs d'affectation privés.
Comme j'ai expliqué dans une autre réponse, tout dépend de l'objet. La clé, c'est si l'objet doit ou non supporter l'affectation ; l'implémentation de l'affectation quand il y a des références n'est pas sans problèmes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
