1
1
openmpi/ompi/mpi/cxx/info.h

104 строки
2.6 KiB
C
Исходник Обычный вид История

// -*- c++ -*-
//
// Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
// University Research and Technology
// Corporation. All rights reserved.
// Copyright (c) 2004-2005 The University of Tennessee and The University
// of Tennessee Research Foundation. All rights
// reserved.
// Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
// University of Stuttgart. All rights reserved.
// Copyright (c) 2004-2005 The Regents of the University of California.
// All rights reserved.
// Copyright (c) 2006-2008 Cisco Systems, Inc. All rights reserved.
// $COPYRIGHT$
//
// Additional copyrights may follow
//
// $HEADER$
//
class Info {
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
// friend class PMPI::Info;
#endif
friend class MPI::Comm; //so I can access pmpi_info data member in comm.cc
friend class MPI::Request; //and also from request.cc
public:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
// construction / destruction
Info() { }
virtual ~Info() {}
// copy / assignment
Info(const Info& data) : pmpi_info(data.pmpi_info) { }
This is a workaround to bug in the Intel C++ compiler, version 9.1 (all versions up to and including 20060925). The issue has been reported to Intel, along with a small [non-MPI] test program that reproduces the problem (the test program and the OMPI C++ bindings work fine with Intel C++ 9.0 and many other C++ compilers). In short, a static initializer for a global variable (i.e., its constructor is fired before main()) that takes as an argument a reference to a typedef'd type will simply get the wrong value in the argument. Specifically: {{{ namespace MPI { Intracomm COMM_WORLD(MPI_COMM_WORLD); } }}} The constructor for MPI::Intracomm should get the value of &ompi_mpi_comm_world. It does not; it seems to get a random value. As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the prototype for this constructor is: {{{ class Intracomm { public: Intracomm(const MPI_Comm& data); }; }}} Experiments with icpc 9.1/20060925 have shown that removing the reference from the prototype makes it work (!). After lots of discussions about this issue with a C++ expert (Doug Gregor from IU), we decided the following (cut-n-paste from an e-mail): ----- > So here's my question: given that OMPI's MPI_<CLASS> types are all > pointers, is there any legal MPI program that adheres to the above > bindings that would fail to compile or work properly if we simply > removed the "&" from the second binding, above? I don't know of any way that a program could detect this change. FWIW, the C++ committee has agreed that implementation of the C++ standard library are allowed to decide arbitrarily between const& and by-value. If they don't care, MPI users won't care. When you remove the '&', I suggest also removing the "const". It is redundant, but can trigger some strange name mangling in Sun's C++ compiler. ----- So with this change: * we now work again with the Intel 9.1 compiler * our C++ bindings do not exactly conform to the MPI-2 spec, but valid/legal MPI C++ apps cannot tell the difference (i.e., the functionality is the same) This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
Info(MPI_Info i) : pmpi_info(i) { }
Info& operator=(const Info& data) {
pmpi_info = data.pmpi_info; return *this; }
// comparison, don't need for info
// inter-language operability
Info& operator= (const MPI_Info &i) {
pmpi_info = i; return *this; }
operator MPI_Info () const { return pmpi_info; }
// operator MPI_Info* () const { return pmpi_info; }
operator const PMPI::Info&() const { return pmpi_info; }
#else
Info() : mpi_info(MPI_INFO_NULL) { }
// copy
Info(const Info& data) : mpi_info(data.mpi_info) { }
This is a workaround to bug in the Intel C++ compiler, version 9.1 (all versions up to and including 20060925). The issue has been reported to Intel, along with a small [non-MPI] test program that reproduces the problem (the test program and the OMPI C++ bindings work fine with Intel C++ 9.0 and many other C++ compilers). In short, a static initializer for a global variable (i.e., its constructor is fired before main()) that takes as an argument a reference to a typedef'd type will simply get the wrong value in the argument. Specifically: {{{ namespace MPI { Intracomm COMM_WORLD(MPI_COMM_WORLD); } }}} The constructor for MPI::Intracomm should get the value of &ompi_mpi_comm_world. It does not; it seems to get a random value. As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the prototype for this constructor is: {{{ class Intracomm { public: Intracomm(const MPI_Comm& data); }; }}} Experiments with icpc 9.1/20060925 have shown that removing the reference from the prototype makes it work (!). After lots of discussions about this issue with a C++ expert (Doug Gregor from IU), we decided the following (cut-n-paste from an e-mail): ----- > So here's my question: given that OMPI's MPI_<CLASS> types are all > pointers, is there any legal MPI program that adheres to the above > bindings that would fail to compile or work properly if we simply > removed the "&" from the second binding, above? I don't know of any way that a program could detect this change. FWIW, the C++ committee has agreed that implementation of the C++ standard library are allowed to decide arbitrarily between const& and by-value. If they don't care, MPI users won't care. When you remove the '&', I suggest also removing the "const". It is redundant, but can trigger some strange name mangling in Sun's C++ compiler. ----- So with this change: * we now work again with the Intel 9.1 compiler * our C++ bindings do not exactly conform to the MPI-2 spec, but valid/legal MPI C++ apps cannot tell the difference (i.e., the functionality is the same) This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
Info(MPI_Info i) : mpi_info(i) { }
virtual ~Info() {}
Info& operator=(const Info& data) {
mpi_info = data.mpi_info; return *this; }
// comparison, don't need for info
// inter-language operability
Info& operator= (const MPI_Info &i) {
mpi_info = i; return *this; }
operator MPI_Info () const { return mpi_info; }
// operator MPI_Info* () const { return (MPI_Info*)&mpi_info; }
#endif
static Info Create();
virtual void Delete(const char* key);
virtual Info Dup() const;
virtual void Free();
virtual bool Get(const char* key, int valuelen, char* value) const;
virtual int Get_nkeys() const;
virtual void Get_nthkey(int n, char* key) const;
virtual bool Get_valuelen(const char* key, int& valuelen) const;
virtual void Set(const char* key, const char* value);
protected:
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
PMPI::Info pmpi_info;
#else
MPI_Info mpi_info;
#endif
};