Надежны ли экспериментальные возможности современного C ++ для долгосрочных проектов?


87

У меня есть проект, который в настоящее время использует C ++ 11/14, но для этого требуется что-то вроде того std::filesystem, что доступно только в C ++ 17, и, следовательно, у меня нет возможности его использовать. Однако я вижу, что в моем текущем компиляторе он доступен как std::experimental::filesystem. Хорошая идея - использовать экспериментальные функции, если в будущем я смогу добавить что-то вроде:

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

Меня беспокоит:

1. Гарантируется ли, что все совместимые компиляторы имеют одинаковые экспериментальные функции?

2. Склонны ли экспериментальные функции к большим изменениям, которые делают их ненадежными?

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


25
не отвечает ли слово экспериментальный на ваши вопросы?
101010

6
В основном дело вкуса, но я бы не стал загромождать код #idef CXX17. IMHO, переносимый способ - поместить весь код, связанный с файловой системой, в одну единицу компиляции (может быть класс), использовать его во всех остальных частях кода, закодировать его в соответствии с текущим стандартом C ++ 11/14. Задокументируйте, как и почему вы это пишете, и, в конечном итоге, перенесите его на C ++ 17 позже, на этапе обслуживания, если это имеет смысл. (комментируя исходный вопрос)
Серж

4
Это был всего лишь «экспериментальный» кандидат на попадание в стандарт. Это не отражение качества кода.
Галик

5
Между «экспериментальной» и окончательной версией C ++ 17 было довольно много изменений, см. Документ P0492R1
Bo Persson

7
В случае, если filesystemвы подвергаетесь гораздо меньшему риску при его использовании, чем другие вещи, поскольку вы уже знаете, что он стандартизирован в C ++ 17, и его точная спецификация C ++ 17 общедоступна. Поэтому все, что вам нужно сделать, это убедиться, что вы используете только те experimental::filesystemфункции, которые указаны в спецификации C ++ 17. И, конечно же, вы должны знать, что все ваши целевые платформы поддерживают один из experimental::filesystemC ++ 17 или C ++ 17 std::filesystem.
Говард

Ответы:


79
  1. Гарантируется ли, что все совместимые компиляторы имеют одинаковые экспериментальные функции?

Нет, экспериментальные функции необязательны.

  1. Склонны ли экспериментальные функции к большим изменениям, которые делают их ненадежными?

Да, комитет по C ++ может даже решить отказаться от функции, или в процессе стандартизации может возникнуть дефект, который заставит функцию измениться.

Как правило, полагаться на экспериментальные функции - не лучший вариант. Экспериментальные функции - это именно то, что сказано в слове (т. Е. Возможность экспериментировать).


2
Что касается второго пункта, обратите внимание, что я говорю о функциях, которые уже приняты, но могут отличаться.
The Quantum Physicist

14
@TheQuantumPhysicist: «уже принято» - сложная концепция. Все, что угодно, может быть удалено в любое время путем более позднего принятия изменений для удаления, и это произошло со всеми стандартами. Вы, вероятно, захотите дождаться хотя бы проекта международного стандарта, прежде чем набор функций станет достаточно надежным.
Kerrek SB

1
@KerrekSB: Вы не имеете в виду окончательный проект международного стандарта, также известный как FDIS. ? Составление чертежей - довольно постоянный процесс.
MSalters

1
@MSalters: Нет, DIS, вероятно, достаточно хорош, если вы торопитесь. И на этот раз у нас может не быть FDIS.
Kerrek SB

4
@KerrekSB: Я в значительной степени был национальным органом Нидерландов в области C ++ 03;). У нас был национальный секретарь SC22, который знал о процедурах ISO и о том, как отвечать на FDIS, но не о том, что. За исключением нашего делегата WG14 Рэнди Маркеса) никто из наших делегатов SC22 ничего не знал о C ++. И Рэнди просто высмеивал тот факт, что C ++ потребуется больше страниц для определения всего его UB, чем C, необходимого для Defined Behavior - не хотел бы, чтобы он отвечал на этот FDIS;)
MSalters

50

Кто-то из аудитории задал вопрос во время выступления «Панель стандартной библиотеки C ++» на CppCon 2016 ( YouTube ) о том, что имя experimentalможет отпугнуть пользователей от использования чего-либо в пространстве имен:

Считаете ли вы, что [содержимое std::experimentalпространства имен] готово к производству, и можно ли привести этот аргумент, [что] он фактически готов к производству в течение следующих 3 лет, и, может быть, вам придется изменить свой код через 3 года, может быть?

Майкл Вонг (председатель ИК5 и ИК14 и редактор отдела параллелизма) первым ответил на вопрос:

Я думаю, что в комитете есть твердый консенсус, что он практически готов к производству. Как я уже говорил, в большинстве случаев 99% его попадает внутрь с воздуха. Мы хотим убедиться, что это не препятствие для вас. Вы можете понять, почему мы хотим поместить большие функции, большие группы функций в такой контекст, чтобы это не мешало остальной части всей библиотечной системы, но также облегчало вам ее использование. Теперь вы можете включить GCC с помощью специального флага для Concepts, вы знаете, что на самом деле облегчает вам его сегментирование.

Затем Алисдер Мередит (бывший председатель LWG) продолжил:

Я собираюсь занять здесь противоположную позицию. Одна из вещей, которые Херб [Саттер] сказал как организатор WG21, стандартной группы, когда мы двинулись по пути TS, это то, что он не думал, что TS будут успешными, пока мы не сможем что-то продвинуть, потому что это означает, что мы недостаточно экспериментируем, мы недостаточно амбициозны в том, для чего мы используем TS. Мы действительно этого хотимexperimentalЭто намек на то, что да, эти вещи могут быть изменены, мы не связаны с этим, и мы можем ошибаться. Это сделано для того, чтобы снизить наш барьер для вещей, которые мы считаем как можно более амбициозными и достижимыми. [...] Теперь стандарт, похоже, находится на трехлетнем цикле выпуска, мы должны быть гораздо более амбициозными в установке действительно экспериментальных функций в TS и, возможно, быстрее продвигает вещи в самом основном стандарте. Но опять же, это будет интересная тема для обсуждения на следующих нескольких заседаниях [комитета по стандартизации C ++].

Последним ответил Стефан Т. Лававей (разработчик реализации Microsoft STL):

Важно проводить различие между экспериментальностью интерфейса и экспериментальностью реализации, потому что, когда вы говорите «готово к производству», что это означает? Обычно, когда речь идет о реализации, «готово к производству». Вполне возможно, что реализация [чего-то внутри std::experimental] будет абсолютно [...] пуленепробиваемой. [...] Что-то вроде [...] <random>заголовка в TR1, [это было] действительно, очень хорошо в TR1, и вы могли иметь абсолютно пуленепробиваемую реализацию этого, но оказалось, что интерфейс сбился существенно [до выпуска] C ++ 11 и [...] если бы мы знали тогда, что мы делаем сейчас, добавление experimentalбыло бы лучшим сигналом для людей: «Эй, может быть, вы не хотите использоватьstd::experimental::variate_generator потому что, ха-ха, он исчезнет в C ++ 11 ".

Таким образом, похоже, что среди разработчиков стандартных библиотек и членов комитета есть некоторое желание, чтобы, по крайней мере в будущем, содержимое std::experimentalпространства имен было действительно «экспериментальным» по своей природе, и не следует воспринимать как само собой разумеющееся, что что-то std::experimentalбудет сделать его стандартом C ++.

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


47
Спустя 10 лет после того, как я впервые прочитал это имя, тот факт, что сопровождающий Microsoft STL называется STL, все еще заставляет меня смеяться.
Jörg W Mittag

19
@ JörgWMittag, вам следует познакомиться с их разработчиком компилятора, Майклом Сэмом Виктором Коллинзом
MM

28

«Экспериментальный» - это слегка преувеличенный термин. filesystemБиблиотека возникла в Boost , и прошел через несколько итераций там, до представления ISO.

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

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


8

Может быть, есть еще о чем задуматься.

Несколько моментов, которые следует учитывать:

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

  • Насколько велика ваша кодовая база? Насколько велико будет влияние изменений?

  • Насколько важны для вашего проекта функции, предоставляемые API / библиотекой / функцией?

  • Какие есть альтернативы?

    • Используйте экспериментальную функцию, а затем адаптируйте код к изменениям, когда / если он станет стандартизированным. Это может быть так же просто, как удаление experimental::, или так же сложно, как принудительные обходные пути.
    • Добавьте слой абстракции (комментарий Сержа Баллеста). Если экспериментальная функция изменится, ваши повторные записи будут изолированы. Для стандартной функции это может быть излишним (std :: filesystem уже является уровнем абстракции ...).
    • Используйте другой API / библиотеку. Те же вопросы: зрелость? надежность? стабильность? портативность? простота использования? функции?
  • В случае std :: filesystem (или сетевого TS) есть boost :: filesystem (соответственно boost :: asio) в качестве альтернативы или запасного варианта на случай experimentalотказа или исчезновения.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.