I would like to implement 'GetParent()' function in here-
class ChildClass;
class ParentClass
{
public:
....
ChildClass childObj;
....
};
class ChildClass
{
friend class ParentClass;
private:
ChildClass();
public:
ParentClass* GetParent();
};
I've tried to create a private member variable which stores pointer to parent object. However this method requires additional memory.
class ChildClass
{
friend class ParentClass;
private:
ChildClass();
ParentClass* m_parent;
public:
ParentClass* GetParent()
{
return m_parent;
}
};
So I used offsetof() macro (performance costs of calling offsetof() can be ignored), but I'm not sure this approach is safe. Would it be work on every situation? Is there any better Idea?
class ChildClass
{
public:
ParentClass* GetParent()
{
return reinterpret_cast<ParentClass*>(
reinterpret_cast<int8_t*>(this) - offsetof(ParentClass, childObj)
);
}
};
Calculating the address of the container object using
offsetof
is safe in the sense that it can work.offsetof
is commonly used in C for this purpose. See for example the container_of macro in Linux kernel.It can be unsafe in the sense that if there is a
ChildClass
instance that is not that particular member variable, then you have undefined behaviour on your hands. Of course, since the constructor is private, you should be able to prevent that.Another reason why it's not safe is that it has undefined behaviour if the container type is not a standard layout type.
So, it can work as long as you take the caveats into account. Your implementation however, is broken. The second parameter of the
offsetof
macro must be the name of the member. In this case, it must bechildObj
and note[index]
which is not the name of the member.Also (maybe someone will correct me if I'm wrong, but I think) casting to an unrelated type
uint8_t*
before doing the pointer arithmetic and then cast to yet another unrelated type seems a bit dangerous. I recommend usingchar*
as the intermediate type. It is guaranteed thatsizeof(char) == 1
and it has special exceptions about aliasing and not having trap representations.It might be worth mentioning that this use - or any use other than use with arrays - of pointer arithmetic is not defined by the standard. Which strictly speaking makes
offsetof
useless. Still, pointers are widely used beyond arrays, so the lack of standard backing can in this case be ignored.Here a more general solution for future visitors:
Test case:
There is a
static_assert
that defends against UB caused by the given struct not having standard layout as mentioned by user2079303.The code as shown requires C++11, however, you can delete
#include <type_traits>
and thestatic_assert
to make it compile in C++03, however, you will have to manually make sure you have a standard layout type.