Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Глядя на процесс развития некоторых языков программирования почему-то возникают параллели с эволюцией многих программных продуктов, вроде Nero Burning.
Хорошо что С++ это не грозит.
Хорошо что С++ это не грозит.
Если кто-то реализует функциональность сложного метакласса на макросах — то вы никак не поймете что все эти макросы делают просто глядя на них.
На старом видео с прошлой конференции Герб чуть подробнее про это сказал.
Основная мысль — сейчас уже есть вещи, которые нельзя отладить (например нельзя войти в конструктор с = default), отладку должна предоставлять IDE.
Основная мысль — сейчас уже есть вещи, которые нельзя отладить (например нельзя войти в конструктор с = default), отладку должна предоставлять IDE.
Обеспечьте 1) чтоб я точно знал, что будет на выходе и мог легко посмотреть, что на этом самом выходе
Пока такой поддержки в метаклассах я не вижу.
А зря. Еще на презентации в том году годболт уже умел разворачивать тот вариант метаклассов.
2) отладку
Это же в конце концов просто кодогенерация. В стеке напечатает метод экземпляра метакласса, отладчик ткнет в сгенерированный заголовочник
Ошибка в метаклассе аналогична ошибке в метафункции, но тут хотя бы можно писать нормальные сообщения времени компиляции. Хуже точно не станет, если только вы не запрещаете использование шаблонны библиотек в своих проектах.
А вот на счет отладки использующего метакласс класса действительно возникает вопрос. Но если метаклассы будут добавлять реализации функций — на этих реализациях можно будет ставить точку останова, как на привычных шаблонных функциях (почему нет?), а добавление новых членов, как в примере с актором, принципиально не отличается от шаблонных аналогов, наподобие std::bind. Да и тот же std::bind на метаклассах, на мой взгляд, можно сделать более отлаживаемым как во время компиляции, так и во время выполнения.
А вот на счет отладки использующего метакласс класса действительно возникает вопрос. Но если метаклассы будут добавлять реализации функций — на этих реализациях можно будет ставить точку останова, как на привычных шаблонных функциях (почему нет?), а добавление новых членов, как в примере с актором, принципиально не отличается от шаблонных аналогов, наподобие std::bind. Да и тот же std::bind на метаклассах, на мой взгляд, можно сделать более отлаживаемым как во время компиляции, так и во время выполнения.
С метаклассами плюсы с хорошей вероятностью превратятся в write-only язык типа перла.По мнению очень и очень многих
Скоррее до C++11. Яркий пример тому — буст с его вывертами для создания лямбд… Сейчас код на C++ гораздо более читаем и понятен нежели раньше.
Ну, если неподготовленному человеку показать самодельную реализацию std::apply из C++17 с самодельной же реализацией std::index_sequence из C++14, но сделанную средствами C++11, то вряд ли скажет, что «код на C++ гораздо более читаем и понятен нежели раньше» :)
Это я к тому, что в адрес C++ всегда (еще даже до C++98) раздавались жалобы о том, что код на C++ нечитаем и мало кто в состоянии его поддерживать. И, действительно, есть моменты, когда в C++ коде сложно разобраться. Только вот, обычно, это либо проблема разработчика (он, как настоящий творец, так видит), либо проблема сложности самой предметной области или задачи. И в меньшей степени языка C++.
Это я к тому, что в адрес C++ всегда (еще даже до C++98) раздавались жалобы о том, что код на C++ нечитаем и мало кто в состоянии его поддерживать. И, действительно, есть моменты, когда в C++ коде сложно разобраться. Только вот, обычно, это либо проблема разработчика (он, как настоящий творец, так видит), либо проблема сложности самой предметной области или задачи. И в меньшей степени языка C++.
Так надо сравнивать их с альтернативой до C++11, например с функциональными элементами и списками типов из библиотеки Loki от Александреску. И все вопросы отпадут:))))
Так-то оно так. Но раньше навороты от Александреску — это был высший пилотаж. А сейчас каждый может использовать лямбды, auto и variadic templates. Поэтому сейчас часто слышны возгласы вроде «налепили лямбду на лямбде, невозможно понять, что тут происходит». Так что, ИМХО, количество жалоб на «нечитабельность» C++ только растет по мере развития C++. Причем, подозреваю, большинство жалующихся с C++ толком-то и не работают.
Лямбды можно и в шарпе лепить, и в Java уже и в питоне… На самом деле, при грамотном использовании весь ужас метапрограммирования прячется где-то под капотом, и если в команде есть люди которые это с трудом воспринимают, то как правило им это и не надо, они пользуются уже следствиями всего этого, а там уже все намного проще. Вот например захотел я сделать что то типа Asp.Net WebApi на плюсах, конечно один в один не вышло, но сделал так что при определении класса можно определить (а можно не определить методы get post put delete итд...), хотел чтобы н было наследования, чтобы класс был чистым, без полиморфизма, и что бы если класс не содержит методов обработки соответствующих запросов, ервер отвечал что то вразумительное. Под капотом сущий ад из вариативных шаблонов SFINAE, traits итд… Но с наружи пользоваться этим легко и просто, создал реализуаци, определил статический метод который определяет путь обработки запроса — типа «api/device» и реализвывай что тебе надо — get, post итд… И добавь его в список типов, все. Пользуются и радуются:)
При грамотном использовании, как правило, жалоб на write-only язык не появляется. Подобные жалобы, как по мне, появляются либо у тех, кто сталкивается с неправильным использованием, либо у тех, кто не успевает обучаться и не принимает нововведений, либо у тех, кто языком не пользуется, но мнение имеет.
С метаклассами стандарт C++ имеет все шансы из трудночитаемого нечто, превратиться в хорошо описанный документ, где трудных мест будет куда меньше, чем сейчас. Кроме того, это позволит реализовывать общие паттерны единообразно и легко. Позволит уменьшить количество кода-повторений (boilerplate). Ума не приложу, как можно воспринимать метаклассы как что-то отрицательное…
И да, на любом языке можно писать в режиме write-only, только не всегда дело в языке. В C++ нет каких-то «врождённых» проблем, который выдают write-only любым программистом. Точнее есть, но их немного, и они постепенно решаются, в том числе всё большим обузданием SFINAE нормальными инструментами. Т.е. язык явно движется в сторону большей выразительности, а не наоборот.
И да, на любом языке можно писать в режиме write-only, только не всегда дело в языке. В C++ нет каких-то «врождённых» проблем, который выдают write-only любым программистом. Точнее есть, но их немного, и они постепенно решаются, в том числе всё большим обузданием SFINAE нормальными инструментами. Т.е. язык явно движется в сторону большей выразительности, а не наоборот.
del
Мое ЛИЧНОЕ мнение: лучшее что могут сделать разработчики стандарта С++ это либо разбить язык на модули либо принять идею «стандарт языка С++ не может быть больше 1000 страниц» как святую истину. Уже ну очень много всего намешано и все со своими нюансами присыпанное тоннами undefined behavior. Язык превращается в свалку. Человеку который говорит я знаю С++ можно смело плевать в лицо. Сам Страуструп не знает всех нюансов описанных на over 1500 страниц мелким шрифтом. И все добавляют и добавляют… Это хорошо что добавляют… Но очень-очень плохо, что не упорядочивают и не убирают.
А ещё каждый уважающий себя создатель компилятора С++ добавляет свои улучшения (особо отличился Borland/Embarcadero). И получаем по итогу всего например в каких-то мультиплатформенных библиотеках #ifdef на #endif-e и #define-oм погоняет. Да ещё с гарантией того, что на нужной вам платформе оно всё равно без танцев с бубном не соберется.
Какая гадость эти ваши метаклассы. Если кто-то готов платить за такой оверхед на ООП (а indirect calls — это чистое зло с точки зрения производительности), то непонятно зачем писать на C++. Есть другие языки, в которых есть и интерфейсы, и свойства, и время сборки там идёт на секунды, и возможностей выстрелить себе в ногу гораздо меньше.
Может хватит уже пытаться превращать C++ в плохую Java, а, мистер Суттер?
Может хватит уже пытаться превращать C++ в плохую Java, а, мистер Суттер?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[CppCon 2018] Herb Sutter: На пути к более простому и мощному C++