Оптимизация пустой базы MSVC

#c #visual-c

Вопрос:

Оптимизация пустой базы с множественным наследованием, похоже, все еще нарушена в msvc 2010. В настоящее время, похоже, это работает только для первого типа, производного от, поэтому, если вы производите от нескольких пустых баз, дочерний тип заканчивается большим количеством байтов (просто бесполезное заполнение!) чем это необходимо.

По-видимому, это было так в течение некоторого времени: https://connect.microsoft.com/VisualStudio/feedback/details/100686/empty-member-optimization-not-working-properly

Эта ссылка помечена как «закрыта — не подлежит исправлению». Просто интересно, знает ли кто-нибудь, происходит ли что-нибудь с этой «функцией» в наши дни??

1. Хотя комментариям 4 года, весь тот код, который мог сломаться, никуда не делся. Так что они, вероятно, будут упорствовать, пока у них не появится реальная возможность полностью отказаться от существующих двоичных файлов.

2. Есть ли веская причина, по которой «большой объем» существующего кода будет зависеть от того, что объекты будут больше, чем они должны быть??

3. Не имеет значения, веская причина или нет. Того, что код существует, достаточно для того, чтобы MS решила, что вносить кардинальные изменения не стоит. Также вполне возможно, что они больше ссылаются на необходимое изменение ABI, которое будет сопровождать это, но это не то, с чем мне когда-либо приходилось возиться.

4. Некоторые люди используют write(p, n) подход к двоичной сериализации … возня с размерами объектов и смещениями в них приведет к нарушению десериализации существующих дампов. Тем не менее, я не потрудился прочитать страницу MS… просто предположение и мысль о комментариях выше.

Ответ №1:

Оптимизация пустой базы с множественным наследованием, похоже, все еще нарушена в msvc 2010

Что вы подразумеваете под «сломанным»? Что, это не соответствует стандарту?

Стандарт не требует, чтобы пустые классы имели нулевой размер при выводе из них. Реализация может оптимизировать это, а может и не оптимизировать вообще.

1. Достаточно справедливо. Возможно, мне следовало сказать «неоптимальный», а не «сломанный».

2. @Darren: Даже тогда мой ответ остается правильным, поскольку стандарт не требует, чтобы компиляторы оптимизировали пустые базовые классы. Они могут выполнять оптимизацию вообще, а могут и не выполнять.

3. Я понимаю, о чем вы говорите, но, очевидно, была попытка реализовать EBO в msvc, так что, есть ли это в стандарте или нет, по крайней мере, «интересно», что это было сделано только наполовину. Я не пишу код, который явно требует, чтобы sizeof (data) равнялся чему-то определенному, это просто снижает эффективность использования памяти, если EBO не работает должным образом.

4. @Darren: Слишком много вещей, которые MSVC не реализовал, даже те, которые требуются Стандартом. Если это так, то ничего страшного, если он не оптимизировал пустые базы.