LuckyLocker schrieb:
Da ich mir denke, dass es den Leuten, die das entwickelt haben auch so ginge, muss es ja einen Grund geben dafür, der würde mich interessieren. Unter "mutex lock_guard cumbersome" oder ähnlichen Suchanfragen habe ich leider nichts gefunden.
Ich denke da gibt es mehrere Gründe.
Man braucht manchmal direkt Zugriff auf die lock()/unlock() Funktionen, ohne "Guard". Das heisst natürlich nicht dass man nicht zusätzlich ne Guard-Variante anbieten kann, aber es heisst dass es nicht die einzige Möglichkeit sein darf ne Mutex zu locken.
Zur Zeit wo diese Libraries entwickelt wurden gab's noch kein "auto".
Zur Zeit wo diese Libraries entwickelt wurden gab's noch kein "move".
Ich finde die Variante auto guard = lock(mutex); auch viel eleganter.
LuckyLocker schrieb:
Dieses acquire kann ich ja jetzt nicht in den std header packen, das heißt in jeder CU müsste ich wieder nen Header inkludisionieren oder das template neu definieren :((
Du wirst bei jeder Sprache und jedem Framework Dinge finden die dir abgehen. Dafür schreibt man sich in jedem Projekt dann Hilfsfunktionen, die man dann an vielen Stellen verwendet.
Das Argument "ich müsste dann ja ne Header inkludieren" ist für mich irgendwie ... lächerlich (sorry, nicht böse gemeint, aber ich kanns überhaupt nicht nachvollziehen).
Ich meine, du musst ja auch Headers einbinden damit du überhaupt Mutexen verwenden kannst
Meine Projekte haben alle ein "Common.h", wo Zeugs included/deklariert wird das an vielen Stellen des Projekts immer wieder gebraucht wird. Und jedes Header-File des Projekts bindet dann als erstes die "Common.h" ein.
Noch eine andere Frage:
ist std::future<void> eine gangbare einfache Alternative *snip*
Ich verstehe die Frage nicht. Wenn du was hast, auf das std::future<void> perfekt passt, dann ja, klar, wieso solltest du dann nicht std::future<void> dafür verwenden?
