On Mon, Oct 13, 2008 at 11:12 AM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > > On Mon, 13 Oct 2008, John Peterson wrote: > >> Hmm... >> >> I'm not sure I see how this function works. r and r_src are >> vector<complex<T>> but we are MPI gathering them as datatype<T>, where >> T=Real. Surely the layouts of an array of T and a vector<complex<T>> >> are not the same in memory. > > No, but they're nearly interchangeable: a complex<T> is basically > just a struct with two T's in it, and I believe an array ca of the > former can be interpreted as an array ra of the latter where ca[n].real() == > ra[2*n] and > ca[n].imag() == ra[2*n+1]. > > I don't think the standard prohibits other in-memory representations > of complex<>, but the only other space-efficient representation would > be to put the imaginary part first, which would work just as well with > this code.
I checked out GCC's implementation of std::complex<T> and I see the class contains two T's rather than e.g. a length=2 array such as: "T array[2];". So in the (purely academic) case where someone had a vector<complex<char>> I would be a little worried about the struct padding in doing what we are trying to do, but with a float or double I feel pretty confident everything is fine... -- John ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
