Re: Is this portable? [static pointer casts, char* arithmetic]
* SG:
I was toying around with some "copy-on-write" wrapper class design
(cow<>) and felt the need to use some ugly pointer casts. I was
wondering whether it is even 100% portable and if not what other
alternatives there are that don't affect the public interface of the
cow<> class template.
I basically use Boost.Function-like "type erasure" with reference
counting. I keep two pointers in the class cow<T> as data members.
One pointer to an abstract wrapper class (for cloning and ref-
counting) and another pointer T* that points directly to the wrapped
object that lives inside the wrapper. To support conversions from
cow<T> to cow<U> in case T* is convertible to U* I made the abstract
wrapper class to be a non-template. The problem arises when I need to
create a copy and adjust the 2nd pointer accordingly.
Here're some code fragments (for brevity) so you know what I'm talking
about:
--------8<----------------8<----------------8<--------
class abstract_wrapper
{
public:
abstract_wrapper() : ref_counter(1) {}
virtual ~abstract_wrapper() {}
virtual abstract_wrapper* clone() const = 0;
void refct_inc() {++ref_counter;}
bool refct_dec() {return (--ref_counter)==0;}
bool unique() const {return ref_counter<=1;}
private:
long ref_counter;
};
Think about separating concerns.
Why should the same class have responsibility for cloning and reference counting?
Also, when you do reference counting you should really not allow the reference
count to drop to zero, as implied by your 'unique' implementation. When the
reference count drops to zero, self-destroy. That is, after all, the point.
// .....
template<typename T>
class cow
{
private:
template<typename> friend class cow;
abstract_wrapper* paw;
I suggest using a boost::intrusive_ptr here.
T* ptr; // points to a member of *paw
Why a member of?
void make_copy();
public:
// .....
T const& operator*() const {return *ptr;}
T const* operator->() const {return ptr;}
T& wref()
{
if (!paw->unique()) make_copy();
return *ptr;
}
// .....
};
OK so far, assuming you have just left out declarations of copy assignment and
copy construction.
template<typename T>
void cow<T>::make_copy()
{
assert( !paw->unique() );
typedef ..... char_t;
typedef ..... void_t;
// is T const? | char_t | void_t
// ------------+------------+-----------
// yes | const char | const void
// no | char | void
abstract_wrapper* paw2 = paw->clone();
char_t* bas1 = static_cast<char_t*>(static_cast<void_t*>(paw));
char_t* bas2 = static_cast<char_t*>(static_cast<void_t*>(paw2));
char_t* sub1 = static_cast<char_t*>(static_cast<void_t*>(ptr));
char_t* sub2 = bas2 + (sub1-bas1);
Offset calculations are only formally well-defined for PODs, which this isn't.
The clone function either returns a pointer that can be downcasted to T*, or it
doesn't, in which case it returns too little information.
Anyway, forget the silly and misleading double static_cast and use
reinterpret_cast when you really want casting to char*.
It's not like reinterpret_cast can fail to preserve the address value.
For it supports casting back and obtaining the original pointer, exactly.
ptr = static_cast<T*>(static_cast<void_t*>(sub2));
paw->refct_dec();
Client code has no business messing with internal reference counts.
Instead use a boost::intrusive_ptr for 'paw'.
For example.
paw = paw2;
}
--------8<----------------8<----------------8<--------
Obviously the private function "make_copy" looks a bit ugly with all
the casts. But as far as I can tell this should be portable. The
dynamic types of *paw and *paw2 are the same. The assumption is that
the object layout is consistent over all possible objects of that
dynamic type and that I can safely compute the address of the new
member object the way I did.
Am I correct?
Formally it's debatable, that is, whether the compiler is allowed to place some
part of an object some unrelated place in memory and just include an offset or
pointer or something. It can do that for virtual multiple inheritance. The
formal level problem is whether it can do so more generally, because as far as I
know nobody's found any language that forbids it (for non-POD).
In practice it's well-defined, as long as you're dealing with complete objects.
If OTOH you're cloning an object that's a base class sub-object of another
object and that inherits virtually from some base class, and that virtual base
class sub-object is your T*, then all bets are off. But presumably that's not
what you're doing. However, the fact that you're dealing separately with the paw
and the ptr, not simply having the same pointer of 2 different types, seems to
indicate that your design doesn't properly enforce identity of these pointers.
But as I hope the comments above make clear, a better solution is to re-design
so that you have available the required information.
The missing information, the presence of the casts, indicates some design flaw.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!