Jed,
If it is as simple as you say then I am fine with adding support BUT it
will require "yet another flag" and hence increase complexity.
--with-c-for-c-code=1 or something and either require a compiler that is smart
enough to switch based on extension or two lists of files to compile with the
two compilers. These choices are already complicated for some users and the
logic in PETSc will get messy.
Barry
On Apr 5, 2011, at 2:03 AM, Jed Brown wrote:
> 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.
