wake-up-neo.net

Wann werden Referenzen und Zeiger verwendet?

Ich verstehe die Syntax und die allgemeine Semantik von Zeigern im Vergleich zu Verweisen, aber wie soll ich entscheiden, wann mehr oder weniger angemessen ist, Verweise oder Zeiger in einer API zu verwenden?

Natürlich benötigen manche Situationen die eine oder andere (operator++ benötigt ein Referenzargument), aber im Allgemeinen ziehe ich die Verwendung von Zeigern (und Konstantenzeigern) vor, da die Syntax eindeutig ist, dass die Variablen destruktiv übergeben werden.

Z.B. im folgenden Code:

void add_one(int& n) { n += 1; }
void add_one(int* const n) { *n += 1; }
int main() {
  int a = 0;
  add_one(a); // Not clear that a may be modified
  add_one(&a); // 'a' is clearly being passed destructively
}

Mit dem Zeiger ist es immer (mehr) offensichtlich, was los ist. Für APIs und dergleichen, bei denen Klarheit ein großes Problem ist, sind Zeiger nicht geeigneter als Verweise. Bedeutet das, dass Referenzen nur dann verwendet werden sollten, wenn dies erforderlich ist (z. B. operator++)? Gibt es irgendwelche Leistungsprobleme mit dem einen oder anderen?

BEARBEITEN (AUSGEZEICHNET):

Neben dem Zulassen von NULL-Werten und dem Umgang mit rohen Arrays scheint die Wahl auf persönliche Vorlieben zurückzuführen. Ich habe die Antwort unter den Referenzen akzeptiert - C++ Style Guide von Google , da sie die Ansicht vertreten, dass "Referenzen verwirrend sein können, da sie eine Wertesyntax, aber Zeigersemantik haben.".

Aufgrund der zusätzlichen Arbeit, die erforderlich ist, um Zeigerargumente zu bereinigen, die nicht NULL sein sollten (z. B. add_one(0) ruft die Zeigerversion auf und bricht zur Laufzeit ab), ist es aus Sicht der Wartungsfreundlichkeit sinnvoll, Referenzen zu verwenden, bei denen ein Objekt MUSS vorhanden sein, obwohl es ein ist Schade um die syntaktische Klarheit zu verlieren.

346
connec

Verwenden Sie Verweise, wo immer Sie können, Verweise, wo immer Sie müssen.

Vermeiden Sie Zeiger, bis Sie es nicht können.

Der Grund ist, dass Zeiger das Lesen/Lesen schwieriger machen, weniger sicher und weitaus gefährlichere Manipulationen als andere Konstrukte.

Die Faustregel lautet also, Zeiger nur zu verwenden, wenn keine andere Wahl besteht. 

Die Rückgabe eines Zeigers auf ein Objekt ist beispielsweise eine gültige Option, wenn die Funktion in einigen Fällen nullptr zurückgeben kann und davon ausgegangen wird, dass dies der Fall ist. Eine bessere Option wäre die Verwendung von boost::optional.

Ein anderes Beispiel ist die Verwendung von Zeigern auf den Rohspeicher für bestimmte Speichermanipulationen. Das sollte in sehr engen Teilen des Codes versteckt und lokalisiert sein, um die gefährlichen Teile der gesamten Codebasis zu begrenzen. 

In Ihrem Beispiel hat es keinen Sinn, einen Zeiger als Argument zu verwenden, weil:

  1. wenn Sie als Argument nullptr angeben, gehen Sie in undefined-behaviour-land.
  2. die Referenzattributversion erlaubt (ohne leicht zu erkennende Tricks) das Problem mit 1.
  3. die Version des Referenzattributs ist für den Benutzer einfacher zu verstehen: Sie müssen ein gültiges Objekt angeben, und nicht etwas, das Null sein könnte.

Wenn das Verhalten der Funktion mit oder ohne ein gegebenes Objekt funktionieren müsste, schlägt die Verwendung eines Zeigers als Attribut vor, dass Sie nullptr als Argument übergeben können. Das ist eine Art Vertrag zwischen dem Benutzer und der Implementierung.

264
Klaim

Die Leistungen sind exakt gleich, da Referenzen intern als Zeiger implementiert werden. Sie brauchen sich darum keine Sorgen zu machen.

Es gibt keine allgemein anerkannte Konvention hinsichtlich der Verwendung von Referenzen und Zeigern. In einigen Fällen müssen Sie Referenzen zurückgeben oder akzeptieren (z. B. Copy Constructor), aber ansonsten können Sie nach Belieben arbeiten. Eine häufig anzutreffende Konvention ist die Verwendung von Referenzen, wenn der Parameter auf ein vorhandenes Objekt und Zeiger verweisen muss, wenn ein NULL-Wert in Ordnung ist.

Einige Codierungskonventionen (wie Googles ) schreiben vor, dass man immer Zeiger oder const-Referenzen verwenden sollte, da Referenzen etwas unklare Syntax haben: Sie haben Referenzverhalten, jedoch Wertsyntax.

56
Andrea Bergia

Von C++ FAQ Lite

Verwenden Sie Verweise, wenn Sie können, und Verweise, wenn Sie müssen.

Verweise werden in der Regel den Zeigern vorgezogen, wenn Sie nicht .__ benötigen. "Wiedersetzen". Dies bedeutet normalerweise, dass Verweise in einer .__ am nützlichsten sind. öffentliche Schnittstelle der Klasse. Verweise werden normalerweise auf der Skin von .__ angezeigt. ein Objekt und Zeiger innen.

Die Ausnahme zu dem oben genannten ist, wo Parameter einer Funktion oder Rückgabe Wert benötigt eine "Sentinel" -Referenz - eine Referenz, die nicht verweist zu einem Objekt. Dies geschieht in der Regel am besten, indem Sie einen Zeiger zurückgeben. und dem NULL-Zeiger diese besondere Bedeutung verleihen (Verweise müssen immer Alias-Objekte, nicht ein dereferenzierter NULL-Zeiger).

Hinweis: Alte Line-C-Programmierer mögen ab Version _ keine Referenzen. Sie bieten eine Referenzsemantik, die in der .__ des Aufrufers nicht explizit ist. Code. Nach etwas Erfahrung mit C++ erkennt man jedoch schnell, dass dies .__ ist. eine Form der versteckten Information, die eher ein Vermögenswert als ein .__ ist. Haftung. Zum Beispiel sollten Programmierer Code in der Sprache von .__ schreiben. Problem und nicht die Sprache der Maschine.

31
Mahesh

Meine Faustregel lautet:

  • Verwenden Sie Zeiger für ausgehende oder ein-/ausgehende Parameter. Es ist also ersichtlich, dass der Wert geändert wird. (Sie müssen & verwenden)
  • Verwenden Sie Zeiger, wenn der Parameter NULL ein akzeptabler Wert ist. (Stellen Sie sicher, dass es const ist, wenn es sich um einen eingehenden Parameter handelt.)
  • Verwenden Sie Referenzen für eingehende Parameter, wenn dieser nicht NULL sein kann und kein primitiver Typ (const T&) ist.
  • Verwenden Sie Zeiger oder intelligente Zeiger, wenn Sie ein neu erstelltes Objekt zurückgeben.
  • Verwenden Sie Zeiger oder intelligente Zeiger anstelle von Verweisen als Struktur- oder Klassenmitglieder.
  • Verweise für Aliasing verwenden (zB int &current = someArray[i])

Unabhängig davon, welche Sie verwenden, vergessen Sie nicht, Ihre Funktionen und die Bedeutung ihrer Parameter zu dokumentieren, wenn sie nicht offensichtlich sind.

14
Calmarius

Wie andere bereits beantwortete: Verwenden Sie immer Referenzen, es sei denn, die Variable, die NULLnullptr ist, ist _/really ein gültiger Status.

John Carmacks Standpunkt zu diesem Thema ist ähnlich:

NULL-Zeiger sind das größte Problem in C/C++, zumindest in unserem Code. Die doppelte Verwendung eines einzelnen Werts als Flag und Adresse führt zu einer unglaublichen Anzahl fataler Probleme. C++ - Referenzen sollten nach Möglichkeit gegenüber Zeigern bevorzugt werden. Ein Verweis ist zwar „wirklich“ nur ein Zeiger, er hat jedoch den impliziten Vertrag, nicht NULL zu sein. Führen Sie NULL-Überprüfungen durch, wenn Zeiger in Verweise umgewandelt werden. Anschließend können Sie das Problem ignorieren.

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

Bearbeiten 2012-03-13

Benutzer Bret Kuhns bemerkt zu Recht:

Der C++ 11-Standard wurde abgeschlossen. Ich denke, es ist an der Zeit in diesem Thread zu erwähnen, dass der meiste Code mit einer Kombination von Referenzen, shared_ptr und unique_ptr, perfekt funktionieren sollte.

Das stimmt, aber die Frage bleibt immer noch bestehen, selbst wenn rohe Zeiger durch intelligente Zeiger ersetzt werden.

Beispielsweise können std::unique_ptr und std::shared_ptr durch ihren Standardkonstruktor als "leere" Zeiger konstruiert werden:

... was bedeutet, dass die Verwendung von ihnen, ohne zu überprüfen, dass sie nicht leer sind, einen Absturz bedeutet. Genau darum geht es bei J. Carmack.

Und dann haben wir das amüsante Problem "Wie übergeben wir einen intelligenten Zeiger als Funktionsparameter?"

Jon 's antwort für die Frage C++ - Weitergabe von Verweisen auf boost :: shared_ptr , und die folgenden Kommentare zeigen, dass selbst dann ein Smart Pointer per Kopie oder durch Verweis nicht übergeben wird klarer schnitt wie man möchte (ich bevorzuge mir standardmäßig die "by-reference", aber ich könnte mich irren).

12
paercebal

Haftungsausschluss: Abgesehen von der Tatsache, dass Referenzen nicht NULL oder "Rebound" sein können (was bedeutet, dass das Objekt, das sie als Aliasnamen verwenden, nicht geändert werden kann), kommt es wirklich auf Geschmackssache an, also werde ich nicht sagen "das ist besser".

Das heißt, ich stimme nicht mit Ihrer letzten Aussage in dem Beitrag überein, da ich glaube, dass der Code nicht an Klarheit verliert. In Ihrem Beispiel

add_one(&a);

könnte klarer sein als

add_one(a);

da Sie wissen, dass sich der Wert von a höchstwahrscheinlich ändern wird. Auf der anderen Seite jedoch die Signatur der Funktion

void add_one(int* const n);

ist auch etwas unklar: Wird n eine einzelne ganze Zahl oder ein Array sein? Manchmal haben Sie nur Zugriff auf (schlecht dokumentierte) Header und Signaturen wie

foo(int* const a, int b);

sind auf den ersten Blick nicht leicht zu interpretieren.

Imho, Referenzen sind so gut wie Zeiger, wenn keine (Neu-) Zuweisung oder Umbindung (in dem zuvor erläuterten Sinn) erforderlich ist. Wenn ein Entwickler nur Zeiger für Arrays verwendet, sind die Funktionssignaturen etwas weniger eindeutig. Ganz zu schweigen von der Tatsache, dass die Operatorsyntax mit Referenzen viel besser lesbar ist.

12
bartgol

Es ist keine Geschmackssache. Hier sind einige definitive Regeln.

Wenn Sie sich auf eine statisch deklarierte Variable innerhalb des Gültigkeitsbereichs beziehen möchten, in dem sie deklariert wurde, verwenden Sie eine C++ - Referenz, die absolut sicher ist. Gleiches gilt für einen statisch deklarierten Smart Pointer. Das Übergeben von Parametern als Referenz ist ein Beispiel für diese Verwendung.

Wenn Sie sich auf etwas beziehen möchten, das über einen Bereich hinausgeht, der über den angegebenen Bereich hinausgeht, sollten Sie einen intelligenten Referenzzeiger verwenden, damit dieser absolut sicher ist.

Sie können auf ein Element einer Auflistung mit einer Referenz zur Vereinfachung der Syntax verweisen, dies ist jedoch nicht sicher. Das Element kann jederzeit gelöscht werden.

Um einen Verweis auf ein Element einer Sammlung sicher zu halten, müssen Sie einen intelligenten Referenzzeiger verwenden.

7
John Morrison

Jeder Leistungsunterschied wäre so gering, dass er den weniger eindeutigen Ansatz nicht rechtfertigen würde.

Erstens ist ein Fall, bei dem Referenzen im Allgemeinen überlegen sind, const-Referenzen. Bei nicht einfachen Typen wird durch die Übergabe eines const reference die Erstellung eines temporären Elements vermieden und es entsteht keine Verwirrung, die Sie betreffen (da der Wert nicht geändert wird). Wenn Sie eine Person dazu zwingen, einen Zeiger zu übergeben, führt dies zu der Verwirrung, die Sie beunruhigen, da die Anzeige der Adresse, die an eine Funktion übergeben wird, den Eindruck erwecken könnte, dass sich der Wert geändert hat.

Auf jeden Fall stimme ich Ihnen grundsätzlich zu. Ich mag es nicht, dass Funktionen, die Verweise verwenden, ihren Wert ändern, wenn es nicht offensichtlich ist, dass dies die Funktion ist. Auch ich ziehe es vor, Zeiger in diesem Fall zu verwenden.

Wenn Sie einen Wert in einem komplexen Typ zurückgeben müssen, neige ich dazu, Referenzen zu bevorzugen. Zum Beispiel:

bool GetFooArray(array &foo); // my preference
bool GetFooArray(array *foo); // alternative

Der Funktionsname macht hier deutlich, dass Sie Informationen in einem Array zurückerhalten. Es gibt also keine Verwirrung.

Die Hauptvorteile von Referenzen sind, dass sie immer einen gültigen Wert enthalten, sauberer als Zeiger sind und Polymorphismus unterstützen, ohne dass eine zusätzliche Syntax erforderlich ist. Wenn keiner dieser Vorteile zutrifft, besteht kein Grund, eine Referenz einem Zeiger vorzuziehen.

5
David Schwartz

Aus Wiki - kopiert

Eine Folge davon ist, dass in vielen Implementierungen das Arbeiten mit einer Variablen mit automatischer oder statischer Lebensdauer durch eine Referenz, obwohl sie syntaktisch ähnlich ist wie der direkte Zugriff auf sie, verborgene Dereferenzierungsvorgänge beinhalten kann, die kostspielig sind. Verweise sind ein syntaktisch kontroverses Merkmal von C++, da sie die Indirektionsebene eines Bezeichners verdecken. im Gegensatz zu C-Code, bei dem Zeiger normalerweise syntaktisch hervorstechen, ist es in einem großen Block von C++ - Code möglicherweise nicht sofort ersichtlich, ob das Objekt, auf das zugegriffen wird, als lokale oder globale Variable definiert ist oder ob es sich um einen Verweis (impliziten Zeiger) handelt ein anderer Ort, insbesondere wenn der Code Referenzen und Zeiger mischt. Dieser Aspekt kann dazu führen, dass schlecht geschriebener C++ - Code schwieriger gelesen und debuggt werden kann (siehe Aliasing).

Ich stimme 100% zu, und deshalb glaube ich, dass Sie eine Referenz nur dann verwenden sollten, wenn Sie einen sehr guten Grund dafür haben.

4
user606723

Es gibt ein Problem mit der Regel "Referenzen verwenden wo immer möglich" und es tritt auf, wenn Sie die Referenz für die weitere Verwendung beibehalten möchten. Um dies mit einem Beispiel zu veranschaulichen, stellen Sie sich vor, Sie haben folgende Klassen.

class SimCard
{
    public:
        explicit SimCard(int id):
            m_id(id)
        {
        }

        int getId() const
        {
            return m_id;
        }

    private:
        int m_id;
};

class RefPhone
{
    public:
        explicit RefPhone(const SimCard & card):
            m_card(card)
        {
        }

        int getSimId()
        {
            return m_card.getId();
        }

    private:
        const SimCard & m_card;
};

Zunächst scheint es eine gute Idee zu sein, Parameter im RefPhone(const SimCard & card)-Konstruktor durch einen Verweis übergeben zu lassen, da er verhindert, dass falsche/Null-Zeiger an den Konstruktor übergeben werden. Es empfiehlt sich irgendwie, Variablen auf Stack zuzuordnen und von RAII zu profitieren.

PtrPhone nullPhone(0);  //this will not happen that easily
SimCard * cardPtr = new SimCard(666);  //evil pointer
delete cardPtr;  //muahaha
PtrPhone uninitPhone(cardPtr);  //this will not happen that easily

Aber dann kommen Provisorien, um deine glückliche Welt zu zerstören.

RefPhone tempPhone(SimCard(666));   //evil temporary
//function referring to destroyed object
tempPhone.getSimId();    //this can happen

Wenn Sie sich also blind an Referenzen halten, tauschen Sie die Möglichkeit aus, ungültige Zeiger zu übergeben, um Referenzen auf zerstörte Objekte zu speichern, was im Grunde die gleiche Wirkung hat.

edit: Beachten Sie, dass ich an der Regel "Verweise verwenden, wo immer Sie können, Zeiger, wo immer Sie müssen. Vermeiden Sie Zeiger, bis Sie es nicht können." von der am meisten bewerteten und akzeptierten Antwort (andere Antworten deuten auch darauf hin). Obwohl es offensichtlich sein sollte, ist das Beispiel nicht zu zeigen, dass Referenzen als solche schlecht sind. Sie können jedoch wie Zeiger missbraucht werden, und sie können ihre eigenen Bedrohungen in den Code einbringen.


Es gibt folgende Unterschiede zwischen Zeigern und Verweisen.

  1. Wenn es um das Übergeben von Variablen geht, sieht Übergeben nach Verweis wie Übergeben nach Wert aus, weist jedoch Zeigersemantik auf (wirkt wie Zeiger). 
  2. Referenz kann nicht direkt auf 0 (null) initialisiert werden. 
  3. Referenz (Referenz, nicht referenziertes Objekt) kann nicht geändert werden (entspricht dem Zeiger "* const").
  4. const Referenz kann temporäre Parameter akzeptieren.
  5. Lokale const-Referenzen verlängern die Lebensdauer temporärer Objekte

Unter Berücksichtigung dieser Punkte lauten meine derzeitigen Regeln wie folgt.

  • Verwendet Referenzen für Parameter, die lokal innerhalb eines Funktionsbereichs verwendet werden.
  • Verwenden Sie Zeiger, wenn 0 (Null) ein akzeptabler Parameterwert ist oder Sie Parameter für die weitere Verwendung speichern müssen. Wenn 0 (Null) zulässig ist, füge ich dem Parameter ein "_n" -Suffix hinzu, verwenden Sie einen geschützten Zeiger (wie QPointer in Qt) oder dokumentieren Sie ihn einfach. Sie können auch intelligente Zeiger verwenden. Sie müssen mit gemeinsam genutzten Zeigern noch vorsichtiger sein als mit normalen Zeigern (andernfalls können Sie durch konstruktive Speicherlecks und Verantwortungsverwirrung enden).
3
doc

Punkte zu beachten:

  1. Zeiger können NULL sein, Verweise können nicht NULL sein.

  2. Referenzen sind einfacher zu verwenden. const kann für eine Referenz verwendet werden, wenn wir den Wert nicht ändern möchten und nur eine Referenz in einer Funktion benötigen.

  3. Zeiger, der mit einem * verwendet wird, während Verweise mit einem & verwendet werden.

  4. Verwenden Sie Zeiger, wenn eine Zeigerarithmetik erforderlich ist. 

  5. Sie können Zeiger auf einen ungültigen Typ int a=5; void *p = &a; haben, aber keine Referenz auf einen ungültigen Typ.

Zeiger Vs Referenz

void fun(int *a)
{
    cout<<a<<'\n'; // address of a = 0x7fff79f83eac
    cout<<*a<<'\n'; // value at a = 5
    cout<<a+1<<'\n'; // address of a increment by 4 bytes(int) = 0x7fff79f83eb0
    cout<<*(a+1)<<'\n'; // value here is by default = 0
}
void fun(int &a)
{
    cout<<a<<'\n'; // reference of original a passed a = 5
}
int a=5;
fun(&a);
fun(a);

Fazit wann man was benutzt

Zeiger : Für Array-, Linklisten-, Baumimplementierungen und Zeigerarithmetik.

Referenz : In Funktionsparametern und Rückgabetypen.

2
shaurya uppal

Im Folgenden sind einige Richtlinien aufgeführt.

Eine Funktion verwendet übergebene Daten, ohne sie zu ändern:

  1. Wenn das Datenobjekt klein ist, z. B. ein eingebauter Datentyp oder eine kleine Struktur, übergeben Sie es als Wert.

  2. Wenn das Datenobjekt ein Array ist, verwenden Sie einen Zeiger, da dies Ihre einzige Wahl ist. Machen Sie den Zeiger auf const.

  3. Wenn das Datenobjekt eine ausreichend große Struktur hat, verwenden Sie einen const-Zeiger oder eine const-Referenz, um die Effizienz des Programms zu erhöhen. Sie sparen Zeit und Platz, um Eine Struktur oder ein Klassendesign zu kopieren. Stellen Sie den Zeiger oder die Referenz konstant.

  4. Wenn das Datenobjekt ein Klassenobjekt ist, verwenden Sie einen const-Verweis. Die Semantik des Klassenentwurfs erfordert häufig die Verwendung eines Verweises. Dies ist der Hauptgrund, aus dem C++ Dieses Feature hinzugefügt hat. Daher ist die Standardmethode für das Übergeben von Klassenobjektargumenten by Referenz.

Eine Funktion ändert Daten in der aufrufenden Funktion:

1.Wenn das Datenobjekt ein integrierter Datentyp ist, verwenden Sie einen Zeiger. Wenn Sie Code Wie fixit (& x) entdecken, wobei x ein int ist, ist es ziemlich klar, dass diese Funktion x ändern möchte.

2.Wenn das Datenobjekt ein Array ist, wählen Sie nur einen Zeiger.

3.Wenn das Datenobjekt eine Struktur ist, verwenden Sie eine Referenz oder einen Zeiger.

4.Wenn das Datenobjekt ein Klassenobjekt ist, verwenden Sie eine Referenz.

Natürlich sind dies nur Richtlinien, und es kann Gründe geben, andere Entscheidungen zu treffen. Beispielsweise verwendet cin Verweise für Basistypen, sodass Sie cin >> n Anstelle von cin >> & n verwenden können.

1
Sachin Godara

Zeiger und Referenzen haben die gleiche Geschwindigkeit, und Zeiger können alles, was Referenzen können, und mehr. Es hängt stark von der persönlichen Meinung ab, welche man verwenden soll. Es ist üblich, Referenzen zu verwenden, es sei denn, Sie benötigen einige der Funktionen von Zeigern.

Ich habe gerade meinen Cent hingelegt. Ich habe gerade einen Test gemacht. Ein sneeky dazu. Ich lasse einfach die Assembly-Dateien desselben Mini-Programms mit Hilfe von Zeigern erstellen, verglichen mit den Referenzen . Wenn Sie die Ausgabe betrachten, sind sie exakt gleich. Außer dem Symbolnamen. Betrachtet man die Leistung (in einem einfachen Beispiel), gibt es kein Problem.

Nun zum Thema Zeiger vs. Referenzen. Meiner Meinung nach steht Klarheit über allem. Sobald ich implizites Verhalten lese, kräuseln sich meine Zehen. Ich stimme zu, dass es ein implizites Verhalten von Nizza ist, dass eine Referenz nicht NULL sein kann.

Das Referenzieren eines NULL-Zeigers ist nicht das Problem. Es wird Ihre Anwendung zum Absturz bringen und ist leicht zu debuggen. Ein größeres Problem sind nicht initialisierte Zeiger, die ungültige Werte enthalten. Dies führt höchstwahrscheinlich zu einer Speicherbeschädigung, die undefiniertes Verhalten ohne einen klaren Ursprung verursacht.

Hier denke ich, dass Referenzen viel sicherer sind als Hinweise. Und ich stimme einer vorherigen Aussage zu, dass die Schnittstelle (die klar dokumentiert werden sollte, siehe Vertragsgestaltung, Bertrand Meyer) das Ergebnis der Parameter einer Funktion definiert. Wenn Sie dies alles in Betracht ziehen, gehen meine Vorlieben zu Verwenden Sie Referenzen, wo immer und wann immer es möglich ist.

0

Referenzen sind sauberer und benutzerfreundlicher und verstecken Informationen besser. Referenzen können jedoch nicht erneut zugewiesen werden. Wenn Sie zuerst auf ein Objekt und dann auf ein anderes Objekt zeigen müssen, müssen Sie einen Zeiger verwenden. Referenzen können nicht null sein. Wenn also die Möglichkeit besteht, dass das betreffende Objekt möglicherweise null ist, dürfen Sie keine Referenz verwenden. Sie müssen einen Zeiger verwenden. Wenn Sie die Objektmanipulation selbst ausführen möchten, d. H. Wenn Sie Speicherplatz für ein Objekt auf dem Heap-Speicher und nicht für den Stack reservieren möchten, müssen Sie Pointer verwenden

int *pInt = new int; // allocates *pInt on the Heap
0

Im Allgemeinen sollte eine Elementvariable niemals eine Referenz sein, da dies keinen Sinn hat. Dadurch wird die Klasse nicht zuweisbar, wenn Sie keinen Zuweisungsoperator angeben. Sobald Sie die Elementreferenz so eingestellt haben, dass sie auf ein Objekt verweist, ist es nicht möglich, dieses Element zu ändern, um auf ein anderes Objekt zu verweisen. Die am besten geeignete Verwendung einer Referenz ist die Verwendung als Funktionsparameter, der das Referenzieren ermöglicht.

0
fatma.ekici