При обсуждении макроса BOOST_VMD_IS_EMPTY я упомянул ограничение входа в макрос. Теперь я расскажу, что это значит с точки зрения препроцессорного метапрограммирования и ввода в макросы в целом.
Когда программист разрабатывает какие-либо типы вызываемых в C++ (функции, функции-члены и т. д.), он определяет, какие типы ввода и значение возврата. Компилятор C++ выполняет эту спецификацию во время компиляции. Аналогичным образом во время выполнения вызывающий может проверить, что его ввод находится в определенных документированных и определенных границах и реагировать соответствующим образом, если он этого не делает. Все это является частью ограничений для любого C++ и должно быть задокументировано любым хорошим программистом.
Препроцессор C++ намного «туманнее», чем компилятор C++, и даже с конструкциями метапрограммирования препроцессора, созданными Полом Менсонидсом в Boost PP, гораздо меньше метапрограммист препроцессора может сделать во время предварительной обработки, чтобы ограничить ввод аргументов в макрос, чем программист может сделать во время компиляции и / или во время выполнения, чтобы ограничить ввод аргументов в C++, который можно вызывать. Тем не менее, вполне допустимо документировать то, что макрос ожидает в качестве своего аргумента, и, если программист не выполняет ограничение, макрос не будет работать должным образом. В идеальном случае в препроцессорном метапрограммировании макрос может сказать, было ли выполнено ограничение, и может выпустить какую-то понятную ошибку предварительной обработки, когда это произошло, но даже в реальности препроцессорного метапрограммирования с Boost PP это не всегда возможно сделать. Тем не менее, если пользователь макроса не следует ограничениям для макропараметра, как указано в документации конкретного макроса, любая ошибка, которая происходит, является ошибкой этого пользователя. Я понимаю, что это может идти вразрез с широко распространенной концепцией, что ошибки программирования всегда должны быть встречены с какой-то компиляцией времени или времени выполнения, что позволяет программисту исправить ошибку, а не молчаливый сбой, который маскирует ошибку. Поскольку препроцессор является «негерметичным» и не может обеспечить такое возникновение во всех случаях, ошибка, к сожалению, может быть замаскирована, несмотря на то, что документация указывает правильное ограничение (ограничения) ввода. В случае с уже обсуждаемым макросом BOOST_VMD_IS_EMPTY маскировка ошибки может происходить только с помощью препроцессора (Visual C++). не соответствует стандарту C++.
Библиотека Boost PP имеет способ генерации ошибки предварительной обработки без генерации вывода препроцессора, но опять же этот способ не работает с несоответствующим препроцессором Visual C++. Средством для этого с помощью Boost PP является макрос BOOST_PP_ASSERT. Как мы увидим и обсудим позже, VMD имеет эквивалентный макрос, который будет работать с Visual C++, создавая неправильный выход C++, а не ошибку предварительной обработки, но даже это не является полным решением, поскольку неправильный вывод C++ может быть скрыт.
Даже попытка создать ошибку предварительной обработки или неправильный вывод, вызывающий ошибку времени компиляции, не решает проблему ограниченного ввода для препроцессорного метапрограммирования. Часто невозможно определить, соответствует ли вход ограничениям, которые на него накладывает препроцессорный метапрограммист и документы. Определенные токены предварительной обработки не могут быть надежно проверены на определенные значения или диапазон значений без самого механизма проверки, создающего ошибку предварительной обработки или неопределенное поведение.
Это не значит, что нужно отказываться от попыток проверить макровходные ограничения. Если это возможно, я вижу, что значение таких проверок и ряд макросов VMD, обсуждаемых ниже, разработаны как макросы предварительной обработки входных ограничений. Но самое важное при работе с макро входными ограничениями — это то, что они должны быть тщательно задокументированы, и что программист должен знать, что если ограничения не будут выполнены, то результатом могут быть ошибки предварительной обработки или неправильные макрорезультаты.
Библиотека VMD, чтобы обеспечить большую функциональность и гибкость препроцессорного программирования, позволяет получить ошибочные результаты, если не будут выполнены определенные ограничения ввода, будь то ошибки предварительной обработки или неправильный вывод из макроса VMD. В то же время VMD делает все, что может сделать препроцессор для проверки входных ограничений, и тщательно документирует для каждого макроса в библиотеке, каким может быть вход для каждого, чтобы избежать ошибочного вывода.
Задокументированные макро-входные ограничения так же действительны в препроцессоре, как и ограничения времени компиляции / времени выполнения действительны в C++, даже если обнаружение таких ограничений и / или обработка ограничений, которые не выполняются, намного сложнее, если не невозможно, в препроцессоре, чем в обработке C++ во время компиляции / времени выполнения.
Библиотека VMD использует ограничения для большинства макросов, а в документации для этих макросов упоминаются ограничения, которые применяются для использования макроса.
