On 4 April 2011 23:44, Dmitry Karpeev <[email protected]> wrote:

On Mon, Apr 4, 2011 at 9:32 PM, Jack Poulson <[email protected]> wrote:

...

On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <[email protected]> wrote:

...

struct _p_Mat {   PETSCHEADER(struct _MatOps);   PetscLayout            rmap,cmap;   ... } typedef struct _p_Mat *Mat; Mat A; Now ((PetscObject)A)->comm is kosher, because of the way C lays out the struct. I don't know whether C++ does the same (there is the issue of where it sticks the vtable, and I'm not sure what else). I imagine there will be no problem, since we've been compiling the PETSc C code with C++ compilers for a decade now, but I don't know whether the C++ standard guarantees that.  Jed is the only person I know that actually reads the standard (or maybe it's part of the ABI). Dmitry.

I would think that most compilers would not even use a vtable for C code since there are no virtual functions and no class derivations. On the other hand,  it is my understanding that the way vtables are handled is not in the standard and is up to the compiler. Jed may know better even though he hates C++.

If you take a piece of C code and compile it with a C++ compiler, then all structs become classes. Sure, if there are no virtual methods, no vtable will get generated, but the mere possibility of having it there might force the compiler to lay the rest of the crap out differently.  As I said, though, experience shows nothing like that happens.

But some day, some guy will add something like this to PETSc: struct something { ... #ifdef __cplusplus virtual void foo() #endif } Barry's rant is going to be memorable :-) -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169