Dynarray Implementation

ScottZhang

krümelkacker schrieb:

Ähm, nö, so nicht. Das lässt ggf die Objekte, die vorher logisch in *this wohnten zu lange am Leben.

Und was könnte dadurch passieren?

krümelkacker

Sone schrieb:

Im dynarray-Proposal taucht Move-Semantik nicht auf und das ist schätzungsweise Absicht.

Das Proposal ist von 2008.

Move-Semantik ist noch nicht sooo jung. Ich kann aber vorstellen, dass es was mit dem zu tun hat, was ich vorhin um 17:43 Uhr ansprach, nämlich, der Stack-Speicher-Optimierung. Das wäre dann eine nette Alternative zu VLAs. Wie gesagt, ich denke, das ist der Grund, warum es überhaupt dieses Proposal gibt. Man will so etwas wie VLAs haben, ohne dafür am Sprachkern "rumzufummeln".

Sone

krümelkacker schrieb:

Sone schrieb:

Im dynarray-Proposal taucht Move-Semantik nicht auf und das ist schätzungsweise Absicht.

Das Proposal ist von 2008.

Move-Semantik ist noch nicht sooo jung. Ich kann aber vorstellen, dass es was mit dem zu tun hat, was ich vorhin um 17:43 Uhr ansprach, nämlich, der Stack-Speicher-Optimierung. Das wäre dann eine nette Alternative zu VLAs. Wie gesagt, ich denke, das ist der Grund, warum es überhaupt dieses Proposal gibt. Man will so etwas wie VLAs haben, ohne dafür am Sprachkern "rumzufummeln".

So, habe den Code jetzt verändert.

Kann sich das bitte jemand reinziehen?

krümelkacker

ScottZhang schrieb:

krümelkacker schrieb:

Ähm, nö, so nicht. Das lässt ggf die Objekte, die vorher logisch in *this wohnten zu lange am Leben.

Und was könnte dadurch passieren?

Siehe
http://cpp-next.com/archive/2009/09/your-next-assignment/

ScottZhang

krümelkacker schrieb:

ScottZhang schrieb:

krümelkacker schrieb:

Ähm, nö, so nicht. Das lässt ggf die Objekte, die vorher logisch in *this wohnten zu lange am Leben.

Und was könnte dadurch passieren?

Siehe
http://cpp-next.com/archive/2009/09/your-next-assignment/

Danke

Edit: Ich fange an C++ zu hassen, hier geht aber auch nix naiv :xmas1: ... nee nur spass

Nexus

Wo genau liegt jetzt der Vorteil dieser Implementierung gegenüber std::vector ?

Und warum and etc.? Du bist so ziemlich der einzige, der das heutzutage noch verwendet, und verwirrst damit viele Programmierer nur. Und warum kein std::swap() in Dynarray::swap() ? Im Nahezu-Move-Konstruktor den Zuweisungsoperator aufzurufen ist auch unüblich, gerade wenn man den Allokator damit wegwirft. using namespace im Header ist nicht gut. Wie du auf Fehler bei der Zerstörung reagierst, ist auch interessant. Gibt sicher noch Weiteres...

Sone

Nexus schrieb:

Wo genau liegt jetzt der Vorteil dieser Implementierung gegenüber std::vector ?

Sieh erster Satz in meinem ersten Posting. Da kommt das Wort Spaß drin vor

Und warum and etc.? Du bist so ziemlich der einzige, der das heutzutage noch verwendet, und verwirrst damit viele Programmierer nur.

"etc."? Welches ecetera?
and ist weg.

Nexus schrieb:

Und warum kein std::swap() in Dynarray::swap() ?

Done.

Nexus schrieb:

Im Nahezu-Move-Konstruktor den Zuweisungsoperator aufzurufen ist auch unüblich, gerade wenn man den Allokator damit wegwirft.

Hä? Ich initialisiere meinen doch direkt darüber!
Kurze Nebenfrage: Sollte ich den Allokator bei einer Zuweisung weitergeben?
Ja, oder?

Nexus schrieb:

using namespace im Header ist nicht gut.

Hab jetzt die Vergleichsoperatoren weggelassen, das ist momentan eh unnötig.

Nexus schrieb:

Wie du auf Fehler bei der Zerstörung reagierst, ist auch interessant.

Jetzt aber ehrlich... ist es nur interessant oder ist das reinste Untertreibung?
Sehr ungeübt in solchen Sachen. Muss mir mal Exceptional C++ zulegen.

Gibt sicher noch Weiteres...

Dafür habe ich ja euch... :xmas1:

camper

Ein paar Bemerkungen

1. vom Allokator (privat) ableiten zwecks EBO
2. _clean : exceptions könnten nur von Destruktoren stammen, relativ sinnlos, damit umgehen zu wollen, zudem werden dann nicht alle Objekte zerstört
3. InputIteratoren sind nur für single-pass-Algorithmen gut - der Range-Konstruktor benötigt mindestens ForwardIterator
4. Konstruktoren werden nicht über Zuweisung implementiert.
5. Die Zuweisungsoperatoren sind jetzt mehrdeutig für rvalues.
6. Der Moveoperator kann nicht korrekt mit self-move umgehen.
7. Exceptionspezifikationen alten Stils sind zu vermeiden
8. swap sollte noexcept sein, und wird zweckmäßigerweise über swap für die einzelnen Member implementiert
9. noexcept für Destruktor, move-Konstruktor/Zuweisung etc.

Sone

Das man die einzelnen Member tauschen sollte war mir klar! Da kam Nexus daher...

Habe alle Sachen berücksichtigt (bis auf ein, zwei). Kannst es dir noch mal ansehen? :xmas1:

Als ich campers Namen gesehen habe, wusste ich, jetzt kommt was

Sone

camper schrieb:

9. noexcept für Destruktor, move-Konstruktor/Zuweisung etc.

Schwierige Sache, da schon im Dtor das deallokieren vom Allokator nicht zwangsläufig nothrow sein muss.
(Oder das zerstören der Feldelemente)

Sone

Und noch eine Frage:
soll ich
allocator_type::propagate_on_container_copy_assignment , `

allocator_type::propagate_on_container_move_assignment und

allocator_type::propagate_on_container_swap

`
Mit einbeziehen?

TyRoXx

Sone schrieb:

Her mit der Kritik :xmas1:

Danke im Voraus,
MfG :xmas2:

Edit: Erneuere jetzt den Code immer hier.

Interessante Sache, aber mach das bitte auf Github oder so. Das Forum ist nicht die beste Versionsverwaltung.

Sone schrieb:

camper schrieb:

9. noexcept für Destruktor, move-Konstruktor/Zuweisung etc.

Schwierige Sache, da schon im Dtor das deallokieren vom Allokator nicht zwangsläufig nothrow sein muss.
(Oder das zerstören der Feldelemente)

Wenn ein Destruktor wirft, wird das Programm ohnehin terminiert (oder schlimmeres). Deswegen muss man diesen Fall nicht behandeln.

Müsste _deallocateAll nicht in einer Endlosschleife enden? Schließlich ruft es sich selber ohne eine Bedingung auf. Oder was ist der Sinn dahinter?

Sone

Hmmmmmm schrieb:

Müsste _deallocateAll nicht in einer Endlosschleife enden? Schließlich ruft es sich selber ohne eine Bedingung auf. Oder was ist der Sinn dahinter?

Hahahahaha
Das war ein kleines Malheur mit der Replace-Funktion meiner IDE

Korrigiert

Sone

TyRoXx schrieb:

Sone schrieb:

camper schrieb:

9. noexcept für Destruktor, move-Konstruktor/Zuweisung etc.

Schwierige Sache, da schon im Dtor das deallokieren vom Allokator nicht zwangsläufig nothrow sein muss.
(Oder das zerstören der Feldelemente)

Wenn ein Destruktor wirft, wird das Programm ohnehin terminiert (oder schlimmeres). Deswegen muss man diesen Fall nicht behandeln.

Ach!
Ganz vergessen. Natürlich. Kopf->Tisch

Sofort.

P.S.: Und Danke für den Tipp mit Github, mach ich sofort!

camper

Sone schrieb:

Schwierige Sache, da schon im Dtor das deallokieren vom Allokator nicht zwangsläufig nothrow sein muss.

Die Deallokation darf nicht werfen (17.6.3.5/Table 28), Exceptions können folglich nur von Destruktoren stammen. Und mit Exceptions aus Destruktorn umgehen zu wollen, ist sowieso zum Scheitern verurteilt.

Sone

camper schrieb:

Sone schrieb:

Schwierige Sache, da schon im Dtor das deallokieren vom Allokator nicht zwangsläufig nothrow sein muss.

Die Deallokation darf nicht werfen (17.6.3.5/Table 28)

Schon vor dir gefunden

, Exceptions können folglich nur von Destruktoren stammen. Und mit Exceptions aus Destruktorn umgehen zu wollen, ist sowieso zum Scheitern verurteilt.

Wenn du es sagst.
noexcept -Spezifikationen hinzugefügt.

Noch was?

Sone

Sone

So, jetzt geht alles. Code ist auf GitHub. ( Header "Dynarray.hxx")

Eine Sache verstehe ich nur nicht:

vom Allokator (privat) ableiten zwecks EBO

Soll ich vom Allokator ableiten, oder wie soll ich das verstehen?

TyRoXx

Das häufige Wechseln zwischen public und private macht die Klasse unübersichtlich.
Tests wären auch nicht schlecht.
Warum die exotische Endung .hxx ?
Warum verschiedene Namensschemata? Ich sehe mindestens drei: my_iterator_traits , Dynarray , _constructWith

camper schrieb:

9. noexcept für Destruktor, move-Konstruktor/Zuweisung etc.

Der Destruktor ist implizit noexcept(true) .