On Tue, Apr 5, 2011 at 04:33, Barry Smith <[email protected]> wrote:

Since the sieve c++ compiled code uses the C code (like VecXXX) the C++ compiler would have to know that the other parts of C are not compiled with C++. At a minimum you would have to extern c it in the header files other wise the C++ compiled code will call the C routines with name-mangling turned on while the C compiler doesn't know about name mangling and hence would generate routines without name mangling and the c++ code wouldn't find the c routines.

But this is already what happens --with-c-support. Why is it ever necessary to compile the C source with a C++ compiler (that is, why support with-c-support=0)? The C++ convenience functions (PetscPolymorphicFunction) can easily be defined whenever a C++ compiler is used, they will be name mangled (and usually inlined). I think all you would need to do is remove the PETSC_USE_EXTERN_CXX clause from #if !defined(PETSC_USE_EXTERN_CXX) && defined(__cplusplus)

In other words, even without issues of struct layouts currently everything in PETSc needs to be built with the same compiler. If sieve was made a completely separate package form PETSc then one could easily arrange things so that sieve compiled with c++ and PETSc with c.

I don't see any complexity in always building C source with a C compiler and C++ source with a C++ compiler. It seems simpler to me. And then people could build a PETSc that includes Sieve and still call it from C (e.g. when they happen to not be using Sieve). The only problem I can think of, and which might be justification for building C code with a C++ compiler, is that C++ compilers seem to be stricter about complex. C99 complex is binary compatible with C++ complex, but type checking is weaker. I don't know if this is implicit in the standard or if the GNU compilers are unnecessarily lenient about C99 complex. This is purely a matter of quality error/warning messages, but I'm loathe to give up any static type checking.