You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when an object is not movable, the builder create method takes an out parameter reference to an optional<T> and returns an expected<void, Error>. This approach has a few drawbacks:
the object cannot be initialized when declared
this has the additional drawback that other objects depending on the T in option<T> also cannot be initialized when declared
one can call reset on the option any time and therefore theoretically one have to take care of this null-ability
I would much more prefer the following idiom shown with the Mutex as example
RefTrackerSource would provide the memory for an atomic refcount and RefTracker would access this memory via a relocatable pointer. When RefTrackerSource is destroyed but the refcount is not zero, the application will be terminated. This has the advantage that one cannot accidentally reset the Mutex (or the Semaphore which also uses this idiom). The only disadvantage is that Mutex could easily be moved to another thread but this could be prevented by adding an assert(false, "should not be moved") to the move ctor of Mutex. The move ctor will not be called on creation due to RVO but the move ctor must still be declared. This limitation is lifted with C++17 and then the runtime error would be propagated to a compile time error when one would try to move the Mutex. In this case, the RefTracker would not be required, only the MutexStorage and Mutex classes.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently, when an object is not movable, the builder
create
method takes an out parameter reference to anoptional<T>
and returns anexpected<void, Error>
. This approach has a few drawbacks:T
inoption<T>
also cannot be initialized when declaredreset
on theoption
any time and therefore theoretically one have to take care of this null-abilityI would much more prefer the following idiom shown with the
Mutex
as examplewith
and
RefTrackerSource
would provide the memory for an atomic refcount andRefTracker
would access this memory via a relocatable pointer. WhenRefTrackerSource
is destroyed but the refcount is not zero, the application will be terminated. This has the advantage that one cannot accidentally reset theMutex
(or theSemaphore
which also uses this idiom). The only disadvantage is thatMutex
could easily be moved to another thread but this could be prevented by adding anassert(false, "should not be moved")
to the move ctor ofMutex
. The move ctor will not be called on creation due to RVO but the move ctor must still be declared. This limitation is lifted with C++17 and then the runtime error would be propagated to a compile time error when one would try to move theMutex
. In this case, theRefTracker
would not be required, only theMutexStorage
andMutex
classes.Beta Was this translation helpful? Give feedback.
All reactions