Open
Description
Currently soft_this_ptr/soft_this_ptr_impl is a mess:
- it does NOT seem to use template parameter T at all; if it is not necessary - let's make soft_this_ptr NON-templated
- its move and copy constructors seem to be BADLY broken: while assignment and move-assignment ops SHOULD dp nothing (as now), move and copy constructors MUST initialize it in EXACTLY the same manner as default constructor
- by its current nature, it is NOT a
soft_ptr
, but something which allows to convert raw ptrs into soft_ptrs; as a result, it is not really a soft_this_ptr, but soft_this_converter; let's rename it accordingly. - most likely, we do NOT need cbPtr at all (it is calculatable from
this
andoffset
; special case of nullptr can be handled via offset==0xFFFFFFFF); this will save 8 bytes per object - in implementation of getSoftPtr(), three lines of code involving allocatedPtr are unclear/messy: do we REALLY need them?
- let's clarify semantics when we try to create it on-stack; suggested to allow creation, but fail at the point of getSoftPtr()
- as getSoftPtr() seems to be THE ONLY function which will be ever provided by soft_this_ptr, I suggest to change it to templated operator()(TT*); this way, it will be used as
soft_ptr<MyNode> = soft_this_converter(this);