j ai un petit probleme surement simpliste a resoudre ...
un code, que je ne peut pas toucher a un objet avec l operateur = en
private.
or un vieux code, qui marchait ecrivait : *toto=objet(valeur);
le complateur actuel indique : erreur - operator = private
Comment je peut reconduire elegement cete fonction ?
j ai un petit probleme surement simpliste a resoudre ...
un code, que je ne peut pas toucher a un objet avec l operateur = en
private.
or un vieux code, qui marchait ecrivait : *toto=objet(valeur);
le complateur actuel indique : erreur - operator = private
Comment je peut reconduire elegement cete fonction ?
j ai un petit probleme surement simpliste a resoudre ...
un code, que je ne peut pas toucher a un objet avec l operateur = en
private.
or un vieux code, qui marchait ecrivait : *toto=objet(valeur);
le complateur actuel indique : erreur - operator = private
Comment je peut reconduire elegement cete fonction ?
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Fabien Chêne wrote:
[...]Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
Fabien Chêne wrote:
[...]
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
Fabien Chêne wrote:
[...]Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
"James Kanze" writes:Fabien Chêne wrote:
[...]Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
Je répondrai au singulier GCC/g++ avec l'option -fno-access-control.
Mais j'imagine que cela doit bien exister pour d'autres compilateurs.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
"James Kanze" <james.kanze@gmail.com> writes:
Fabien Chêne wrote:
[...]
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
Je répondrai au singulier GCC/g++ avec l'option -fno-access-control.
Mais j'imagine que cela doit bien exister pour d'autres compilateurs.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
"James Kanze" writes:Fabien Chêne wrote:
[...]Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ».
Quels compilateurs ?
Je répondrai au singulier GCC/g++ avec l'option -fno-access-control.
Mais j'imagine que cela doit bien exister pour d'autres compilateurs.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moins.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ». Voir la documentation de ton compilateur.
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ». Voir la documentation de ton compilateur.
Des compilateurs proposent des options pour désactiver l'effet des
spécificateurs d'accès « protected et private » au profit de
« public ». Voir la documentation de ton compilateur.
"James Kanze" writes:La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moi ns.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
Je trouverais également conpréhensible la présence de cette option si
les bugs venaient d'autres compilateurs massivement utilisés -- je
serais quand même bien étonné que GCC/g++ soit le seul compilateur à
avoir eu un jour un bug sur les contrôles d'accès.
"James Kanze" <james.kanze@gmail.com> writes:
La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moi ns.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
Je trouverais également conpréhensible la présence de cette option si
les bugs venaient d'autres compilateurs massivement utilisés -- je
serais quand même bien étonné que GCC/g++ soit le seul compilateur à
avoir eu un jour un bug sur les contrôles d'accès.
"James Kanze" writes:La distinction public/private est à la base de C++ ; elle est plus
ancienne encore que l'héritage. Il existe bien des compilateurs qui
ne font pas la distinction, mais il ne supporte pas les fonctions
membres non plus (qui n'ont pas de sens sans cette distinction), et
on les appelle des compilateurs C.
la documentation de cette option indique que c'est utilisé pour
contourner des bugs sur les spécificateurs d'accès, ni plus ni moi ns.
Historiquement, g++ a eu des problèmes avec sa gestion de
contrôle d'accès -- de très anciennes versions permettaient
assez souvent des accès qui étaient intérdits. L'option est donc
sans doute motivée chez g++ par le désir de ne pas casser du
code (correct ou non) qui marchait avant. C'est compréhensible,
mais seulement chez g++, et seulement à cause des bugs dans
d'anciennes versions.
Je trouverais également conpréhensible la présence de cette option si
les bugs venaient d'autres compilateurs massivement utilisés -- je
serais quand même bien étonné que GCC/g++ soit le seul compilateur à
avoir eu un jour un bug sur les contrôles d'accès.
(Fabien Chêne) writes:
| "James Kanze" writes:
| >> > La distinction public/private est à la base de C++ ; elle est pl us
| >> > ancienne encore que l'héritage. Il existe bien des compilateurs qui
| >> > ne font pas la distinction, mais il ne supporte pas les fonctions
| >> > membres non plus (qui n'ont pas de sens sans cette distinction), et
| >> > on les appelle des compilateurs C.
| >> la documentation de cette option indique que c'est utilisé pour
| >> contourner des bugs sur les spécificateurs d'accès, ni plus ni m oins.
| > Historiquement, g++ a eu des problèmes avec sa gestion de
| > contrôle d'accès -- de très anciennes versions permettaient
| > assez souvent des accès qui étaient intérdits. L'option est donc
| > sans doute motivée chez g++ par le désir de ne pas casser du
| > code (correct ou non) qui marchait avant. C'est compréhensible,
| > mais seulement chez g++, et seulement à cause des bugs dans
| > d'anciennes versions.
| Je trouverais également conpréhensible la présence de cette optio n si
| les bugs venaient d'autres compilateurs massivement utilisés -- je
| serais quand même bien étonné que GCC/g++ soit le seul compilateu r à
| avoir eu un jour un bug sur les contrôles d'accès.
La question n'est pas si aucun autre compilateur n'a pas eu de bugs en
ce qui concerne les contrôles d'accès.
Il serait interessant de calculer l'intersection des bugs des
compilateurs en matière de contrôle d'accès.
Je ne crois pas qu'il soit possible de comprendre GCC et ses options
juste en un prenant un cliché à un instant t fixé.
GCC est un logiciel en perpétuelle évolution (c'est ce qui arrive à la
plupart des logiciels qui ont du succès) et l'ensemble de ses
développeurs est également en perpétuelle évolution. Il en reste des
situations qu'on ne peut comprendre qu'à travers l'histoire.
fabien.chene@gmail.com (Fabien Chêne) writes:
| "James Kanze" <james.kanze@gmail.com> writes:
| >> > La distinction public/private est à la base de C++ ; elle est pl us
| >> > ancienne encore que l'héritage. Il existe bien des compilateurs qui
| >> > ne font pas la distinction, mais il ne supporte pas les fonctions
| >> > membres non plus (qui n'ont pas de sens sans cette distinction), et
| >> > on les appelle des compilateurs C.
| >> la documentation de cette option indique que c'est utilisé pour
| >> contourner des bugs sur les spécificateurs d'accès, ni plus ni m oins.
| > Historiquement, g++ a eu des problèmes avec sa gestion de
| > contrôle d'accès -- de très anciennes versions permettaient
| > assez souvent des accès qui étaient intérdits. L'option est donc
| > sans doute motivée chez g++ par le désir de ne pas casser du
| > code (correct ou non) qui marchait avant. C'est compréhensible,
| > mais seulement chez g++, et seulement à cause des bugs dans
| > d'anciennes versions.
| Je trouverais également conpréhensible la présence de cette optio n si
| les bugs venaient d'autres compilateurs massivement utilisés -- je
| serais quand même bien étonné que GCC/g++ soit le seul compilateu r à
| avoir eu un jour un bug sur les contrôles d'accès.
La question n'est pas si aucun autre compilateur n'a pas eu de bugs en
ce qui concerne les contrôles d'accès.
Il serait interessant de calculer l'intersection des bugs des
compilateurs en matière de contrôle d'accès.
Je ne crois pas qu'il soit possible de comprendre GCC et ses options
juste en un prenant un cliché à un instant t fixé.
GCC est un logiciel en perpétuelle évolution (c'est ce qui arrive à la
plupart des logiciels qui ont du succès) et l'ensemble de ses
développeurs est également en perpétuelle évolution. Il en reste des
situations qu'on ne peut comprendre qu'à travers l'histoire.
(Fabien Chêne) writes:
| "James Kanze" writes:
| >> > La distinction public/private est à la base de C++ ; elle est pl us
| >> > ancienne encore que l'héritage. Il existe bien des compilateurs qui
| >> > ne font pas la distinction, mais il ne supporte pas les fonctions
| >> > membres non plus (qui n'ont pas de sens sans cette distinction), et
| >> > on les appelle des compilateurs C.
| >> la documentation de cette option indique que c'est utilisé pour
| >> contourner des bugs sur les spécificateurs d'accès, ni plus ni m oins.
| > Historiquement, g++ a eu des problèmes avec sa gestion de
| > contrôle d'accès -- de très anciennes versions permettaient
| > assez souvent des accès qui étaient intérdits. L'option est donc
| > sans doute motivée chez g++ par le désir de ne pas casser du
| > code (correct ou non) qui marchait avant. C'est compréhensible,
| > mais seulement chez g++, et seulement à cause des bugs dans
| > d'anciennes versions.
| Je trouverais également conpréhensible la présence de cette optio n si
| les bugs venaient d'autres compilateurs massivement utilisés -- je
| serais quand même bien étonné que GCC/g++ soit le seul compilateu r à
| avoir eu un jour un bug sur les contrôles d'accès.
La question n'est pas si aucun autre compilateur n'a pas eu de bugs en
ce qui concerne les contrôles d'accès.
Il serait interessant de calculer l'intersection des bugs des
compilateurs en matière de contrôle d'accès.
Je ne crois pas qu'il soit possible de comprendre GCC et ses options
juste en un prenant un cliché à un instant t fixé.
GCC est un logiciel en perpétuelle évolution (c'est ce qui arrive à la
plupart des logiciels qui ont du succès) et l'ensemble de ses
développeurs est également en perpétuelle évolution. Il en reste des
situations qu'on ne peut comprendre qu'à travers l'histoire.
