Wie übergebe ich ein Array an eine Klasse in C++?

[Hancock]

Wenn dir #14 nicht als Erklärung reicht. Aber als Hinweis für Polymorphismus: Splicing.

Referenzen sehen aus wie Objekte, sind es aber nicht. Und das führt oft zu subtilen Fehlern, die man nur schwer sieht. Dass Referenzen null/Müll sind, kommt aber gerne vor, weil es eben so einfach geht.

Und Referenzen können nicht mit den Containern. Sie sind auch nicht default-constructible. Im Factory-Pattern kannst du nicht mal prüfen, ob du nen nullptr hast, oder ihn zurückgeben.

std::pair<bool,Base&>DerivedFactory(...);//first is true on success
...
[success, obj]=DerivedFactory(...);//What happens on failure

Einziger Ausweg scheint mir hier eine Exception zu sein. Aber ist das dann noch wirklich schön?

Mir ist natürlich klar, dass "->" zwei Tastendrücke auf dem IBM-Keyboard sind statt mit "." nur einen.

 

[KitKat::new()]

Und Referenzen können nicht mit den Containern.

https://en.cppreference.com/w/cpp/utility/functional/reference_wrapper

Sie sind auch nicht default-constructible.

ja, macht Sinn - Problem?

Im Factory-Pattern kannst du nicht mal prüfen, ob du nen nullptr hast, oder ihn zurückgeben.

Das würde ich entsprechend meinem Zitat auch nicht so machen, sondern unique_ptr (evtl. mit optional) nutzen.
(In Rust imho besser gelöst, weil Box<T> nicht null sein kann)

Aber als Hinweis für Polymorphismus: Splicing.

Meinst du Slicing?

 

[Hancock]

Meinst du Slicing?

Ja

https://en.cppreference.com/w/cpp/utility/functional/reference_wrapper

Und was passiert, wenn ich (in dem Beispiel da), l.clear() aufrufe? Dann enthält v nur noch ... UB?

ja, macht Sinn - Problem?

Klar, das macht alles (bis zu einem gewissen Grad) Sinn. Aber ein Anfänger schießt sich damit so leicht in den Fuß. Wenn er mal programmieren kann, kann er gerne Referenzen verwenden. Er kann auch gerne https://en.cppreference.com/w/cpp/language/lifetime studieren, vor allem so Sachen wie unter "Storage reuse". Oder er kann auch operator,() überladen. So wie ein erfahrener Pilot auch nen Looping fliegen kann, aber ein Anfänger sollte das nicht.

 

[KitKat::new()]

Ja

Kann man sicher konstruieren, wie alles in C++, da braucht es gar keine Referenzen, aber schau mal was bei einer abstrakten Klasse passieren würde:

<source>:18:19: error: cannot allocate an object of abstract type 'Shape'
   18 |     Shape shape = circle_ref;
      |                   ^~~~~~

https://godbolt.org/z/dczvsr8dd

Keine Chance versehentlich die Referenz wegzulassen

Und was passiert, wenn ich (in dem Beispiel da), l.clear() aufrufe? Dann enthält v nur noch ... UB?

nein, einfach ausprobieren...

main.cpp:27:11: error: 'class std::reference_wrapper<int>' has no member named 'clear'
   27 |         i.clear();
      |           ^~~~~

Klar, das macht alles (bis zu einem gewissen Grad) Sinn. Aber ein Anfänger schießt sich damit so leicht in den Fuß.

Das ist normal bei C++, egal was er macht. Mit Pointer kann er sich genauso leicht in den Fuss schiessen.
Man sollte imho nicht von gutem Programmierstil abraten, nur weil man damit was falsch machen kann.

Wenn man Sorgen vor in den Fuss schiessen hat, sollte man nicht C++ nutzen

So wie ein erfahrener Pilot auch nen Looping fliegen kann, aber ein Anfänger sollte das nicht.

Referenzen sind mMn basics.
Der Looping wäre wohl sowas wie Template Meta Programming

 

[Hancock]

i.clear();

i!=l. Wie bei allen Pointern (und das sie Referenzen nun mal), kann ich ein Rugpull machen.

BTW: Der Standard schreibt nicht vor, dass das eine Access-Violation ergibt, l.clear muss nicht zwingend den Speicher freigeben, dadurch würde sogar bei valgrind kein Fehler kommen...

Mein Punkt ist, Referenzen sind "basics", aber man braucht sie eigentlich nicht zwingend (C kommt ohne aus, Ausnahme const T& im Funktionsparameter für copy Constructor und operator= und Rückgabewert von operator=). Und Pointer haben ne extra Schreibweise (* und ->), damit es "auffällt" wenn man einen Pointer nutzt.

 

[KitKat::new()]

i!=l. Wie bei allen Pointern (und das sie Referenzen nun mal), kann ich ein Rugpull machen.

Oups, sorry.
Aber: Und? Und wo ist das Problem nun bei Referenzen?
Mit pointern hast das gleiche Problem, und oben drauf musst vorher auf null prüfen.

Mein Punkt ist, Referenzen sind "basics", aber man braucht sie eigentlich nicht zwingend

Zwingend brauchen tut man nicht viel, aber man nutzt was man hat.

Ausnahme const T& im Funktionsparameter für copy Constructor und operator= und Rückgabewert von operator=)

Braucht man auch nicht unbedingt ;-)

Und Pointer haben ne extra Schreibweise (* und ->), damit es "auffällt" wenn man einen Pointer nutzt.

Auch Referenzen haben zumindest teilweise eine andere Schreibweise (&), und (wichtig) eine andere Semantik (nicht null)