Wann benutzt ihr direkt Pointer?
-
Moin,
in C++ gibt es ja mit Referenzen, Boost, STL viele Möglichkeiten nicht direkt mit Pointern in Berührung zu kommen. Nun zu meiner Frage, benutzt ihr noch viel die nackten Pointer in euren Programmen oder nutzt ihr doch mehr die Alternativen?
Wenn ihr Pointer nehmt, könntet ihr da ein paar pauschale Anwendungsgebiete nennen?
Beste Grüße
Chris
-
Ich benutze immer Zeiger, es sei denn:
- Ich brauche konstantes call-by-ref, dann const T&
- Mit einer "Referenz" soll auch Besitz übergeben werden --> Smartpointer
- Ein Attribut einer Klasse wird durch einen Getter rausgereicht --> Dann auch Referenzen
-
Ich hab mal mein aktuelles Projekt durchgeschaut, vorkommen von Pointern:
- (const) char* bei exceptions und main-Argumenten
- Ein abstraktes Factorytemplate liefert aktuell noch rohe Pointer, steht aber im nächsten Refactoring-Sprint zur Änderung an
- Eine policy, die für die Factory benötigt wird, benutzt einen rohen Pointer, bleibt vermutlich auch so - der Pointer wird nur innerhalb der Policy benutzt und besitzt das referenzierte Objekt nicht.
- Die clone-Methode einer Klasse, die immer in unique_ptr gehalten wird, liefert einen Pointer statt eines unique_ptr -> grade für den nächsten Refactoring-Sprint eingetragen
-
Ich benutze rohe Pointer für alles, wo man optional einen Zeiger auf ein Objekt übergeben/zurückgeben kann.
-
Ich habe, mal abgesehen vom char**-Paramater der main, keine rohen Pointer in meinem aktuellen Projekt.
-
und wo ist der unterschied ob ich nun einfach direkt die instanz rumgebe oder einen pointer der instanz?
-
asd_maus schrieb:
und wo ist der unterschied ob ich nun einfach direkt die instanz rumgebe oder einen pointer der instanz?
Das eine ist eine Kopie und das andere nicht.
-
asd_maus schrieb:
und wo ist der unterschied ob ich nun einfach direkt die instanz rumgebe oder einen pointer der instanz?
Meinst du mit INstanz direkt rumgeben Kopien der Instanz??
-
Generell:
Immer dann wenn es den "NULL Fall gibt" also ich auch ungueltigkeits-Werte zurueckgeben muss, und die Klasse auf die ich zeig zu komplex ist, um eine Expliziete Ungueltigkeit-Instanz zu erzeugen.
UND wenn Templates (Smartpointer) als Parameter nicht gehen.Praktisch:
Interfaces die ueber Dll grenzen gehen muessen/Könnten und Faktory-like Instanzen nach dem Create / Destroy Muster erzeugen ...Ansonsten nehm ich Referenzen, und wenn die ned gehen dann smartpointer ...
Und natuerlich wenn ich "Datenstrukturen" im Speicher liegen habe und local innerhalb eines Algos mir Stellen darauf merken muss ... dann nehm ich fuer die variablen auch zeiger, klar ...
Ciao ...
-
Wenn ich nicht groß damit arbeiten muss, dann nehm ich immer const char* statt std::string. Wer std::string nutzt braucht nur ein c_str und allen anderen zwinge ich nicht std::string und sinnlose Kopiererei und Allocation auf.
-
Nicht besitzende Memberpointer
class Ding { public: Ding(const Ding& deinNachbar) :nachbar(&deinNachbar){} protected: const Ding& MeinNachbar() const {return *nachbar;} private: const Ding* nachbar; };
-
Aktuell: Ganz klassisch als Verweise auf Objekte, die in einer Liste gespeichert sind. So markiere ich ein paar spezielle Objekte aus dieser Liste, die Verweise sind dann in einer anderen Liste gespeichert. Warum keine Iteratoren? Weil man aus einem Iterator leicht einen Pointer bekommen kann, aber wenn man nur einen Pointer hat, dann kommt man nur über Compilererweiterungen an einen passenden Iterator. Und mit letzterem bin ich ordentlich auf die Schnauze gefallen, als das nicht mehr ging.
-
Verweise, die nicht besitzend sind und für die Referenzen zu wenig flexibel sind.
Tachyon schrieb:
Ich habe, mal abgesehen vom char**-Paramater der main, keine rohen Pointer in meinem aktuellen Projekt.
Was verwendest du, wenn Referenzen nicht ausreichen, z.B. weil du Verweise nachträglich ändern musst oder
NULL
haben willst?shared_ptr
?
-
Nexus schrieb:
Verweise, die nicht besitzend sind und für die Referenzen zu wenig flexibel sind.
Tachyon schrieb:
Ich habe, mal abgesehen vom char**-Paramater der main, keine rohen Pointer in meinem aktuellen Projekt.
Was verwendest du, wenn Referenzen nicht ausreichen, z.B. weil du Verweise nachträglich ändern musst oder
NULL
haben willst?shared_ptr
?unique_ptr oder shared_ptr. Je nach Anwendungsfall. Manchmal auch Iteratoren aus einer Liste.
Edit: Ach ja, bei boost/std::bind benutze ich auch noch rohe Zeiger.
-
justchris schrieb:
Wann benutzt ihr direkt Pointer?
Eigentlich nur wenns ne Schnittstelle erfordert oder wenns sich durch Profilen tatsächlich als nötig erweisen sollte, was aber eigentlich nur vorkommt wenn ich über die Pixel eines Bilds renne. Sonst immer per default unique oder shared pointer.
-
Dobi schrieb:
justchris schrieb:
Wann benutzt ihr direkt Pointer?
Eigentlich nur wenns ne Schnittstelle erfordert oder wenns sich durch Profilen tatsächlich als nötig erweisen sollte, was aber eigentlich nur vorkommt wenn ich über die Pixel eines Bilds renne. Sonst immer per default unique oder shared pointer.
Warum? Warum nutzt man das bei Parametern?
void foo(std::shared_ptr<LargeObject> pointer) { if (pointer) { } } // Statt void foo(LargeObject* pointer) { if (pointer) { } }
Wo ist der Vorteil? Man bindet den Aufrufer an einen Zeigertyp, und man bindet die Funktion an Teile der Standardbibliothek, bei unique_ptr bindet man sogar an C++11. Und wozu das Ganze? Es hat doch überhaupt keine Vorteile.
-
Irgendwann könnte das ganze ja multithreadig werden.
Aber da bei sowas würd ich eigentlich eh erstmal eine Referenz nehmen. Ich kann mich grad gar nicht dran erinnern, dass ich in meinen letzten Projekten mal prüfen musste, ob ein Zeiger null ist. Falls das ein Indikator für Design-Probleme ist, flame ruhig. Ich weiß, dass es noch viel für mich zu lernen gibt.
-
Wenn der Zeiger nicht nullptr sein darf, nimmst du natürlich eine Referenz. Wenn nicht, nimmst du halt einen Zeiger. Aber ein shared_ptr oder ein unique_ptr& macht eigentlich aus oben genannten Gründen nie Sinn. unique_ptr ist toll, wenn man auch gleich Besitz übergeben möchte. shared_ptr ist toll, wenn man wirklich shared ownership möchte. (Auch wenn ich das noch nie gebraucht habe.) Aber ansonsten sind "rohe" Pointer und Referenzen doch einfach zu bevorzugen?
-
Achso, klar. Grundsätzlich nehm ich natürlich Referenzen. Wenn die aber nicht gehen, dann shared oder unique pointer. Ich wüsste gerade keine Situation in der Referenzen nicht passen würden und gleichzeitig shared/unique nicht hilfreich wäre. Fällt dir eine ein?
-
Dobi schrieb:
Ich wüsste gerade keine Situation in der Referenzen nicht passen würden und gleichzeitig shared/unique nicht hilfreich wäre. Fällt dir eine ein?
Sogar zwei, wie schon erwähnt: Nicht-besitzende Verweise, die sich ändern oder die ungültig sein können.