Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
Maintenant pour optimiser, on décide d'ajouter un bool
Maintenant pour optimiser, on décide d'ajouter un bool
Maintenant pour optimiser, on décide d'ajouter un bool
Bonjour les amis :-)
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais
vraiment eu de cas réels où il m'aurait été utile. Par
conséquent, le cas qui suit, très simple, me laisse perplexe
et je me demande s'il y a un autre moyen...
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
class Données
{
public :
Données(); // Récupère les données d'un fichier
void ModifierLesDonnées(); // Et autres fonctions de modif.
void Afficher() const; // Et autres de consultation
void Enregistrer() const; // Enregistre dans le fichier
~Données()
{
Enregistrer();
// Et d'autres opérations probablement
}
// ...
};
Les clients peuvent appeler Enregistrer() s'ils ne veulent pas
attendre l'enregistrement fait par la destruction.
Maintenant pour optimiser, on décide d'ajouter un bool, genre
« estModifié » qui sera mis à false au départ, mais mis à true
par les fonctions de modification. On voudra alors faire :
void Données::Enregistrer() const
{
if ( ! estModifié)
return;
// ... Le code pour l'enregistrement
estModifié= false;
}
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Ceci dit, ça me paraît difficile de croire que ce cas
n'arrivait à personne avant que l'on invente mutable, alors je
me demande s'il y a une autre solution, moins « C++ très
moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je
n'avais pas tendance à enseigner mutable aux débutants (de
peur qu'ils en abusent), mais là, je me pose la question...
Dois-je attendre au chapitre 17 de mon livre (le dernier)
avant de parler de mutable, si mes exemples tout simples
semblent parfois l'exiger ?
Bonjour les amis :-)
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais
vraiment eu de cas réels où il m'aurait été utile. Par
conséquent, le cas qui suit, très simple, me laisse perplexe
et je me demande s'il y a un autre moyen...
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
class Données
{
public :
Données(); // Récupère les données d'un fichier
void ModifierLesDonnées(); // Et autres fonctions de modif.
void Afficher() const; // Et autres de consultation
void Enregistrer() const; // Enregistre dans le fichier
~Données()
{
Enregistrer();
// Et d'autres opérations probablement
}
// ...
};
Les clients peuvent appeler Enregistrer() s'ils ne veulent pas
attendre l'enregistrement fait par la destruction.
Maintenant pour optimiser, on décide d'ajouter un bool, genre
« estModifié » qui sera mis à false au départ, mais mis à true
par les fonctions de modification. On voudra alors faire :
void Données::Enregistrer() const
{
if ( ! estModifié)
return;
// ... Le code pour l'enregistrement
estModifié= false;
}
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Ceci dit, ça me paraît difficile de croire que ce cas
n'arrivait à personne avant que l'on invente mutable, alors je
me demande s'il y a une autre solution, moins « C++ très
moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je
n'avais pas tendance à enseigner mutable aux débutants (de
peur qu'ils en abusent), mais là, je me pose la question...
Dois-je attendre au chapitre 17 de mon livre (le dernier)
avant de parler de mutable, si mes exemples tout simples
semblent parfois l'exiger ?
Bonjour les amis :-)
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais
vraiment eu de cas réels où il m'aurait été utile. Par
conséquent, le cas qui suit, très simple, me laisse perplexe
et je me demande s'il y a un autre moyen...
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
class Données
{
public :
Données(); // Récupère les données d'un fichier
void ModifierLesDonnées(); // Et autres fonctions de modif.
void Afficher() const; // Et autres de consultation
void Enregistrer() const; // Enregistre dans le fichier
~Données()
{
Enregistrer();
// Et d'autres opérations probablement
}
// ...
};
Les clients peuvent appeler Enregistrer() s'ils ne veulent pas
attendre l'enregistrement fait par la destruction.
Maintenant pour optimiser, on décide d'ajouter un bool, genre
« estModifié » qui sera mis à false au départ, mais mis à true
par les fonctions de modification. On voudra alors faire :
void Données::Enregistrer() const
{
if ( ! estModifié)
return;
// ... Le code pour l'enregistrement
estModifié= false;
}
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Ceci dit, ça me paraît difficile de croire que ce cas
n'arrivait à personne avant que l'on invente mutable, alors je
me demande s'il y a une autre solution, moins « C++ très
moderne » et sans abus du langage.
Peut-être que quelque chose m'échappe. Personnellement, je
n'avais pas tendance à enseigner mutable aux débutants (de
peur qu'ils en abusent), mais là, je me pose la question...
Dois-je attendre au chapitre 17 de mon livre (le dernier)
avant de parler de mutable, si mes exemples tout simples
semblent parfois l'exiger ?
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis
retrouvé avec du mutable. Je ne vois qu'une alternative : Dire
que rien n'est const...
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis
retrouvé avec du mutable. Je ne vois qu'une alternative : Dire
que rien n'est const...
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis
retrouvé avec du mutable. Je ne vois qu'une alternative : Dire
que rien n'est const...
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change l'état
de l'instance (ne serait-ce que d'un 'dirty' flag),
dans la réalité une fonction de sérialisation pourra désallouer des
temporaires, purger un buffer qui aurait grossi au dela d'une valeur
d'usage, effacer et déréférencer un fichier temporaire, incrémenter un
numéro de version de l'instance, etc, etc, non, pas const tout ça.
(on trouve parfois ce mauvais exemple du carnet d'adresses où le load
serait non const et le save const, c'est un très mauvais exemple).
une fonction estEnregistrable serait surement const car elle dépendrait de
l'instance mais ne serait pas censé la modifier et de son environnement
(le disque target par exemple).
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
ils conceptuallisaient peut être pas de la même façon.Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
l'attribut mutable me parait évident comme renfort _et_ contournement à la
règle: l'attribut const est évident de sens, cependant il est plus ou
moins un artifice d'écriture et on peux le 'violer', mutable offre un
passe-droit dans les règles (plus besoin de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut mémoriser le
nombre de lecture (donc const) d'une de ses données, on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
};
Sylvain.
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change l'état
de l'instance (ne serait-ce que d'un 'dirty' flag),
dans la réalité une fonction de sérialisation pourra désallouer des
temporaires, purger un buffer qui aurait grossi au dela d'une valeur
d'usage, effacer et déréférencer un fichier temporaire, incrémenter un
numéro de version de l'instance, etc, etc, non, pas const tout ça.
(on trouve parfois ce mauvais exemple du carnet d'adresses où le load
serait non const et le save const, c'est un très mauvais exemple).
une fonction estEnregistrable serait surement const car elle dépendrait de
l'instance mais ne serait pas censé la modifier et de son environnement
(le disque target par exemple).
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
ils conceptuallisaient peut être pas de la même façon.
Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
l'attribut mutable me parait évident comme renfort _et_ contournement à la
règle: l'attribut const est évident de sens, cependant il est plus ou
moins un artifice d'écriture et on peux le 'violer', mutable offre un
passe-droit dans les règles (plus besoin de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut mémoriser le
nombre de lecture (donc const) d'une de ses données, on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
};
Sylvain.
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change l'état
de l'instance (ne serait-ce que d'un 'dirty' flag),
dans la réalité une fonction de sérialisation pourra désallouer des
temporaires, purger un buffer qui aurait grossi au dela d'une valeur
d'usage, effacer et déréférencer un fichier temporaire, incrémenter un
numéro de version de l'instance, etc, etc, non, pas const tout ça.
(on trouve parfois ce mauvais exemple du carnet d'adresses où le load
serait non const et le save const, c'est un très mauvais exemple).
une fonction estEnregistrable serait surement const car elle dépendrait de
l'instance mais ne serait pas censé la modifier et de son environnement
(le disque target par exemple).
difficile de croire que ce cas n'arrivait à personne avant que
l'on invente mutable, alors je me demande s'il y a une autre
solution, moins « C++ très moderne » et sans abus du langage.
ils conceptuallisaient peut être pas de la même façon.Peut-être que quelque chose m'échappe. Personnellement, je n'avais
pas tendance à enseigner mutable aux débutants (de peur qu'ils en
abusent), mais là, je me pose la question... Dois-je attendre au
chapitre 17 de mon livre (le dernier) avant de parler de mutable,
si mes exemples tout simples semblent parfois l'exiger ?
l'attribut mutable me parait évident comme renfort _et_ contournement à la
règle: l'attribut const est évident de sens, cependant il est plus ou
moins un artifice d'écriture et on peux le 'violer', mutable offre un
passe-droit dans les règles (plus besoin de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut mémoriser le
nombre de lecture (donc const) d'une de ses données, on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
};
Sylvain.
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change
l'état de l'instance (ne serait-ce que d'un 'dirty' flag),
l'attribut mutable me parait évident comme renfort _et_
contournement à la règle: l'attribut const est évident de sens,
cependant il est plus ou moins un artifice d'écriture et on peux le
'violer', mutable offre un passe-droit dans les règles (plus besoin
de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut
mémoriser le nombre de lecture (donc const) d'une de ses données,
on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change
l'état de l'instance (ne serait-ce que d'un 'dirty' flag),
l'attribut mutable me parait évident comme renfort _et_
contournement à la règle: l'attribut const est évident de sens,
cependant il est plus ou moins un artifice d'écriture et on peux le
'violer', mutable offre un passe-droit dans les règles (plus besoin
de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut
mémoriser le nombre de lecture (donc const) d'une de ses données,
on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
Michel Michaud wrote on 25/04/2006 05:18:
Pour moi, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
pour moi elle est conceptuellement non const puisque qu'elle change
l'état de l'instance (ne serait-ce que d'un 'dirty' flag),
l'attribut mutable me parait évident comme renfort _et_
contournement à la règle: l'attribut const est évident de sens,
cependant il est plus ou moins un artifice d'écriture et on peux le
'violer', mutable offre un passe-droit dans les règles (plus besoin
de transcaster salement).
et les exemples peuvent êtres simples, si une instance veut
mémoriser le nombre de lecture (donc const) d'une de ses données,
on écrira volontiers:
class X {
Z z;
mutable long c;
...
public:
Z getZ() const { ++c, return z; }
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis retrouvé
avec du mutable. Je ne vois qu'une alternative : Dire que rien
n'est const...
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis retrouvé
avec du mutable. Je ne vois qu'une alternative : Dire que rien
n'est const...
Maintenant pour optimiser, on décide d'ajouter un bool
C'est en général dans ce genre de situation que je me suis retrouvé
avec du mutable. Je ne vois qu'une alternative : Dire que rien
n'est const...
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais vraiment
eu de cas réels où il m'aurait été utile.
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais vraiment
eu de cas réels où il m'aurait été utile.
Même si je comprends très bien les raisons de l'existence de
mutable, son emploi, sa sémantique, etc., je n'ai jamais vraiment
eu de cas réels où il m'aurait été utile.
Michel Michaud wrote:Bonjour les amis :-)
Tiens, un revenant. Bienvenu de retour.
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas d'erreur
lors de l'enrégistrement ? Gérer des erreurs depuis un
destructeur, c'est assez délicat. (Mais bien, il y a des cas...
Si tu es sur un disque local, et que la taille du fichier
n'augmente pas, les cas d'erreur doivent être assez rare qu'on
puisse en faire abstraction. C'est juste pour te taquiner un
peu.)
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Tout à fait.
Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Si l'exemple l'exige, il vaut mieux le présenter. Mais je me
pose la question s'il ne vaut pas mieux changer l'exemple, pour
qu'il ne l'exige pas -- c'est en effet quelque chose de spécial,
qu'on n'a pas besoin de présenter aux débuttants.
Michel Michaud wrote:
Bonjour les amis :-)
Tiens, un revenant. Bienvenu de retour.
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas d'erreur
lors de l'enrégistrement ? Gérer des erreurs depuis un
destructeur, c'est assez délicat. (Mais bien, il y a des cas...
Si tu es sur un disque local, et que la taille du fichier
n'augmente pas, les cas d'erreur doivent être assez rare qu'on
puisse en faire abstraction. C'est juste pour te taquiner un
peu.)
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Tout à fait.
Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Si l'exemple l'exige, il vaut mieux le présenter. Mais je me
pose la question s'il ne vaut pas mieux changer l'exemple, pour
qu'il ne l'exige pas -- c'est en effet quelque chose de spécial,
qu'on n'a pas besoin de présenter aux débuttants.
Michel Michaud wrote:Bonjour les amis :-)
Tiens, un revenant. Bienvenu de retour.
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction permet
d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas d'erreur
lors de l'enrégistrement ? Gérer des erreurs depuis un
destructeur, c'est assez délicat. (Mais bien, il y a des cas...
Si tu es sur un disque local, et que la taille du fichier
n'augmente pas, les cas d'erreur doivent être assez rare qu'on
puisse en faire abstraction. C'est juste pour te taquiner un
peu.)
Pour moi, clairement, la fonction est conceptuellement const et
il faut donc que estModifié soit mutable.
Tout à fait.
Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Si l'exemple l'exige, il vaut mieux le présenter. Mais je me
pose la question s'il ne vaut pas mieux changer l'exemple, pour
qu'il ne l'exige pas -- c'est en effet quelque chose de spécial,
qu'on n'a pas besoin de présenter aux débuttants.
Dans le message ,Michel Michaud wrote:
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction
permet d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas
d'erreur lors de l'enrégistrement ? Gérer des erreurs depuis
un destructeur, c'est assez délicat. (Mais bien, il y a des
cas... Si tu es sur un disque local, et que la taille du
fichier n'augmente pas, les cas d'erreur doivent être assez
rare qu'on puisse en faire abstraction. C'est juste pour te
taquiner un peu.)
Oui, mais j'ajouterai que la gestion des erreurs d'espace
disque (et autres du même genre) dépasse encore plus le niveau
débutant que mutable.
En fait, j'ai l'impression que dans des programmes où c'est
très important, il est impossible d'utiliser <fstream> ou les
FILE*, car on voudra tout ce que le système d'exploitation
peut nous donner par l'utilisation des fichiers natifs.
[...]Pour moi, clairement, la fonction est conceptuellement
const et il faut donc que estModifié soit mutable.
Tout à fait.
Venant de toi, ça me rassure :-)
[...]Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Donc ça se faisait, c'est ce que je voulais savoir. Merci !
Dans le message 1145950522.760147.59960@e56g2000cwe.googlegroups.com,
Michel Michaud wrote:
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction
permet d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas
d'erreur lors de l'enrégistrement ? Gérer des erreurs depuis
un destructeur, c'est assez délicat. (Mais bien, il y a des
cas... Si tu es sur un disque local, et que la taille du
fichier n'augmente pas, les cas d'erreur doivent être assez
rare qu'on puisse en faire abstraction. C'est juste pour te
taquiner un peu.)
Oui, mais j'ajouterai que la gestion des erreurs d'espace
disque (et autres du même genre) dépasse encore plus le niveau
débutant que mutable.
En fait, j'ai l'impression que dans des programmes où c'est
très important, il est impossible d'utiliser <fstream> ou les
FILE*, car on voudra tout ce que le système d'exploitation
peut nous donner par l'utilisation des fichiers natifs.
[...]
Pour moi, clairement, la fonction est conceptuellement
const et il faut donc que estModifié soit mutable.
Tout à fait.
Venant de toi, ça me rassure :-)
[...]
Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Donc ça se faisait, c'est ce que je voulais savoir. Merci !
Dans le message ,Michel Michaud wrote:
Pour simplifier, disons que j'ai une classe qui contient et
gère des données récupérées d'un fichier. Une fonction
permet d'enregistrer les modifications et elle est appelée
automatiquement par le destructeur :
Ce n'est pas bien, ça. Et qu'est-ce qui se passe en cas
d'erreur lors de l'enrégistrement ? Gérer des erreurs depuis
un destructeur, c'est assez délicat. (Mais bien, il y a des
cas... Si tu es sur un disque local, et que la taille du
fichier n'augmente pas, les cas d'erreur doivent être assez
rare qu'on puisse en faire abstraction. C'est juste pour te
taquiner un peu.)
Oui, mais j'ajouterai que la gestion des erreurs d'espace
disque (et autres du même genre) dépasse encore plus le niveau
débutant que mutable.
En fait, j'ai l'impression que dans des programmes où c'est
très important, il est impossible d'utiliser <fstream> ou les
FILE*, car on voudra tout ce que le système d'exploitation
peut nous donner par l'utilisation des fichiers natifs.
[...]Pour moi, clairement, la fonction est conceptuellement
const et il faut donc que estModifié soit mutable.
Tout à fait.
Venant de toi, ça me rassure :-)
[...]Il y a eu des conversions explicites depuis le début du temps.
Quelque chose du genre :
((Données*)this)->estModifié = false ;
L'ARM en prevenait le cas, et permettait ce genre de manip, même
Donc ça se faisait, c'est ce que je voulais savoir. Merci !