Le compilateur génére automatiquement certains opérateurs par défaut
pour les classes qui ne le font pas automatiquement.
Sauf erreur de ma part, il s'agit de:
- constructeur par défaut (Classe::Classe())
- constructeur de recopie (Classe::Classe(const Class&))
- affectation (Classe::operator = (const Classe&))
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par
exemple) de comparaison (==)?
L'implémentation naturelle serait de considérer ses attributs un à un,
tout comme pour la recopie.
Y a-t'il une raison?
Le compilateur génére automatiquement certains opérateurs par défaut pour les classes qui ne le font pas automatiquement. Sauf erreur de ma part, il s'agit de: - constructeur par défaut (Classe::Classe()) - constructeur de recopie (Classe::Classe(const Class&)) - affectation (Classe::operator = (const Classe&))
Et le destructeur.
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C. En général, l'effet d'avoir les opérateurs par défaut, c'est de faire qu'on n'a pas d'erreur de compilation quand on oublie de les définir, même si (comme c'est le cas le plus souvent) il ne font pas ce qu'il faut.
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Y a-t'il une raison?
Comme j'ai dis : il n'était pas nécessaire.
-- 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
Olivier Croquette wrote:
Le compilateur génére automatiquement certains opérateurs par
défaut pour les classes qui ne le font pas automatiquement.
Sauf erreur de ma part, il s'agit de:
- constructeur par défaut (Classe::Classe())
- constructeur de recopie (Classe::Classe(const Class&))
- affectation (Classe::operator = (const Classe&))
Et le destructeur.
Pourquoi n'est-il pas prévu qu'il fasse de même pour
l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de
compatibilité C. En général, l'effet d'avoir les opérateurs par
défaut, c'est de faire qu'on n'a pas d'erreur de compilation
quand on oublie de les définir, même si (comme c'est le cas le
plus souvent) il ne font pas ce qu'il faut.
L'implémentation naturelle serait de considérer ses attributs
un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un
pointeur.
Y a-t'il une raison?
Comme j'ai dis : il n'était pas nécessaire.
--
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
Le compilateur génére automatiquement certains opérateurs par défaut pour les classes qui ne le font pas automatiquement. Sauf erreur de ma part, il s'agit de: - constructeur par défaut (Classe::Classe()) - constructeur de recopie (Classe::Classe(const Class&)) - affectation (Classe::operator = (const Classe&))
Et le destructeur.
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C. En général, l'effet d'avoir les opérateurs par défaut, c'est de faire qu'on n'a pas d'erreur de compilation quand on oublie de les définir, même si (comme c'est le cas le plus souvent) il ne font pas ce qu'il faut.
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Y a-t'il une raison?
Comme j'ai dis : il n'était pas nécessaire.
-- 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
Olivier Croquette
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il est bien là par défaut. Cette raison ne saurait donc suffire.
Copie sur fclc et suivi sur fclc++.
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour
l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de
compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu
veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme
ne permet pas de comparer des structures comme il est possible de faire
des affectations?
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs
un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un
pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il est bien là
par défaut. Cette raison ne saurait donc suffire.
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il est bien là par défaut. Cette raison ne saurait donc suffire.
Copie sur fclc et suivi sur fclc++.
Franck Branjonneau
Olivier Croquette écrivait:
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
Non. Que les fonctions membres définies par le compilateur suffisent à assurer la compatibilité "ascendante" avec le C.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Pourquoi n'est-il pas prévu qu'il fasse de même pour
l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de
compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu
veux dire que le fournir aurait conduit à une incompatibilité avec le
C?
Non. Que les fonctions membres définies par le compilateur suffisent à
assurer la compatibilité "ascendante" avec le C.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme
ne permet pas de comparer des structures comme il est possible de
faire des affectations?
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
Non. Que les fonctions membres définies par le compilateur suffisent à assurer la compatibilité "ascendante" avec le C.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Elle le permet, *à ta discrétion*.
-- Franck Branjonneau
James Kanze
Olivier Croquette wrote:
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
Pas forcement. Mais que les opérateurs qui sont fourni par défaut sont nécessaire pour des raisons de compatabilité avec le C. En C, je peux affecter des struct, par exemple.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si on va implémenter ==, pourquoi pas > aussi. Voire même +.
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il est bien là par défaut. Cette raison ne saurait donc suffire.
Oui, mais dans le cas de l'opérateur d'affectation, on n'avait pas le choix. Pour des raisons de compatabilité C.
-- James Kanze (Gabi Software) email: 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
Olivier Croquette wrote:
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour
l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de
compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu
veux dire que le fournir aurait conduit à une incompatibilité avec le C?
Pas forcement. Mais que les opérateurs qui sont fourni par
défaut sont nécessaire pour des raisons de compatabilité avec le
C. En C, je peux affecter des struct, par exemple.
En tout cas ma question est valable pour le C aussi. Pourquoi
la norme ne permet pas de comparer des structures comme il est
possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si
on va implémenter ==, pourquoi pas > aussi. Voire même +.
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs
un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un
pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il
est bien là par défaut. Cette raison ne saurait donc suffire.
Oui, mais dans le cas de l'opérateur d'affectation, on n'avait
pas le choix. Pour des raisons de compatabilité C.
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
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
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
Pas forcement. Mais que les opérateurs qui sont fourni par défaut sont nécessaire pour des raisons de compatabilité avec le C. En C, je peux affecter des struct, par exemple.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si on va implémenter ==, pourquoi pas > aussi. Voire même +.
(voir aussi 6.5 de http://www.faqs.org/faqs/fr/comp/lang/faq-c-2/)
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
Ce qui est le cas de l'opérateur d'affectation, pourtant il est bien là par défaut. Cette raison ne saurait donc suffire.
Oui, mais dans le cas de l'opérateur d'affectation, on n'avait pas le choix. Pour des raisons de compatabilité C.
-- James Kanze (Gabi Software) email: 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
Olivier Croquette
Question corollaire à la discussion:
Existe-t'il un moyen de comparer des structures aux membres simples autre que la comparaison membre à membre?
J'ai une solution en tête:
Vu que le bourrage (padding) peut faire échouer une comparaison alors que les membres sont bien égaux, je me demande si on ne peut pas initialiser à 0 *chaque* structure:
Et enfin les comparer: memcmp((void *) &s1, (void *)&s2, sizeof(s));
Questions: - est-ce assuré de marcher? - est-ce que ça marchera en pratique courantes? Sinon sur quelles plate-formes?
Question corollaire à la discussion:
Existe-t'il un moyen de comparer des structures aux membres simples
autre que la comparaison membre à membre?
J'ai une solution en tête:
Vu que le bourrage (padding) peut faire échouer une comparaison alors
que les membres sont bien égaux, je me demande si on ne peut pas
initialiser à 0 *chaque* structure:
Existe-t'il un moyen de comparer des structures aux membres simples autre que la comparaison membre à membre?
J'ai une solution en tête:
Vu que le bourrage (padding) peut faire échouer une comparaison alors que les membres sont bien égaux, je me demande si on ne peut pas initialiser à 0 *chaque* structure:
Et enfin les comparer: memcmp((void *) &s1, (void *)&s2, sizeof(s));
Questions: - est-ce assuré de marcher? - est-ce que ça marchera en pratique courantes? Sinon sur quelles plate-formes?
Sylvain
James Kanze wrote on 02/09/2006 18:31:
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si on va implémenter ==, pourquoi pas > aussi. Voire même +.
"==" est univoque alors qu'une relation d'ordre sur N champs ou de l'algèbre nécessite une définition de (quasi) groupe.
"==" pourrait être implicite avec un (par exemple): typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
recopier un pointeur (sans ref. counting, etc) est un mauvais effet de bord, comparer des adresses est bien ce que l'on attend de "==".
Sylvain.
James Kanze wrote on 02/09/2006 18:31:
En tout cas ma question est valable pour le C aussi. Pourquoi
la norme ne permet pas de comparer des structures comme il est
possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si
on va implémenter ==, pourquoi pas > aussi. Voire même +.
"==" est univoque alors qu'une relation d'ordre sur N champs ou de
l'algèbre nécessite une définition de (quasi) groupe.
"==" pourrait être implicite avec un (par exemple):
typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
L'implémentation naturelle serait de considérer ses attributs
un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un
pointeur.
recopier un pointeur (sans ref. counting, etc) est un mauvais effet de
bord, comparer des adresses est bien ce que l'on attend de "==".
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Probablement parce qu'on n'en a pas vu l'intérêt. Après tout, si on va implémenter ==, pourquoi pas > aussi. Voire même +.
"==" est univoque alors qu'une relation d'ordre sur N champs ou de l'algèbre nécessite une définition de (quasi) groupe.
"==" pourrait être implicite avec un (par exemple): typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
L'implémentation naturelle serait de considérer ses attributs un à un, tout comme pour la recopie.
C-à-d qu'ils aient une mauvaise sémantique dès qu'il y a un pointeur.
recopier un pointeur (sans ref. counting, etc) est un mauvais effet de bord, comparer des adresses est bien ce que l'on attend de "==".
Sylvain.
Franck Branjonneau
Cyrille écrivait:
Pourtant, pour des classes ou des structures avec que des membres simples, il est un peu idiot de devoir définir manuellement des fonctions ou méthodes qui font membre à membre la recopie ou la comparaison.
[...]
Je ne voudrais pas prendre mon cas pour une généralité, mais dans les projets que j'ai fait pour l'instant j'ai beaucoup plus de classes qui dérivent de boost::noncopyable que de classes pour lesquelles j'ai du écrire un opérateur d'égalité. Et si je peux oublier de mettre des classes en noncopyable alors qu'elles le devraient, je me rend compte assez vite qu'un opérateur d'égalité est manquant.
Je suis d'accord avec Cyrille, j'ajouterais que certains objets sont comparables de différentes manières.
A problème simple, devrait correspondre une solution simple et élégante.
Le conditionnel est de rigueur : de nombreux problèmes NP-difficiles sont simples... Quand à l'élégance, c'est une utopie.
-- Franck Branjonneau
Cyrille <cyrille@frsf.invalid> écrivait:
Pourtant, pour des classes ou des structures avec que des membres
simples, il est un peu idiot de devoir définir manuellement des
fonctions ou méthodes qui font membre à membre la recopie ou la
comparaison.
[...]
Je ne voudrais pas prendre mon cas pour une généralité, mais dans les
projets que j'ai fait pour l'instant j'ai beaucoup plus de classes qui
dérivent de boost::noncopyable que de classes pour lesquelles j'ai du
écrire un opérateur d'égalité. Et si je peux oublier de mettre des
classes en noncopyable alors qu'elles le devraient, je me rend compte
assez vite qu'un opérateur d'égalité est manquant.
Je suis d'accord avec Cyrille, j'ajouterais que certains objets sont
comparables de différentes manières.
A problème simple, devrait correspondre une solution simple et
élégante.
Le conditionnel est de rigueur : de nombreux problèmes NP-difficiles
sont simples... Quand à l'élégance, c'est une utopie.
Pourtant, pour des classes ou des structures avec que des membres simples, il est un peu idiot de devoir définir manuellement des fonctions ou méthodes qui font membre à membre la recopie ou la comparaison.
[...]
Je ne voudrais pas prendre mon cas pour une généralité, mais dans les projets que j'ai fait pour l'instant j'ai beaucoup plus de classes qui dérivent de boost::noncopyable que de classes pour lesquelles j'ai du écrire un opérateur d'égalité. Et si je peux oublier de mettre des classes en noncopyable alors qu'elles le devraient, je me rend compte assez vite qu'un opérateur d'égalité est manquant.
Je suis d'accord avec Cyrille, j'ajouterais que certains objets sont comparables de différentes manières.
A problème simple, devrait correspondre une solution simple et élégante.
Le conditionnel est de rigueur : de nombreux problèmes NP-difficiles sont simples... Quand à l'élégance, c'est une utopie.
-- Franck Branjonneau
Franck Branjonneau
Olivier Croquette écrivait:
Franck Branjonneau wrote:
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Elle le permet, *à ta discrétion*.
Entends-tu par là: *manuellement*?
Avec du code ad hoc, écrit à la main ou autrement.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme
ne permet pas de comparer des structures comme il est possible de
faire des affectations?
Elle le permet, *à ta discrétion*.
Entends-tu par là: *manuellement*?
Avec du code ad hoc, écrit à la main ou autrement.
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
Elle le permet, *à ta discrétion*.
Entends-tu par là: *manuellement*?
Avec du code ad hoc, écrit à la main ou autrement.
-- Franck Branjonneau
Fabien LE LEZ
On Thu, 31 Aug 2006 19:41:08 +0200, Olivier Croquette :
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui permettrait, dans une classe "simple" comme
struct C { int x; std::string machin; double truc; };
de pouvoir déclarer, simplement mais explicitement, un constructeur
et des opérateurs == et != qui comparent membre à membre.
Mais de toutes façons, ça ne doit pas être implicite.
On Thu, 31 Aug 2006 19:41:08 +0200, Olivier Croquette
<ocroquette@ocroquette.free.fr>:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par
exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en
résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on
n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui
permettrait, dans une classe "simple" comme
struct C
{
int x;
std::string machin;
double truc;
};
de pouvoir déclarer, simplement mais explicitement, un constructeur
On Thu, 31 Aug 2006 19:41:08 +0200, Olivier Croquette :
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui permettrait, dans une classe "simple" comme
struct C { int x; std::string machin; double truc; };
de pouvoir déclarer, simplement mais explicitement, un constructeur
et des opérateurs == et != qui comparent membre à membre.
Mais de toutes façons, ça ne doit pas être implicite.
Sylvain
Fabien LE LEZ wrote on 02/09/2006 21:32:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
"plus de problèmes" parce qu'il existerait qlq exceptions ?!? j'ai du mal à suivre !
s'il ne correspond pas, on le (re)définit (localement), n'est-ce pas le propre d'un langage objet ? quant à savoir si "on" en a besoin ou pas, je ne connais pas ce monsieur et pour ma part je ne me tire pas des balles dans le pied (ni le code).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui permettrait, dans une classe "simple" comme [...] de pouvoir déclarer, simplement mais explicitement, un constructeur
"explicitement" tu peux déjà écrire C::C (int x_, std::string const& machin_, double truc_) c'est un peu plus court et strictement équivalent.
Mais de toutes façons, ça ne doit pas être implicite.
tu veux dire: "il est évident" que ça ne doit pas être implicite?
Sylvain.
Fabien LE LEZ wrote on 02/09/2006 21:32:
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par
exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en
résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on
n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
"plus de problèmes" parce qu'il existerait qlq exceptions ?!? j'ai du
mal à suivre !
s'il ne correspond pas, on le (re)définit (localement), n'est-ce pas le
propre d'un langage objet ?
quant à savoir si "on" en a besoin ou pas, je ne connais pas ce monsieur
et pour ma part je ne me tire pas des balles dans le pied (ni le code).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui
permettrait, dans une classe "simple" comme
[...]
de pouvoir déclarer, simplement mais explicitement, un constructeur
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Un opérateur == par défaut apporterait plus de problèmes qu'il n'en résoudrait. En effet, à chaque fois qu'il ne correspond pas, et qu'on n'en a pas besoin, il faudrait le déclarer privé (comme pour = ).
"plus de problèmes" parce qu'il existerait qlq exceptions ?!? j'ai du mal à suivre !
s'il ne correspond pas, on le (re)définit (localement), n'est-ce pas le propre d'un langage objet ? quant à savoir si "on" en a besoin ou pas, je ne connais pas ce monsieur et pour ma part je ne me tire pas des balles dans le pied (ni le code).
Par contre, ce qui serait bien, c'est un sucre syntaxique qui permettrait, dans une classe "simple" comme [...] de pouvoir déclarer, simplement mais explicitement, un constructeur
