L'initialisation d'une référence à un membre de la valeur NULL en C++

Est-il possible d'initialiser un membre de référence à NULL en c++?

J'essaie à quelque chose comme ceci: 

class BigClass
{
private:
  Object m_inner;
public:
  const Object& ReadOnly;
  BigClass() : ReadOnly(NULL)
  {
    Do stuff.
  }
};

Je sais que je peux le faire si j'initialise "ReadOnly" à une véritable référence d'un objet, mais quand je veux mettre dedans "NULL", j'obtiens l'erreur:

"impossible de convertir de 'int' à 'const Objet &"

Comment puis-je résoudre ce problème?

  • Le point de référence est de rendre cela impossible. L'utilisation régulière d'un pointeur à la place.
  • Vous pouvez le faire { const Objet& ReadOnly = *(Objet*)NULL; } Mais sa moche. Le pré-processeur enlève juste le & et le *
  • pré-processeur enlève juste le & et le *" non-sens
  • hem... permettez-moi de préciser hater. Le préprocesseur annule *& combo. Le déclarant à l'aide de réf & est juste en deçà de la main de sorte que vous n'avez pas besoin d'utiliser l'option -> il court à la main pour (*la).chose. donc là 😉
  • Le préprocesseur C++ n'a pas une telle chose.
  • Désolé pré-compilateur

InformationsquelleAutor Idov | 2012-01-29
  1. 28

    Pas, les références ne peuvent pas être NULL en C++.1

    Solutions possibles incluent:

    • l'aide d'un pointeur au lieu d'une référence.
    • avoir un mannequin Object instance qui peut être utilisé pour indiquer "sans objet".

    [1] à Partir de la C++11:

    [dcl.ref] [...] une référence null ne peut pas exister dans un programme bien défini, parce que la seule façon de créer une telle référence serait à lier à la “objet” obtenue par le déréférencement d'un pointeur null, ce qui provoque un comportement indéfini.

    • Yep, ne le faites pas, c'est un comportement indéterminé.
    • Quelle partie?
    • la référence n'est pas chose de magique. Référence peut pointer sur NULL. Par exemple : Objet& objet = ( Objet ) NULLE.
    • Qui ne compile pas.
    • Objet& objet = * ( Objet * ) NULL
    • Il n', la dernière fois que astérisques ont été supprimés par stackoverflow, désolé.
    • Ok, mais c'est simplement un comportement indéterminé. Et la C++ standard appelle explicitement ceci: "une référence null ne peut pas exister dans un programme bien défini, parce que la seule façon de créer une telle référence serait à lier à la “objet” obtenue par le déréférencement d'un pointeur null, ce qui provoque un comportement indéfini".
    • oui, ce n'est pas la technique la plus répandue, et il ya un trop grand nombre de coutumes autour de ce genre de choses. quelques programmeurs du siècle précédent, fait tout leur possible pour forcer le monde à penser d'une manière qu'ils aiment. ils réussissent 🙂 seulement. ce qui concerne.

    InformationsquelleAutor Oliver Charlesworth
  2. 10

    Vous ne pouvez pas "résoudre" ce. Utiliser un pointeur si vous voulez être en mesure d'avoir ce membre pas pour rien.

    Référence doit être initialisée à un objet réel, ils ne peuvent pas "point de nulle part".

    • dépend. Pointeurs intelligents impliquent généralement la propriété. Parfois vous voulez juste pour pointer vers quelque chose sans revendique la propriété. Bien sûr, vous pourriez utiliser une faible pointeur, mais cela nécessite l'allocation de l'objet sur le tas: pas de pile de objet alloué, aucun attribut d'un plus grand objet, etc... les Pointeurs Intelligents sont PAS une panacée.
    InformationsquelleAutor Mat
  3. 7

    Il peut être fait, mais il est presque certainement une très mauvaise idée. La façon de le faire est de déréférencer correctement tapé NULL pointeur qui montre déjà que c'est une mauvaise idée: vous arrivez à un comportement non défini à ce stade, qui, cependant, généralement, tend à "travailler".

    En C++ références sont destinés à se réfèrent toujours à un objet réel. C'est différent pour d'autres langages de programmation où les "références" sont en fait l'équivalent de pointeurs en C++ (généralement sans des choses comme l'arithmétique des pointeurs). Ce que vous avez probablement fait envie (vous n'a malheureusement pas dire ce que vous essayez d'atteindre, mais a demandé une solution à un problème qui est sans doute un élément d'une approche erronée) est d'utiliser un pointeur à la place:

    Object const* const readOnly;
BigClass(): readOnly(0) {}
    • Mon préféré répondre. J'ai juste eu à déboguer un complexe de classe, et besoin d'appeler une fonction unique, avec un certain objet. 0 référencé toutes les références comme décrit, construit obj, ignoré les références, la fonction appelée, a résolu le problème, défait tout. Évidemment pas quelque chose que vous voulez faire de manière permanente si.
    InformationsquelleAutor Dietmar Kühl
  4. 2

    Utiliser un pointeur:-
    const Objet* pReadOnly;

    InformationsquelleAutor QuentinUK
  5. 0

    Il est utile dans la rédaction de l'unité-tests. C'est le seulement endroit où il doit être fait, mais là, c'est tout à fait utile.

     Bar& bar(*static_cast<Bar*>(0));
 MockClass mock; //derives from RealClass
 mock.foo(bar);

    Ici, je suis en train de tester le code qui utilise MockClass, pas MockClass lui-même.

    Ce n'est pas une panacée, mais il peut aider. Aussi, GoogleMock pourrait être votre ami si vous êtes moqueur "béton" des classes.

    struct Bar;
struct RealClass {
  int& x_;
  double& y_;
  RealClass(int& x, double& y) :x_(x), y_(y) {}
  virtual void foo(Bar&);
};
struct MockClass: public RealClass {
  MockClass(): RealClass(*(int*)0, *(double*)0) {}
  MOCK_METHOD1(foo, void(Bar&));
};
    • Bas-votants: Essayez cette sans à l'aide d'une référence NULL. Très difficile! Dans le cas où il n'est pas évident, nous avons pour objectif de code de test qui utilise un RealClass, et qui appelle foo() sur que RealClass. Nous injecter à la fois la RealClass et la Bar instances. MockClass doit appeler le constructeur de RealClass, mais les données sous-jacentes ne sont jamais nécessaires. C'est valable de cas d'utilisation, cessez donc de la baisse de vote.
    • Si vous avez besoin d'écrire ce genre de tests, je pense que vous avez un sérieux problème de conception.
    • Code hérité ou non, présentant un comportement indéfini dans les tests unitaires est une idée terrible.
    • Ce n'est pas un comportement indéfini. Et il répond à la question. Downvote la question, pas une réponse.
    • C'est UB. (voir stackoverflow.com/questions/7130878/...).
    • Dans la pratique, l'absense de comportement. Si vous passez à un compilateur où il échoue, supprimer le test. Mais vous avez raison: Il vaut la peine de déconseillent l'utilisation de ce dans le code de production.
    • Merci @cdunn2001! Il était très utile de se moquer de l'unité de tester mon application avec z gtkmm.

    InformationsquelleAutor cdunn2001