Предложения по сопровождению и лучшие практики для программирования шаблонов

Question

Поддерживаемость шаблонов является проблемой. Это простой факт, когда вы работаете вне сообщества, посвященного общим библиотекам. Я не хочу, чтобы мои друзья и коллеги использовали Clang для запуска моего кода, просто потому что ... ну ... тогда это не очень универсально и переносимо, не так ли? Но я отчаянно хочу иметь возможность писать некоторый шаблонный код время от времени.

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

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

Некоторые ресурсы, которые я нашел:
C ++ FAQ
Ошибка расшифровки
Что такое вариационные шаблоны?

Answer 1

Я использую следующий подход:

• Разделите ваших многочисленных помощников по классу в detail_ пространстве имен; выставляйте только то, что нужно.
• Для (почти) каждого шаблонного класса предоставьте вспомогательную функцию для создания типа: это особенно полезно для итераторов и функторов, которые затем могут быть построены встроенными. Для этого используйте хорошую схему именования: iterator_transformer<Iter, F> построено на transform_iterator.
• Используйте хорошую схему именования (существительные для классов, глаголы для методов, прилагательные для перечислений). Возьмите суффиксное соглашение (_traits, _concept, ...) и придерживайтесь его (1)
• Есть соглашение для шаблонного метапрограммирования: для меня type - это «тип возврата» метафункции, которая возвращает типы, value - это тип статического константного возврата функции, возвращающей статическое целое число константы, other - это для метафункций, возвращающих шаблоны. Возможно, вы захотите использовать boost MPL, если вы злоупотребляете метапрограммированием и соблюдаете их соглашения (спасибо @Noah Roberts)
• Не будь извергнутым: делай самое простое, что соответствует твоим потребностям. Используйте общее программирование, только если оно приносит что-то в ваш код. Иногда простой полиморфизм лучше.
• Организуйте свой код в заголовках: встроенные реализации идут в файлы «заголовков реализации», которые вы #include в своем «включаемом» заголовке
• Заставьте себя использовать стандартные алгоритмы: они делают код более читабельным
• Предоставляйте игрушечные / тестовые / типовые занятия, особенно если вы хотите, чтобы люди расширяли ваш код.
• Часто используйте typedefs: старайтесь, как обычно, не комментировать свой код.
• Не беспокойтесь, если компилятор рано выйдет из строя: редко используйте enable_if, это делает код менее читабельным. Однако вы можете использовать его внутри.
• У вас есть два основных инструмента: вывод аргументов шаблона для шаблонов функций и сопоставление с шаблоном с частичной специализацией шаблонов классов. Вы должны попытаться использовать эти инструменты самым простым способом. В частности, не пытайтесь перегружать функции в зависимости от того, реализует ли тип определенную концепцию или злоупотребляют enable_if. Сохраняй это простым.
• Разделите реализацию сложных классов на более простые. Злоупотребление чертами характера в этом отношении (спасибо @Noah Roberts)

(1) Я использую _concept для базовых классов для шаблона CRTP (т. Е. «Статический полиморфизм»). CRTP хорош, поскольку позволяет уточнить реализацию по умолчанию с минимальным кодом.

Answer 2

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

Однако шаблоны могут запутаться, поэтому я склонен следовать нескольким рекомендациям:

• Показывать только строгий минимум и скрывать детали только в пространстве имен details или, что еще лучше, в отдельном заголовочном файле
• По возможности, используйте аргументы шаблона по умолчанию для упрощения синтаксиса: никто не любит писать один и тот же список аргументов шаблона снова и снова
• Помните, что иногда шаблоны также могут быть деталями реализации: они являются выбранной реализацией для данной проблемы, не мешают вам предоставлять один абстрактный базовый класс пользователям вашей библиотеки
• Максимально используйте typedef: когда «семейство» шаблонных классов работает вместе и, как правило, ожидают одинаковых аргументов шаблона, предоставьте вложенный typedef (либо в объекте библиотеки «main», либо в отдельном шаблоне). struct).
• Прокомментируйте свой код и, в частности, выразите требования к каждому параметру шаблона

Answer 3

Я не очень понимаю.Проблемы с шаблонами связаны с трудностью получения правильных заказов на добавление и объявлений / определений, а не переносимости.

Шаблонный код не менее переносим, ​​чем обычный код.

Answer 4

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

Если у ваших коллег возникли проблемы с этим, то трудно назвать их программистами на C ++. Тогда у вас действительно есть только два варианта:

• не пишите код на C ++. Напишите C, или, возможно, своего рода диалект "C с классами" C ++, или
• обучайте своих коллег. Если вы должны работать на C ++, то все в команде должны иметь дело с кодом, написанным на C ++.

Answer 5

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

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

это все, что я могу думать в минуту. Удачи