Mail.ru Group corporate blog
Programming
Perfect code
C++
Development Management
Comments 26
+4

У подхода (2) есть один очевидный плюс — на меня не вываливают фактически новый язык "в один день".


Между С++98 и С++11 просто пропасть, как синтаксическая, так и по содержанию стандартной библиотеки. Эта же пропасть есть между С++11 и С++20. Если бы на меня вывалили всё то, что появилось в С++14 и С++17 вдобавок к тому, что появится в С++20, я бы наверное ушел программировать на другом языке.

+2
Тем не менее стоит признать, что C++20 будет «сырым» — в том же смысле в каком C++11 был «сырым».

Очень многие фичи в нём недовылизаны… и это нормально. Потому что ну невозможно боььшие, «тяжёлые» фичи «вылизать в лаборатории».

У вас выбор:
1. Выпустить C++20, услышать поток матерной брани от людей, которые попытаются воспользоваться фичами в продакшн… и исправить C++23 так, чтобы он не был таким «сырым».
2. Потратить три года, вылизать фичи ещё — и всё равно получить «сырой» C++20… только теперь он будет называться C++23.

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

Не могу похвастаться глубоким знанием стандарта. Скажите, ведь новые стандарты обратно совместимы с предыдущими? И, если да, то какая-то косячная фича в будущем может быть только расширена, дополнена итп, но не переделана?

0
Может быть и выпилена auto_ptr was fully removed in C++17. Если я правильно понял вопрос.
0
Вы, может быть удивитесь, но ответа на этот вопрос нет. Сейчас ситуация очень странная:
1. Де-юре никаких ограничений по совместимости у комитета по стандартизации нет.
2. Де-факто предложение что-то поломать — встречается требованием объяснить кто именно будет затронут и жуткой паникой.
В C++20 «выпилили» несколько фич официально, и хотят посмотреть — что будет. А перед C++20 уже будут решать — то ли официально вносить «совместимость» как одну из целей, то ли, наоборот — начать принимать изменения, которые могут на неё повлиять…
0
если следить за развитием языка (даже статей на хабре хватит), то вы заметите, что многие фичи получают огласку за 5-6 лет до их включения в стандарт
0

Есть один момент — если эти фичи не стандартизованы, то использовать их на продакшене зачастую довольно рискованно. Представим себе, что даже какая-нибудь небольшая вещь вроде std::optional вдруг внезапно поменяет свой интерфейс, а вы уже 7 лет пишете с её использованием в ожидание того, что она войдет в стандарт такой, какая она есть.

0
Есть и обратная тенденция: фичи, которые комитет по стандартизации включил в драфт, часто разрешают применять даже если формально релиза ещё не было. У нас сейчас активно используются designated initializers и начинают использоваться модули — хотя «де-юре» они появятся в C++20.

А вот пока в черновиках их не было — они были запрещены.
0
Даже не знаю как на это реагировать… Слишком рано или слишком поздно?

Хочу напомнить что модули были включены в стандарт буквально несколько месяцев назад, уже-таки в 2019м, до этого никто точно не знал — будут они в C++20 или нет, а если будут — то в каком виде.

И если вы любите использовать фичи, которых в стандарте ещё нет, а потом всё 20 раз переделывать… то это не значит, что другие компании (особенно крупные) должны вести себя так же…
0
И если вы любите использовать фичи, которых в стандарте ещё нет

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

Это просто. Ну я не знаю как — семантика приличного языка не позволяет.
0
Слишком рано или слишком поздно?

Без обид, но слишком опоздали.
Ну вот, #include изобрели в 1968, он устарел в 1969, и далее вы примерно на полвека опоздали.
0
Здаётся мне что #include изобрели таки пораньше. А язык C — это 1972й-1973й. И в нём никаких модулей до сих пор нету.
0
и начинают использоваться модули

О, раз вы их как-то более-менее опробовали в бою.


А зачем вообще модули? Я почитал, подумал и не понял, чем они мне (ну и людям вроде меня) помогут.


Единственное, что меня не устраивает в препроцессоре и #include — скорость компиляции. Но то, как устроены темплейты в C++, означает, что полноценной раздельной компиляции шаблонов не будет никогда, что для того кода, который я обычно пишу, означает, что модули сэкономят максимум на повторном парсинге хедеров (и то не факт), что, опять же, для того кода, который я обычно пишу, не так много.


Я слышал, людям они ещё нравятся потому, что макросы там не утекают, всякое такое. Но, опять же, в коде, который я пишу, и в библиотеках, которыми я пользуюсь, они почему-то и так не утекают (отчасти потому, что их толком нет, а то, что есть, утекать должно).


А вот designated initializers да, тема, я как узнал, что их в стандарт включат, начал везде пихать.

0
Я слышал, людям они ещё нравятся потому, что макросы там не утекают, всякое такое.
Не только макросы. Ничего не утекает. Главное преимущество — то, что если ваш модуль использует какой-нибудь <set>, то это не значит, автоматически, что его получат и те, кто ваш модуль захочет поиспользовать. И, соответственно, ничего не развалится, когда вы <set> прекратите использовать.

А время компиляции — да, тут большого выигрыша нет, это не о том.
0
А время компиляции — да, тут большого выигрыша нет, это не о том.

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

0
Эту проблему давным-давно решили precompiled headers. Вряд ли модули смогут что-то лучше сделать.

Нет, модули — это о другом. Решение проблем с ODR и инкапсуляция. Нет, какое-то ускорение будет, да, но ради него — никто не стал бы весь этот огород городить…
+1
Эту проблему давным-давно решили precompiled headers. Вряд ли модули смогут что-то лучше сделать.

разве модули не обещали в среднем двукратный прирост скорости компиляции?
0
Уж не знаю какую некромагию вы применяли чтобы услышать мнение модулей о чём-либо… или вы о каких-то шарлатанах, которые мало чего понимают в С++ и его проблемах говорите?

Если о последнем — то явки, пароли, в студию. Откуда могло бы взяться какое-то существенное ускорение — мне, например, неясно. И кто вам его обешал — мне неизвестно тоже.
+1
Пусть икается тем (ладно-ладно, только Гору Нишанову ;-)), кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках? Ведь были же достойные альтернативы (от того же самого Christopher Kohlhoff — автора библиотеки Boost.Asio), но Microsoft как обычно продавила своё решение…
0

Может быть слишком много кода бы сломалось c async/yield? Никто ведь не хочет переписывать тонны кода на плюсах просто так.

0
Могу сказать, что в пыхе тоже много умных сделали свой yield, и он у них ожидаемо сломался, когда это внезапно стало ключевым словом. Ничего, переписали.
0
Не знаю, кто такая «пыха», но в PHP ломают совместимость местами не то, что в минорных релизах, но даже и в «мелких фиксах» — это не повод теперь такую же фигню в нормальных языках устраивать…
0

Решить проблему можно было очень просто — ввести слова asyng и await в список зарезервированных, скажем в С++14 и кидать варнинги 6 лет подряд. Думаю за это время все всё переписали бы.

0
кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках?

есть такая функция, std::this_thread::yield(). C P1485 были бы и слова нормальные, и сигнатура, но сначала дотянули, а потом стало слишком поздно. Хотя про то что co_* уродливо, орало всё комьюнити, с самого первого дня. Плюс, мы имеем UB с перепутанными return/co_return на абсолютно ровном месте.

Теперь единственный вариант — реализовать P1485 во всех основных компиляторах в виде расширения и продвигать в с++23. Одно маленькое «но» — msvc проприетарный.
Only those users with full accounts are able to leave comments. , please.