Тяжелое использование шаблонов для мобильных платформ

Я просматривал книгу Modern С++ Design от Andrei Alexandrescu, и это кажется интересным материалом. Однако он очень широко использует шаблоны, и я хотел бы узнать, следует ли этого избежать, если использовать С++ для разработки мобильных платформ (Brew MP, WebOS, iOS и т.д.) Из-за соображений размера.

В Symbian OS С++ стандартное использование шаблонов не рекомендуется, сама ОС Symbian использует их, но использует идиому, известную как тонкие шаблоны, где базовая реализация выполняется в стиле C, используя указатели void * с тонким шаблоном, расположенным сверху для достижения безопасности типа. Причина, по которой они используют эту идиому, а не регулярное использование шаблонов, заключается в том, чтобы избежать раздувания кода.

Итак, каковы мнения (или факты) об использовании шаблонов при разработке приложений для мобильных платформ.

Ответ 1

В моем личном опыте использование (и даже злоупотребление) шаблонов очень редко приводит к большому раздуванию кода, а компиляция с помощью -Os очень помогает.

Не так часто бывает, что огромные шаблоны шаблонов дублируются (создаются экземплярами) много раз, потому что редко классы огромны, а потому, что в большинстве случаев вы создаете только шаблоны с несколькими разными аргументами, а не сотнями. Кроме того, легко повторно использовать некоторый общий код в ваших самых больших классах/функциях шаблонов, и компилятор поможет вам в этом.

Обычно размер данных (графика, аудио,...) на порядки больше, чем код. Поэтому я не стал бы волноваться.

Конечно, могут быть исключения из того, что я сказал, но я думаю, что они будут в основном касаться продвинутых (специальных/странных/сложных) вещей, а не самых обычных повседневных классов.

Подводя итог моему предложению: используйте шаблоны столько, сколько хотите, если что-то пойдет не так, вы обнаружите это путем профилирования, и вы легко сможете оптимизировать размер.

Ответ 2

Идем дальше и используем шаблоны везде, где они упрощают понимание и поддержку кода. Избежание шаблонов на мобильных платформах можно классифицировать как "преждевременную оптимизацию".

Если вы столкнулись с проблемами исполняемого файла, тогда при необходимости перепроектируйте, но не начинайте с предположения, что шаблоны вызовут проблемы, прежде чем вы увидите какие-либо актуальные проблемы.

Многие вещи в "Современном дизайне С++" и подобные книги не приведут к раздутому коду, потому что большая часть его действительно предназначена для обеспечения безопасности типов и магии метапрограммирования времени компиляции, а не для генерации код.

Шаблоны могут использоваться, чтобы делать много разных вещей. Они могут генерировать больше кода, чем вы ожидаете, но это не повод запретить их использование. Не так давно разные власти рекомендовали избегать исключений, виртуальных функций, математики с плавающей запятой и даже классов из-за опасений относительно размера и производительности кода, но люди делали эти вещи, и как-то все получилось в порядке.

Ответ 3

Шаблоны не обязательно приводят к раздуванию кода. Если вы напишете шаблон функции или класса и создаете его для десятка различных типов, тогда да, вы получите много дублированного кода (возможно, так или иначе). Некоторые компиляторы могут объединить идентичные экземпляры обратно вместе.

Но если шаблон создается только для одного типа, тогда в размере кода нулевой стоимости. Если вы создаете его несколько раз, вы платите определенную сумму, но вы также в конечном итоге платите, если вы использовали любой из других способов достижения того же. Динамический полиморфизм (виртуальные функции и наследование) также не является бесплатным. Вы платите за это с точки зрения vtables, кода, сгенерированного для облегчения всех типов бросков и конверсий, и просто из-за кода, который нельзя отстроить или оптимизировать.

Взяв std::vector в качестве примера, тогда да, если вы используете как vector<int>, так и vector<float>, вы получаете две копии некоторого кода. Но с помощью шаблонов компилируется только используемый код. Функции-члены, которые вы никогда не вызываете, не генерируют никакого кода, и даже в компилируемых функциях компилятор может устранить много кода. Например, для определенных типов код обработки исключений может быть ненужным, поэтому компилятор может устранить его, уступая меньший код, чем если бы вы использовали динамический полиморфизм, где компилятор не смог бы сделать какие-либо предположения о сохраненном типе, Таким образом, в приведенном выше примере вы получите код, сгенерированный как для vector<int>, так и vector<float>, но каждый из них будет намного меньше, чем полиморфный вектор, как вы можете найти в Java, например.

Основная проблема с использованием шаблонов заключается в том, что для этого требуется компилятор, который его поддерживает. На ПК это не проблема. На любой другой платформе, имеющей зрелый компилятор С++, это не проблема.

Но не на всех платформах имеется современный сверхпрочный компилятор С++. Некоторые из них не поддерживают ряд дополнительных функций, и некоторые из них недостаточно хороши для оптимизации, требуемой для работы кода шаблона (например, шаблоны, как правило, требуют много вложения). Поэтому на некоторых платформах лучше избегать шаблонов. Не из-за каких-либо проблем с размером кода, а потому, что компилятор может не справиться с ним.

Ответ 4

Независимо от того, что вы делаете, НЕ пытайтесь писать код, компилировать его и сравнивать размер исполняемого файла или код.

Ответ 5

Я бы сказал, что в целом (не только связанный с мобильной разработкой) этот совет держится. Некоторые из методов, описанных в Modern С++ Design, могут привести к длительному времени сборки и раздуванию кода.

Это особенно актуально при работе с "неясными" устройствами, такими как сотовые телефоны. Многие методы шаблонов полагаются на то, что компилятор и компоновщик делают отличную работу по устранению неиспользуемого/дублирующего кода. Если они этого не делают, вы рискуете иметь сотни дубликатов экземпляров std::vector, разбросанных по всему вашему коду. И поверьте мне, я видел, как это происходит.

Это не значит, что Modern С++ Design - плохая книга, или что шаблоны плохи. Но особенно на встроенных проектах лучше всего следить, потому что он может укусить.