[petsc-dev] meaning of PETSC_USE_EXTERN_CXX?
Barry Smith
bsmith at mcs.anl.gov
Tue Mar 5 18:58:34 CST 2013
On Mar 5, 2013, at 6:35 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Tue, Mar 5, 2013 at 6:28 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Ok, and this will still support all four cases above. How do we do that? And would it simplify the mess we have now?
>
> We just take the PETSC_USE_EXTERN_CXX branch everywhere so that if defined(__cplusplus), we always use extern "C" (independent of how PETSc was configured). This also gets rid of PETSC_EXTERN_C and PETSC_INTERN_C, leaving only PETSC_EXTERN and PETSC_INTERN.
I have created a fork https://bitbucket.org/BarryFSmith/petsc-dev-simp this contains all my changes plus Jed's changes with PETSC_INTERN. It works on all configurations I tried.
I propose:
Jed check it out and fix any thing I broke ASAP.
We rework this fork to the new model, C compiler and C++ compiler (with C bindings). (No -with-c-support flag or PETSC_USE_EXTERN_CXX flag)
We will need to coordinate our edits on this, I am available to work on it but will not do anything until Jed tells me what to do. So Jed tell me what to do and I'll do it. Better sooner (like now :-) then later.
Barry
>
> > We don't use overloading (PetscPolymorphic* was removed last spring) so I don't think there is any functional reason to mangle symbols. AFAICT, the only functional reason for building PETSc with a C++ compiler is to use C++ complex
>
> Yes, if a C++ programmer is using PETSc and complex numbers this is a legitimate case
>
> > (and perhaps because the C++ compiler catches different errors than the C compiler).
>
> Yes, this is a legitimate use of our testing PETSc regularly with C++.
>
>
More information about the petsc-dev
mailing list