[mpich-discuss] Problems with MPI and virtual functions in C++
dkimpe at mcs.anl.gov
Wed Dec 12 14:22:11 CST 2012
* Hélvio Vairinhos <helvio.vairinhos at gmail.com> [2012-12-12 20:00:28]:
> Thanks for your suggestion, Dries! It works if I use &p.elem as the
> initial address (not &p->elem), and only if I make elem public.I guess
> that's a price to pay (well, I can always fetch the address with a getter).
> Do you know what happens to the memory layout in the presence of virtual
> functions if I have multiple components? For example:
> double a,b;
> instead of:
> double elem;
When you have virtual functions (in fact, according to the <C++98
standard, as soon as you have non-trivial constructor/destructor), you can
no longer reason about the memory layout of the struct/class.
They are no longer PODs (plain old datatype).
> Is it safe to assume that &p.a would give the initial address of a
> contiguous structure? Or should I play safe and use MPI_Pack and MPI_Unpack,
> for example?
Even for a 'contiguous' structure (such as POD struct) the compiler is
allowed to insert padding for alignment reasons.
The difference with non-POD is that you are allowed to copy those bytes as
well to another instance and expect everything to work.
(i.e. memcpy (&a, &b, sizeof(a)) is allowed for POD).
Really, this is a larger topic. If I'm not mistaken, there is some
discussion of this in the MPI standard, even though at this point, your
question is more a C/C++ question than an MPI question.
To give you at least some practical advice: POD types will generally work
as expected. But I would strongly recommend against making similar
assumptions for non-POD types (i.e. types having public/protect/private
modifiers, non-trivial constructors/destructors, and especially virtual
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the discuss