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 <[email protected]> [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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss