[petsc-dev] Compiling C code with C compiler

Dmitry Karpeev karpeev at mcs.anl.gov
Mon Apr 4 21:44:09 CDT 2011


On Mon, Apr 4, 2011 at 9:32 PM, Jack Poulson <jack.poulson at gmail.com> wrote:

> On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <karpeev at mcs.anl.gov>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.

Dmitry.


>
> Jack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110404/71eb89d0/attachment.html>


More information about the petsc-dev mailing list