Стоит ли изучать C++17 (и выше) для долгосрочных будущих проектов?

Да

Именно C++17 и выше, отбросив все старые приемы и костыли.

Определённо да. Так и делают нормальные люди.

Нет, с++17 — набор старых приёмов и костылей, то ли дело c++20.

Именно C++17

Уже 20 завозят вроде. Лично мне вкусностей «International Standard ISO/IEC 14882:2014(E) Programming Language C++» хватает.

Отсюда https://github.com/cplusplus/draft ?

Именно.

А по теме - выкидывай костыли времен 03 и переходи на 11/14 стандарт, он сейчас вроде считается стабильным. C++ будет актуален всегда)

14882:2014(E)

o/

Области применения: машинное обучение, рендеринг, симуляция, моделирование, системное программирование, десктопный софт, серверный софт и т.д.

Ты всё это собрался один писать?

2014(E) Programming Language C++» хватает.

template<typename T>
struct Foo
{
    T t_;
    Foo(T t) : t_{t} {}
};

int main(int, const char**)
{
    auto f1 = Foo(1);
    auto f2 = Foo(1.0);
}

с++ протух 20- лет как.

что ты хочешь отбрасывать? всё нужно изучать, и системно.

хотелось бы что-нибудь универсальное и чтобы оно не протухло через 10+ лет

Нет

Странная постановка вопроса. Ну вот ответят вам 20 человек, что смысл есть, а еще 30 — что смысла нет. На LOR-е, да. Причем половина из ответивших будет анонимными икспердами по всему на свете.

И что, на основании результата такого опроса вы будете принимать решение о том, изучать вам C++17 или нет?

Области применения: машинное обучение, рендеринг, симуляция, моделирование, системное программирование, десктопный софт, серверный софт и т.д.

Так вот ты какой, легендарный СПВ

Можете объяснить для непосвящённых, в чём смысл вашего сообщения? Разный тип f1 и f2?

Смысл в том, что С++17 полезный, и С++14 не всегда хватает. Например, в С++14 нужно явно указывать тип шаблона(хотя по типу аргумента компилятор мог бы догадаться, что и было исправлено в С++17)

template<typename T>
struct Foo
{
    T t_;
    Foo(T t) : t_{t} {}
};

/* c++17 -ok, c++14 -error
int main(int, const char**)
{
    auto f1 = Foo(1);
    auto f2 = Foo(1.0);
}
*/
// c++14 -ok, c++17-ok too
int main(int, const char**)
{
    auto f1 = Foo<int>(1);
    auto f2 = Foo<double>(1.0);
}

А, вот как. Спасибо! Я думал, что и в C++14 так можно, потому и задал вопрос.

Обычно если есть софт, написаный на чем-то настолько боянистом, как С++, и нужно его исправить, а кто-то становится в позу и гордо говорит «не могу исправить, я Java-программист», то это звучит убого. Да осильте уже этот С++ в конце концов. Если например компания или проект не поощряет ковбойское программирование и код достаточно консервативен и прост, то не нужно 10+ лет опыта на С++ чтобы эффективно его рефакторить, расширять и исправлять. А новые проекты пишите уже на чем угодно

Стоит, и не для долгосрочных, а уже прямо сейчас. Книжки не нужны, хватит списка новых фичей на википедии, за пордобнослями на cppreference.com

Книжки не нужны

Нужны, но их нет)

Однозначно стоит. Вдруг тебе внезапно понадобятся эллиптические интегралы и функции Бесселя? Как мы раньше без этого жили.

Причем половина из ответивших будет анонимными икспердами по всему на свете.

Ну почему же анонимных :-) Вот у нас эксперт не анонимный :-) Женя теперь пятизвёздочный почётный профессионал ЛОРа :-) Тоже в дискуссии участвует :-) Может быть лучше он расскажет про тернистый путь в освоении цепепе? :-) Что уж там взять с анонимных смайликов? :-) Вот как ты думаешь, сколько надо лет просидеть на стуле, чтобы профессионально писать на цепепе? :-) Лол :-)

Смысл в том, что С++17 полезный, и С++14 не всегда хватает. Например, в С++14 нужно явно указывать тип шаблона(хотя по типу аргумента компилятор мог бы догадаться, что и было исправлено в С++17)

А для функций оно и так работает. Свободную функию без явного указания типа шаблона можно, а конструктор низзя. Л – Логичность, а П – Последовательность.

Учи Rust лучше, он меньше и куда прямее.

1. Для любой ос уже есть компиляторы с поддержкой C++17 с поддержкой от производителей дистрибутива (в дебиане в тестинге, в Ubuntu в отдельном репе, в RedHat в devtoolset, в Windows в MSVS2017).

2. В C++17 появилось много полезных и удобных возможностей (structured bindings, std::optional, std::variant, std::string_view и много других), которыми нужно пользоваться.

Так что для нового проекта имеет смысл сразу закладываться на C++17. Старые проекты в активной разработке тоже вполне можно переводить на новый стандарт (но тут, скорее всего, быстро это не сделать, потому что, однозначно, потребуются хоть и чисто косметические переделки, из-за новых warning'ов, но это при любом раскладе потребует тестирования, ну, а тот, кто использует бинарные не чист C-шные библиотеки - ССЗБ). Проекты, которые в состоянии поддержки (без развития) переводить на C++17 нет смысла.

Есть некоторые косяки в Kdevelop и QtCreator, из-за того, что в них используется для семантического анализа clang-3.9, который не в курсе про C++17 (в MSVS все нормально) и в IDE новые возможности показываются с ошибкой. Для QtCreator вот исправляющий костыль (https://bugreports.qt.io/browse/QTCREATORBUG-18657), либо использовать после следующую версию QtC (следующая вот-вот выйдет, но тоже с clang-3.9). Как исправлять в KDevelop я не в курсе. CLion тоже чуть косячит, но не настолько. Он, например, для std::variant выдает предупреждение (в только что вышедшей версии его не исправили).

Ну и самое главное. Вот представь, начинаешь ты новый проект на C++, но на версии 14. Проект будет существовать долго, у тебя уже дети заведутся, подрастут слегка и как-то лет через 10 (в 2027 году, когда с++20 будет не первой свежести) придет к тебе сынишка и спросит: «Папа, а почему ты в своем проекте не используешь c++17?». Ну и что ты ему скажешь?

проще сразу глаза выколоть, ибо всё равно вытекут от чтения кода на rust.

Нет.