1

2

3

4

Graphcomm& Graphcomm::Clone() const Distgraphcomm& Distgraphcomm::Clone() const

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

namespace MPI { class Comm {

virtual Comm& Clone() const = 0;

};

class Intracomm : public Comm { Intracomm Dup() const { ... };

virtual Intracomm& Clone() const { ... };

};

class Intercomm : public Comm { Intercomm Dup() const { ... };

virtual Intercomm& Clone() const { ... };

};

//Cartcomm, Graphcomm,

//and Distgraphcomm are similarly defined

};

(End of advice to implementors.)

16.1.8 Exceptions

int Get_error_code() const; int Get_error_class() const;

const char *Get_error_string() const;

};

};

Advice to implementors.

The exception will be thrown within the body of MPI::ERRORS_THROW_EXCEPTIONS. It is expected that control will be returned to the user when the exception is thrown. Some MPI functions specify certain return information in their parameters in the case of an error and MPI_ERRORS_RETURN is speci ed. The same type of return information must be provided when exceptions are thrown.

For example, MPI_WAITALL puts an error code for each request in the corresponding entry in the status array and returns MPI_ERR_IN_STATUS. When using MPI::ERRORS_THROW_EXCEPTIONS, it is expected that the error codes in the status array will be set appropriately before the exception is thrown.

(End of advice to implementors.)

16.1.9 Mixed-Language Operability

The C++ language interface provides functions listed below for mixed-language operability. These functions provide for a seamless transition between C and C++. For the case where the C++ class corresponding to <CLASS> has derived classes, functions are also provided for converting between the derived classes and the C MPI_<CLASS>.

MPI::<CLASS>& MPI::<CLASS>::operator=(const MPI_<CLASS>& data)

MPI::<CLASS>(const MPI_<CLASS>& data)

MPI::<CLASS>::operator MPI_<CLASS>() const

These functions are discussed in Section 16.3.4.

16.1.10 Pro ling

This section speci es the requirements of a C++ pro ling interface to MPI.

Advice to implementors. Since the main goal of pro ling is to intercept function calls from user code, it is the implementor's decision how to layer the underlying implementation to allow function calls to be intercepted and pro led. If an implementation of the MPI C++ bindings is layered on top of MPI bindings in another language (such as C), or if the C++ bindings are layered on top of a pro ling interface in another language, no extra pro ling interface is necessary because the underlying MPI implementation already meets the MPI pro ling interface requirements.

Native C++ MPI implementations that do not have access to other pro ling interfaces must implement an interface that meets the requirements outlined in this section.

High-quality implementations can implement the interface outlined in this section in order to promote portable C++ pro ling libraries. Implementors may wish to provide

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

4

5

6

7

8

9

10

11

(End of advice to implementors.)

To meet the requirements of the C++ MPI pro ling interface, an implementation of the MPI functions must:

1.Provide a mechanism through which all of the MPI de ned functions may be accessed with a name shift. Thus all of the MPI functions (which normally start with the pre x \MPI::") should also be accessible with the pre x \PMPI::."

19

20

21

22

23

4.Where the implementation of di erent language bindings is done through a layered approach (e.g., the C++ binding is a set of \wrapper" functions which call the C implementation), ensure that these wrapper functions are separable from the rest of the library.

24

25

26

27

28

29

30

This is necessary to allow a separate pro ling library to be correctly implemented, since (at least with Unix linker semantics) the pro ling library must contain these wrapper functions if it is to perform as expected. This requirement allows the author of the pro ling library to extract these functions from the original MPI library and add them into the pro ling library without bringing along any other unnecessary code.

5. Provide a no-op routine MPI::Pcontrol in the MPI library.

Example 16.6 Sample mpi.h le.

namespace PMPI { class Comm { public:

int Get_size() const;

};

// etc.

};

namespace MPI { public:

class Comm { public:

int Get_size() const;

private:

PMPI::Comm pmpi_comm;

};

};

Note that all constructors, the assignment operator, and the destructor in the MPI class will need to initialize/destroy the internal PMPI object as appropriate.

The de nitions of the functions must be in separate object les; the PMPI class member functions and the non-pro ling versions of the MPI class member functions can be compiled into libmpi.a, while the pro ling versions can be compiled into libpmpi.a. Note that the PMPI class member functions and the MPI constants must be in di erent object les than the non-pro ling MPI class member functions in the libmpi.a library to prevent multiple de nitions of MPI class member function names when linking both libmpi.a and libpmpi.a. For example:

Example 16.7 pmpi.cc, to be compiled into libmpi.a.

int PMPI::Comm::Get_size() const

{

// Implementation of MPI_COMM_SIZE

}

Example 16.8 constants.cc, to be compiled into libmpi.a.

const MPI::Intracomm MPI::COMM_WORLD;

Example 16.9 mpi_no_profile.cc, to be compiled into libmpi.a.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

1

2

3

4

5

6

int MPI::Comm::Get_size() const

{

return pmpi_comm.Get_size();

}

41

42

43

44

2.Extended Fortran Support An implementation with this level of Fortran support provides Basic Fortran Support plus additional features that speci cally support Fortran 90, as described in Section 16.2.4.