On Apr 5, 2011, at 10:02 AM, Jed Brown wrote: > On Tue, Apr 5, 2011 at 14:36, Barry Smith <bsmith at mcs.anl.gov> wrote: > If it is as simple as you say then I am fine with adding support BUT it will > require "yet another flag"
If you don't have a flag to turn off using the C or C++ compiler on the "C" code then you are forcing the user into the model of C for C code and C++ for C++ code which we have never supported in 15 plus years. This is a new feature and has to have a way of turning it off. Barry If you make the C for C code feature the default that might not be the end of the world but you cannot make it be the only possibility. > > I'm not sure about this. What does PETSc need to do at compile time to expose > the C++ interface? Isn't all the genuine C++ in headers anyway (e.g. logging > interface in petsclog.hh, Exception and Point in petscsys.hh, almost all of > Sieve, the few "*.c" files are obviously C++ only and thus should be renamed)? > > If indeed the C++ stuff (apart from Sieve) resides only in headers, we could > unconditionally enable it when __cplusplus (so users could do a standard C > build of PETSc and then use the "C++ bits" when calling PETSc from C++).
