struct B : public A
{
virtual const std::string f(int x) const { return "titi"; } // l.13
};
int main()
{
B b;
std::cout << b.f() << std::endl; // l.20
}
L'erreur affichée est :
a.cpp: In function `int main()':
a.cpp:20: error: no matching function for call to `B::f()'
a.cpp:13: note: candidates are: virtual const std::string B::f(int) const
Y'aurait-il un bug dans mon compilateur (g++ version 3.4) ou bien ce
comportement est-il normal ? (auquel cas je ne vois vraiment pas ce qui
pose problème.)
Comment contourner le problème (c'est-à-dire, comment permettre l'appel
de "f" sans paramètres, sans renommer la fonction) ?
Vincent
--
vmime, une bibliothèque C++ sous licence GPL pour parser et générer
des messages au format MIME : http://www.sourceforge.net/projects/vmime/
Le fait d'utiliser "struct" plutôt que "class" est-il normal ?
L'unique différence entre les deux mots-clef est que la protection est par défaut à « public » dans une structure, et à « private » dans une classe.
Personnellement, j'utilise « struct » lorsque je déclare une petite classe utilitaire dont le but est principalement de regrouper quelques valeurs, sans réellement fournir d'autres choses. Par exemple :
class A { struct Point3D { int x ; int y ; int z ; } ;
Le fait d'utiliser "struct" plutôt que "class" est-il normal ?
L'unique différence entre les deux mots-clef est que la protection
est par défaut à « public » dans une structure, et à « private » dans
une classe.
Personnellement, j'utilise « struct » lorsque je déclare une petite
classe utilitaire dont le but est principalement de regrouper quelques
valeurs, sans réellement fournir d'autres choses. Par exemple :
class A
{
struct Point3D
{
int x ;
int y ;
int z ;
} ;
Le fait d'utiliser "struct" plutôt que "class" est-il normal ?
L'unique différence entre les deux mots-clef est que la protection est par défaut à « public » dans une structure, et à « private » dans une classe.
Personnellement, j'utilise « struct » lorsque je déclare une petite classe utilitaire dont le but est principalement de regrouper quelques valeurs, sans réellement fournir d'autres choses. Par exemple :
class A { struct Point3D { int x ; int y ; int z ; } ;
// ... } ;
--drkm
Alexandre
Oui. La différence entre « class » et « struct » relève simplement du sucre syntaxique. Mais dans les années '80, cela était peut-être psychologiquement nécessaire pour montrer aux gens qu'il y a quelque chose de plus que juste du C.
Une petite différence : si tu veux que tous les membres soient publics, ça va plus vite ;-)
-- Gaby
Oui. La différence entre « class » et « struct » relève simplement du
sucre syntaxique. Mais dans les années '80, cela était peut-être
psychologiquement nécessaire pour montrer aux gens qu'il y a quelque
chose de plus que juste du C.
Une petite différence : si tu veux que tous les membres soient publics, ça
va plus vite ;-)
Oui. La différence entre « class » et « struct » relève simplement du sucre syntaxique. Mais dans les années '80, cela était peut-être psychologiquement nécessaire pour montrer aux gens qu'il y a quelque chose de plus que juste du C.
Une petite différence : si tu veux que tous les membres soient publics, ça va plus vite ;-)
-- Gaby
James Kanze
Gabriel Dos Reis writes:
|> drkm writes:
|> [...]
|> | Personnellement, j'utilise « struct » lorsque je |> | déclare une petite classe utilitaire dont le but est |> | principalement de regrouper quelques valeurs, sans réellement |> | fournir d'autres choses. Par exemple :
|> Il y a quelques années, je suis devenu très paresseux et |> j'écris presque instinctivement « struct foo : bar » au |> lieu de « class foo : public bar » (vu que la plupart de mes |> dérivations sont publiques) et j'ai été « surpris » |> de voir que mon boss actuel fait pareil dans ses codes récents |> que j'ai pu lire.
Dans quels contextes ? Moi, je fais pareil quand il s'agit d'écrire des petits bouts de code pour discuter une question de langage. Dans de tels cas, tout texte qui ne touche pas directement au problème visé est du bruit.
Quand j'écris du code de production, en revanche, je m'aligne aux habitudes courantes dans la boîte où je me trouve. Jusqu'ici, ça voulait dire n'utiliser « struct » que dans le cas où tous les membres données étaient publics.
|> Aussi, je mets systématiquement les membres publiques avant les |> membres protectés et avant les membres privés. Ainsi, j'ai
|> struct Overload_impl : Expr_impl<Overload> { |> // master declaration for the subscripting type. |> const Decl& operator[](const Type&) const;
|> // number of master declarations in this overload-set |> std::size_t size() const;
|> Overload_impl(const Overload_impl&); // not implemented |> Overload_impl& operator=(const Overload_impl&); // not implemented |> };
Tout à fait. Le seul problème que je vois, c'est le message que ça donne à trop de gens.
-- James Kanze 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> drkm <usenet.fclcxx@fgeorges.org> writes:
|> [...]
|> | Personnellement, j'utilise « struct » lorsque je
|> | déclare une petite classe utilitaire dont le but est
|> | principalement de regrouper quelques valeurs, sans réellement
|> | fournir d'autres choses. Par exemple :
|> Il y a quelques années, je suis devenu très paresseux et
|> j'écris presque instinctivement « struct foo : bar » au
|> lieu de « class foo : public bar » (vu que la plupart de mes
|> dérivations sont publiques) et j'ai été « surpris »
|> de voir que mon boss actuel fait pareil dans ses codes récents
|> que j'ai pu lire.
Dans quels contextes ? Moi, je fais pareil quand il s'agit d'écrire
des petits bouts de code pour discuter une question de langage. Dans de
tels cas, tout texte qui ne touche pas directement au problème
visé est du bruit.
Quand j'écris du code de production, en revanche, je m'aligne aux
habitudes courantes dans la boîte où je me trouve. Jusqu'ici,
ça voulait dire n'utiliser « struct » que dans le cas où
tous les membres données étaient publics.
|> Aussi, je mets systématiquement les membres publiques avant les
|> membres protectés et avant les membres privés. Ainsi, j'ai
|> struct Overload_impl : Expr_impl<Overload> {
|> // master declaration for the subscripting type.
|> const Decl& operator[](const Type&) const;
|> // number of master declarations in this overload-set
|> std::size_t size() const;
|> Overload_impl(const Overload_impl&); // not implemented
|> Overload_impl& operator=(const Overload_impl&); // not implemented
|> };
Tout à fait. Le seul problème que je vois, c'est le message que
ça donne à trop de gens.
--
James Kanze
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
|> | Personnellement, j'utilise « struct » lorsque je |> | déclare une petite classe utilitaire dont le but est |> | principalement de regrouper quelques valeurs, sans réellement |> | fournir d'autres choses. Par exemple :
|> Il y a quelques années, je suis devenu très paresseux et |> j'écris presque instinctivement « struct foo : bar » au |> lieu de « class foo : public bar » (vu que la plupart de mes |> dérivations sont publiques) et j'ai été « surpris » |> de voir que mon boss actuel fait pareil dans ses codes récents |> que j'ai pu lire.
Dans quels contextes ? Moi, je fais pareil quand il s'agit d'écrire des petits bouts de code pour discuter une question de langage. Dans de tels cas, tout texte qui ne touche pas directement au problème visé est du bruit.
Quand j'écris du code de production, en revanche, je m'aligne aux habitudes courantes dans la boîte où je me trouve. Jusqu'ici, ça voulait dire n'utiliser « struct » que dans le cas où tous les membres données étaient publics.
|> Aussi, je mets systématiquement les membres publiques avant les |> membres protectés et avant les membres privés. Ainsi, j'ai
|> struct Overload_impl : Expr_impl<Overload> { |> // master declaration for the subscripting type. |> const Decl& operator[](const Type&) const;
|> // number of master declarations in this overload-set |> std::size_t size() const;
|> Overload_impl(const Overload_impl&); // not implemented |> Overload_impl& operator=(const Overload_impl&); // not implemented |> };
Tout à fait. Le seul problème que je vois, c'est le message que ça donne à trop de gens.
-- James Kanze 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
James Kanze
Gabriel Dos Reis writes:
|> Oui. La différence entre « class » et « struct » |> relève simplement du sucre syntaxique. Mais dans les années |> '80, cela était peut-être psychologiquement nécessaire pour |> montrer aux gens qu'il y a quelque chose de plus que juste du C.
Et dans les années 2000, il faut prendre en compte tous ceux qui ont appris le C++ dans les années 80 ou les années 90, et les attentes qu'ils font à struct.
AMHA, c'est un peu comme la lutte de Francis pour utiliser and à la place de &&. Sans la passée, on pouvait en discuter, mais au point où on est, le jeu ne vaut plus la chandelle.
-- James Kanze 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> Oui. La différence entre « class » et « struct »
|> relève simplement du sucre syntaxique. Mais dans les années
|> '80, cela était peut-être psychologiquement nécessaire pour
|> montrer aux gens qu'il y a quelque chose de plus que juste du C.
Et dans les années 2000, il faut prendre en compte tous ceux qui ont
appris le C++ dans les années 80 ou les années 90, et les attentes
qu'ils font à struct.
AMHA, c'est un peu comme la lutte de Francis pour utiliser and à la
place de &&. Sans la passée, on pouvait en discuter, mais au point
où on est, le jeu ne vaut plus la chandelle.
--
James Kanze
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
|> Oui. La différence entre « class » et « struct » |> relève simplement du sucre syntaxique. Mais dans les années |> '80, cela était peut-être psychologiquement nécessaire pour |> montrer aux gens qu'il y a quelque chose de plus que juste du C.
Et dans les années 2000, il faut prendre en compte tous ceux qui ont appris le C++ dans les années 80 ou les années 90, et les attentes qu'ils font à struct.
AMHA, c'est un peu comme la lutte de Francis pour utiliser and à la place de &&. Sans la passée, on pouvait en discuter, mais au point où on est, le jeu ne vaut plus la chandelle.
-- James Kanze 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
Gabriel Dos Reis
James Kanze writes:
[...]
| Tout à fait. Le seul problème que je vois, c'est le message que | ça donne à trop de gens.
Pour le moment, « nos clients » comprennent le message :-)
-- Gaby
James Kanze <kanze@gabi-soft.fr> writes:
[...]
| Tout à fait. Le seul problème que je vois, c'est le message que
| ça donne à trop de gens.
Pour le moment, « nos clients » comprennent le message :-)
| Tout à fait. Le seul problème que je vois, c'est le message que | ça donne à trop de gens.
Pour le moment, « nos clients » comprennent le message :-)
-- Gaby
James Kanze
Gabriel Dos Reis writes:
|> James Kanze writes:
|> [...]
|> | Tout à fait. Le seul problème que je vois, c'est le message |> | que ça donne à trop de gens.
|> Pour le moment, « nos clients » comprennent le message :-)
J'apprécie l'émoticon:-).
Et je te donne tout à fait raison. Tout dépend du clientèle auquel tu t'adresses.
-- James Kanze 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
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|> James Kanze <kanze@gabi-soft.fr> writes:
|> [...]
|> | Tout à fait. Le seul problème que je vois, c'est le message
|> | que ça donne à trop de gens.
|> Pour le moment, « nos clients » comprennent le message :-)
J'apprécie l'émoticon:-).
Et je te donne tout à fait raison. Tout dépend du clientèle
auquel tu t'adresses.
--
James Kanze
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
|> | Tout à fait. Le seul problème que je vois, c'est le message |> | que ça donne à trop de gens.
|> Pour le moment, « nos clients » comprennent le message :-)
J'apprécie l'émoticon:-).
Et je te donne tout à fait raison. Tout dépend du clientèle auquel tu t'adresses.
-- James Kanze 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
