[petsc-dev] PetscCheck__FUNCT__ and PETSC_FUNCTION_NAME

Satish Balay balay at mcs.anl.gov
Thu Oct 7 15:28:04 CDT 2010


On Thu, 7 Oct 2010, Jed Brown wrote:

> On Thu, Oct 7, 2010 at 21:15, Blaise Bourdin <bourdin at lsu.edu> wrote:

> > This is a problem when __FUNCT__ as been set purposely (or not) to not
> > match __func__
> > Tao, for instance does a lot of
> > #undef __FUNCT__
> > #define __FUNCT__ "TaoVecPetsc::Clone"
> > int TaoVecPetsc::Clone(TaoVec**ntv){
> > In thus, case __func__ (and hence PETSC_FUNCTION_NAME ) is Clone, and
> > PetscCheck__FUNCT__ complains (I only checked with the intel compilers on
> > mac OS).
> 
> That's expected, and __PRETTY_FUNCTION__ (which is not standard) includes
> all the types, so it wouldn't match either.  A partial fix would be to just
> waive the check if __FUNCT__ contains "::", but then you would still see the
> non-namespaced version (because __func__ takes precedence if configure finds
> it).  I vote for just turning it off for C++ builds of PETSc.

Another way of dealing with this [was discussing with Jason about it]
- is to split of the names into 2 macros.

#define __CLASS__ TaoVecPetsc [or TaoVecPetsc::]

#define __FUNCT__ Clone

So - somehow the petsc macros print out the same info Jason would like
[TaoVecPetsc::Clone] - but internally - the check of __func__ vs
__FUNCT__ is still done [but not the __CLASS__ part]

> __func__ was not standardized until C99, nothing is standard in C++,
> and idiot Microsoft still hasn't even partially added C99 support
> (maybe moot, I don't know if PETSc builds with Visual Studio at the
> moment).

It should..

Satish



More information about the petsc-dev mailing list