[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