On Jul 25, 2012, at 2:08 AM, Yury Semikhatsky <[email protected]> wrote:
> > > On Tue, Jul 24, 2012 at 10:34 PM, Maciej Stachowiak <[email protected]> wrote: > > On Jul 24, 2012, at 12:39 AM, Yury Semikhatsky <[email protected]> wrote: > >> >> >> On Tue, Jul 24, 2012 at 12:47 AM, Maciej Stachowiak <[email protected]> wrote: >> >> On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky <[email protected]> wrote: >> >>> >>> >>> First option we consider is to define a class with the same set of fields >>> as the instrumented one, then have a compile time assert that size of the >>> reference class equals to the size of the instrumented one. See >>> https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more >>> details. >>> >>> Pros: compile time error whenever size of an instrumented class changes >>> with the appropriate modifications to the instrumentation function. >>> Cons: it will require each committer to adjust the reference class and the >>> instrumentation on any modification that affects size of the instrumented >>> class. Changes that don't affect size of the class will go unnoticed. >> >> What is the advantage of this approach compared to just using the sizeof >> operator on the relevant classes? >> >> Regards, >> Maciej >> >> >> Summing up sizeof type of each field and parent class and comparing it to >> sizeof the class would do the same thing except that we would need sometimes >> to manually handle alignment discrepancies on different platforms. > > I'm not sure I understand the problem you are trying to solve. Isn't sizeof > on the class the correct answer? Why would you need to manually add sizeof > for the fields? You need sizes of objects referenced by pointer, but that > won't be affected by alignment issues. > We use sizeof to report *this size, after that we need to go through the > fields and report referenced objects. The problem is that the set of fields > may change eventually and break the instrumentation. The compile check should > help developers not to forget to update the instrumentation and add traversal > code for the new fields. It seems like the compile-time check would give false positives (if you add a non-pointer field) and false negatives (if you change the size of a buffer pointed to). The most obvious way to fix it would also be to update the size of the reference class and not do anything special about new pointers, which would be the wrong thing to do. So based on that, I'm not sure it's worth the cost. I think compile-time checks are more effective when the failure is more directly related to a developer mistake. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
