Недавно набрёл на доклад Герба Саттера на тему cppfront
Пост про него от самого Герба Саттера здесь.
Я вообще не самый большой поборник перехода на новый С++, т.к. в большинстве своём все разговоры о новых его вариантах начинаются с "а вот мы хотим тут побольше ограничений и проверок напихать, чтобы некоторые странные, по нашему мнению, вещи нельзя было выразить". Потому что в своё время C++ зашёл мне наоборот - возможностью делать в нём сравнительно сложные вещи, несмотря на выстрел в себе ногу. Ну и часто есть ощущение, что из-за этих ограничений придётся писать больше, чего мне вообще хотелось бы избежать (вообще чем дольше живёшь, тем меньше хочется программировать). Я вообще сторонник того, что в условном C++2+ должна появиться адекватная стандартная библиотеками побольше, нормальная работа с кодировками и много чего другого (впрочем это пахнет фреймворком, да).
Но здесь доклад мне зашёл, потому что во-первых зашла идея про то, что это всё компилируется в C++ (т.е. прямое взаимодействие со старым кодом возможно, что клёво). Мне страшно понравилась идея того, что некоторые операторы и конструкторы будут генерироваться из других реализаций. Говорите, что угодно, но сейчас реализовать все конструкторы и операторы что требуются от сложного класса в куче с move-семантикой прямо долго в реализации, так что я иногда забиваю. Думаю что я в этом не один.
Ещё там убрали непубличное наследование с замечанием, что оно не нужно. И я, пожалуй, соглашусь - не применял его ни разу, да и везде где читал, это считалось плохой практикой. Насчёт виртуального наследования (а его вроде тоже убрали) трудно сказать, но я в целом против ромбовидного наследования, т.к. единственное место, где как я видел, это хорошо было сделано - это Eiffel и там оно довольно многословно. Впрочем, думается, это реально уже давно не нужно, если адекватно проектировать архитектуру.
Понравилась идея об условном разделении классов на подвиды с пометками и требовании к реализации их определённым образом - как по мне это нужно для всяких value class, интерфейсов и прочему. Очень здорово, что для расширения там есть метаязык для описания требований, думаю, что это интересный вариант и может пригодиться.
Позабавил момент с "сестринскими языками" плюсов - в списке оказались Python и JS, что логично, в силу применения их в скриптовании. Странно, что в список не попал Lua.
Честно говоря, хочется попробовать повозиться с этим, жаль, что сейчас в приоритете совсем другие задачи.
Комментариев нет:
Отправить комментарий