Прекрасный доклад. Рефлексия это моя персональная боль, которой очень не хватает в плюсах и отсутствие которой вынуждает писать ад где сперва идут макросы, потом шаблоны и... собственно что я рассказываю в любой хорошой библиотеке есть этот ад, в Boost он есть, он везде есть :)
Вот этот бардак начался с тех пор как программистов допустили непосредственно к стандарту языка. Развивается не фреймворк, как с С# или других нормальных языках, где нет анархии в стандартизации. Любой очкастый "умник"-проходимец, может надеть толстовку "я разрабатываю с++" и начать реализовывать "а мне так удобнее" или "так код красивее". Это всё равно как скрестить законодательную власть с судебной или исполнительной - какой закон мне сейчас нужен, такой и напишу. Что нет концептуального взгляда на эволюцию языка - то мелочи. Сначала усложнили стандарт "синтаксическим сахаром" для упрощения, а потом: "ну это же с++, в нём не бывает просто". Нужен "сахар" - не замешивайте его в стандарт - выносите в бусты и стд. Сначала введём auto, чисто потому что "так проще", а потом, когда возникает неоднозначность, реализовываются целые механизмы для уточнения авто. Упростили, но так что пришлось усложнить - где логика??? Если С++ - язык с явной типизацией, то какие auto, какие decltype??? Если автору для его аудио надо - то делай библиотеку - причём здесь стандарт??? Я не против развития языка - он должно идти в ногу со временем и технологиями. Пример тому - многопоточность. Но когда каждые три года новая "революция" - это деградация, а не развитие. Язык умирает изнутри, потому что цели его возникновения и существования размываются... В своё время stl создали учёные в области информатики, как отражение научного подхода на практику; сейчас авторы stl - авторы бустов в красивых толстовках.
Реально и так был язык тысяч костылей, а теперь его можно называть "миллиард костылей". Писать стало проще, но под простотой заложили такую мину, что вряд ли будущие поколения её потянут !
Момент на 48:10 неужели действительно кто-то будет писать такой код с использованием ranges вместо простого range-based for? Я не вижу ни одного преимущества, а вот недостатков много: сложность дебага, время компиляции, производительность(в дебаг-билдах в основном, но иногда и при -O3). Количество строк кода будет то-же.
На таком небольшом примере наверное это не очень очевидно, но чем больше требуется фильтраций и трансформов, тем будет: 1) сложнее код цикла, 2) легче допустить ошибку в фильтрации руками (забыть оператор !, например) или трансформ (обратиться к другому полю класса, например) 3) в теле цикла будут значения, которые там не нужны. Это когда мы сужаем скоуп переменных, чтобы не было лишних возможностей опечататься.
@@ЗолотойКупол-я4о В C# его тоже толком нет, макры как в Nemerle не напишешь. Правда constexpr сделали могучий, но программируемого языка программирования так и не вышло. Может это и невозможно, образец гибкости (во всём) - это Common Lisp, но за эту гибкость приходится платить явным указанием типов для эффективности (таковая может превышать эффективность Си за счёт прекомпиляции). Компилятор вроде SBCL или Lispworks умеет оптимизировать и даже выводить типы, но при всей мощи макросов нет "из коробочных" шаблонов типов, чтобы оптимизировать в стиле C++. Даже если реализовать аналог шаблонов вместе с концептами и прочей хренью (мы уже делали такое на системе типов Hindley-Milner), то получится ещё одна реализация громоздкого C++ или аналог OCaml. Вывод: идеального языка программирования (серебряной пули) не может быть, решает правильная смесь !
Синхронный (!) генератор - это ещё не coroutine (уважаемый Тимур) - это так, побаловаться. А вот асинхронные coroutines - это действительно высший пилотаж и им действительно стоило уделить время, а не синхронному генератору, который, IMHO совсем несущественное дополнение к C++. Про coroutines Вы совсем не поговорили. Очень поверхностный само PR. Зачем говорить о том, чего не знаешь сам?!
Представьте себе, это в разных потоках, это значит что поток остановится на yield, пока генератор не вызовут в другом потоке, а тот будет стоять ещё на чём то. А если самому написать то же самое (один хрен столько кода реализовывать), то можно будет управлять буфферизацией, чтобы поток не простаивал, если принимающий поток несинхронно жрёт подаваемое. Какой смысл вообще это вводить в язык, когда то же самое пишется на раз "вручную" ? Лепишь генератор, дёргаешь его, возвращаешь, сто лет назад обработку видео так делали и без всяких уродских co_yield !
...с ещё более уродскими и нечитаемыми решениями, да. "Уродские" co_yield облегчают написание и сопровождение подобного кода в разы. Если с ними, конечно, разобраться нормально, а не ныть как старпёр "раньше было лучше", не желая разбираться в чём-то новом. Но ты прав в одном: если нужна тонкая настойка низкоуровневых деталей, то придётся писать самому. И так было всегда в C++. Стандартная библиотека только предоставляла "достаточно адекватные" (но не оптимальные!) решения. Например, ты не выберешь стратегию роста capacity в std::vector'е или размер буфера для SSO внутри std::string'а. Хочешь управлять этим -- пиши свои собственные реализации (или бери такие из сторонних библиотек). Но для большинства задач, где нет необходимости выжимать максимум возможной производительности, стандартных "неоптимальных" средств вполне достаточно. Зато это будет дёшево в плане стоимости разработки и поддержки. Вот, с корутинами и асинхронностью то же самое.
Видимо неопытный плюсист докладчик, говорит что надо было писать длинющий тип, когда не было auto, а typedef куда делся ? Чтобы инициализировать вектор, надо было писать цикл, а ничего, что вектор в памяти хранится последовательно и размер елемента известен, соответственно его можно инициализировать чисто статически. Вот из-за таких "ветеранов" они и нагородили с три короба.
auto удобен в множестве случаев и в случае чтобы много typedef не использовать, об этом Бьярн говорил, яркий пример auto it = vec.begin() и ему похожие. Один из конструкторов vector тем и занимается что в цикле копирует в себя.
Это прекрасная иллюстрация того, что язык настолько уродлив и переуслажнен, что человек, годами работающий с этим языком, не может толком им пользоваться. И на профессиональной конференции видеть, что не самые глупые люди планеты не могут овладеть всеми тонкостями хитросплетений, заложенных в каждом элементе этого "профессионального" инструмента - это лютая дичь. Жалко, что из плюсов она никуда не улетит.
@@МаксимХвостов-м1й Но писать длиннющий тип не надо было, потому что он был забит в typedef, когда мастеришь вектор и сам тип, а тип итератора уже можно было доставать из него самого. auto удобен конечно, но по факту это уже изврат из ранней неспособности С++ выводить типы автоматически, по сравнению с OCaml, Haskell и т.п. А потом эти новинки из ФП стали проникать в С++ и другие императивные популярные языки типа Java, C# (лямбды одни чего стоят) и понеслась, стали тащить всё что плохо лежит 🙂 Что наверное к лучшему, потому что ФП всегда был передовым краем программирования и компьютерных наук.
@@IExSet c++ всегда был «швейцарским ножом». Когда он появился он назывался C With Classes что из названия говорило об этом языке, в те времена ООП был популярен. С тех пор ни чего не изменилось в язык по прежнему вваливается всё до чего дотянуться можно, программист сам потом должен с этим разгребаться. Тут высказывания Линуса в тему. Я наблюдал в компаниях где используют C++, используют C++98 и некоторые фишки из новых стандартов тотже auto. Связанно с тем что новички не владеют новым стандартом, обучать дорого, переписывать продукт на новый стандарт дорого, и просто… новое не всегда значит эффективное. Прототип программы сначала пишут на (обычно Питон, его все любят) затем переписывают на C++. Ни когда не видел чтобы сразу на плюсах писали.
Только для ниасиляторов вроде тебя. А для людей, которые им пользуются, он стал только лучше. Не было бы у него преимуществ -- на нём бы никто не писал.
@@MaceUA Он стал лучше, но комментатор прав, просто все проблемы замели под коврик новых и новых слоёв, значит рано или поздно придётся поднять и говно полезет во все стороны !!! Мне почему то больше нравится C++, чем тот же Rust, но ПРАВДУ я знаю и не прячу голову в песок!
@@IExSet Хейтеры уже который десяток лет ждут, пока "говно полезет". А оно пока всё никак. Но будь уверен, что твои субъективные впечатления, называемые "ПРАВДОЙ", действительны, а все осилившие C++ программисты, не разделяющие подобную истерику, просто "прячут голову в песок". Это твоё право.
это же надо, человек даже не понимает как работают микропроцессоры, потоки, что это такое, и что происходит "после С++" для непосредственного запуска на микропроцессорной технике. Разве можно разрешать такому обсуждать корутины, колбеки и потоки? А я не знаю "компиляторы" и что они там после себя порождают, - гордо заявляет это тело (с)
@@IExSet угу, ну просто очевидно же, что если корутина - это не "про поток", а тем не менее N микротасков действительно выполняются одновременно и лепятся в одну кучу в одном потоке с иллюзией многозадачности, то там существует диспетчер микротасков, компилятор сам бьёт каждый микротаск на логические конструкции, по возможности логически изолированные, для каждого инжектит начальный пролог, завершающий эпилог с информированием управляющего ядра корутин. Делается виртуальная "нарезка". И молотит каждый мини элемент в цикле последовательно один за одним дёргая из каждой нарезки по чуть чуть. Средня длительной 1 элемента нарезки, скажем 1 милисек. Для асинхронного I/O синтетический колбек направляется в ядро. Микротаск, для которого взведёно сосотояние "ожидается колбек" - пропускается в цикле. Неужто человек сам не может такое за пол дня сделать под себя с минимумом лишнего шлака и привнесённого оверхеда? Или уже люди настолько измельчали, что не могут свой "аналог корутины" ручками побить на логически независимые части с промежуточным отходом в своё "контролирующее ядро"? Пусть даже корутина занимает 10 экранов вниз, 20, 50. Это не же долго.
@@IExSet Нашли одного, который не разбирается в компиляторах (причём и близко не главного в комитете), среди сотен человек, участвующих в стандартизации -- "они и возглавляют". Логика. И ничего, что людей, разбирающихся в компиляторах, в комитете тоже предостаточно -- и их мнение обязательно будет учитываться, если кто-то из незнающих предложит что-то неудачное. А такие, как этот докладчик, могут всё ещё рассказывать про высокоуровневые вещи в языке; про его правила, описываемые стандартом (который тоже про компиляторы практически ничего не знает). Никто не запрещает потом также послушать и тех, кто разбирается в низкоуровневых деталях, и сложить 2+2 самостоятельно.
@@MaceUA Предостаточно, но курс на ожирение то мы видим, вот уже постепенно начинают забивать на принцип, что не надо платить за то чем не пользуешься.
Всеж заголовок - это неадекватный перевод. Как и хедер - неадекватное название. Но другое слово както не находится, потому адекватнее наверн ввести новый термин "хедер" в язык. Что обычное дело
@@HedgehogInTheCPP без мэтта, море овер. иф ю хочешь фаинд фолт, то zagolovochnye faily. Хедер алвайс хедер :-3 Приятно тебе такую галиматью на смеси английского и нижегородского читать ? Одно дело профессиональные термины, другое дело наплевательство на язык, культуру и слушателей !
@@IExSet "Заставь дурного богу молиться..." Конечно, если так в крайности бросаться, то будет "галиматья". Любую сколь угодно хорошую идею доведи до абсурда -- будет так же. А "хедер" нормальное слово для разработчиков на C++. Культурологи и прочие борцуны за чистоту языка идут фак земселвс.
6:08 - начало настоящего доклада. Не благодарите.
Что мешало обрезать первые минуты ролика, где идёт трёп, не имеющий отношения к теме?
Это Сибирь! Здесь еду по карточкам выдают, не посмотришь начало видео - останешься голодным ;)
сделайте форк видео и обрежьте начало :)
@@МаксимХвостов-м1й Причём строго по карточкам NVidia, AMD вообще не принимают, прикиньте !!!
уже 23-й стандарт, а полноценная поддержка модулей компиляторами до сих пор отсутствует.
19:22 "Этот код конечно не соберётся, потому что конечно в плюсах не бывает так, чтобы было просто." Сколько же боли в этих словах :'(
Прекрасный доклад. Рефлексия это моя персональная боль, которой очень не хватает в плюсах и отсутствие которой вынуждает писать ад где сперва идут макросы, потом шаблоны и... собственно что я рассказываю в любой хорошой библиотеке есть этот ад, в Boost он есть, он везде есть :)
Давай делайте больше видосов про С++.
Делайте уроки по С++ 20.
Какой доклад Sean Parent'a с упоминанием о циклах в C++ имелся ввиду?
"C++ Seasoning" с GoingNative 2013
чем yield лучше static?
Вот этот бардак начался с тех пор как программистов допустили непосредственно к стандарту языка. Развивается не фреймворк, как с С# или других нормальных языках, где нет анархии в стандартизации. Любой очкастый "умник"-проходимец, может надеть толстовку "я разрабатываю с++" и начать реализовывать "а мне так удобнее" или "так код красивее". Это всё равно как скрестить законодательную власть с судебной или исполнительной - какой закон мне сейчас нужен, такой и напишу. Что нет концептуального взгляда на эволюцию языка - то мелочи. Сначала усложнили стандарт "синтаксическим сахаром" для упрощения, а потом: "ну это же с++, в нём не бывает просто". Нужен "сахар" - не замешивайте его в стандарт - выносите в бусты и стд. Сначала введём auto, чисто потому что "так проще", а потом, когда возникает неоднозначность, реализовываются целые механизмы для уточнения авто. Упростили, но так что пришлось усложнить - где логика??? Если С++ - язык с явной типизацией, то какие auto, какие decltype??? Если автору для его аудио надо - то делай библиотеку - причём здесь стандарт??? Я не против развития языка - он должно идти в ногу со временем и технологиями. Пример тому - многопоточность. Но когда каждые три года новая "революция" - это деградация, а не развитие. Язык умирает изнутри, потому что цели его возникновения и существования размываются... В своё время stl создали учёные в области информатики, как отражение научного подхода на практику; сейчас авторы stl - авторы бустов в красивых толстовках.
Реально и так был язык тысяч костылей, а теперь его можно называть "миллиард костылей". Писать стало проще, но под простотой заложили такую мину, что вряд ли будущие поколения её потянут !
Момент на 48:10 неужели действительно кто-то будет писать такой код с использованием ranges вместо простого range-based for? Я не вижу ни одного преимущества, а вот недостатков много: сложность дебага, время компиляции, производительность(в дебаг-билдах в основном, но иногда и при -O3). Количество строк кода будет то-же.
На таком небольшом примере наверное это не очень очевидно, но чем больше требуется фильтраций и трансформов, тем будет:
1) сложнее код цикла,
2) легче допустить ошибку в фильтрации руками (забыть оператор !, например) или трансформ (обратиться к другому полю класса, например)
3) в теле цикла будут значения, которые там не нужны. Это когда мы сужаем скоуп переменных, чтобы не было лишних возможностей опечататься.
6:30 начало
Ну правильно плевать на представление докладчика :-)
зачем корутины называть функциями? почему не называть генераторами?
Кстати - это самое понятное название, генератор - это их суть, никакие они не "ко" и не "рутины" :-)
Не обязательно генератор, может быть асинхронная задача, ввод вывод, да в общем всё на что фантазии хватит.
@@МаксимХвостов-м1й должно быть одно слово, покороче. Вот такие многословные не прижились, и были вытеснены аглицкими кальками.
@@АлександрЛитягин-ф6у сопрограммы ?
Ranges - наконец завезли аналог LINQ из C#. С поправкой на более громоздкий синтаксис :)
LINQ в C# по круче будет. В С++ пока не хватает доступа к AST, чтоб как в C# было
@@ЗолотойКупол-я4о В C# его тоже толком нет, макры как в Nemerle не напишешь. Правда constexpr сделали могучий, но программируемого языка программирования так и не вышло. Может это и невозможно, образец гибкости (во всём) - это Common Lisp, но за эту гибкость приходится платить явным указанием типов для эффективности (таковая может превышать эффективность Си за счёт прекомпиляции). Компилятор вроде SBCL или Lispworks умеет оптимизировать и даже выводить типы, но при всей мощи макросов нет "из коробочных" шаблонов типов, чтобы оптимизировать в стиле C++. Даже если реализовать аналог шаблонов вместе с концептами и прочей хренью (мы уже делали такое на системе типов Hindley-Milner), то получится ещё одна реализация громоздкого C++ или аналог OCaml. Вывод: идеального языка программирования (серебряной пули) не может быть, решает правильная смесь !
Синхронный (!) генератор - это ещё не coroutine (уважаемый Тимур) - это так, побаловаться. А вот асинхронные coroutines - это действительно высший пилотаж и им действительно стоило уделить время, а не синхронному генератору, который, IMHO совсем несущественное дополнение к C++. Про coroutines Вы совсем не поговорили. Очень поверхностный само PR. Зачем говорить о том, чего не знаешь сам?!
Представьте себе, это в разных потоках, это значит что поток остановится на yield, пока генератор не вызовут в другом потоке, а тот будет стоять ещё на чём то. А если самому написать то же самое (один хрен столько кода реализовывать), то можно будет управлять буфферизацией, чтобы поток не простаивал, если принимающий поток несинхронно жрёт подаваемое. Какой смысл вообще это вводить в язык, когда то же самое пишется на раз "вручную" ? Лепишь генератор, дёргаешь его, возвращаешь, сто лет назад обработку видео так делали и без всяких уродских co_yield !
...с ещё более уродскими и нечитаемыми решениями, да.
"Уродские" co_yield облегчают написание и сопровождение подобного кода в разы. Если с ними, конечно, разобраться нормально, а не ныть как старпёр "раньше было лучше", не желая разбираться в чём-то новом.
Но ты прав в одном: если нужна тонкая настойка низкоуровневых деталей, то придётся писать самому.
И так было всегда в C++. Стандартная библиотека только предоставляла "достаточно адекватные" (но не оптимальные!) решения. Например, ты не выберешь стратегию роста capacity в std::vector'е или размер буфера для SSO внутри std::string'а. Хочешь управлять этим -- пиши свои собственные реализации (или бери такие из сторонних библиотек).
Но для большинства задач, где нет необходимости выжимать максимум возможной производительности, стандартных "неоптимальных" средств вполне достаточно. Зато это будет дёшево в плане стоимости разработки и поддержки.
Вот, с корутинами и асинхронностью то же самое.
@@MaceUA Что там "нового" кроме раздувания и так уже полного костылей языка ???
@@IExSet !!!!!11
Видимо неопытный плюсист докладчик, говорит что надо было писать длинющий тип, когда не было auto, а typedef куда делся ? Чтобы инициализировать вектор, надо было писать цикл, а ничего, что вектор в памяти хранится последовательно и размер елемента известен, соответственно его можно инициализировать чисто статически. Вот из-за таких "ветеранов" они и нагородили с три короба.
auto удобен в множестве случаев и в случае чтобы много typedef не использовать, об этом Бьярн говорил, яркий пример auto it = vec.begin() и ему похожие.
Один из конструкторов vector тем и занимается что в цикле копирует в себя.
Это прекрасная иллюстрация того, что язык настолько уродлив и переуслажнен, что человек, годами работающий с этим языком, не может толком им пользоваться. И на профессиональной конференции видеть, что не самые глупые люди планеты не могут овладеть всеми тонкостями хитросплетений, заложенных в каждом элементе этого "профессионального" инструмента - это лютая дичь. Жалко, что из плюсов она никуда не улетит.
@@МаксимХвостов-м1й Но писать длиннющий тип не надо было, потому что он был забит в typedef, когда мастеришь вектор и сам тип, а тип итератора уже можно было доставать из него самого. auto удобен конечно, но по факту это уже изврат из ранней неспособности С++ выводить типы автоматически, по сравнению с OCaml, Haskell и т.п. А потом эти новинки из ФП стали проникать в С++ и другие императивные популярные языки типа Java, C# (лямбды одни чего стоят) и понеслась, стали тащить всё что плохо лежит 🙂 Что наверное к лучшему, потому что ФП всегда был передовым краем программирования и компьютерных наук.
@@IExSet c++ всегда был «швейцарским ножом». Когда он появился он назывался C With Classes что из названия говорило об этом языке, в те времена ООП был популярен. С тех пор ни чего не изменилось в язык по прежнему вваливается всё до чего дотянуться можно, программист сам потом должен с этим разгребаться. Тут высказывания Линуса в тему. Я наблюдал в компаниях где используют C++, используют C++98 и некоторые фишки из новых стандартов тотже auto. Связанно с тем что новички не владеют новым стандартом, обучать дорого, переписывать продукт на новый стандарт дорого, и просто… новое не всегда значит эффективное. Прототип программы сначала пишут на (обычно Питон, его все любят) затем переписывают на C++. Ни когда не видел чтобы сразу на плюсах писали.
С++ изговнили. Он всё более и более не читаемый, а ультимативных преимуществ, как не было так и нет.
Только для ниасиляторов вроде тебя. А для людей, которые им пользуются, он стал только лучше. Не было бы у него преимуществ -- на нём бы никто не писал.
ок, бумер
@@MaceUA Он стал лучше, но комментатор прав, просто все проблемы замели под коврик новых и новых слоёв, значит рано или поздно придётся поднять и говно полезет во все стороны !!! Мне почему то больше нравится C++, чем тот же Rust, но ПРАВДУ я знаю и не прячу голову в песок!
@@IExSet Хейтеры уже который десяток лет ждут, пока "говно полезет". А оно пока всё никак. Но будь уверен, что твои субъективные впечатления, называемые "ПРАВДОЙ", действительны, а все осилившие C++ программисты, не разделяющие подобную истерику, просто "прячут голову в песок". Это твоё право.
@@MaceUA ещё один гений, приравнивающий популярность и качество.
На нём пишут только из-за большого наследия ПО.
Для этого нужен целый "ток". Не перепутал с физикой ? "Инклудирует эти два хедера". Кэтч май диз, рэдиш !
это же надо, человек даже не понимает как работают микропроцессоры, потоки, что это такое, и что происходит "после С++" для непосредственного запуска на микропроцессорной технике. Разве можно разрешать такому обсуждать корутины, колбеки и потоки?
А я не знаю "компиляторы" и что они там после себя порождают, - гордо заявляет это тело (с)
Ну видимо они и возглавляют процесс стандартизации, так что держитесь крестоводы :-)
@@IExSet угу, ну просто очевидно же, что если корутина - это не "про поток", а тем не менее N микротасков действительно выполняются одновременно и лепятся в одну кучу в одном потоке с иллюзией многозадачности, то там существует диспетчер микротасков, компилятор сам бьёт каждый микротаск на логические конструкции, по возможности логически изолированные, для каждого инжектит начальный пролог, завершающий эпилог с информированием управляющего ядра корутин. Делается виртуальная "нарезка". И молотит каждый мини элемент в цикле последовательно один за одним дёргая из каждой нарезки по чуть чуть. Средня длительной 1 элемента нарезки, скажем 1 милисек. Для асинхронного I/O синтетический колбек направляется в ядро. Микротаск, для которого взведёно сосотояние "ожидается колбек" - пропускается в цикле. Неужто человек сам не может такое за пол дня сделать под себя с минимумом лишнего шлака и привнесённого оверхеда? Или уже люди настолько измельчали, что не могут свой "аналог корутины" ручками побить на логически независимые части с промежуточным отходом в своё "контролирующее ядро"? Пусть даже корутина занимает 10 экранов вниз, 20, 50. Это не же долго.
@@IExSet Нашли одного, который не разбирается в компиляторах (причём и близко не главного в комитете), среди сотен человек, участвующих в стандартизации -- "они и возглавляют". Логика. И ничего, что людей, разбирающихся в компиляторах, в комитете тоже предостаточно -- и их мнение обязательно будет учитываться, если кто-то из незнающих предложит что-то неудачное.
А такие, как этот докладчик, могут всё ещё рассказывать про высокоуровневые вещи в языке; про его правила, описываемые стандартом (который тоже про компиляторы практически ничего не знает).
Никто не запрещает потом также послушать и тех, кто разбирается в низкоуровневых деталях, и сложить 2+2 самостоятельно.
@@MaceUA Предостаточно, но курс на ожирение то мы видим, вот уже постепенно начинают забивать на принцип, что не надо платить за то чем не пользуешься.
хедера... ЗАГОЛОВКИ!
без разницы, более того, уж ели придираться то заголовочные файлы. А header он везде хедер :-3
си плас плас... СИ ПЛЮС ПЛЮС!
Всеж заголовок - это неадекватный перевод. Как и хедер - неадекватное название.
Но другое слово както не находится, потому адекватнее наверн ввести новый термин "хедер" в язык. Что обычное дело
@@HedgehogInTheCPP без мэтта, море овер. иф ю хочешь фаинд фолт, то zagolovochnye faily. Хедер алвайс хедер :-3 Приятно тебе такую галиматью на смеси английского и нижегородского читать ? Одно дело профессиональные термины, другое дело наплевательство на язык, культуру и слушателей !
@@IExSet "Заставь дурного богу молиться..." Конечно, если так в крайности бросаться, то будет "галиматья". Любую сколь угодно хорошую идею доведи до абсурда -- будет так же.
А "хедер" нормальное слово для разработчиков на C++. Культурологи и прочие борцуны за чистоту языка идут фак земселвс.