On Tue, Apr 5, 2011 at 7:36 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
   Jed,<br>
<br>
     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.</blockquote>
<div><br></div><div>I actually want the code compiled with the C++ compiler. That is what the option said and that is what I want. You can</div><div>want something else, so make a different option for it. This is exactly what users requested and we implemented.</div>
<div><br></div><div>Can someone give a 1 line description of the dlopen() test they want and I will put it in today.</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
    Barry<br>
</font><div><div></div><div class="h5"><br>
On Apr 5, 2011, at 2:03 AM, Jed Brown wrote:<br>
<br>
> On Tue, Apr 5, 2011 at 04:33, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> 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.<br>

><br>
> 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<br>

><br>
> #if !defined(PETSC_USE_EXTERN_CXX) && defined(__cplusplus)<br>
><br>
> 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.<br>

><br>
> 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).<br>

><br>
><br>
> 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.<br>

<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>