salut petite question d’écriture, souvent dans le cours C++ je vois ceci: 

int ajouteDeux(int nombreRecu)
{
    int valeur(nombreRecu + 2);

    return valeur;
}

mais je me demandait si cela changeait quelques chose de l’écrire comme ca: 

int ajouteDeux(int nombreRecu)
{
   return nombreRecu +2;
}

dans le cours j'ai presque jamais vu une fonction écrite comme ceci, et je me demandais si c’était une bonne manière de l’écrire ou je dois me tenir a l'écriture du cours ?

c'est peut être une question bête mais je veux être sûr.

merci !

-
Edité par EmirSaglam 14 mai 2022 à 11:42:08

La deuxieme fonction est meilleure, elle coute moins.

Dans le "cours" du site y'a pas mal de choses a revoir...

Bonjour

Non, ça ne change rien, la seconde est même mieux que la première.

Pour la première l'utilisation des parenthèses pour initialiser la variable est plutôt à proscrire. On utilise plutôt les accolades :

    int valeur { nombreRecu + 2 } ;

Tu peux aussi éventuellement utiliser l'opérateur d'affectation :

    int valeur = nombreRecu + 2 ;

Mais évite les parenthèses.

Aucune différence, le code machine généré sera le même -- dès que l'on sort du mode "sans optim"

La seconde forme est plus simple pour l'humain habitué au développement: moins de bruit inutile ici (surtout avec un nom aussi inexpressif que "valeur"). Maintenant la première forme est plus simple à surveiller dans des débuggueurs, ce qui se retrouve dans l'asm: le résultat de l'addition (eax) est restocké en mémoire: (pour les curieux https://godbolt.org/z/z9b4zP4dv )

Dans cet exemple les 2 façons sont strictement équivalentes. La seconde est quand même plus lisible mais la première a l'avantage de pouvoir passer sur la variable avec le debugger et voir sa valeur quand le curseur est sur le return (sinon on sortirai direct de la fonction, mais cela dépend des debuggers).

Par contre si la variable n'est pas copiable, la première version ne compilera pas, mais la seconde si, grâce à la guaranteed copy elision (qui comme les autres concepts de C++ porte mal son nom et ne veut pas dire que la copie sera optimisée, mais bien qu'il n'y aura tout simplement pas de copie en premier lieu).

struct Foo {
  Foo() = default;
  Foo(const Foo&) = delete;
  Foo& operator=(const Foo&) = delete;
};

Foo get_foo() {
  Foo valeur {};
  return valeur; // ne compile pas
}

Foo get_foo() {
  return {}; // ok
}

EDIT : évidemment j'ai la manie de poster sans lire les réponses et parfois même sans lire la question, du coup si j'ai dit des trucs déjà dit vous pouvez les ignorer

-
Edité par JadeSalina 14 mai 2022 à 16:30:25

JadeSalina a écrit:

grâce à la guaranteed copy elision (qui comme les autres concepts de C++ porte mal son nom et ne veut pas dire que la copie sera optimisée, mais bien qu'il n'y aura tout simplement pas de copie en premier lieu).

Du coup, le nom est correct, à moins qu'on n'a pas la même définition de "elision".

A noter que la première version peut fonctionner avec une classe non copiable, si cette classe est movable. (Dans ton code, ta classe est non copiable et non movable). Et la seconde version peut fonctionner également sans la guaranteed copy elision (donc en C++11 et C++14), si elle est movable.

La seconde fonctionne même sans la nécessité d'être déplaçable puisque c'est une direct-initialisation qui est utilisée. Par contre, return Foo{} nécessiterait d'être déplaçable avant C++17.

gbdivers a écrit:

JadeSalina a écrit:

grâce à la guaranteed copy elision (qui comme les autres concepts de C++ porte mal son nom et ne veut pas dire que la copie sera optimisée, mais bien qu'il n'y aura tout simplement pas de copie en premier lieu).

Du coup, le nom est correct, à moins qu'on n'a pas la même définition de "elision".

A noter que la première version peut fonctionner avec une classe non copiable, si cette classe est movable. (Dans ton code, ta classe est non copiable et non movable). Et la seconde version peut fonctionner également sans la guaranteed copy elision (donc en C++11 et C++14), si elle est movable.

Oui ce que j'appelle "copy elision" c'est : on ne fait pas la copie qui aurait dû être faite en temps normal (dans un soucis d'optimisation), mais la guaranteed copy elision (eux ils appellent ça mandatory copy elision) veut dire qu'il n'y a pas de copie du tout (et pas simplement une copie supprimée par optimisation) donc il faudrait pas appeler ça copy "elision".

"Note: the rule above does not specify an optimization: C++17 core language specification of prvalues and temporaries is fundamentally different from that of the earlier C++ revisions: there is no longer a temporary to copy/move from. Another way to describe C++17 mechanics is "unmaterialized value passing": prvalues are returned and used without ever materializing a temporary."

https://en.cppreference.com/w/cpp/language/copy_elision

Ca reste de la copy elision dans les 2 cas. La différence, c'est qu'avant, ce n'était pas dans la norme et qu'ensuite ca était ajouté. Mais c'est la même technique d'optimisation.

Bref, c'est du chipotage sans intérêt de dire que le nom est mal choisi.

La question est posée sur des entiers, donc la problématique n'est pas sur les objets copiables ou pas.

C'est juste une affaire de style d'écriture du code. Celui du cours est épouvantable.

Concrètement, définir et initialiser une variable juste pour retourner sa valeur, ça n'apporte rien. Ca complique au lieu de simplifier.

-
Edité par michelbillaud 15 mai 2022 à 6:50:38