Ответ 1

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

Ответ 2

Хм, как насчет...

3: они могут медленно компилироваться

4: они заставляют вещи вычисляться во время компиляции, а не время выполнения (это также может быть преимуществом, если вы предпочитаете быструю скорость выполнения над гибкостью во время выполнения)

5: Старые компиляторы С++ не обрабатывают их или не обрабатывают их правильно

6: Сообщения об ошибках, которые они генерируют, когда вы не получаете правильный код, могут быть почти непонятными

Ответ 3

Шаблоны раскрывают вашу реализацию клиентам вашего кода, что упрощает сохранение вашего ABI, если вы отправляете шаблонные объекты на границах библиотек.

Ответ 4

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

Ответ 5

До сих пор никто, кажется, не упомянул о главном недостатке, который я нахожу в шаблонах: читаемость кода сбрасывается!

Я не имею в виду проблемы синтаксиса - да, синтаксис уродлив, но я могу это простить. Я имею в виду следующее: я нахожу, что с невидимым ранее не-шаблонным кодом, каким бы крупным оно ни было, если я начинаю с main(), я обычно могу декодировать широкие штрихи того, что делает программа без проблем. И код, который просто использует vector<int> или подобное, нисколько не мешает мне. Но как только код начинает определять и использовать свои собственные шаблоны для целей, отличных от простых типов контейнеров, понятность быстро выходит из окна. И это имеет очень негативные последствия для обслуживания кода.

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

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

Несвязанная трудность с шаблонами заключается в том, что отладчикам по-прежнему сложно отображать содержимое контейнеров STL (по сравнению с, скажем, массивами в стиле C).

Ответ 6

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

Ответ 7

Меньше людей понимают их, epsecially, на уровне метапрограммирования, поэтому меньше людей могут их поддерживать.

Ответ 8

Когда вы используете шаблоны, ваш компилятор генерирует только то, что вы на самом деле используете. Я не думаю, что есть недостатки в использовании метапрограмм шаблонов С++, кроме времени компиляции, которое может быть довольно длинным, если вы использовали очень сложные структуры, как библиотеки boost или loki.

Ответ 9

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

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

Ответ 10

Абсолютное худшее: сообщения об ошибках компилятора, полученные из плохого кода шаблона.

Ответ 11

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

1.

Необходимость либо....................................................... Это необходимо для компиляции. Опция a.) Может быть выполнена путем определения функций в заголовке или на самом деле включая cpp.

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

2.

Функции, вызываемые при создании экземпляра типа шаблона, могут не выполняться во время компиляции, приводя к ошибкам ссылок. Например. T пример; example.CompilerDoesntKnowIfThisFunctionExistsOnT(); Это "свободно" ИМХО.

Решение:

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

Если тип неважен, например. вектор <T> то как насчет просто использования "объекта". С++ не предоставил ключевое слово "объект", и я предложил д-ру Бьярне Страуступу, что это было бы полезно, особенно сказать компилятору и людям, читающим код, который не имеет значения (для случаев, когда это не так). Я не думаю, что С++ 11 имеет это, возможно, С++ 14 будет?