Passage de paramètre par référence en c++

Je vais avoir un problème avec l'option paramètre de fonction en C++

Ce que j'essaie de faire est d'écrire de la fonction avec le paramètre optionnel qui est passé par référence, afin que je puisse l'utiliser de deux manières (1) et (2), mais sur (2) je ne m'en soucie pas vraiment quelle est la valeur de mFoobar.

J'ai essayé ce code:

void foo(double &bar, double &foobar = NULL)
{
   bar = 100;
   foobar = 150;
}

int main()
{
  double mBar(0),mFoobar(0);

  foo(mBar,mFoobar);              //(1)
  cout << mBar << mFoobar;

  mBar = 0;
  mFoobar = 0;

  foo(mBar);                     //(2)
  cout << mBar << mFoobar;

  return 0;
}

mais il bloque au 

void foo(double &bar, double &foobar = NULL)

avec le message :

error: default argument for 'double& foobar' has type 'int'

Est-il possible de le résoudre sans surcharge de fonctions?

  • Bien sûr que non, même si vous pouvez passer une référence NULLE, que pensez-vous arriverait-il au sein de la fonction lorsque vous avez essayé de lui affecter une valeur ?
  • Erreur de Compilation n'est pas un accident.
  • Votre code n'est pas "s'écraser", il obtient une erreur de compilation. Une panne peut se produire après que vous avez entièrement construit votre programme et de tenter de l'exécuter.
  • double possible de la valeur par Défaut à un paramètre alors que le passage par référence en C++
  • Toute personne dans cette situation doit vraiment avaler leur fierté et préférences esthétiques et utiliser un *const pointeur. C'est une indirection, tout comme une référence, mais avec la possibilité de valeur null/testabilité. Pourquoi compliquer les choses avec des variables nominales, la dilatation de Boost, etc - quand la langue fournit une des fonctions de base qui correspond à la facture précisément pour autant que je peux dire?
InformationsquelleAutor Moomin | 2010-05-12
  1. 28

    L'argument par défaut d'un (mutable) de référence doit être une l-value. Le mieux que je peux penser, sans surcharge, est

    static double _dummy_foobar;
void foo(double &bar, double &foobar = _dummy_foobar)
    • Il peut être intéressant de définir lvalue pour la personne. (Essentiellement, et de façon informelle, "quelque chose qui peut être attribué à.")
    • Cette définition est commune, mais mal. Certains rvalues peuvent également être affectés, par exemple std::string("hello") = world, et certains lvalues ne peut être affectée, par exemple C-les tableaux et les objets sans un opérateur d'affectation. (Aussi, const lvalues ne peut être affectée, bien sûr, mais qui semble être bien compris.)
    • Cela peut introduire un subtil fil des questions de sécurité, si l'objet factice est jamais lu.
    • Pour plus de sécurité, définir _dummy_foobar dans un internal espace de noms et ne facultatif opérations avec foobar dans la fonction foo si &foobar!=&internal::_dummy_foobar pour éviter _dummy_foobar d'être accessible.
    • bien sûr, il répond à la question du degré limité que c'est possible, mais je m'interroge sur la motivation derrière la question... pourquoi s'embêter avec le désordre de l'attribution d'une inutile variable muette quand le C++ fournit déjà une alternative indirection qui est nullable/vérifiables? ça s'appelle un pointeur!
    • Alors que c'est une bonne réponse, je ne vois pas l'avantage par rapport à un pointeur. Si vous avez une option de paramètre de pointeur, et vous essayez d'y accéder, vous obtenez une erreur à l'exécution. Si vous utilisez un mannequin de référence, vous n'avez pas. Vous pouvez être en interaction avec un objet factice, et ne pas le savoir. Je préfère avoir une erreur d'exécution qui m'avise que je suis en train de faire quelque chose de mal. Maintenant, vous pourriez le comparer à la variable muette, et voir si le paramètre a en effet été spécifié; mais ensuite, vous pouvez faire le test si le pointeur est différent de zéro. Le point est, la détection de l'erreur est dans le cas où vous avez OUBLIÉ de test.
    • Cependant, je suis ouvert aux suggestions, réels avantages que cela peut avoir.

    InformationsquelleAutor kennytm
  2. 38

    Ne pas utiliser des références pour les paramètres facultatifs. Il n'y a pas de notion de référence NULL: une référence est toujours un alias à un objet particulier.

    Peut-être regarder boost::optional ou std::expérimental::optional. boost::optional est même spécialisé pour les types référence!

    void foo(double &bar, optional<double &> foobar = optional<double &>())
    InformationsquelleAutor Potatoswatter
  3. 31

    Pourquoi ne pouvez-vous pas utiliser la fonction de surcharge? Sûrement, c'est la meilleure solution à votre problème?

    void foo(double &bar, double &foobar) 
{ 
   bar = 100; 
   foobar = 150; 
}

void foo(double &bar) 
{ 
   double foobar = 0.0;
   foo(bar, foobar);
}
    • Mais je voulais juste savoir si il est possible de résoudre le problème sans surcharge. Imaginez de vous réveiller sur une île où les gens ont vraiment la haine surcharge :).
    • Je suppose que la "je déteste les paramètres par défaut" de l'île a beaucoup plus d'habitants 😉
    • la surcharge de fonction doit être la meilleure alternative à un mannequin bool traîne dans le fond de la classe, surtout quand il y a d'autres classes héritant de la classe de base.
    • silico Que si foo a plus de lignes de code et l'option réf variable foobar fait, seul des 4 lignes de code dans la première surcharge void foo(double &bar) ? puis cette idée, sera certainement une duplication de code, non?
    InformationsquelleAutor In silico
  4. 5

    Une autre façon de le faire est d'utiliser des pointeurs au lieu de références. Ceci fournit la sémantique que vous voulez sans surcharge. (Personnellement, je serais probablement aller avec la surcharge.)

    void foo(double* bar, double* foobar = 0)
{
   if (bar) *bar = 100;
   if (foobar) *foobar = 150;
}

   //...

   foo(&mBar, &mFoobar);

   //...

   foo(&mBar);

   //...
    • ce qui conduit à un tas de != || == nullptr répand aux quatre coins de l'univers et un gros mal de tête + retard dans le fait d'arriver à travailler lorsque le programmeur de la lecture de votre bibliothèque de 20 000 à nullptr et ** * * ** ** saupoudré partout ne peut pas savoir qui possède quoi, ce qui doit être spécifié et ce qui ne l'est pas, et a un léger accident vasculaire cérébral.
    • J'entends ce que vous dites, mais vous êtes à la survente de plus qu'un peu. Comme je l'ai dit, ma préférence va généralement utiliser la surcharge, mais j'ai souvent l'appel de ces publics de référence basé sur les fonctions surchargées en fonction privée pour faire le travail, dont je suis plus que satisfait, le passage de pointeurs et de faire de mon null vérifications.
    InformationsquelleAutor pkh
  5. 3

    Voici un autre fou de façon à ne pas entraîner des fuites de mémoire, que vous ne devez jamais utiliser dans la vie réelle, mais semble être conformes à la norme au premier coup d'œil et se compile avec Visual C++ 2008 & g++ 3.4.4 sous Cygwin:

    void foo(double &bar, double &foobar = (*((double*)0)))
{
   bar = 100;
   double* pfoobar = &foobar;
   if (pfoobar != 0)
       foobar = 150;
}

    À rappeler: NE faites PAS CELA! IL YA DE MEILLEURES OPTIONS! LA SURCHARGE PEUT ÊTRE VOTRE AMI! Mais oui, vous pouvez le faire si vous êtes stupide et le plus prudent. 🙂

    • Les références doivent désigner un objet au point de liaison de ref
    • il compile, peut-être... mais pour quoi faire? avez-vous essayer de l'exécuter? c'est pas "conforme à la norme", à tous, de sorte que le compilateur est libre de le traiter comme AC et de faire absolument n'importe quoi - comme la suppression de la chose qui doit arriver si elle n'est pas NULLE, ou l'intégralité de l'appel de la fonction, ou le soufflage de votre grille-pain. qui s'en soucie?
    • L'un, oui j'ai essayer de l'exécuter. J'y ai fait allusion qu'avec ma référence à deux compilateurs ci-dessus. De deux, je suppose mea culpa pour la lecture un peu rapide et lâche avec le concept de "respect des normes" près de cinq ans. À aucun moment, je cite le chapitre et le verset, et à aucun moment je dis qu'il a été défini comportement. De trois, je l'ai dit à plusieurs reprises qu'il y avait de meilleurs moyens. Peut-être que vous ne voyez pas le texte ci-dessus et ci-dessous l'exemple de code que j'ai posté. Je pense que le point d'origine est assez clair qu'il y a beaucoup de mauvaises choses qui peut être fait du point de vue syntaxique, mais qui ne devrait pas être fait.
    InformationsquelleAutor CasaDeRobison
  6. 1

    Il est beaucoup plus facile d'utiliser un pointeur de type et la valeur NULL de la configuration par défaut d'option et/ou de la valeur pour un paramètre de référence.

    • Il est beaucoup plus facile pour vous lorsque vous écrivez votre programme. C'est un mélange confus de "ce qui est défini, qui la définit, quelqu'un a définir ensuite les garder ou de la main sur la propriété, dois-je gérer cela?" pour quelqu'un d'autre en train d'essayer de l'utiliser.
    • D'autre part, les références peuvent être un mélange confus de "est-ce la fonction de la bibliothèque va changer ma variable ou pas?", ce qui peut conduire à enfiler des questions de sécurité, entre autres choses. C'est un autre cas de C/C++ en vous laissant dans l' "pour évaluer votre situation particulière" bateau. Les deux peuvent être des outils utiles dans la boîte à outils.
    • Shaw: C'est pourquoi vous avez const références. À moins que la fonction de la bibliothèque prend une const de référence, vous devez supposer qu'il va changer votre variable. Les références doivent être préférés aux pointeurs dans la plupart des cas.
    • Je suis d'accord avec vous, mais le problème est de deux ordres. La première question est beaucoup trop de programmeurs de ne pas comprendre et de ne pas utiliser const de la façon dont il est destiné à être utilisé (trop souvent ses entendue comme "constante" plutôt que de "lecture seule"). Ce qui laisse les gens en utilisant des bibliothèques dans la situation où ils N'ont à assumer des variables sera modifié et programme autour de cette hypothèse. Le même est vrai avec des pointeurs.
    • L'autre partie est que ce n'est pas toujours clair que vous faites affaire avec un passage par référence plutôt que d'un passage par valeur. Vous devez regarder à la déclaration. Bien sûr, si vous êtes d'écrire du nouveau code vous, mais si un responsable vient le long, ils risquent de manquer ce détail. Au moins avec les pointeurs, vous SAVEZ ce que vous faites affaire avec, et vous pouvez toujours utiliser const avec des pointeurs... pour ne Pas dire qu'on ne doit jamais utiliser de passage par référence, juste qu'il a des inconvénients à prendre en compte.
    • Peut-être que vous n'aimez pas les pointeurs, mais vos objections semblent alias ranty, n'est pas pertinent. L'idée de désordre, est discutable: une théorie "référence null" contraindrait les mêmes contrôles. La chose à propos de la propriété est un leurre quand on peut juste (A) la vérification de la déclaration et de la documentation autour de lui - quelque chose que vous devez faire lors du passage d'un non-pointeur de toute façon, afin de déterminer s'il peut être considéré comme un non-const de référence... ou (B) supposons qu'un pointeur brut est non propriétaire, puisque nous avons la STL _ptr classes pour signifier à la propriété et à utiliser les sémantiquement.

    InformationsquelleAutor Zorayr
  7. 0

    Parler en termes de paradigme Orienté Objet: Si la classe a et "par Défaut", ce Défaut doit déclarée en conséquence, et puis peut être utilisé comme un "Paramètre par Défaut"
    Ex:

    class Pagination {
private:
    int currentPage;
public:

    //...
    Pagination() {
        currentPage = 1;
        //...
    }

    //your Default Pagination (Must be initialized before thread concurrency)
    static Pagination& Default() {
        static Pagination p; 
        return p;
    }
};

    Sur votre Méthode ...

         //...
     std::vector<User>
     findByFilter(User& audit, Pagination& p = Pagination::Default() ) {
     //...

    Édité: Cette solution est tout à fait approprié puisque dans ce cas c'est un "par défaut" de la Pagination et une seule "référence" de la valeur. Vous aurez également le pouvoir de changer les valeurs par défaut telles que la navigation/préférences d'affichage et etc.

    Edit2: l'orthographe et la fixation...

    InformationsquelleAutor wdavilaneto
  8. -1

    C'est comment j'ai résolu cette question:

    Ma fonction d'origine n'ont pas renvoyé l'erreur de chaîne de caractères:
    bool Maclasse::validateXML(const QString& fileName, const QUri& schemaUri);

    Je voulais ajouter les résultats de la validation dans une chaîne d'erreur donc j'ai mis en place:
    bool Maclasse::validateXML(const QString& fileName,
    const QUri& schemaUri,
    QString& errorString = *(std::make_unique().get()));

    De cette façon, vous pouvez faire référence à la errorString dans validateXML sans vérifier s'il est valide, et pas de fuites de mémoire.

    • brr, chose effrayante à voir.Pourquoi ne pas vous venez de déclarer un QString et de le transmettre? Le code n'a pas encore d'établir de toute façon.
    InformationsquelleAutor Bobby_Zero
  9. -5

    Vous pouvez le faire complètement folle:

    void foo(double &bar, double &foobar = (*(new double())))

    P. S. - je sais que c'est pas agréable, mais son chemin. Assurez-vous également de ne pas laisser les fuites de mémoire! :))

    • Même si elle ne provoque pas d'un comportement indéterminé, ce qui serait un mécanisme possible pour la suppression en toute sécurité le paramètre facultatif dans le cas où il a été effectivement utilisé?
    • faire un smart_ptr et vous êtes sur!
    • Il n'y a aucun moyen d'éviter une fuite - vous ne pouvez pas dire à l'intérieur de la fonction si la mémoire a été allouée par l'argument par défaut ou pas, et il n'y a aucun moyen à l'extérieur de la fonction, à savoir le pointeur. Vous êtes arrosé (et fuite)!
    InformationsquelleAutor faya