As an alternative, would it be acceptable to heap allocate these
objects, using the original padding numbers?
On 12/15/2015 5:11 PM, Howard Hinnant wrote:
On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs <jonat...@codesourcery.com> wrote:
Could these large padding things be related to the fact that the test is used
as a performance check for the implementation? That being said, I have no idea
who is paying attention to the numbers that come out of this test (if anyone
even is?). Maybe @howard.hinnant knows something about it?
It’s been a few years since I wrote this code, but my best recollection is that
the large buffers indicate my concern of getting the correct answer
accidentally as the dynamic_cast code will add/subtract offsets to pointers.
The implementation is wicked hard to get right, and so the tests are extra
paranoid.
As I wrote this I only had to worry about OS X / iOS. If you need to reduce
these numbers for other platforms, I think that would be fine. However I would
not reduce them to double digits. I would keep them as large as you can
reasonably get away with.
There may have also been effort to make sure that the numbers involved were not
even close to multiples of one another, or add up to each other, etc, I don’t
remember for sure. The main concern is that the offset arithmetic implemented
under __dynamic_cast does not accidentally get the right answer. And I suspect
alignment is also factored in to the offset computation (I don’t recall for
sure), and so one can not depend entirely on small primes (which may be rounded
to alignment).
Handy link:
http://mentorembedded.github.io/cxx-abi/abi.html#dynamic_cast-algorithm
Normally I don’t write a lot of comments in code. Code should be self
explanatory. The sheer volume of comments in private_typeinfo.cpp should serve
as a signal that this code is very tricky. So I recommend keeping the tests as
paranoid as possible.
Howard
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
