C ++ 17 Polyfills и Boost - PullRequest
       8

C ++ 17 Polyfills и Boost

0 голосов
/ 15 мая 2018

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

Существует ли канонический способ портативного использования новых языковых функций при использовании более старой версии стандарта?

Если вы уже используете boost, следует ли вам продолжать использовать буст-версии или версии в C ++ 17 или экспериментальные версии?

Как далеко вы должны идти, пытаясь быть переносимым?

Я удивлен, что не нашел этот вопрос в качестве FAQ.Разве не должно быть что-то об этом в основных руководящих принципах, в часто задаваемых вопросах и как в документе комитета ISO?

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

1 Ответ

0 голосов
/ 15 мая 2018

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

Вы можете импортироватьподходящая версия с использованием предложений, но это рискованно, поскольку маскирует семантические различия, см. также:

От повышения до std :: экспериментальный и, кроме того, c ++ 17

Вы можетерассмотрите возможность использования макрокоманд функциональных тестов и создайте заголовки, такие как " cxx17 / option.hpp ", содержащие:

#ifdef __cpp_lib_experimental_optional
#include <experimental/optional>
namespace cxx17
{
using std::experimental::optional;
}
#elif __cpp_lib_optional
#include <optional>
namespace cxx17
{
using std::optional;
}
#else
#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}
#endif

Однако это все еще ограничивает семантические различия.В некоторых случаях библиотеки наддува намеренно отличаются от стандартных.

Вы также должны учитывать, что не существует такой вещи, как переносимый код, который был перенесен.Вы не можете гарантировать, что ваш код будет работать, если вы на самом деле не проверили его в каждой среде.

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

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

Хорошая вещь - это задокументировать намерение.Если вы просто хотите облегчить жизнь будущим сопровождающим, но на данный момент вы застряли на C ++ 11, вы можете подумать об этом (в cxx17 / import_optional.hpp ):

#include <boost/optional.hpp>
namespace cxx17
{
using boost::optional;
}

и использование пространства имен cxx17, чтобы указать, что вы хотите использовать C ++ 17, но пока не можете.Это также подразумевает, что вы считаете отклонения между повышением и стандартом ISO ошибкой для вашего проекта.Другие пользователи могут просто предпочесть версию буста.(рассмотрим, например, В чем различия между std :: option и boost :: option? )

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

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

...