Чи надійні експериментальні особливості сучасного С ++ для довгострокових проектів?

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. Чи схильні експериментальні функції до значних змін, які роблять їх ненадійними?

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

c++  c++11  portability  c++17  c++-standard-library 
— Квантовий фізик
джерело
25
слово експериментальний не відповідає на ваші запитання?
— 101010,
6
Головним чином справа смаку, але я б не хотів захаращувати код #idef CXX17. IMHO, портативний спосіб полягає в тому, щоб розмістити весь код, пов'язаний з файловою системою, в одному єдиному модулі компіляції (може бути класом), використовувати його в інших частинах коду, кодувати його згідно з чинним стандартом C ++ 11/14. Задокументуйте, чому ви пишете це так, і згодом перенесіть його на C ++ 17 пізніше на етапі технічного обслуговування, якщо це має сенс. (коментуючи оригінальне запитання)
— Серж Баллеста
4
Він був лише "експериментальним" як кандидат для вступу в стандарт. Це не відображення якості коду.
— Галик
5
Було досить багато змін між "експериментальною" та остаточною версіями C ++ 17, див. Документ P0492R1
— Бо Перссон
7
У випадку, якщо filesystemви несете набагато менший ризик його використання, ніж інші речі, оскільки ви вже знаєте, що він стандартизується в C ++ 17, а його точна специфікація C ++ 17 є загальнодоступною. Отже, все, що вам потрібно зробити, це переконатися, що ви використовуєте лише ті experimental::filesystemфункції, які вказані в специфікації C ++ 17. І звичайно, ви повинні знати, що всі ваші цільові платформи підтримують одну з experimental::filesystemабо C ++ 17 std::filesystem.
— Говард Хіннант,

Відповіді:

79
  1. Чи гарантовано, що всі сумісні компілятори мають однакові експериментальні функції?

Ні, експериментальні функції необов’язкові.

  1. Чи схильні експериментальні функції до значних змін, які роблять їх ненадійними?

Так, комітет С ++ може навіть прийняти рішення відмовитися від функції, або в процесі стандартизації може виникнути дефект, який змусить ознаку змінитися.

Як правило, не дуже добре залежати від експериментальних особливостей. Експериментальні особливості - саме те, про що говорить слово (тобто експериментувати).

— 101010
джерело
2
Посилаючись на другий пункт, зауважте, що я говорю про функції, які вже прийняті, але можуть бути іншими.
— Квантовий фізик
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, необхідного для визначеної поведінки - не хотів би, щоб він відповідав на цей FDIS;)
— MSalters
50

Хтось із аудиторії задав запитання під час виступу на CppCon 2016 ( YouTube ) під назвою "Стандартна бібліотечна панель C ++" про можливість імені experimentalвідлякувати користувачів від використання чогось у просторі імен:

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

Майкл Вонг (голова SG5 та SG14 та редактор Concurrency TS) спочатку поставив запитання:

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

Потім Алісдейр Мередіт (колишній голова робочої групи) продовжила:

Я збираюся тут зайняти протилежну позицію. Однією з речей, яку Герб [Саттер] сказав, як скликач WG21, стандартної групи, коли ми вирушили на шлях TS, є те, що він не думав, що TSes досягне успіху, поки ми не зможемо щось просунути вперед, тому що це означає, що ми недостатньо експериментальні, недостатньо амбітні в тому, для чого використовуємо TS. Ми справді цього хочемоexperimentalщоб бути натяком на те, що так, ці речі можуть бути змінені, ми не зобов’язуємо це робити, і ми можемо щось помилити. Це для того, щоб знизити наш бар’єр для речей, які ми вважаємо настільки амбіційними та досяжними, наскільки ми можемо [...] Зараз стандарт, схоже, перебуває на трирічному циклі випуску, ми повинні бути набагато амбітнішими, застосовуючи справді експериментальні функції в TS, і, можливо, швидше просувається в самий основний стандарт. Але знову ж таки, це буде цікавою темою для обговорення на наступних кількох засіданнях [стандартного комітету C ++].

Стефан Т. Лававей (підтримуючий впровадження STL від Microsoft) востаннє відповів:

Важливо провести різницю між експериментальністю інтерфейсу та експериментальністю реалізації, тому що коли ви говорите "виробництво готове", що це означає? Зазвичай, "виробництво готове", ви думаєте про те, що говорять про впровадження. Цілком можливо, щоб реалізація [чогось із std::experimental] була абсолютно [...] куленепробивною. [...] Щось на зразок [...] <random>заголовка в TR1, [це було] дуже, дуже приємно в TR1, і ви могли б мати абсолютно куленепробивну реалізацію цього, але виявилося, що інтерфейс збився по суті [до виходу] C ++ 11 і [...] якби ми тоді знали, що ми робимо зараз, введення було experimentalб кращим сигналом для людей, що, "Гей, можливо, ти не хочеш використанняstd::experimental::variate_generator тому що, ха-ха, це зникне в C ++ 11 ".

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

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

— Джозеф Томсон
джерело
47
Через 10 років після того, як я вперше прочитав це ім’я, той факт, що супровідник STL від Microsoft називається STL, все ще змушує мене хихикати.
— Jörg W Mittag
19
@ JörgWMittag вам слід познайомитися з їхнім супроводжувачем компілятора, Майклом Сем Віктором Коллінзом
— MM
28

"Експериментальний" - це дещо перебільшений термін. filesystemБібліотека виникла в Boost , і пройшов через декілька ітерацій там, до подання ISO.

Однак стандарти ISO навмисно дуже консервативні. Називання експериментального означає, що ISO явно не обіцяє, що іменування буде стабільним; Абсолютно ясно, що вам доведеться повторно звертатися до свого коду деякий час у майбутньому. Але, знаючи ISO, цілком ймовірно, що будуть вказівки як.

Що стосується сумісності між компіляторами, сподівайтесь, що вона буде розумною. Але траплятимуться кутові випадки (подумайте, наприклад, про шляхи, що відносяться до диска Windows), і саме тому майбутній стандарт може зламати ваш існуючий код. В ідеалі це зламало б ваш код лише тоді, коли ви залежали від цього кутового випадку, але це не гарантія.

— MSalters
джерело
8

Можливо, є більше речей, про які можна дивуватися.

Кілька моментів, на які слід звернути увагу:

  • Наскільки мультиплатформенний ваш проект? Якщо задіяний лише один компілятор, ви можете перевірити його реалізацію та послужний список, щоб прийняти рішення. Або запитайте їх!

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

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

  • Які альтернативи?

    • Використовуйте експериментальну функцію, а потім адаптуйте код до модифікацій, коли / якщо він стане стандартизованим. Це може бути настільки просто, як видалення experimental::, або настільки важким, як примусові обхідні шляхи.
    • Додайте шар абстракції (коментар Сержа Баллеста). Якщо експериментальна функція зміниться, ваші повторні записи будуть ізольовані. Для стандартної функції це може бути надмірним (std :: файлова система - це вже рівень абстракції ...).
    • Використовуйте інший API / бібліотеку. Ті самі питання: зрілість? міцність? стабільність? портативність? простота використання? особливості?
  • У випадку файлової системи std :: (або мережевої TS) існує boost :: filesystem (відповідно. Boost :: asio) як альтернатива або резервна версія, на випадок, якщо ця система experimentalвийде з ладу або зникне.
— Пабло Х.
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.