Недостатки шаблонов и STL в C++

Question

Есть ли недостатки в использовании STL или шаблонов. Есть ли ситуации, для которых они являются неуместными.

Answer 1

Во-первых, вы должны использовать, вероятно, использовать их, если они помогут вам решить вашу проблему. Шаблоны являются очень важной частью C++ и уже многие годы являются частью стандарта. STL очень мощный и быстрый во время выполнения и должен поддерживаться всеми достойными компиляторами, но, конечно, есть проблемы.

• Если у вас действительно старый компилятор, STL может не поддерживаться полностью.
• Потоковая безопасность реализации STL может работать для вашего приложения
• Шаблоны могут привести к более медленному времени компиляции и, возможно, к более крупному исполняемому файлу, особенно к старым компиляторам.
• Компиляторы часто создают непонятные сообщения об ошибках в коде с использованием шаблонов.

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

Answer 2

Очевидные недостатки:

• Синтаксис может быть ужасным - некоторые биты синтаксиса шаблона в C++ действительно раздвигают пределы здравого смысла, и пересекаются с другими частями языка (например >>)

• Многие люди не очень хорошо понимают STL, поэтому вы можете ограничить аудиторию.

• Сообщения об ошибках, как правило, ужасно сложны.

• Дизайн коллекций STL ведет к большому количеству копий объектов. Оригинальный «умный указатель» (std :: auto_ptr) не подходит для использования в большинстве коллекций. Вещи улучшились в связи с этим в последнее время (TR1)

Answer 3

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

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

Answer 4

В реализации MSVC std :: string имеет накладные расходы на 26 байт PER STRING, даже если строка пуста. Если вы делали только char *, это было бы 4 байта на строку.

Answer 5

Возможно, что они плохо переводятся на другие объектно-ориентированные языки, которые не поддерживают шаблоны, такие как C# и Java, поэтому, если у вас есть группа разработчиков, выходящая с этих языков, они столкнутся с более крутой кривой обучения.

Answer 6

Есть несколько потенциальных преимуществ и недостатков

• Шаблоны увеличить размер результирующего кода.
• Шаблонный код расширяется и обрабатывается во время компиляции, что может сделать время компиляции более продолжительным.(С другой стороны, исполняемый код может быть более эффективным).
• Неиспользованные элементы STL могут привести к более медленному коду
• STL на самом деле делает код более читаемым (мое мнение отличается от Will's). Как любой язык или библиотека, вы должны понимать это, чтобы использовать его соответствующим образом ... что является недостатком для людей, которые не знают.
• Если вы используете шаблоны в метапрограммном смысле (не путайте с использованием STL), код выглядит как язык, полностью отличный от C++. Это может быть сложнее проанализировать, что на самом деле делает код. (OTOH, сделано правильно - мета-программирование позволяет сосредоточиться на архитектуре и дизайне, а также приносит больше ошибок для компиляции времени и времени исполнения. Это большая победа, когда у вас есть критическая функция, и вы можете поймать неправильно закодированную часть во время компиляции, а не при получении клиентом во время работы!)

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

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

Редактировать: Еще один серьезный недостаток я забыл упомянуть - переносимость. Если вам нужно написать переносимый код, шаблоны могут оказаться неправильным способом. Самые популярные компиляторы сегодня поддерживают STL, однако большинство из них не все. Методы метапрограммирования могут быть реальными убийцами для переносимости, поэтому это определенное соображение для принятия решения о целесообразности его использования.

Answer 7

Способ создания шаблонов требует, чтобы вы были осторожны с тем, как объявлять и определять свои шаблоны, когда вы делитесь ими между единицами перевода. Книга «C++ templates: полное руководство» является хорошим источником информации о том, как справиться с этим.

Сообщения об ошибках компилятора и компоновщика для шаблонов, как правило, очень подробные. Вы должны привыкнуть к этому, и я думаю, что есть некоторые скрипты/инструменты, которые делают их более читабельными, но у меня нет опыта с ними.

Но кроме этого шаблоны отличные!

Answer 8

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

Answer 9

Сложные контейнеры STL (и в этом отношении любой сложный класс C++) делают отладку намного сложнее.

Помимо нечитаемых сообщений об ошибках, упомянутых ранее, в текущих отладчиках обычно мало поддержки для обработки конструкций STL. Например, гораздо проще исследовать собственный массив C во время выполнения, чем векторный контейнер <>.

Надеемся, что ситуация со временем изменится. Кроме этого, шаблоны замечательны.

Answer 10

Чтобы перефразировать Андрея Александреску из Modern C++ Design fame. Template are an orthogonal structure to multiple inheritance. У них есть взаимодополняющие компромиссы и выгоды.Шаблоны имеют богатую механику, но специализация шаблонов не масштабируется.

Answer 11

См. templates section из C++ FQA [sic] по многим причинам, чтобы не использовать шаблоны.

Answer 12

1. Тяжелое злоупотребление шаблон (в частности шаблон мета-программирования и увеличения наркомании) может привести к чрезмерно длинных компилировать и компоновать раз.

2. Вы также ветер с исполняемыми , которые имеют значительно большие (необработанного) исполняемых файлов, но, как правило , что это не страшно вопрос.

3. Плохо разработанные шаблоны могут также увеличение кода дублирования далее усугубляя исполняемый размер вопрос.

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

5. Сообщения об ошибках из сильно затененного кода могут быть пугающими для непосвященных и редко, если они когда-либо ясны, как сообщения об ошибках, которые вы получаете из незанятого кода.

Тем не менее, для большинства применений шаблонов являются прекрасным инструментом для повторного использования кода и помогут поднять уровень дискурса от переопределяя к повторному использованию кода; редко эти проблемы превзошли все преимущества.

Answer 13

Цель шаблона - предоставить абстракцию с минимальным штрафом за производительность. В большинстве случаев выгоды перевешивают недостатки. Большинство проблем с шаблонами связаны с поддержкой компилятора и отладчика.

My pet peeve about template: он побеждает интеллектуальную систему сборки из-за зависимостей заголовков. Разработка кода шаблона, как правило, приводит к гораздо большей перекомпиляции нетронутого кода, чем к разработке чистой системы на основе OO, особенно если последние хорошо используют DIP (принцип инверсии зависимостей). Это усугубляет проблему медленной компиляции. OTOH, более быстрое оборудование для разработчиков в наши дни делает вещи намного более терпимыми, чем раньше.

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