<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 6:28 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":18m">   Ok, and this will still support all four cases above. How do we do that? And would it simplify the mess we have now?<br>
</div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":18m"><div class="im">
> 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<br>

<br>
</div>   Yes, if a C++ programmer is using PETSc and complex numbers this is a legitimate case<br>
<div class="im"><br>
> (and perhaps because the C++ compiler catches different errors than the C compiler).<br>
<br>
</div>  Yes, this is a legitimate use of our testing PETSc regularly with C++.</div></blockquote></div><br><br></div></div>