Если вы пишете на c++98/99, то какие ограничения не позволяют вам перейти на c++11/14/17?

Большое количество серверов с говномамонтным дебианом, обновлять их сложно, а исторически сложилось так, что собирают прямо не отходя от кассы.

А зачем на него переходить ? Я вижу ровно 0 (нуль) полезного в c++11/14/17.

На какой-то embedded железке нельзя обновить ос и компилятор.

Самое распространенное - AVR, MSP430, Cortex-M, под это дело уже есть gcc 7.2.0. Про пики не знаю, может тоже есть что-то. Остаются только совсем уж древние и специфические железки.

Я вижу ровно 0 (нуль) полезного в c++11/14/17.

Хотя бы из-за смартпоинтеров. Да и речь о Си без плюсов.

Когда нужно собирать древним компилятором, по какой-то причине.

future/promise/async? Мне понравилось.

Хотя бы из-за смартпоинтеров.

Хахаха. Скажем дружно. Нафиг нужно.

Хахаха. Скажем дружно. Нафиг нужно.

Толсто вбрасываешь ;)

Это разве уже в си втащили ?

c++ я про с++, да да Си есть только 11 или будет.

Чёрт, либо я выдал желаемое за действительное, либо афтар заголовок поравил.

c++ я про с++, да да Си есть только 11 или будет.

Тю. А чего ж дезу такую вкинул сначала? Кстати, году в 20 скорее всего можно ждать новый Си.

Нет не правил C++ написано изначально

а как же божественный auto, делающий волосы мягкими и шелковистыми?

auto нормально так скрывает переменную, что непонятно что там вернулось. Но волосы и правда мягкие и шелковистые :)

Еще всякие военные, у которых всякие сертифицированные РОСА, и последний gcc там чуть ли не 2.9

Большое количество серверов с говномамонтным дебианом

Впролне приличное подмножество С++11 есть уже в Debian 5 (8 лет назад).

нельзя обновить ос и компилятор

This.

За переизбыток auto нужно бить палками.

Я вижу ровно 0 (нуль) полезного в c++11/14/17.

То есть, практическим программированием на с++ ты не занимаешься.

Какие есть ещё?

Рак мозга, например.

На какой-то embedded железке нельзя обновить ос и компилятор.

Со стороны заказчиков бывают требования по поддержке вусмерть тухлых ОС. Например, rhel4. Нацелить на неё современный компилятор (и не сломать его при этом) - это определенный объем работы.

Ну или начальство не разрешает... что странно.

Компиляторы от версии к версии становятся всё агрессивнее и строже. При большой и не очень качественной кодовой базе, обновление компилятора - это трудозатраты (хотя бы просто добиться, чтобы оно собралось) и риск трудноразбираемых багов вокруг UB. Так что начальство может считать, что овчинка не стоит выделки.

Не всякая кодовая база на c++03 успешно скомпилируется под новые стандарты. Модернизировать старый код - это время и деньги. Не все готовы это оплачивать.

Угодал.

Какие есть ещё?

Любовь к хорошо разложившимся трупам.

Есть такое ограничение, называется «зачем?». Эффективно ограничивает от ненужно.

Ну, допустим клиентская база, если делаешь API. Чем тухлее и стабильнее стандарт - тем больше у тебя клиентов, до определенного момента.

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

Если не модернизировать код, то цена поддержки будет только возрастать.

А разве для коммерции это плохо?

А разве для коммерции это плохо?

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

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

Поддержка CentOS 6 =) Но в новых продуктах стали использовать c++11/14/17

Впролне приличное подмножество С++11 есть уже в Debian 5 (8 лет назад).

В Debian 7 в gcc 4.7 некоторых моментов не хватает, и это напрягает. Кажется, emplace у std::vector или что-то вроде того.

Если вы пишете на c++98/99, то какие ограничения не позволяют вам перейти на c++11/14/17?

Да и речь о Си без плюсов.

Ну-ка, это вгде такая речь?

Кресты 17 и 9х это такие разные диалекты уже. Шутки о языке-помойке не смешат уже.

Ну-ка, это вгде такая речь?

Вроде изначально была опечатка (Си без плюсов) или же мне показалось...

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

А как же капитализьм, поиск своего места на рынке, влезание в финпоток? Без этого денег не будет, их другие получат и не поделятся. Написал прогу на фортране и поддерживай и развивай её 100 лет, что может быть лучше, если доходы растут:)))

Большая часть применений auto - это

auto var = std::make_shared<my_super_template<size_t, string, vector<another_template<int64_t>>>>();

Это очевидно, но когда софт работает и есть не просит особо, то об этом не думают.

Впролне приличное подмножество С++11 есть уже в Debian 5 (8 лет назад).

В Debian 7 в gcc 4.7 некоторых моментов не хватает

Эээ... и что? Это причина всё писать на C++98?

Впролне приличное подмножество С++11 есть уже в Debian 5 (8 лет назад).

В Debian 7 в gcc 4.7 некоторых моментов не хватает

Эээ... и что?

Я к тому, что в Debian 7 использование C++11 доставляет ощутимые неудобства. Чего уж там говорить о Debian 5. Не пробовал писать на той версии с++0x, но кажется мне, что это могут делать только отчаянные энтузиасты.

А как же капитализьм, поиск своего места на рынке, влезание в финпоток?

Так и произойдёт. Если, конечно, не получится сделать vendor lock-in.

Написал прогу на фортране и поддерживай и развивай её 100 лет, что может быть лучше, если доходы растут:)))

Просто придёт другой, который предложит цену в два раза ниже за аналогичный продукт, и перейдут на него. А цена в два раза ниже будет благодаря тому, что затраты на разработку и поддержку будут в 10 раз ниже.

>какие ограничения не позволяют вам перейти на c++11/14/17?

«работает - не трогай» :)

Не пробовал писать на той версии с++0x, но кажется мне, что это могут делать только отчаянные энтузиасты.

Так могут делать все, кому хочется чего-то большего, чем C++98. Уже одни shared_ptr и unique_ptr очень сильно облегчают жизнь (но да, unique_ptr придется позаимствовать из Сети).

Думаю, что те, кому очень хочется, уже вполне могли сделать #include <boost/shared_ptr.hpp>.

Просто придёт другой, который предложит цену в два раза ниже за аналогичный продукт, и перейдут на него. А цена в два раза ниже будет благодаря тому, что затраты на разработку и поддержку будут в 10 раз ниже.

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

Думаю, что те, кому очень хочется, уже вполне могли сделать #include <boost/shared_ptr.hpp>.

Если у них использовался boost (или им разрешили его добавить). А unique_ptr в Boost есть?

А что насчет decltype, variadic templates?

Что такое C++99?

хе, это если не пытаться из крестов сделать особый уличный пистон

А для этого в крестах есть есть язык шаблонов без типизации. Можно получить филиал питона во время компиляции.

А что насчет decltype, variadic templates?

Глупо спорить с тем, что больше выразительных возможностей делают жизнь проще. Особенно, если их используют не бездумно, а со вкусом.

Но я говорю про другое. В старых версиях компиляторов — особые версии C++0x, это не C++11. Возможно, кому-то достаточно. Мне вот — нет. И это притом, что я эти decltype и variadic templates не использую. Мне больнее использовать порезанный C++11, чем старый C++2003.

В старых версиях компиляторов — особые версии C++0x, это не C++11.

Ничего особенного - подмножество.

Возможно, кому-то достаточно. Мне вот — нет.

И вывод... какой? Что тем, кто писал на C++98, вообще не следует эти возможности использовать?