> > change this code:
> > typedef struct NiuRoutingStruct {
> > sqlite3_vtab vtab;
> > } NiuRouting;
> > to this:
> > struct NiuRouting : public sqlite3_vtab vtab {
> > ... // your implementation, eventually
> > };
> >
> > This way, the casting is unnecessary and any pointer offsetting will be
> > done correctly.
>
> Just for my curiosity:
> Is the above really equivalent to the C definition like:
> typedef struct NiuRoutingStruct {
> sqlite3_vtab vtab;
> ... // your implementation, eventually
> } NiuRouting;
>
> ?
>
> Reason I'm asking: sqlite uses a pointer to that structure to access
> "sqlite3_vtab vtab" member - in machine code that would be
> memory offset 0, all other private members start at
> +sizeof(sqlite3_vtab)+optional alignment.
> Now, I'm wondering if a c++ style of inheritance is defined
> in the same way - Note that sqlite relies on that, or better
> say "the compiler that produced the sqlite machine code relies
> on that".
> Just in case the c++ compiler rearrange the byte offset differently
> it will crash rights away, I think.
>
> Thanks.
Without my copy/paste error, (the 'vtab' should be gone, leaving just the
struct name), it would be equivalent provided that the alignment of a
sqlite3_vtab was no less restrictive than the alignment of
NiuRoutingStruct as it is finally defined. However, static_casting from
derived to base automatically incorporates the correct offset, (as would
taking the address of an embedded sqlite3_vtab member, instead of using
the OP's reinterpret cast), so the crash you worry about (with good
reason) would be made less likely.
I think all SQLite relies upon is getting correct pointers to its portion
of whatever object it is passing around. That virtual table API is
designed to make it agnostic as to any other, tag-along content.
Best regards,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
