Question argument d'une fonction de type string

Bonjour,

Juste une question
J'ai beacoup lu des tutorials sur les strings
et j'arrive toujours pas à comprendre pourquoi

quand on met un argument de type string on doit toujours faire "const string& nom_var"

ex :

Code:

---

1 2 3 4 5

string fonction_name(const string& variable_name) { //Code here }

---

pourquoi ne pas faire tout simplement commme suit

Code:

---

1 2 3 4 5

string fonction_name(string variable_name) { //Code here }

---

ou aussi

Code:

---

1 2 3 4 5

string fonction_name(string& variable_name) { //Code here }

---

Parce que copier coute cher quand un objet est plus gros qu'un int.
Et parce qu'un réaliser une allocation et une libération (ce qui se passe en interne quand on copie des strings) coute encore plus cher.

On met le mot clef const pour indiquer que, dans la fonction, il n'est pas autorisé de modifier la variable.

On passe par référence pour éviter de perdre du temps à copier, c'est tout ce qu'il y a à comprendre, faut pas chercher plus loin.

Quand tu dis "on doit toujours faire", c'est faux, parfois on veut pouvoir mettre à jour la variable passée en argument, sans la passer par le return. On ne met pas de const dans ce cas.

Parfois on préférera carrément en faire une copie en la passant par valeur pour pouvoir travailler dessus sans risque.

Salut,

Il y a une dernière raison, qui justifie la constance de la référence:

La norme interdit de créer des références anonymes non constantes.

C'est à dire que, si tu veux appeler ta fonction sous la forme de

Code:

---

1 2 3 4 5 6

string str=function_name("salut koala"); /* ce qui aurait pu être séparé en */ string str; /*...*/ str=function_name("salut koala");

---

la version prenant une chaine par valeur aura l'inconvénient de provoquer la copie de la chaine, et la version prenant une référence non constante ne sera pas admise.

Seule la version prenant une référence constante pourra fonctionner en évitant les deux écueils ;)

Bien vu, mais c'est bien dommage.

non, c'est normal:

une référence peut servir d'argument in/out...

Or, si tu laisse une référence non constante, la fonction qui la reçoit en argument est susceptible de modifier cet argument.

Et, pourtant, si la fonction est appelée sous la forme présentée lors de mon intervention précédente, il sera impossible de modifier cet argument, étant donné que quel que soit le type de l'argument, il sera créé de manière temporaire, et le langage n'a aucun moyen de faire la différence, s'il vient à accepter une référence non constante.

Dés lors, le fait de forcer les référence anonymes à être constantes permet de prendre les différents cas en considération:

Si l'argument est à considérer comme in/out, il ne doit pas être constant, mais il faut qu'une variable du bon type existe avant l'appel de la fonction, alors que s'il doit pouvoir être créé de manière anonyme, il n'a aucune raison d'être volatile, ni de servir d'argument in/out ;)

Ben si justement, il pourrait y en avoir des raisons. Je me suis déjà frotté au cas, c'est pour ça que je dis ça aujourd'hui. :( Mais pas grave je vivrais avec.

Par exemple il m'aurait bien été utile d'avoir une référence non constante pour un retourner une variable afin d'implémenter une nouvelle fonctionnalité (le return était déjà pris), sans obliger l'utilisateur de la fonction à utiliser ce retour (variable par défaut).

A priori je ne vois rien qui empêcherait le compilateur de retomber sur ses pattes si la variable par défaut est utilisée : il créé un bête temporaire avant l'appel, il l'utilise, le modifie à souhait, et le détruit à la fin de la fonction.

Ben non, je suis forcé de passer soit par un pointeur [et aller, c'est parti pour une longue série de if (pointeur) pointeur->truc(); très joli...] ou alors une fonction wrapper qui effectivement créé le temporaire avant l'appel, le job suposé du compilo quoi, lazy b*st*rd...

quoi je l'ai mauvaise ?? :lol: effectivement elle a eu du mal à passer celle-là.

Citation:

---

Envoyé par NiamorH

Ben si justement, il pourrait y en avoir des raisons. Je me suis déjà frotté au cas, c'est pour ça que je dis ça aujourd'hui. :( Mais pas grave je vivrais avec.

Par exemple il m'aurait bien été utile d'avoir une référence non constante pour un retourner une variable afin d'implémenter une nouvelle fonctionnalité (le return était déjà pris), sans obliger l'utilisateur de la fonction à utiliser ce retour (variable par défaut).

---

Voyons... réfléchi un peu...

Comment voudrais tu utiliser une valeur modifiée de la chaine "salut koala" lors d'un appel du genre de

Code:

---

int i = mafonct("salut koala");

---

:question:
quel nom donnerais tu à la variable devant recevoir la valeur modifiée, après appel de la fonction :question:

Si tu veux disposer de la valeur modifiée, tu n'as pas le choix, il te faut une variable légalement déclarée au sein de la fonction appelante pour y accéder.

Et donc, le code utilisable devient

Code:

---

1 2 3 4

std::string str="salut koala"; int i = mafonct(str); /* possibilité d'utiliser str qui sera modifié */

---

pour autant que tu aie passé str en tant que référence non constante (ce qui est autorisé ;))

Citation:

---

A priori je ne vois rien qui empêcherait le compilateur de retomber sur ses pattes si la variable par défaut est utilisée : il créé un bête temporaire avant l'appel, il l'utilise, le modifie à souhait, et le détruit à la fin de la fonction.

---

Ce n'est pas tant le fait que le compilateur puisse créer une variable temporaire, c'est surtout qu'il faut que tu puisse éventuellement utiliser cette variable, en n'ayant aucune idée du nom que le compilateur peut lui avoir donné...

Au sein de la fonction appelée, tu dispose du nom de l'argument fourni, mais, au sein de la fonction appelante, tu ne dispose de toutes manières d'aucun moyen de récupérer cette valeur modifiée (cf plus haut ;))

Il n'y a donc a priori aucune raison pour autoriser la modification d'une référence anonyme (à comprendre: d'une variable créée sur base d'une valeur n'étant pas une variable dans la fonction appelante) ;)

Citation:

---

Ben non, je suis forcé de passer soit par un pointeur [et aller, c'est parti pour une longue série de if (pointeur) pointeur->truc(); très joli...] ou alors une fonction wrapper qui effectivement créé le temporaire avant l'appel, le job suposé du compilo quoi, lazy b*st*rd...

---

Non, tu es obligé de passer par une variable correctement déclarée dans la fonction appelante, et par une référence - éventuellement non constante - sur cette variable dans la fonction appelée.

L'utilisation d'une référence non constante, quand elle a lieu dans le contexte d'une variable légalement déclarée au sein de la fonction appelante ne pose absolument aucun problème, et permet d'avoir un argument in/out...

Ce qui pose problème, c'est de vouloir utiliser comme argument in/out une valeur qui n'est pas une variable légalement déclarée dans la fonction appelante.

Encore une fois, relis le lignes ci-dessus pour comprendre pourquoi il serait de toutes façons inutile de le permettre ;)

Citation:

---

quoi je l'ai mauvaise ?? :lol: effectivement elle a eu du mal à passer celle-là.

---

En fait, j'ai l'impression que tu as simplement mal compris le priincipe d'une "référence anonyme" ;)

Les quelques lignes qui précèdent t'auront, je l'espère, permis de comprendre de quoi il s'agit réellement, et auront sans doute pour effet de fluidifier le passage ;)

Quand on parle de référence anonyme, il s'agit en réalité d'une "référence sur une variable anonyme (qui n'a pas de nom légalement déclaré)" ;)

Citation:

---

Envoyé par koala01

Voyons... réfléchi un peu...

Comment voudrais tu utiliser une valeur modifiée de la chaine "salut koala" lors d'un appel du genre de

Code:

---

int i = mafonct("salut koala");

---

---

C'est au compilateur de me donner une jolie error pour ce cas particulier où j'écrirais de la m****, il en est capable.

Citation:

---

Envoyé par koala01

Si tu veux disposer de la valeur modifiée, tu n'as pas le choix, il te faut une variable légalement déclarée au sein de la fonction appelante pour y accéder.

...

Ce n'est pas tant le fait que le compilateur puisse créer une variable temporaire, c'est surtout qu'il faut que tu puisse éventuellement utiliser cette variable,

...

au sein de la fonction appelante, tu ne dispose de toutes manières d'aucun moyen de récupérer cette valeur modifiée (cf plus haut ;))

...

Il n'y a donc a priori aucune raison pour autoriser la modification d'une référence anonyme

---

Citation:

---

Envoyé par Niamorh

A priori je ne vois rien qui empêcherait le compilateur de retomber sur ses pattes si la variable par défaut est utilisée : il créé un bête temporaire avant l'appel, il l'utilise, le modifie à souhait, et le détruit à la fin de la fonction.

---

Tu n'a visiblement pas saisi l'intérêt qui existe bel et bien :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int fonction( int ancien = 1, NouvelObjet & nouvelle fonctionnalité = NouvelObjet() );   void Anciennefonctionquisefichetotalementdelanouvellefonctionnalite() { // Aucune modification sur le fichier int resultat = fonction( 7 ); }   void Nouvellefonctionquiaimeraitbienutiliserlanouvellefonctionnalite() { // Ben la j'utilise une variable puisque je m'en sert après NouvelObjet objt; int resultat = fonction( 7, objt ); if ( objt.EstDansEtat() == truc ) // faire d' autres supers trucs; }

---

C'est ça l'intérêt rien de plus. Et je ne vois aucune contrainte technique énorme pour qu'elle puisse être implémentée.

Citation:

---

en n'ayant aucune idée du nom que le compilateur peut lui avoir donné...

---

Si par cette phrase tu te demandais comment s'en servir, on s'en balance vu que c'est pas le but, si tu te demandais si il n'y allais pas y avoir de conflit de noms avec des variables locales, le compilateur peut utiliser une variable avec un nom commençant par underscore, elle lui sont réservées.

Citation:

---

Encore une fois, relis le lignes ci-dessus pour comprendre pourquoi il serait de toutes façons inutile de le permettre ;)

---

Je suis pas du tout d'accord, relis les lignes dessus pour comprendre pourquoi il seriat utilise de le permettre.

Citation:

---

En fait, j'ai l'impression que tu as simplement mal compris le priincipe d'une "référence anonyme" ;)

---

C'est possible, une variable par défaut est-elle considérée comme anonyme ? Parce que c'est cela dont je parle. Et qu'il est interdit en tant que reference non constante.

non, ce qui est interdit c'est une référence sur une variable anonyme non constante...

La notion d'argument par défaut est à comprendre dans le sens de "en dehors de toute indication contraire de la part de l'utilisateur" ;) et n'est clairement pas considéré, au sein de la fonction qui l'utilise, comme une variable anonyme... la preuve: l'argument a un nom ;)

Tu peux très bien fournir une valeur par défaut sur une référence non constante ;)

Mais, de là à récupérer un objet créé (pourquoi pas par défaut) de manière temporaire à une fonction et - éventuellement - modifié au sein de cette fonction dans la fonction qui l'appelle, explique moi comment tu voudrais t'y prendre ;)

Citation:

---

Envoyé par koala01

Mais, de là à récupérer un objet créé (pourquoi pas par défaut) de manière temporaire à une fonction et - éventuellement - modifié au sein de cette fonction dans la fonction qui l'appelle, explique moi comment tu voudrais t'y prendre ;)

---

J'abandonne, j'ai déjà expliqué que ce n'était pas mon but.

Citation:

---

Tu peux très bien fournir une valeur par défaut sur une référence non constante.

---

Code:

---

1 2 3 4 5 6

class B {};   class A { void func( B & b = B() ); };

---

Citation:

---

Comeau C/C++ 4.3.9 (Mar 27 2007 17:24:47) for ONLINE_EVALUATION_BETA1
Copyright 1988-2007 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 5: error: initial value of reference to non-const must be an lvalue
void func( B & b = B() );

1 error detected in the compilation of "ComeauTest.c".

---

Citation:

---

Envoyé par NiamorH

J'abandonne, j'ai déjà expliqué que ce n'était pas mon but.

---

Au temps pour moi... je viens de "percuter" sur ton but réel...:aie:

Et, vérification faite, effectivement un argument passé comme référence ayant une valeur par défaut doit être fournis sous la forme d'une référence constante (re :aie:)

Mais, ceci dit, l'argument peut très bien rester valable au sein de la fonction appelée:

Normalement, quand tu donne un objet par défaut à un argument, c'est que tu estime que "dans la plupart des cas", l'objet par défaut permettra d'arriver au but que tu t'es fixé, et qu'il est donc "inutile" de forcer à fournir toujours cet objet

Or, si tu dois commencer par modifier quelque chose dans cet objet avant de pouvoir l'utiliser (ou en cours d'utilisation):

1. cela indique sans doute que tu n'a pas réfléchi assez aux informations que devait contenir ton objet par défaut
2. toutes les modifications que tu pourrais apporter seront de toutes manières perdues en sortir de fonction... dés lors, on peut se poser la question de leur utilité réelle
3. tu romps avec le sacrosaint principe de la délégation des tâches: ta fonction reçoit une responsabilité à laquelle elle ne devrait pas prétendre

Dés lors, cela ne me gène absolument pas que l'objet fournis par défaut soit constant dans ce cas de figure, et cela devrait peut être t'inciter à réfléchir d'avantage aux informations contenues par l'objet par défaut, voire, à factoriser d'avantage ton code ;)... ou, pourquoi pas, à envisager plutôt la surcharge de la fonction, de manière à pouvoir utiliser l'objet "par défaut" dans l'une des fonctions et l'objet reçu en argument dans l'autre ;)

d'ou la construction typiquement C++ienne

Code:

---

std::vector().swap(variable);

---

car

Code:

---

variable.swap(std::vector());

---

ne compile pas. (je crois que Visual C++ l'accepte cependant)

Citation:

---

Envoyé par koala01

• toutes les modifications que tu pourrais apporter seront de toutes manières perdues en sortir de fonction... dés lors, on peut se poser la question de leur utilité réelle

---

Tout à fait d'acord pour dire que les données ne sont pas utiles tout le temps. D'où l'intérêt d'un argument par défaut.

Comment t'expliquer... Parfois, tu n'est pas intéressé par le code de retour de certaines fonctions ? Pourtant la fonction s'éforce à chaque fois de te retourner un beau code cohérent. Ben là c'est pareil. Libre à l'utilisateur de ne pas sans servir.

Citation:

---

Envoyé par koala01

• tu romps avec le sacrosaint principe de la délégation des tâches: ta fonction reçoit une responsabilité à laquelle elle ne devrait pas prétendre

---

D'accord aussi. Mais tu laisses un aspect de coté :

Imagine que tu implémente un compilateur (woah le taf).

Quelle implémentation choisirais-tu :

- Scanner d'abord les warnings (1ere boucle)
- Puis compiler (2eme boucle)

ou

- Compiler jusqu'à trouver des erreurs en stocquant au fur et à mesure les erreurs (1 seule boucle)

?

C'est exactement ce que je fais : un traitement avec un retour d'erreurs sous forme de string (utilisé ou non pour affichage ou autre après appel)

Citation:

---

ou, pourquoi pas, à envisager plutôt la surcharge de la fonction, de manière à pouvoir utiliser l'objet "par défaut" dans l'une des fonctions et l'objet reçu en argument dans l'autre ;)

---

C'est la solution du wrapper de fonction que j'ai déjà évoqué. C'est plus joli qu'une solution à base de pointeur, mais (je me répète) c'est vraiment dommage que la ref non constante ne soit pas compatible avec les argument par défaut car c'est l'écriture la plus simple pour faire cela, tout en restant logique et implémentable par les compilos.

Citation:

---

Envoyé par NiamorH

Tout à fait d'acord pour dire que les données ne sont pas utiles tout le temps. D'où l'intérêt d'un argument par défaut.

Comment t'expliquer... Parfois, tu n'est pas intéressé par le code de retour de certaines fonctions ? Pourtant la fonction s'éforce à chaque fois de te retourner un beau code cohérent. Ben là c'est pareil. Libre à l'utilisateur de ne pas sans servir.

---

Il ne faut pas confondre le but d'un retour de fonction avec celui d'un argument.

Le but du retour de fonction est... de fournir le résultat du traitement au sein de la fonction.

Celui d'un argument est... de fournir les informations dont la fonction a besoin pour travailler mais qu'elle est incapable de trouver par elle-même

Quand tu fournis un argument par défaut, cela revient seulement à dire à l'utilisateur de la fonction (à comprendre ici: celui qui décidera de l'invoquer dans son code ;))que

Citation:

---

Normalement, vous devriez fournir un argument de <tel type>, mais, comme j'ai remarqué qu'une valeur peut être utiliser dans une majorité de cas - et que je suis un mec décidément trop bon - j'ai décidé d'être gentil et de vous faciliter le travail, et vous n'êtes donc pas obligé fournir l'argument si la valeur vous convient (en respectant les limitations d'usage ;)).

---

Mais comme le but d'un argument est - à la base - de fournir à la fonction les informations nécessaires pour effectuer son travail en toute quiétude, la fonction ne devrait - a priori - jamais avoir la responsabilité de modifier une donnée au sein de l'argument.

Comme souvent, on se rend compte que le comportement "par défaut" (ici, la possiblité de faire subsister les modification apportée à un argument en dehors de la fonction) ne correspond qu'à une exception... qui n'entre pas dans le cadre "stricto senso" d'une méthode d'objet ou d'une fonction. (remarque que Java, par exemple, prend le problème dans l'autre sens, avec d'autres implications: pour lui, tout objet est toujours constant... et ce n'est pas forcément mieux :p)

Comme la modification de l'argument reçu par l'argument n'a - a priori - rien à faire dans une fonction, et que, en plus, en ce qui concerne ceux qui ont des valeurs par défaut, il devient impossible de jouir de ces valeurs en dehors de la fonction dans laquelle ils sont utilisés, j'estime parfaitement cohérent de ne pas autoriser les références anonymes non constantes.

Ceci dit, Je ne prétend pas que les décisions prises par le comité de standardisation soient les meilleures sur le sujet... je dis simplement que ce sont - de mon point de vue strictement personnel - les plus cohérentes par rapport aux autres, et par rapport à ma définition (peut être un peu trop) personnelle (à ton gout :question:) d'un argument ;)

Citation:

---

D'accord aussi. Mais tu laisses un aspect de coté :

Imagine que tu implémente un compilateur (woah le taf).

Quelle implémentation choisirais-tu :

- Scanner d'abord les warnings (1ere boucle)
- Puis compiler (2eme boucle)

ou

- Compiler jusqu'à trouver des erreurs en stocquant au fur et à mesure les erreurs (1 seule boucle)

?

C'est exactement ce que je fais : un traitement avec un retour d'erreurs sous forme de string (utilisé ou non pour affichage ou autre après appel)

C'est la solution du wrapper de fonction que j'ai déjà évoqué. C'est plus joli qu'une solution à base de pointeur, mais (je me répète) c'est vraiment dommage que la ref non constante ne soit pas compatible avec les argument par défaut car c'est l'écriture la plus simple pour faire cela, tout en restant logique et implémentable par les compilos.

---

Même dans le cadre de l'implémentation d'un compilateur... la fonction est quand même destinée à être appelée, et, s'il y a des arguments à lui fournir de manière à lui permettre de travailler, on souhaitera sans doute récupérer, à un moment ou un autre les arguments volatiles qu'on lui aura passé ;)

Dés lors, on en revient toujours au même point: il faut une variable existante pour les récupérer en dehors de la fonction (je sais, ce n'est pas ce dont tu parle, mais étant donné que c'est le but final de tels arguments... ;)) et que l'on passe donc du problème de référence sur variable anonyme à un problème tout à fait classique de devoir récupérer plus d'un résultat lors de l'appel d'une fonction ;)

Citation:

---

Envoyé par koala01

Celui d'un argument est... de fournir les informations dont la fonction a besoin pour travailler mais qu'elle est incapable de trouver par elle-même

---

Absolument pas d'accord.
Il existe des paramètres en entrée seule, en sortie seule, et en entrée/sortie.
Un lien au hasard : http://www.jaylelillois.info/index.p...chap3&desc=iut

Citation:

---

Mais comme le but d'un argument est - à la base - de fournir à la fonction les informations nécessaires pour effectuer son travail en toute quiétude, la fonction ne devrait - a priori - jamais avoir la responsabilité de modifier une donnée au sein de l'argument.

---

De fait, pas d'accord. Ce serait le cas si le paramètre était const seulement. Un paramètre non const peut être modifié en récupéré en sortie... C'est quand même dingue de dire ça.

Citation:

---

Comme souvent, on se rend compte que le comportement "par défaut" (ici, la possiblité de faire subsister les modification apportée à un argument en dehors de la fonction) ne correspond qu'à une exception... qui n'entre pas dans le cadre "stricto senso" d'une méthode d'objet ou d'une fonction. (remarque que Java, par exemple, prend le problème dans l'autre sens, avec d'autres implications: pour lui, tout objet est toujours constant... et ce n'est pas forcément mieux :p)

Comme la modification de l'argument reçu par l'argument n'a - a priori - rien à faire dans une fonction, et que, en plus, en ce qui concerne ceux qui ont des valeurs par défaut, il devient impossible de jouir de ces valeurs en dehors de la fonction dans laquelle ils sont utilisés, j'estime parfaitement cohérent de ne pas autoriser les références anonymes non constantes.

---

Pour moi, ça n'a vraiment aucun sens ce que tu dis. Tu pars d'une règle avec laquelle je ne suis pas d'accord. Voir plus haut.

Citation:

---

Même dans le cadre de l'implémentation d'un compilateur... la fonction est quand même destinée à être appelée, et, s'il y a des arguments à lui fournir de manière à lui permettre de travailler, on souhaitera sans doute récupérer, à un moment ou un autre les arguments volatiles qu'on lui aura passé ;)

---

Les arguments volatiles ? Fais attention, les termes que tu emploies pour faire de jolies phrases ont un sens en C++, ça devient parfois étrange de te lire et pas toujours facile à comprendre.
Pareil : essaye d'être précis lorsque tu parles d'argument/paramètre. C'est juste histoire de se comprendre plus facilement. ;)

Code:

---

1 2 3 4 5 6 7 8

// a est un paramètre void f( int a );   int main() { // 9 est un argument f( 9 ); }

---

Citation:

---

l'on passe donc du problème de référence sur variable anonyme à un problème tout à fait classique de devoir récupérer plus d'un résultat lors de l'appel d'une fonction ;)

---

Oui !!!!
C'est ça que j'ai dis bien plus haut : mon retour est déjà utilisé !! Sinon je m'en serais bien évidement servi !

Citation:

---

Envoyé par NiamorH

Tu n'a visiblement pas saisi l'intérêt qui existe bel et bien :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int fonction( int ancien = 1, NouvelObjet & nouvelle fonctionnalité = NouvelObjet() );   void Anciennefonctionquisefichetotalementdelanouvellefonctionnalite() { // Aucune modification sur le fichier int resultat = fonction( 7 ); }   void Nouvellefonctionquiaimeraitbienutiliserlanouvellefonctionnalite() { // Ben la j'utilise une variable puisque je m'en sert après NouvelObjet objt; int resultat = fonction( 7, objt ); if ( objt.EstDansEtat() == truc ) // faire d' autres supers trucs; }

---

---

En l'espèce, il suffit de faire une fonction de délégation (forwarding) :

Code:

---

1 2 3 4 5 6

int fonction( int ancien, NouvelObjet & nouvelle fonctionnalité);   inline int fonction( int ancien = 1) { NouvelObjet tmp; fonction (ancien, tmp); }

---

Dans ce cas précis, je ne vois pas vraiment l'intérêt de lier une référence à une rvalue.

Et puis, les arguments par défauts, beurk.

Citation:

---

Envoyé par NiamorH

Code:

---

1 2 3 4 5 6

class B {};   class A { void func( B & b = B() ); };

---

---

La plupart du temps, y'a des trucs faisables :

Code:

---

1 2 3 4 5 6

class B {};   class A { void func( B & b = (B()=B()) ); };

---

mais bon.

Citation:

---

Envoyé par koala01

du problème de référence sur variable anonyme

---

l'interdiction de lier une référence non-constante à une rvalue

@corrector :
Pourrais tu expliquer pourquoi :

Code:

---

1 2 3 4 5 6

class B {};   class A { void func( B & b = (B()=B()) ); };

---

fonctionne

D'avance merci

L'inconvenient ici c'est que l'operateur d'affectation doit etre disponible.
C'est pas très beau mais c'est pas mal comme astuce.

Code:

---

1 2 3 4 5 6

int fonction( int ancien, NouvelObjet & nouvelle fonctionnalité);   inline int fonction( int ancien = 1) { NouvelObjet tmp; fonction (ancien, tmp); }

---

Oui c'est l'une des solution que j'ai déjà évoqué.

Citation:

---

Envoyé par Montag

@corrector :
Pourrais tu expliquer pourquoi :

Code:

---

1 2 3 4 5 6

class B {};   class A { void func( B & b = (B()=B()) ); };

---

fonctionne

D'avance merci

---

Tout simplement : dans ce cas d'espèce (classe B vide), puisqu'aucun opérateur d'affectation ("operator=") n'est déclaré, le compilateur va automatiquement générer une déclaration, équivalente à :

Code:

---

1 2 3 4

class B { public: B& operator= (const B&); };

---

Remarque : si la classe B avait eu des membres, il en aurait été de même, du moment qu'aucun membre n'a un opérateur d'affectation prenant une référence non-constante (comme auto_ptr).

Il faut noter à propos d'operator= que :

1. c'est une fonction membre (forcément!)
2. elle prend une référence constante
3. elle renvoie une référence non-constante

Le (1) implique qu'il est possible de l'invoquer sur une r-valeur, comme par exemple un temporaire :

Code:

---

1 2 3

B x; B().operator= (x); // fonction membre : ok B() = x; // exacactement la même chose, avec une syntaxe plus sympathique

---

Le (2) permet évidement de passer une r-valeur :

Code:

---

1 2	B().operator= (B()); B() = B();

---

Le (3) signifie que le résultat de l'application de cette fonction est une l-valeur, comme :

Code:

---

1 2 3 4 5 6

int val(); int &ref(); &val(); // erreur : val() est une r-valeur! val() = 4; // idem &ref(); // ok : ref() est une l-valeur ref() = 4; // idem

---

Comme "B().operator= (B())" a le type référence non-constante sur B, c'est une l-valeur non-constante de B, donc on peut lier une référence non-constante sur B dessus :

Code:

---

1 2	B &ref = (B().operator= (B())); B &r = (B() = B());

---

donc le code est correct.

Ok, je pense avoir compris, merci beaucoup.

Citation:

---

Envoyé par NiamorH

L'inconvenient ici c'est que l'operateur d'affectation doit etre disponible.
C'est pas très beau mais c'est pas mal comme astuce.

Code:

---

1 2 3 4 5 6

int fonction( int ancien, NouvelObjet & nouvelle fonctionnalité);   inline int fonction( int ancien = 1) { NouvelObjet tmp; fonction (ancien, tmp); }

---

Oui c'est l'une des solution que j'ai déjà évoqué.

---

C'est juste une façon de faire qui marche ici.

En général, c'est plutôt sur des classes qui n'ont pas de notion de copie qu'on a besoin d'une telle chose, notamment ostrstream (traditionnellement)/ostringstream (actuellement).

En traditionnel :

Code:

---

char *p = ((ostrstream&)(ostrstream() << ...)).str(); // cast ancien style, c'est du traditionnel!

---

Mais ostrstream() est un temporaire, donc si on voulait sortir une classe Date :

Code:

---

1 2	class Date; ostream& operator<< (ostream& os, const Date& d);

---

ça marchait pas, évidement (référence liée à une r-valeur, vous connaissez la musique).

Alors, on écrivait :

Code:

---

char *p = ((ostrstream&)(ostrstream() << "" << date << ...)).str();

---

parce que la sortie de const char * était

Code:

---

ostream& ostream::operator<< (const char*)

---

donc fonction membre, ça marche, << "" est un NOP, ça nous donne une l-valeur, super.

Il se trouve, malheureusement, et bizarrement, que le comité, dont les voies sont vraiment impénétrables, a décidé qu'il valait mieux que cette fonction soit non-membre (ou alors, il a juste décidé ça à "pile-ou-face").

Donc cette astuce ne fonction plus! Mais il reste heureusement des fonctions qui ne font rien et qui renvoient une référence sur *this, et d'habitude on utilise flush() pour ça (on en a souvent besoin sur un ostringstream, et flush ne fait strictement rien sur un ostringstream) :

Code:

---

std::string s = (static_cast<std::ostringstream&>(ostringstream().flush() << ...)).str();

---

Citation:

---

Envoyé par NiamorH

Absolument pas d'accord.
Il existe des paramètres en entrée seule, en sortie seule, et en entrée/sortie.
Un lien au hasard : http://www.jaylelillois.info/index.p...chap3&desc=iut

---

A vrai dire, cette approche est, certes juste, si on ne se réfère qu'aux langages actuels, mais oublie le cheminement qui à mené à ce résultat.

C'est un peu comme si on n'étudiait l'histoire de l'homme qu'à partir de 1800, en "oubliant" le Moyen-Age, l'antiquité et la préhistoire ;)

Avant que la notion de paramètres n'intervienne, on parlait de procédure, et non de fonction.

Une procédure n'avait besoin que d'un nom, et ne nécessitait ni valeur de retour ni argument pour la simple et bonne raison que les langages qui les proposaient travaillaient... avec des variables globales.

L'ensemble des procédures d'un programme avait donc tout loisir d'accéder à n'importe quelle variable globale, que ce soit en "lecture" ou en "écriture", avec tous les problèmes inhérents à cet état de fait.

Une procédure poursuivait alors deux objectifs majeurs:

• Eviter la recopie d'un code lourd en le remplaçant par l'appel de la procédure
• permettre qu'un morceau de code puisse n'avoir qu'une responsabilité clairement définie.

Par la suite, on (quand je dis "on", je parle des pères fondateurs de la programmation...;)) a pris conscience des problèmes inhérents à l'utilisation de variables globales, et on a décidé de les remplacer par des variables locales.

Cela a impliqué que l'on réfléchisse à "d'autres moyens" en vue de mettre cette délégation de responsabilités en oeuvre, à savoir:

• Etre en mesure de fournir des données nécessaire à la fonction
• Etre en mesure de récupérer le résultat de la fonction

La première étape est devenue le passage d'arguments, et la seconde la valeur de retour.

Au début, il n'est question de passer les arguments que "en entrée", car le passage d'argument se fait "par valeur", et donc, une fonction ne pouvait donc fournir qu'un seul résultat, sous la forme de sa valeur de retour.

Evidemment, pour "idéal" que soit cet état de fait du pur point de vue de la délégation des tâches, il présentait malgré tout des inconvénients majeurs, ne serait-ce que parce qu'il obligeait à écrire un code proche de

Code:

---

a = fonction(a)

---

Ou parce qu'il est difficile, quand tout est renvoyé par valeur de pouvoir déterminer si une structure est valide ou non lors du retour de la fonction.

C'est alors que le C est apparu et a émis l'idée que

Citation:

---

Si nous fournissions comme argument la valeur de l'adresse mémoire à modifier au lieu de la valeur elle-même, nous pourrions "répercuter" les modifications apportées au sein d'une fonction appelée à la variable utilisée par la fonction appelante

---

avec pour corolaire le fait que l'on pourrait très bien utiliser la valeur de retour pour signifier la réussite ou l'échec du traitement tout en obtenant la valeur valablement modifiée... Voire obtenir plusieurs valeurs modifiées (au détriment de la délégation des tâches).

Le pointeur était né, et avec lui, la notion d'argument "d'entrée / sortie".

Mais le pointeur n'est, à l'extrême, qu'un "sucre syntaxique" permettant de contourner une restriction au niveau des valeurs de retour ;)

Quand le C++ (mais pas seulement lui) est arrivé, il y avait suffisemment d'expérience de pointeurs mal gérés pour se rendre compte que le fait de travailler sur "l'adresse mémoire" à laquelle se trouve une variable peut être catastrophique, et l'idée suivante a donc été de "permettre de fournir un alias de la variable" comme argument de fonction (sous entendu que toute les modifications apportées à cet alias seraient répercutée sur la variable d'origine): cet alias de variable a pris le nom de référence en C++.

Alors, bien sur, maintenant, tout le monde considère (du moins, quand on regarde les langages qui "ont le vent en poupe" actuellement) qu'un argument peut être en entrée seule, en entrée sortie ou en sortie...

Mais, historiquement parlant, cela n'a absolument pas été toujours le cas.

C'est la raison pour laquelle il est largement préférable de se rappeler que, bien qu'il soit *maintenant* possible d'envisager un argument "d'entrée / sortie", ça ne reste "qu'une facilité apportée par le langage" parce que le propre d'un argument a toujours été... de fournir à la fonction une valeur qu'elle est dans l'incapacité de déterminer d'elle-même.

Une fois que tu accepte cette historique (très rapide) et que tu te rappelle d'où vient le C++, tu te rend compte que l'optique d'interdire une référence anonyme non constante ou un argument par défaut fourni sous la forme d'une référence non constante est la seule optique cohérente.

Maintenant, d'autres optiques auraient pu être envisagées, mais elles l'auraient été au prix de l'oubli des racines du C++, et les philosophes (et les historiens) nous mettent en garde contre le danger de répéter les erreurs si on oublie trop son passé ;)

Citation:

---

Envoyé par koala01

Une fois que tu accepte cette historique (très rapide) et que tu te rappelle d'où vient le C++, tu te rend compte que l'optique d'interdire une référence anonyme non constante ou un argument par défaut fourni sous la forme d'une référence non constante est la seule optique cohérente.

---

Je vois mal ce qu'il y a de "cohérent" à forcer le programmeur à utiliser les différentes astuces que j'ai donné pour obtenir une l-valeur non-constante sur un temporaire.

<rien à voir>

Citation:

---

Envoyé par koala01

Avant que la notion de paramètres n'intervienne, on parlait de procédure, et non de fonction.

---

Dans le plus récent, je suis tombé sur le "cours d'algorithmie" de Stepanov (dispo en ligne gratuitement sur son site, avec les sources LaTeX/beamer et tout et tout). Bref, il emploie "procédure" pour les routines qui peuvent aussi altérer leurs arguments, et "fonctions" pour celles qui ne le peuvent/font pas -- et ce n'est pas du tout dit comme ça.
</>

Citation:

---

Envoyé par Luc Hermitte

<rien à voir>Bref, il emploie "procédure" pour les routines qui peuvent aussi altérer leurs arguments, et "fonctions" pour celles qui ne le peuvent/font pas -- et ce n'est pas du tout dit comme ça.
</>

---

<rien à voir/Ce n'est pas la terminologie Ada, ça? Jean-Marc?/

Je trouve cette terminologie bien plus cohérente, parce qu'on distingue bien les fonctions au sens mathématique ou de programmation fonctionnelle, des procédures.

En l'occurence, un paramètre en entrée/sortie, c'est souvent pour éviter des recopies redondantes comme dit Koala, ou qu'on ne dispose pas d'un mécanisme simple pour créer des n-uplets.

Citation:

---

Envoyé par corrector

Je vois mal ce qu'il y a de "cohérent" à forcer le programmeur à utiliser les différentes astuces que j'ai donné pour obtenir une l-valeur non-constante sur un temporaire.

---

Le fait que, justement, c'est un objet temporaire que tu veux passer par référence...

Il ne faut pas oublier que, en C++ (car l'optique est différente, en C# ou en java, par exemple), une référence est l'alias d'un objet existant, et qu'un objet est systématiquement détruit lorsque l'on quitte la portée dans laquelle il est déclaré.

Une référence ne peut donc être valide que tant que l'objet auquel elle fait référence existe, et est utilisée pour deux raisons particulières qui sont:

• d'éviter la copie de structures de grandes tailles
• de permettre aux modifications apportées à la référence d'être répercutées vers l'objet d'origine existant dans la fonction appelante

A partir du moment où tu ne poursuit pas ces deux objetctifs - et c'est le cas quand tu décide de fournir un argument facultatif sous la forme d'une référence, ne serait-ce que parce que cela implique la création d'un objet temporaire - je comprend parfaitement(et je laisse tout le monde libre de ne pas être d'accord avec moi) que le comité de normalisation n'ai pas jugé - jusqu'à présent - d'autoriser la modification de cet argument.

Et la raison qui vient directement à l'esprit est, tout simplement, que tu ne dispose d'aucun moyen de savoir, lorsque tu implémente (toi, en tant que programmeur) ta fonction, si l'appel sera fait en passant une référence sur un objet existant ou si, au contraire, c'est l'argument par défaut (et donc temporaire) qui est utilisé.

Bien sûr, tu peux encore "facilement" effectuer un test de valeur sur un membre de cet argument... Mais encore faut-il alors t'assurer que la valeur de l'argument par défaut n'apparaitra que... dans le cadre de l'argument par défaut, et ne puisse en aucun cas apparaitre lorsque l'argument est issu d'un objet existant.

Autrement, tu risque, lors de l'implémentation de ta fonction, de partir du principe que "l'argument est tiré d'un objet existant en dehors de la fonction", et de fournir un comportement purement inutile (et potentiellement dangereux) si, d'aventure, ce n'est pas le cas.

En gros, le comité n'a donc que pleinement appliqué le principe du rasoir d'Occam : si tu n'a pas besoin de quelque chose, ne le fais pas ;)

Cette optique est donc clairement cohérente avec les autres concepts, même si, de fait, d'autres optiques auraient peut être pu être tout aussi cohérentes ;)

Citation:

---

Envoyé par Luc Hermitte

<rien à voir>

Dans le plus récent, je suis tombé sur le "cours d'algorithmie" de Stepanov (dispo en ligne gratuitement sur son site, avec les sources LaTeX/beamer et tout et tout). Bref, il emploie "procédure" pour les routines qui peuvent aussi altérer leurs arguments, et "fonctions" pour celles qui ne le peuvent/font pas -- et ce n'est pas du tout dit comme ça.
</>

---

Je conçois sans aucun problème que les termes "procédure" et "fonction" puissent être utilisés de manière pour ainsi dire indifférente lorsque l'on ne considère que l'algorithmique de manière générale.

Cependant, un fait reste présent:

Dans les langages qui utilisent les variables globales (COBOL avec sa procedure division (remarque qu'il ne s'agit pas de la fonction division :D ), le BASIC tel qu'il était présent dans les premier micro, ...) c'est le terme procédure qui est systématiquement utilisé, avec - effectivement - comme sous entendu qu'une procédure est susceptible de modifier n'importe quelle variable.

Si, dans les langages qui n'utilisent pas exclusivement les variables globales, le terme procédure peut être utilisé, ce n'est que suite à l'amalgame entre les deux, mais en oubliant que si toute fonction (avec valeur de retour et arguments éventuels) est une procédure "particulière", une procédure au sens strict n'est pas forcément une fonction, car ne disposant pas forcément d'une valeur de retour et/ou d'arguments éventuels.

Evidemment, on rencontre aussi des langages qui permettent d'office de considérer les argument comme étant "d'entrée / sortie" (sauf indication contraire), mais, de manière générale, on court moins de risque à penser sous la forme de

Citation:

---

un argument est d'entrée seule

---

que sous celle de

Citation:

---

un argument est systématiquement d'entrée/sortie

---

pour la simple et bonne raison que, si un argument est d'entrée / sortie et qu'on le considère comme étant d'entrée seule, au pire, on se restreint dans l'utilisation que l'on peut en faire, alors que si on considère un argument d'entrée seule comme étant un argument d'entrée/sortie, on s'ouvre la porte à des incompatibilités majeures ;)

Citation:

---

Envoyé par koala01

bla bla bla ... moyen age ... bla bla bla ... inutile ... bla bla bla ... dangereux

---

désolé, je ne suis pas convaincu.