On Tue, Apr 5, 2011 at 04:33, Barry Smith <bsmith at mcs.anl.gov> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110405/4d82af0b/attachment.html>
