I strongly suggest you take a look at boost::mpi,
It handles serialization transparently and has some great natural
extensions to the MPI C interface for C++, e.g.
bool global = all_reduce(comm, local, logical_and<bool>());
This sets "global" to "local_0 && local_1 && ... && local_N-1"
Luis Vitorio Cargnini wrote:
> Thank you very much John, the explanation of &v, was the kind of
> think that I was looking for, thank you very much.
> This kind of approach solves my problems.
> Le 09-07-05 à 22:20, John Phillips a écrit :
>> Luis Vitorio Cargnini wrote:
>>> So, after some explanation I start to use the bindings of C inside my
>>> C++ code, then comme my new doubt:
>>> How to send a object through Send and Recv of MPI ? Because the types
>>> are CHAR, int, double, long double, you got.
>>> Someone have any suggestion ?
>> If you are sending collections of built in data types (ints, doubles,
>> that sort of thing), then it may be easy, and it isn't awful. You want
>> the data in a single stretch of continuous memory. If you are using an
>> STL vector, this is already true. If you are using some other
>> container, then no guarantees are provided for whether the memory is
>> Imagine you are using a vector, and you know the number of entries in
>> that vector. You want to send that vector to processor 2 on the world
>> communicator with tag 0. Then, the code snippet would be;
>> std::vector<double> v;
>> ... code that fills v with something ...
>> int send_error;
>> send_error = MPI_Send(&v, v.size(), MPI_DOUBLE, 2, 0,
>> The &v part provides a pointer to the first member of the array
>> that holds the data for the vector. If you know how long it will be,
>> you could use that constant instead of using the v.size() function.
>> Knowing the length also simplifies the send, since the remote process
>> also knows the length and doesn't need a separate send to provide that
>> It is also possible to provide a pointer to the start of storage for
>> the character array that makes up a string. Both of these legacy
>> friendly interfaces are part of the standard, and should be available
>> on any reasonable implementation of the STL.
>> If you are using a container that is not held in continuous memory,
>> and the data is all of a single built in data type, then you need to
>> first serialize the data into a block of continuous memory before
>> sending it. (If the data block is large, then you may actually have to
>> divide it into pieces and send them separately.)
>> If the data is not a block of all a single built in type, (It may
>> include several built in types, or it may be a custom data class with
>> complex internal structure, for example.) then the serialization
>> problem gets harder. In this case, look at the MPI provided facilities
>> for dealing with complex data types and compare to the boost provided
>> facilities. There is an initial learning curve for the boost
>> facilities, but in the long run it may provide a substantial
>> development time savings if you need to transmit and receive several
>> complex types. In most cases, the run time cost is small for using the
>> boost facilities. (according to the tests run during library
>> development and documented with the library)
>> John Phillips
>> users mailing list
> users mailing list