D
@Schlangenmensch sagte in Zugriff auf ``block local static`` Objekt, während ``non-local dynamic initialization`` Phase:
@DNKpp Hm, ich bin mir jetzt gerade auch nicht sicher ob dein Fall hier wohldefiniert ist.
Aber ich bin kein Freund von dem Design Ansatz mit dem Dummy Objekt. Was spricht dagegen, wenn man das zentrale Objekt austauschen will, direkt die install Funktion aufzurufen?
Gar nichts, kann man machen. Nur möchte ich halt Alternativen bereitstellen, die Nutzer bequem ins Programm einbinden können, ohne selbst von diesem install Prozess überhaupt wissen zu müssen.
Ganz konkret geht es mir darum, dass meine lib mit unterschiedlichen third-party unit-test frameworks zusammenspielen soll. Man kann dabei davon auszugehen, dass immer nur eine der Möglichkeiten im Programm genutzt wird. Also im Endeffekt ist dieses ganze Konstrukt eine bridge, um diese Frameworks über gewisse Sachverhalte zu informieren (Fehler, Tracing, etc.).
Wenn mehrere genutzt werden, dann bleibt nichts anderes übrig, als in diesen Prozess doch manuell einzugreifen. Dadurch, das es durchgehend austauschbar ist, limitiere ich diesen Fall nicht aber direkt supporten möchte ich ihn auch nicht.
@Schlangenmensch sagte in Zugriff auf ``block local static`` Objekt, während ``non-local dynamic initialization`` Phase:
Hintergrund ist, was ist, wenn es mehrere Custom Foos gibt, die jeweils so ein Dummy Objekt initialisieren. In welcher Reihenfolge werden die dann initialisiert und welches Objekt lebt am Ende im unique ptr?
Das ist dann wohl klassisches Undefined Behavior und ich wäre auch zufrieden damit, das so zu benennen. Zumindest, wenn nicht manuell eingegriffen wird. Denn, austauschen lässt es sich ja ohne Probleme.
