Peter Dimov wrote:
Adding a test case will accomplish three things:
1. It will show that we consider the feature important, 2. It will ensure that it works, 3. It will allow us to verify that patches don't break it.
The nice thing is that all this will happen automatically without anybody needing to persuade anyone else. :-)
Likewise, adding a test case for the original 7.1 problem could allow us to address its failure by other, more focused, means instead of going with the suggested fix.
Test-first and all that. :-)
However, I freely admit I have no idea how to test if something uses static initialization or dynamic. Actually, thinking on the fly ... Is everything due for dynamic initialization zero-initialized first? If so, I could declare sentry objects either side of the statically initialized array, and see if it contains zeroes in the first-but-not-second case. Actually, I could probably just check it has the expected values in the first case, zeroes or not. If it contains uninitialized random values it clearly also has not been statically initialized. Of course, this test only fails usefully on compilers that get order of initialization correct, but fail to notice that array< POD, N > should be statically initialized! -- AlisdairM