On Mon, Apr 4, 2011 at 9:24 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">karpeev@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;">
<div><br></div><div>struct _p_Mat {</div><div>  PETSCHEADER(struct _MatOps);</div><div>  PetscLayout            rmap,cmap;</div><div>  ...</div><div>}</div><div>typedef struct _p_Mat *Mat;</div>

<div>Mat A;</div><div>Now ((PetscObject)A)->comm is kosher, because of the way C lays out the struct.</div><div>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).</div>


<div>I imagine there will be no problem, since we've been compiling the PETSc C code with C++ compilers for a decade now,</div><div>but I don't know whether the C++ standard guarantees that.  Jed is the only person I know that actually reads the standard</div>


<div>(or maybe it's part of the ABI).</div><div><br></div><font color="#888888"><div>Dmitry.</div></font></blockquote><div><br></div><div>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++.</div>
<div><br></div><div>Jack</div></div>