Pourquoi sont des références pas reseatable en C++

La raison que le C++ ne permet pas de relier des références est donnée dans de Stroustrup "la Conception et l'Évolution de C++" :

Il n'est pas possible de changer ce qu'un renvoi fait référence à la fin de l'initialisation. C'est, une fois une référence C++ est initialisé, il ne peut être fait référence à un autre objet plus tard; il ne peut pas être re-lié. J'ai eu dans le passé été mordu par Algol68 références où r1=r2 peut soit affecter par r1 à l'objet visé ou d'affecter une nouvelle valeur de référence pour r1 (re-liaison r1) selon le type de r2. Je voulais éviter de tels problèmes en C++.

Car alors vous auriez pas reseatable type qui ne peut pas être 0. À moins que, vous avez inclus 3 types de références/pointeurs. Ce qui pourrait compliquer la langue pour très peu de gain (Et puis pourquoi ne pas ajouter la 4ème trop? Non reseatable de référence qui peut être égal à 0?)

Une meilleure question peut être, pourquoi voulez-vous des références à être reseatable? Si elles l'étaient, qui les rendrait moins utile dans beaucoup de situations. Il serait plus difficile pour le compilateur fasse analyse d'alias.

Il semble que la raison principale des références en Java ou C# sont reseatable est parce qu'ils font le travail de pointeurs. Ils désignent des objets. Ils ne sont pas des alias pour un objet.

Ce qui devrait l'effet de la suite être?

int i = 42;
int& j = i;
j = 43;

En C++ aujourd'hui, avec les non-reseatable des références, c'est simple. j est un alias pour moi, et je termine avec la valeur 43.

Si les références ont été reseatable, puis troisième ligne à lier la référence j d'une valeur différente. Il n'aurait plus alias je, mais plutôt l'entier littéral 43 (ce qui n'est pas valide, bien sûr). Ou peut-être plus simple (ou au moins syntaxiquement valide) exemple:

int i = 42;
int k = 43;
int& j = i;
j = k;

Avec reseatable références. j aurait point de k après l'évaluation de ce code.
Avec C++de non-reseatable références, j toujours des points de i, et i est affectée de la valeur 43.

En faisant des références reseatable la sémantique de la langue. La référence ne peut plus être un alias pour une autre variable. Au lieu de cela, il devient un type distinct de la valeur, avec son propre opérateur d'affectation. Et puis, l'une des utilisations les plus courantes de références serait impossible. Et n'avait rien à gagner en échange. La nouvellement acquise, la fonctionnalité pour les références existait déjà sous la forme de pointeurs. Alors maintenant, nous aurions deux façons de faire la même chose, et aucun moyen de faire ce que les références dans le courant de langage C++ ne.

Un reseatable de référence serait fonctionnellement identique à un pointeur.

Concernant la possibilité de valeur null: vous ne pouvez pas garantir qu'un tel "reseatable de référence" est non NULLE au moment de la compilation, un tel examen aurait lieu au moment de l'exécution. Vous pourriez réaliser vous-même par l'écriture d'un pointeur intelligent de style de modèle de classe qui lève une exception lors de l'initialisation ou affectés NULL:

struct null_pointer_exception { ... };

template<typename T>
struct non_null_pointer {
    //No default ctor as it could only sensibly produce a NULL pointer
    non_null_pointer(T* p) : _p(p) { die_if_null(); }
    non_null_pointer(non_null_pointer const& nnp) : _p(nnp._p) {}
    non_null_pointer& operator=(T* p) { _p = p; die_if_null(); }
    non_null_pointer& operator=(non_null_pointer const& nnp) { _p = nnp._p; }

    T& operator*() { return *_p; }
    T const& operator*() const { return *_p; }
    T* operator->() { return _p; }

    //Allow implicit conversion to T* for convenience
    operator T*() const { return _p; }

    //You also need to implement operators for +, -, +=, -=, ++, --

private:
    T* _p;
    void die_if_null() const {
        if (!_p) { throw null_pointer_exception(); }
    }
};

Ce qui peut être utile à l'occasion, -- une fonction prenant un non_null_pointer<int> paramètre certainement communique plus d'informations à l'appelant qu'une fonction prenant int*.

Intrestingly, beaucoup de réponses ici sont un peu floue ou même à côté de la question (par exemple, ce n'est pas parce que les références ne peuvent pas être zéro ou similaire, en fait, vous pouvez facilement construire un exemple de cas où la référence est égale à zéro).

La vraie raison pour laquelle la re-définition d'une référence n'est pas possible, est plutôt simple.

• Pointeurs de vous permettre de faire deux choses: Pour modifier la valeur derrière le pointeur (soit par le biais de la -> ou la * opérateur), et de modifier le pointeur lui-même (direct attribuer =). Exemple:

  int a;
  int * p = &a;

  1. La modification de la valeur nécessite un déréférencement: *p = 42;
  2. La modification du pointeur: p = 0;

• Références vous permettent de modifier la valeur. Pourquoi? Depuis il n'y a pas d'autre syntaxe pour exprimer la re-régler. Exemple:

  int a = 10;
  int b = 20;
  int & r = a;
  r = b; //re-set r to b, or set a to 20?

En d'autres termes, il serait ambiguë si vous avez été autorisé à re-définir une référence. Il fait encore plus de sens lorsque le passage par référence:

void foo(int & r)
{
    int b = 20;
    r = b; //re-set r to a? or set a to 20?
}
void main()
{
    int a = 10;
    foo(a);
}

Espère que ça aide 🙂

Vous ne pouvez pas faire ceci:

int theInt = 0;
int& refToTheInt = theInt;

int otherInt = 42;
refToTheInt = otherInt;

...pour la même raison pourquoi secondInt et firstInt n'ont pas la même valeur ici:

int firstInt = 1;
int secondInt = 2;
secondInt = firstInt;
firstInt = 3;

assert( firstInt != secondInt );

J'imagine que c'est lié à l'optimisation.

Statique d'optimisation est beaucoup plus facile quand vous pouvez connaître sans ambiguïté que peu de mémoire d'une variable de moyens. Les pointeurs de briser cette condition et re-paramètrables de référence serait de trop.

Je me suis toujours demandé pourquoi ils ne font pas une référence opérateur d'affectation (disons :=) pour ce.

Juste pour obtenir sur quelqu'un de nerfs, j'ai écrit un peu de code pour changer la cible d'une référence dans une structure.

Non, je ne recommande pas de répéter mon truc. Il va se casser si porté suffisamment d'architecture différents.

Le fait que les références en C++ ne sont pas les valeurs null est un effet secondaire d'entre eux étant qu'un alias.

Il y a une solution de contournement si vous voulez une variable de membre qui est une référence et vous voulez être en mesure de relier à elle. Bien que je trouve qu'il est utile et fiable, note qu'il utilise (très faible) hypothèses sur la disposition de la mémoire. C'est à vous de décider si c'est à l'intérieur de vos normes de codage.

#include <iostream>

struct Field_a_t
{
    int& a_;
    Field_a_t(int& a)
        : a_(a) {}
    Field_a_t& operator=(int& a)
    {
        //a_.~int(); //do this if you have a non-trivial destructor
        new(this)Field_a_t(a);
    }
};

struct MyType : Field_a_t
{
    char c_;
    MyType(int& a, char c)
        : Field_a_t(a)
        , c_(c) {}
};

int main()
{
    int i = 1;
    int j = 2;
    MyType x(i, 'x');
    std::cout << x.a_;
    x.a_ = 3;
    std::cout << i;
    ((Field_a_t&)x) = j;
    std::cout << x.a_;
    x.a_ = 4;
    std::cout << j;
}

Ce n'est pas très efficace que vous avez besoin d'un type distinct pour chaque reassignable champ de référence et de leur faire des classes de base; de plus, il y a une faiblesse de l'hypothèse ici qu'une classe a un seul type de référence n'ont pas une __vfptr ou de tout autre type_iddomaine qui pourrait détruire exécution des liaisons de MyType. Tous les compilateurs je sais satisfaire à cette condition (et il serait insensé de ne pas le faire).