> > 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