Bonjour,
J'ai quelques petites fonctions C90, dont je souhaite réutiliser le
code source, éventuellement légèrement modifié (donc pas de mise en
bib).
Faisant largement appel à stdio.h elles sont tout sauf "idiomatiques"
en C++, mais elles sont parfaitement (hum, je l'espère en tous cas)
conformes à la norme de ce langage. Je précise que l'interface
elle-même est C plus que C++. Un exemple:
int AjouteNumLignes(const char nom_in[]
,const char nom_out[]
,const int nbr_caracts
);
Le int de retour est sémantiquement un bool.
Réécririez-vous ces fonctions en vue d'une utilisation en C++, sachant
qu'elles ont été validées par l'usage dans leur version actuelle ?
Quelle serait la raison objective de cette réécriture ?
Pour l'instant, je pense qu'il est possible de réutiliser "as is" ces
fonctions. Eventuellement en modifiant l'interface:
On Tue, 31 Aug 2004 17:32:41 +0200, Pierre Maurette :
Je vais tenter avec un .asm, mais je n'y crois pas trop.
Au pire, il me semble que Borland fournit un assembleur ; tu peux donc transformer un .asm en .obj, et inclure ce dernier dans ton projet.
-- ;-)
Michel Michaud
Dans news:, Andre
Dans le cas de std::string, avec une bibliothèque standard raisonnablement optimisée, il n'est pas nécessaire de passer par référence.
Je ne crois pas qu'on puisse dire ça. Une bibliothèque standard optimisée ou pas, devra l'être selon certains critères. Dans le cas de std::string, l'optimisation qui permettrait de pouvoir se passer de la copie (habituellement un comptage de référence et un COW) est un mauvais choix dans plusieurs contextes et est de plus en plus éliminée...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:g429j0dspkt3u196bv5dm27kk9h8bpuilk@4ax.com, Andre
Dans le cas de std::string, avec une bibliothèque standard
raisonnablement optimisée, il n'est pas nécessaire de passer par
référence.
Je ne crois pas qu'on puisse dire ça. Une bibliothèque standard
optimisée ou pas, devra l'être selon certains critères. Dans le
cas de std::string, l'optimisation qui permettrait de pouvoir
se passer de la copie (habituellement un comptage de référence
et un COW) est un mauvais choix dans plusieurs contextes et est
de plus en plus éliminée...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le cas de std::string, avec une bibliothèque standard raisonnablement optimisée, il n'est pas nécessaire de passer par référence.
Je ne crois pas qu'on puisse dire ça. Une bibliothèque standard optimisée ou pas, devra l'être selon certains critères. Dans le cas de std::string, l'optimisation qui permettrait de pouvoir se passer de la copie (habituellement un comptage de référence et un COW) est un mauvais choix dans plusieurs contextes et est de plus en plus éliminée...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
Jean-Marc Bourguet wrote in message news:...
Pierre Maurette writes:
Fabien LE LEZ a écrit:
On Tue, 31 Aug 2004 15:34:11 +0200, Pierre Maurette : [...]
Et si AjouteNumLignes() est une méthode,
Une fonction membre, tu veux dire ? Oui.
Il me semblait que je pouvais écrire "méthode [d'instance par défaut]", et "méthode de classe [static]".
Methode ne fait pas partie du vocabulaire C++. Certains l'employent mais on ne sait jamais si ca designe toutes les fonctions membres ou seulement les virtuelles.
Certains ? Je dirais plutôt beaucoup. Moi-même, je m'en sers (pour des fonctions membre C++) dans deux contextes :
- Quand je fais une comparaison avec deux langages, par exemple le C++ et le Java. Alors, plutôt que d'utiliser deux vocables pour la même chose, selon le langage, j'unifie sur « méthode ».
- Quand je fais la conception, en UML. Même quand je sais que l'implémentation serait en C++, au niveau de la conception, en UML, une classe a des méthodes, et non des fonctions.
Dans la pratique, ce n'est pas difficile à imaginer que cette dernière raison finit par avoir raison des conventions actuelles. Pour la plupart des programmeurs, le C++ n'est qu'un outil, sans assez d'importance pour mériter son propre vocabulaire, et tout leur travail tourne autour de la conception.
Moi-même, je trouve aussi qu'une fois la conception bien faite, le codage est plutôt simple et mechanique. C'est donc que dans la pratique, je suis plus amené à discuter sur la conception, et donc à utiliser le mot méthode, que sur le codage, avec le mot fonction. Parce que je maintiens mon intérêt pour les détails de C++ quand même, je maintiens aussi l'usage des deux vocables, selon le contexte. Mais je crois que j'en fais exception.
-- James Kanze GABI Software http://www.gabi-soft.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
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxb3c23gx3b.fsf@news.bourguet.org>...
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
Fabien LE LEZ <gramster@gramster.com> a écrit:
On Tue, 31 Aug 2004 15:34:11 +0200, Pierre Maurette
<maurettepierre@wanadoo.fr>:
[...]
Et si AjouteNumLignes() est une méthode,
Une fonction membre, tu veux dire ?
Oui.
Il me semblait que je pouvais écrire "méthode [d'instance par
défaut]", et "méthode de classe [static]".
Methode ne fait pas partie du vocabulaire C++. Certains l'employent
mais on ne sait jamais si ca designe toutes les fonctions membres ou
seulement les virtuelles.
Certains ? Je dirais plutôt beaucoup. Moi-même, je m'en sers (pour des
fonctions membre C++) dans deux contextes :
- Quand je fais une comparaison avec deux langages, par exemple le C++
et le Java. Alors, plutôt que d'utiliser deux vocables pour la même
chose, selon le langage, j'unifie sur « méthode ».
- Quand je fais la conception, en UML. Même quand je sais que
l'implémentation serait en C++, au niveau de la conception, en UML,
une classe a des méthodes, et non des fonctions.
Dans la pratique, ce n'est pas difficile à imaginer que cette dernière
raison finit par avoir raison des conventions actuelles. Pour la plupart
des programmeurs, le C++ n'est qu'un outil, sans assez d'importance pour
mériter son propre vocabulaire, et tout leur travail tourne autour de la
conception.
Moi-même, je trouve aussi qu'une fois la conception bien faite, le
codage est plutôt simple et mechanique. C'est donc que dans la pratique,
je suis plus amené à discuter sur la conception, et donc à utiliser le
mot méthode, que sur le codage, avec le mot fonction. Parce que je
maintiens mon intérêt pour les détails de C++ quand même, je maintiens
aussi l'usage des deux vocables, selon le contexte. Mais je crois que
j'en fais exception.
--
James Kanze GABI Software http://www.gabi-soft.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
On Tue, 31 Aug 2004 15:34:11 +0200, Pierre Maurette : [...]
Et si AjouteNumLignes() est une méthode,
Une fonction membre, tu veux dire ? Oui.
Il me semblait que je pouvais écrire "méthode [d'instance par défaut]", et "méthode de classe [static]".
Methode ne fait pas partie du vocabulaire C++. Certains l'employent mais on ne sait jamais si ca designe toutes les fonctions membres ou seulement les virtuelles.
Certains ? Je dirais plutôt beaucoup. Moi-même, je m'en sers (pour des fonctions membre C++) dans deux contextes :
- Quand je fais une comparaison avec deux langages, par exemple le C++ et le Java. Alors, plutôt que d'utiliser deux vocables pour la même chose, selon le langage, j'unifie sur « méthode ».
- Quand je fais la conception, en UML. Même quand je sais que l'implémentation serait en C++, au niveau de la conception, en UML, une classe a des méthodes, et non des fonctions.
Dans la pratique, ce n'est pas difficile à imaginer que cette dernière raison finit par avoir raison des conventions actuelles. Pour la plupart des programmeurs, le C++ n'est qu'un outil, sans assez d'importance pour mériter son propre vocabulaire, et tout leur travail tourne autour de la conception.
Moi-même, je trouve aussi qu'une fois la conception bien faite, le codage est plutôt simple et mechanique. C'est donc que dans la pratique, je suis plus amené à discuter sur la conception, et donc à utiliser le mot méthode, que sur le codage, avec le mot fonction. Parce que je maintiens mon intérêt pour les détails de C++ quand même, je maintiens aussi l'usage des deux vocables, selon le contexte. Mais je crois que j'en fais exception.
-- James Kanze GABI Software http://www.gabi-soft.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
kanze
Fabien LE LEZ wrote in message news:...
On Tue, 31 Aug 2004 14:19:08 +0200, Fabien LE LEZ :
la solution canonique pour passer un objet en paramètre est la référence constante.
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le .cpp pour comprendre d'où venait le passage par valeur. Mon erreur venait du fait que la copie du std::string pour modification est un détail d'implémentation, et ne doit donc pas apparaître dans la déclaration. Le code correct est :
// .h void f (std::string const& nom);
// .cpp void f (std::string const& nom_) { std::string nom (nom_); nom+= ".extension"; ... }
Je fais en fait comme toi ici. Mais je reconnais la validité de l'argument qui dit que pour l'utilisateur, std::string et std::string const& sont des synonymes. Le choix d'un ou de l'autre dépendrait alors uniquement des considérations de l'implémentation.
Ce que je n'aime pas dans cet argument, c'est que ce detail de l'implémentation se trouve dans l'en-tête, et que si je le change, je provoque la récompilation de tout le code utilisateur.
-- James Kanze GABI Software http://www.gabi-soft.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
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<7h49j0dnteggedo5nen42pn8h1pe852qkb@4ax.com>...
On Tue, 31 Aug 2004 14:19:08 +0200, Fabien LE LEZ
<gramster@gramster.com>:
la solution canonique pour passer un objet en paramètre est la
référence constante.
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le
.cpp pour comprendre d'où venait le passage par valeur. Mon erreur
venait du fait que la copie du std::string pour modification est un
détail d'implémentation, et ne doit donc pas apparaître dans la
déclaration. Le code correct est :
// .h
void f (std::string const& nom);
// .cpp
void f (std::string const& nom_)
{
std::string nom (nom_);
nom+= ".extension";
...
}
Je fais en fait comme toi ici. Mais je reconnais la validité de
l'argument qui dit que pour l'utilisateur, std::string et std::string
const& sont des synonymes. Le choix d'un ou de l'autre dépendrait alors
uniquement des considérations de l'implémentation.
Ce que je n'aime pas dans cet argument, c'est que ce detail de
l'implémentation se trouve dans l'en-tête, et que si je le change, je
provoque la récompilation de tout le code utilisateur.
--
James Kanze GABI Software http://www.gabi-soft.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
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le .cpp pour comprendre d'où venait le passage par valeur. Mon erreur venait du fait que la copie du std::string pour modification est un détail d'implémentation, et ne doit donc pas apparaître dans la déclaration. Le code correct est :
// .h void f (std::string const& nom);
// .cpp void f (std::string const& nom_) { std::string nom (nom_); nom+= ".extension"; ... }
Je fais en fait comme toi ici. Mais je reconnais la validité de l'argument qui dit que pour l'utilisateur, std::string et std::string const& sont des synonymes. Le choix d'un ou de l'autre dépendrait alors uniquement des considérations de l'implémentation.
Ce que je n'aime pas dans cet argument, c'est que ce detail de l'implémentation se trouve dans l'en-tête, et que si je le change, je provoque la récompilation de tout le code utilisateur.
-- James Kanze GABI Software http://www.gabi-soft.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
kanze
Andre Heinen wrote in message news:...
Cependant je suis d'accord avec Fabien: pour la clarté du code, il faut mieux utiliser l'idiome habituel.
L'idiome habituel peut varier d'un utilisateur à l'autre. John Potter, dans un posting dans comp.lang.c++.moderated, disait une fois qu'il considérait l'utilisation d'une référence ici une optimisation. Et la règle en ce qui concerne les optimisations étaient simples : seulement quand le profileur dit que c'est nécessaire.
(Ceci dit, j'ai parfois du mal à savoir quand John veut être sérieux, et quand il s'amuse avec le lecteur.)
-- James Kanze GABI Software http://www.gabi-soft.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
Andre Heinen <nospam@nospam.invalid> wrote in message
news:<g429j0dspkt3u196bv5dm27kk9h8bpuilk@4ax.com>...
Cependant je suis d'accord avec Fabien: pour la clarté du code,
il faut mieux utiliser l'idiome habituel.
L'idiome habituel peut varier d'un utilisateur à l'autre. John Potter,
dans un posting dans comp.lang.c++.moderated, disait une fois qu'il
considérait l'utilisation d'une référence ici une optimisation. Et la
règle en ce qui concerne les optimisations étaient simples : seulement
quand le profileur dit que c'est nécessaire.
(Ceci dit, j'ai parfois du mal à savoir quand John veut être sérieux, et
quand il s'amuse avec le lecteur.)
--
James Kanze GABI Software http://www.gabi-soft.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
Cependant je suis d'accord avec Fabien: pour la clarté du code, il faut mieux utiliser l'idiome habituel.
L'idiome habituel peut varier d'un utilisateur à l'autre. John Potter, dans un posting dans comp.lang.c++.moderated, disait une fois qu'il considérait l'utilisation d'une référence ici une optimisation. Et la règle en ce qui concerne les optimisations étaient simples : seulement quand le profileur dit que c'est nécessaire.
(Ceci dit, j'ai parfois du mal à savoir quand John veut être sérieux, et quand il s'amuse avec le lecteur.)
-- James Kanze GABI Software http://www.gabi-soft.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
Andre Heinen
On Tue, 31 Aug 2004 17:01:53 +0200, Fabien LE LEZ wrote:
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le .cpp pour comprendre d'où venait le passage par valeur. Mon erreur venait du fait que la copie du std::string pour modification est un détail d'implémentation, et ne doit donc pas apparaître dans la déclaration. Le code correct est :
// .h void f (std::string const& nom);
// .cpp void f (std::string const& nom_) { std::string nom (nom_); nom+= ".extension"; ... }
Tout bien réfléchi, je n'en suis plus aussi convaincu qu'hier.
Si je lis "void f(const string&)", j'en conclus que f ne va pas modifier le string, et que je n'ai pas besoin d'en faire une sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas besoin de sauvegarder la valeur d'origine. En plus, j'en conclus que f a besoin d'une copie pour son usage personnel: ce n'est pas mon problème. Il est clair que c'est un détail d'implémentation, et il ne me viendra pas à l'idée d'aller vérifier dans le fichier cpp. Surtout si la fonction est correctement documentée ;-)
Lorsque f a besoin de sa propre copie, passer un string par valeur ne me paraît pas être une si mauvaise pratique.
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 17:01:53 +0200, Fabien LE LEZ
<gramster@gramster.com> wrote:
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le
.cpp pour comprendre d'où venait le passage par valeur.
Mon erreur venait du fait que la copie du std::string pour
modification est un détail d'implémentation, et ne doit donc pas
apparaître dans la déclaration. Le code correct est :
// .h
void f (std::string const& nom);
// .cpp
void f (std::string const& nom_)
{
std::string nom (nom_);
nom+= ".extension";
...
}
Tout bien réfléchi, je n'en suis plus aussi convaincu qu'hier.
Si je lis "void f(const string&)", j'en conclus que f ne va pas
modifier le string, et que je n'ai pas besoin d'en faire une
sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas
besoin de sauvegarder la valeur d'origine. En plus, j'en conclus
que f a besoin d'une copie pour son usage personnel: ce n'est pas
mon problème. Il est clair que c'est un détail d'implémentation,
et il ne me viendra pas à l'idée d'aller vérifier dans le fichier
cpp. Surtout si la fonction est correctement documentée ;-)
Lorsque f a besoin de sa propre copie, passer un string par
valeur ne me paraît pas être une si mauvaise pratique.
--
Andre Heinen
My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 17:01:53 +0200, Fabien LE LEZ wrote:
Plus tard, en voulant utiliser la fonction, j'ai dû chercher dans le .cpp pour comprendre d'où venait le passage par valeur. Mon erreur venait du fait que la copie du std::string pour modification est un détail d'implémentation, et ne doit donc pas apparaître dans la déclaration. Le code correct est :
// .h void f (std::string const& nom);
// .cpp void f (std::string const& nom_) { std::string nom (nom_); nom+= ".extension"; ... }
Tout bien réfléchi, je n'en suis plus aussi convaincu qu'hier.
Si je lis "void f(const string&)", j'en conclus que f ne va pas modifier le string, et que je n'ai pas besoin d'en faire une sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas besoin de sauvegarder la valeur d'origine. En plus, j'en conclus que f a besoin d'une copie pour son usage personnel: ce n'est pas mon problème. Il est clair que c'est un détail d'implémentation, et il ne me viendra pas à l'idée d'aller vérifier dans le fichier cpp. Surtout si la fonction est correctement documentée ;-)
Lorsque f a besoin de sa propre copie, passer un string par valeur ne me paraît pas être une si mauvaise pratique.
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
Andre Heinen
On Tue, 31 Aug 2004 20:16:42 -0400, "Michel Michaud" wrote:
Dans le cas de std::string, l'optimisation qui permettrait de pouvoir se passer de la copie (habituellement un comptage de référence et un COW) est un mauvais choix dans plusieurs contextes et est de plus en plus éliminée...
J'avoue que je ne vois pas dans quel cas un COW puisse poser problème. Peux-tu nous donner un exemple?
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 20:16:42 -0400, "Michel Michaud"
<mm@gdzid.com> wrote:
Dans le
cas de std::string, l'optimisation qui permettrait de pouvoir
se passer de la copie (habituellement un comptage de référence
et un COW) est un mauvais choix dans plusieurs contextes et est
de plus en plus éliminée...
J'avoue que je ne vois pas dans quel cas un COW puisse poser
problème. Peux-tu nous donner un exemple?
--
Andre Heinen
My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 20:16:42 -0400, "Michel Michaud" wrote:
Dans le cas de std::string, l'optimisation qui permettrait de pouvoir se passer de la copie (habituellement un comptage de référence et un COW) est un mauvais choix dans plusieurs contextes et est de plus en plus éliminée...
J'avoue que je ne vois pas dans quel cas un COW puisse poser problème. Peux-tu nous donner un exemple?
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
Andre Heinen
On Tue, 31 Aug 2004 17:32:41 +0200, Pierre Maurette wrote:
Il me reste à voir que faire avec mes sorties vers stderr.
Tu m'y fais penser: pour garantir que le mélange des E/S C et C++ fonctionne correctement, ne doit-on pas appeler sync_with_stdio()? Je ne sais pas comment ça marche.
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 17:32:41 +0200, Pierre Maurette
<maurettepierre@wanadoo.fr> wrote:
Il me reste à voir que faire avec mes sorties vers
stderr.
Tu m'y fais penser: pour garantir que le mélange des E/S C et C++
fonctionne correctement, ne doit-on pas appeler
sync_with_stdio()? Je ne sais pas comment ça marche.
--
Andre Heinen
My address is "a dot heinen at europeanlink dot com"
On Tue, 31 Aug 2004 17:32:41 +0200, Pierre Maurette wrote:
Il me reste à voir que faire avec mes sorties vers stderr.
Tu m'y fais penser: pour garantir que le mélange des E/S C et C++ fonctionne correctement, ne doit-on pas appeler sync_with_stdio()? Je ne sais pas comment ça marche.
-- Andre Heinen My address is "a dot heinen at europeanlink dot com"
Falk Tannhäuser
Andre Heinen wrote:
Si je lis "void f(const string&)", j'en conclus que f ne va pas modifier le string, et que je n'ai pas besoin d'en faire une sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas besoin de sauvegarder la valeur d'origine. En plus, j'en conclus que f a besoin d'une copie pour son usage personnel: ce n'est pas mon problème. Il est clair que c'est un détail d'implémentation, et il ne me viendra pas à l'idée d'aller vérifier dans le fichier cpp. Surtout si la fonction est correctement documentée ;-)
Et on peut être sûr que le paramètre n'est pas 'aliasé" comme ici : ________________________________________________________ #include <string> #include <cstddef> #include <iostream> #include <ostream>
Bien sûr, dans des vrais programmes, on n'écrit jamais des bêtises comme ça ...
Falk
Andre Heinen wrote:
Si je lis "void f(const string&)", j'en conclus que f ne va pas
modifier le string, et que je n'ai pas besoin d'en faire une
sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas
besoin de sauvegarder la valeur d'origine. En plus, j'en conclus
que f a besoin d'une copie pour son usage personnel: ce n'est pas
mon problème. Il est clair que c'est un détail d'implémentation,
et il ne me viendra pas à l'idée d'aller vérifier dans le fichier
cpp. Surtout si la fonction est correctement documentée ;-)
Et on peut être sûr que le paramètre n'est pas 'aliasé"
comme ici :
________________________________________________________
#include <string>
#include <cstddef>
#include <iostream>
#include <ostream>
Si je lis "void f(const string&)", j'en conclus que f ne va pas modifier le string, et que je n'ai pas besoin d'en faire une sauvegarde.
Si je lis "void f(string)", j'en conclus aussi que je n'ai pas besoin de sauvegarder la valeur d'origine. En plus, j'en conclus que f a besoin d'une copie pour son usage personnel: ce n'est pas mon problème. Il est clair que c'est un détail d'implémentation, et il ne me viendra pas à l'idée d'aller vérifier dans le fichier cpp. Surtout si la fonction est correctement documentée ;-)
Et on peut être sûr que le paramètre n'est pas 'aliasé" comme ici : ________________________________________________________ #include <string> #include <cstddef> #include <iostream> #include <ostream>
