[mpich-discuss] Problems with MPI and virtual functions in C++

[Hélvio Vairinhos]

Thank you again, Dries! You were extremely helpful. I will take a look 
at the MPI standard.

Cheers,
Helvio


On 12/12/2012 08:22 PM, Dries Kimpe wrote:
> * 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[0] 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[2];
> 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
> functions).
>
>    Dries
>
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20121212/a7ccf7bb/attachment.html>