Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Откуда оценка в 90%? Само собой, "чисто предикативные" шаблоны вроде is_arithmetic или is_same именно так и работают, но и они выполняются компилятором в десятки-сотни раз медленнее, чем соответствующие предикаты, будь они встроены в компилятор. А используются эти предикаты массово, в том числе во вложенных/рекурсивных шаблонах, и в итоге неслабо тормозят компиляцию.
Ну так это классическая палка с двумя концами: скорость, универсальность. Так это уже давно работает везде и мы эти предикаты используем, а так это все через комитет стандартизации проходило бы годами. Понятно что тормозят, но я-то подумал раз критика в реализации мета-программирования в С++, то С может эти вопросы решать быстрее, но в С-то ничего такого и в помине нет. Особенно меня удивляет как С-шники живут без перегрузки методов:
int add_int(...)
float add_float(...)
...
По-моему это неудобно и названия методов становятся очень длинными. Смотришь на код и сразу видно что С.
ЕМ>Чтобы шаблонный код на 90% (или хотя бы на 50%) выполнялся на этапе компиляции, программист должен хорошо понимать, во что развернется та или иная шаблонная конструкция. Поскольку шаблоны в C++ традиционно используются "не благодаря, а вопреки", большинство программистов не в состоянии адекватно понять, как работают все костыли, на которых реализованы даже шаблоны из std. Но в случае непосредственного использования шаблонов из std хоть можно доверять их авторам, которые в этой кухне неплохо разбираются — там оверхед действительно небольшой. Но когда нужно модифицировать стандартный шаблон или сделать свой на похожих принципах, из-за того же непонимания механизма лепятся конструкции "лишь бы заработало". Как только заработало — задача считается решенной, даже если вызов разворачивается в "ужас-ужас", но кто смотрит, во что оно развернулось?
Не удобно, согласен, но попробуй поставить подобную задачу себе: тебе нужно сделать новую конструкцию в языке где пользователей миллионы, все они делают абсолютно разные вещи, всем нужно угодит да еще и нечего не поломать. Мне кажется что хоть язык С++ и считается системным, он на слишком разных системных уровнях используется и задача его развития изначально очень сложная, если вообще выполнимая.
По поводу шаблонов, особо не разбираясь, смотришь: если нет инстанцирования, то 100% ничего не занимает, если есть, то сложнее. Рекурсивная лапша из методов самый сложный случай, но это и на С сразу не поймешь сколько выполнятся будет.
ЕМ>Кстати, есть компиляторы, умеющие показать результат раскрутки шаблона в терминах языка, а не ассемблерного кода?
Интересный вопрос, присоединяюсь.
ЕМ>Лично я очень люблю шаблоны C++ в их изначальной ипостаси, как средство параметризации. Но меня тошнит от подхода "если это может быть сделано на шаблонах — давайте сделаем на шаблонах". А поскольку на шаблонах, как известно, можно сделать практически все, то большинство идей по расширению C++ выливается в добавление новых шаблонов в std.
Ну потому-что язык такой вот популярный, потому-что комитет... зато хоть что-до добавляется. С-шники пошли более простым путем: а давайте вообще ничего не будет делать. Ну хоть бы брали четкие, понятные вещи из С++ которые гарантированно O(n).
ЕМ>И ладно, если бы такой подход хоть сопровождался поддержкой "метапрограммирования с человеческим лицом". Какие в языке есть средства отладочного слежения за тем, как раскручивается шаблон? Никаких. Какие есть средства диагностики ошибок, чтобы выдать пользователю шаблона осмысленное сообщение, а не вываливать потроха с кучей вспомогательных типов, классов и переменных? Опять никаких. Бассейн построили тридцать лет назад, а воду в него никак не нальют.
Пока подвезли только static_assert и концепты, но ложится это все на плечи программиста: расстелить соломку везде где увидит.
ЕМ>С new/delete как раз все просто — достаточно их переопределить (я так и делаю).
Я не спорю что можно переопределить, но родные-то кидают исключения и на это все и расcчитан весь интерфейс в STL. Кроме переделки всего интерфейса я не вижу выхода.
ЕМ>С исключениями хуже: даже если какой-то модуль их только бросает, но нигде не обрабатывает, в языке нет законного способа определить свою функцию вместо стандартного обработчика, которая вызывалась бы в точке выброса исключения. В каждой реализации для этого нужны свои костыли. ЕМ>По-хорошему, такие вещи тоже нужно документировать в стандарте, хотя бы в виде рекомендаций, чтобы в реализациях CRT не городили кто во что горазд.
Согласен.
V>>Зато в современном С++ появилась масса вещей которые можно делать прямо во время компиляции и с помощью которых можно автоматизировать написание большого объема почти одинакового кода
ЕМ>Так они почти все появились не в C++, а в его std, на тех самых шаблонах. Это как если бы расширения фортрана делались главным образом через подпрограммы/функции на том же фортране.
Сделать через std банально проще и быстрее, так как бла-бла-бла...
V>>Чем вам помешают STL-ные: array, string_view, optional, variant ?
ЕМ>Прежде всего тем, что при любой ошибке их использования компилятор, вместо осмысленного сообщения, вываливает мне потроха шаблона, и я вынужден на них смотреть, хотя совершенно этого не хочу.
Надеюсь концепты в С++20 помогут.
ЕМ>А что может дать C++ для удобного представления исходных таблиц в коде программы? Обрабатывать-то их и на чистом C не особо сложно.
Я имел ввиду что ты их спокойно можешь в цикле, например, нафигачить в constexpr, как простой код без извращений, шаблонов и матриц.
Ну или:
constexpr auto tag = "bla-bla-bla..."sv;
получаешь объект почти с интерфейсом string, но гарантированно не затратив ни секунды времени, ни байта кода. Прям как в С, круто же. Или массив таких объектов.
Ну как там манглится все это под капотом меня должно интересовать только на границе модулей. Но в С-то я вынужден это делать каждую минуту, причем в ручном режиме. В библиотечном коде у меня всегда куча разных типов выполняющих семантически одну и ту же операцию. Потом перегрузка это же не только автоматически выбор имени метода, это автоматически расширяемый код. Интерфейс библиотеки не стоит же на месте. Там непрерывно появляются новые типы, новые методы. Я, честно, вообще не представляю как на С делается такое:
допустим есть уже куча готового кода и нужно сказать — делай вот все-все на 99% тоже самое, но вот с этим новым типом — вот так...
На С++ просто делается перегрузка и все, компилятор сам подставит нужный новый метод, а остальное трогать не нужно.
Здравствуйте, Videoman, Вы писали:
V>Я, честно, вообще не представляю как на С делается такое: V>допустим есть уже куча готового кода и нужно сказать — делай вот все-все на 99% тоже самое, но вот с этим новым типом — вот так...
Либо так
или просто в файле используются названия типов которые надо менять и потом
они подключаются с в исходниках с разными типами
//add.cc
NUM ADD(NUM a,NUM b) { return a+b; }
//add_int.c
#define NUM int
#define ADD add_int
#include "add.cc"
//add_float.c
#define NUM float
#define ADD add_float
#include "add.cc"
// add.h
int add_int(int,int);
float add_float(float,float);
Или кодогенерация скриптами как в opengl и генераторами как например yacc, bison для разных dsl
V>На С++ просто делается перегрузка и все, компилятор сам подставит нужный новый метод, а остальное трогать не нужно.
Ага и ненужный тоже.
Здравствуйте, Videoman, Вы писали:
V>Так это уже давно работает везде и мы эти предикаты используем, а так это все через комитет стандартизации проходило бы годами.
Так комитет в итоге их все равно принял, только в виде шаблонных реализаций в std. Всю жизнь само собой разумелось, что подобные предикаты должны быть в компиляторе, но через C++, похоже, идет обкатка подхода "что бы еще такого дурацкого сделать, чтоб весь мир пользовался?". Сильно напоминает советский анекдот "а вы их дустом не пробовали?".
V>я-то подумал раз критика в реализации мета-программирования в С++, то С может эти вопросы решать быстрее, но в С-то ничего такого и в помине нет.
Еще раз подчеркну, что я очень давно ничего не писал на C, и плохо понимаю, для чего им пользуются другие, кроме как ради небольшого количества удобств, добавленных в C99 (в C11/C17 ничего интересного не помню). Вся моя критика C++ совершенно безотносительна к C.
V>Особенно меня удивляет как С-шники живут без перегрузки методов
Да они и без классов как-то живут.
V>попробуй поставить подобную задачу себе: тебе нужно сделать новую конструкцию в языке где пользователей миллионы, все они делают абсолютно разные вещи, всем нужно угодит да еще и нечего не поломать.
Что могли бы поломать те же самые предикаты, условная трансляция на уровне языка (в том числе внутри шаблона); атрибуты типов/объектов/функций, наследуемые по цепочке использования; операции добавления/удаления константности у типа-параметра; "отложенное" добавление константности объекту, определенному выше по тексту, и подобное?
V>Мне кажется что хоть язык С++ и считается системным, он на слишком разных системных уровнях используется и задача его развития изначально очень сложная, если вообще выполнимая.
Именно поэтому правильнее было бы ввести в язык побольше простых в реализации и использовании средств для описания свойств элементов программы, операций с этими свойствами, и управления обработкой программы. С этого ведь и начиналось: const/volatile — для описания свойств объектов, классы — для описания свойств типов, перегрузка — для описания свойств операций и одноименных функций. Но с той же перегрузкой в конечном счете облажались: вместо явной возможности введения правил вывода, которая упростила бы и программирование, и компиляцию, придумали длинный и запутанный набор стандартных правил, которые все время хочется обойти. А уж сочетание этих правил с шаблонами — вообще неимоверный ужас. Но ведь они все это трудолюбиво тянут.
V>Рекурсивная лапша из методов самый сложный случай, но это и на С сразу не поймешь сколько выполнятся будет.
Обычные методы можно в отладчике обойти, или хоть отладочных печатей наставить.
V>Пока подвезли только static_assert и концепты, но ложится это все на плечи программиста: расстелить соломку везде где увидит.
А давно пора добавить, например, автоматический вызов специальных методов (например, check ()) в определенных точках (скажем, в начале/конце основных методов класса, при передаче объекта в функцию, при возврате из функции и т.п.). Расходы мизерные, зато крайне полезно при отладке.
V>Я не спорю что можно переопределить, но родные-то кидают исключения и на это все и расcчитан весь интерфейс в STL. Кроме переделки всего интерфейса я не вижу выхода.
Вообще, ядро NT поддерживает системные (структурные) исключения, они там используются кое-где, но не массово. Технически нет проблем реализовать в ядерной версии CRT и полноценные исключения C++, и всю std, но подозреваю, что этого не делают умышленно, дабы писатели драйверов на "интуитивно-понятных" фреймворках типа KMDF совсем уж не распоясались.
V>Я имел ввиду что ты их спокойно можешь в цикле, например, нафигачить в constexpr, как простой код без извращений, шаблонов и матриц.
Это удобно, хотя многое из такого оптимизаторы уже давно умели сворачивать, но приходилось контролировать по коду.
Здравствуйте, kov_serg, Вы писали:
V>>На С++ просто делается перегрузка и все, компилятор сам подставит нужный новый метод, а остальное трогать не нужно.
_>Ага и ненужный тоже.
Это потому, что к перегрузке (и вообще автоматическому выводу) нужна возможность явного задания правил этого самого вывода.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так комитет в итоге их все равно принял, только в виде шаблонных реализаций в std. Всю жизнь само собой разумелось, что подобные предикаты должны быть в компиляторе, но через C++, похоже, идет обкатка подхода "что бы еще такого дурацкого сделать, чтоб весь мир пользовался?". Сильно напоминает советский анекдот "а вы их дустом не пробовали?".
Я полностью разделяю твой гнев, но давай честно, ты реально за то что бы в языке вот все эти предикаты появились в виде зарезервированных слов, да еще не простых, а действующих только в пространстве имен std ?
Я себе такое слабо представляю. Уж лучше сделать нормальную диагностику для разных проблем с шаблонами, возможность вменяемо сообщать об ошибках и добавить механизм при котором все это быстро компилировалось бы, ну модули те же.
ЕМ>Что могли бы поломать те же самые предикаты, условная трансляция на уровне языка (в том числе внутри шаблона); атрибуты типов/объектов/функций, наследуемые по цепочке использования; операции добавления/удаления константности у типа-параметра; "отложенное" добавление константности объекту, определенному выше по тексту, и подобное?
Честно, я не в теме твоего предложения, но думаю что множество людей рассматривало разные варианты и решили что по другому нельзя, иначе все это просто вредительство
ЕМ>Именно поэтому правильнее было бы ввести в язык побольше простых в реализации и использовании средств для описания свойств элементов программы, операций с этими свойствами, и управления обработкой программы. С этого ведь и начиналось: const/volatile — для описания свойств объектов, классы — для описания свойств типов, перегрузка — для описания свойств операций и одноименных функций. Но с той же перегрузкой в конечном счете облажались: вместо явной возможности введения правил вывода, которая упростила бы и программирование, и компиляцию, придумали длинный и запутанный набор стандартных правил, которые все время хочется обойти. А уж сочетание этих правил с шаблонами — вообще неимоверный ужас. Но ведь они все это трудолюбиво тянут.
Это тяжелый крест обратной совместимости. Еще раз, я полностью с тобой согласен, что можно все сделать прямее и правильнее, но мы же говорим не о разработке нового языка, а о модификации языка которому уже 40+ лет.
ЕМ>Обычные методы можно в отладчике обойти, или хоть отладочных печатей наставить.
Ну шаблонные тоже обходятся в отладчике без проблем, или я не понял о чем ты. На самом деле появился еще один класс таких же "проблемных" методов — constexpr. Для их отладки я так и не придумал нормального способа кроме как где-то стыдливо объявить #define constexpr _
ЕМ>А давно пора добавить, например, автоматический вызов специальных методов (например, check ()) в определенных точках (скажем, в начале/конце основных методов класса, при передаче объекта в функцию, при возврате из функции и т.п.). Расходы мизерные, зато крайне полезно при отладке.
Не дай бог . Ведь будет также как с шаблонами, только хуже, все начнут этим пользоваться по делу и без — начнется сущий ад. Это же тоже самое что злоупотреблять перегрузкой операторов, только намного хуже.
ЕМ>Вообще, ядро NT поддерживает системные (структурные) исключения, они там используются кое-где, но не массово. Технически нет проблем реализовать в ядерной версии CRT и полноценные исключения C++, и всю std, но подозреваю, что этого не делают умышленно, дабы писатели драйверов на "интуитивно-понятных" фреймворках типа KMDF совсем уж не распоясались.
Честно мне вообще не понятно почему С++ исключения должны быть обязательно реализованы поверх "тяжелого" механизма SEH. Почему нельзя иметь возможность выбирать runtime c которым линкуешься: типа как cppruntime: static, dynamic, singlethreaded, multithreaded и т.д.
Здравствуйте, Videoman, Вы писали:
V>ты реально за то что бы в языке вот все эти предикаты появились в виде зарезервированных слов, да еще не простых, а действующих только в пространстве имен std ?
Если бы их догадались сделать хотя бы двадцать лет назад, когда идея уже оформилась (а еще лучше — тридцать, когда появились шаблоны и стало понятно, что шаблону может быть нужна информация о типах-параметрах), то идеи включать их в std даже не возникло бы. Чтобы не возникало коллизий с пользовательскими именами, можно было сделать в виде _is_xxx, или еще как-нибудь.
V>добавить механизм при котором все это быстро компилировалось бы, ну модули те же.
А как технически сделать так, чтобы рекурсивные шаблоны, глобально доступные везде, могли быстро компилироваться? Только разными видами предкомпиляции, что везде и реализуют. Или опять же реализовать все эти предикаты в компиляторе, вызывая их в виде привычных уже шаблонов.
V>Честно, я не в теме твоего предложения
Так это не для одного приложения, а практически для любого.
V>Это тяжелый крест обратной совместимости.
Чем той обратной совместимости могло помешать добавление в любой момент тех же правил выбора перегруженной версии функции? Если их делать, то так, чтобы можно было задавать как глобально, так и локально для отдельных функций.
ЕМ>>Обычные методы можно в отладчике обойти, или хоть отладочных печатей наставить.
V>Ну шаблонные тоже обходятся в отладчике без проблем, или я не понял о чем ты.
Я о раскрутке инстанцирования шаблона во время компиляции, чтобы видеть, какие подставились значения, с какими параметрами инстанцируются вложенные шаблоны, и т.п.
V>На самом деле появился еще один класс таких же "проблемных" методов — constexpr.
И для них тоже нужен какой-то выхлоп из компилятора о ходе обработки при компиляции.
ЕМ>>добавить, например, автоматический вызов специальных методов (например, check ()) в определенных точках
V>Не дай бог . Ведь будет также как с шаблонами, только хуже, все начнут этим пользоваться по делу и без — начнется сущий ад.
Так это ж сугубо для отладки, оно должно полностью управляться программистом. Во многих языках есть встроенный контроль границ массивов, диапазонов значений переменных и т.п. — это оно и есть. А так ведь некоторые умудряются пускать отладочные сборки в продакшн — что ж, из-за них не надо было вводить возможности отладочных сборок?
V>Честно мне вообще не понятно почему С++ исключения должны быть обязательно реализованы поверх "тяжелого" механизма SEH.
А как их еще можно надежно реализовать? Там же надо ловить и аппаратные исключения (ошибка доступа к памяти, переполнение, деление на нуль и т.п.). В ОС реализована полноценная раскрутка стека, это весьма обширная логика вплоть до эмуляции выполнения команд. Городить свою в CRT — будет слишком много лишнего кода. Или ограничивать стек только вызовами родных функций, скомпилированных без оптимизации стекового кадра. Тогда не получится сделать библиотеку, вызываемую, например, из паскаля, чтоб она могла вызывать паскалевские callback'и, которые, в свою очередь, могли бы вызывать функции C++.
В ядре, конечно, подобным смешиванием не занимаются, но в ответ на вызов из драйвера системной функции система вполне может вызвать одну из служебных функций драйвера, и так далее.
V>Почему нельзя иметь возможность выбирать runtime c которым линкуешься: типа как cppruntime: static, dynamic, singlethreaded, multithreaded и т.д.
Для ядра есть только multithreaded, поскольку никто не гарантирует выполнения кода строго в пределах одного потока. CRT какой-то версии MS VC++ зашит в ядро, поэтому по дефолту все драйверы линкуются к нему (некий аналог dynamic), но можно линковаться и статически, если требуется другая версия CRT.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>При таком подходе на языке можно с одинаковым удобством и эффективностью писать программы для простейших микроконтроллеров, ядра ОС, драйверы, мелкие программы и навороченные комплексы.
Вообще-то это всё актуально и сейчас
ЕМ>А потом среди поклонников (и разработчиков стандарта) возобладал традиционный подход к ЯП — "чтобы реализовать такой-то алгоритм, нужно написать вот это и вот это". Подавляющее большинство C++-программистов уже давно не понимает, что у программы внутри, как она взаимодействует со средой выполнения, какие конструкции порождают компактный код, а какие — развесистый, не умеет оптимизировать без профайлера и т.п., а просто кодирует алгоритм мало-мальски подходящими конструкциями языка и стандартной библиотеки, которая тоже превратилась в паровоз, нахлобученный на легковушку.
Как C++ программист который таки "понимает, что у программы внутри, как она взаимодействует со средой выполнения, какие конструкции порождают компактный код, а какие — развесистый" — могу с полной ответвенностью заявить, что новые стандарты таки упрощают мою работу, а не усложняют.
И если по той или ной причине вдруг приходится использовать предыдущие версии, то постоянно натыкаюсь на места которые с новыми фичами можно выразить намного проще, лаконичнее и понятнее
Или например с ужасом вспоминаю ::result протокол
Здравствуйте, Videoman, Вы писали:
V>Я, честно, вообще не представляю как на С делается такое: V>допустим есть уже куча готового кода и нужно сказать — делай вот все-все на 99% тоже самое, но вот с этим новым типом — вот так... V>На С++ просто делается перегрузка и все, компилятор сам подставит нужный новый метод, а остальное трогать не нужно.
В тёплой ламповой сишечьке для этого есть, барабанная дробь, дженерики! https://en.cppreference.com/w/c/language/generic
Не хотели C++? получите лютую и беспощадную смесь макросов и _Generic, ешьте не обляпайтесь
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>могу с полной ответвенностью заявить, что новые стандарты таки упрощают мою работу, а не усложняют.
Дык, тем, кто понимает, они именно упрощают. Но таких меньшинство. Большинство — тех, кто "применяет средства языка для записи алгоритма".
EP>с ужасом вспоминаю ::result протокол
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не хотели C++? получите лютую и беспощадную смесь макросов и _Generic, ешьте не обляпайтесь
Тут я согласен, что у чистых сишников довлеет какая-то религиозная неприязнь ко всему, что есть в C++. Как у французов: пусть криво, зато не как у англичан.
Здравствуйте, Евгений Музыченко, Вы писали:
EP>>могу с полной ответвенностью заявить, что новые стандарты таки упрощают мою работу, а не усложняют. ЕМ>Дык, тем, кто понимает, они именно упрощают. Но таких меньшинство. Большинство — тех, кто "применяет средства языка для записи алгоритма".
Так если они будут применять новые средства, вместо старых монструозны альтернатив, их код тоже будет проще.
Ну и те кто что-то там не понимают — они всегда будут присутсвовать, но я за то чтобы моя работа упрощалась, и стандарт двигался именно в этом направлении, а не чтобы стандарт оберегал каких-то непонимающих от чего-то там возможного
EP>>с ужасом вспоминаю ::result протокол
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если бы их догадались сделать хотя бы двадцать лет назад, когда идея уже оформилась (а еще лучше — тридцать, когда появились шаблоны и стало понятно, что шаблону может быть нужна информация о типах-параметрах), то идеи включать их в std даже не возникло бы. Чтобы не возникало коллизий с пользовательскими именами, можно было сделать в виде _is_xxx, или еще как-нибудь.
Не, ну ты серьезно ?! Как средства решения могут появиться раньше самой задачи. Мой ответ — скорее всего раньше софт не был таким большим и сложным.
ЕМ>Чем той обратной совместимости могло помешать добавление в любой момент тех же правил выбора перегруженной версии функции? Если их делать, то так, чтобы можно было задавать как глобально, так и локально для отдельных функций.
Ты же сам критикуешь сложность современного С++, а с таким подходом вообще ахренеешь понимать что в итоге вызывается должно. После такого просто глядя на код ты не будешь понимать что вызывается, придется еще и в коде правил разбираться. Поверь эти правила быстро станут не проще того кода на шаблонах который тебе не нравится, а потом ты еще и средства анализа самих правил захочешь .
ЕМ>Я о раскрутке инстанцирования шаблона во время компиляции, чтобы видеть, какие подставились значения, с какими параметрами инстанцируются вложенные шаблоны, и т.п.
Да, это очень интересный вопрос, я бы сам хотел что-то иметь в помощь от компилятора.
ЕМ>Так это ж сугубо для отладки, оно должно полностью управляться программистом. Во многих языках есть встроенный контроль границ массивов, диапазонов значений переменных и т.п. — это оно и есть. А так ведь некоторые умудряются пускать отладочные сборки в продакшн — что ж, из-за них не надо было вводить возможности отладочных сборок?
Если что-то типа ассертов, то я согласен. Но ведь будут тут ныть на форуме: чего это дебажный код работает так медленно, невозможно отлаживаться. Кто-то тут ныл уже, не помню
ЕМ>А как их еще можно надежно реализовать?
А не надо всегда надежно. Просто другой режим. Если я работаю только с С++ и мне нужны быстрые исключения, то я их выбираю.
ЕМ>Там же надо ловить и аппаратные исключения (ошибка доступа к памяти, переполнение, деление на нуль и т.п.). В ОС реализована полноценная раскрутка стека, это весьма обширная логика вплоть до эмуляции выполнения команд. Городить свою в CRT — будет слишком много лишнего кода.
Ну С-то как-то с этим всем работает без исключений. Пусть будут просто обработчики. Если их нет то std::terminate и все тут. Или если ты так близко с железу работаешь, то используй средства OC и скорее всего ты уже и сами исключения в таком случае не будешь использовать.
ЕМ>Или ограничивать стек только вызовами родных функций, скомпилированных без оптимизации стекового кадра. Тогда не получится сделать библиотеку, вызываемую, например, из паскаля, чтоб она могла вызывать паскалевские callback'и, которые, в свою очередь, могли бы вызывать функции C++.
Универсальное средство почти всегда не гибкое. Дайте выбор. Мне вот, например, никогда функцию из паскаля не приходилось вызывать (если не считать что все dll pascal по-умолчанию . Типа-драйвера разные я писал только в режиме пользователя и SEH использовал только платформозавичимый: __try, __catch по-моему.
ЕМ>Для ядра есть только multithreaded, поскольку никто не гарантирует выполнения кода строго в пределах одного потока. CRT какой-то версии MS VC++ зашит в ядро, поэтому по дефолту все драйверы линкуются к нему (некий аналог dynamic), но можно линковаться и статически, если требуется другая версия CRT.
Это все понятно, тут спору нет. Но мы же вообще про С++ рассуждаем.
Здравствуйте, Videoman, Вы писали:
ЕМ>>Я о раскрутке инстанцирования шаблона во время компиляции, чтобы видеть, какие подставились значения, с какими параметрами инстанцируются вложенные шаблоны, и т.п. V>Да, это очень интересный вопрос, я бы сам хотел что-то иметь в помощь от компилятора.
https://cppinsights.io/ может в ряде случаев немного помочь, например можно посмотреть во что инстанциируются шаблонные функции и структуры
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>При таком подходе на языке можно с одинаковым удобством и эффективностью писать программы для простейших микроконтроллеров, ядра ОС, драйверы, мелкие программы и навороченные комплексы.
EP>Вообще-то это всё актуально и сейчас
Очень интересно, что за софт такой пишут любители сложных шаблонов и мув-семантики, что классического С++ им не хватает?
Лично я когда занимался кодеками видео/графики, хорошо видел, что оптимизация алгоритма на порядки эффективнее, чем возня с тонкостями языка программирования.
Теперь снова занимаюсь ядром линукса, и от классов с наследованием бы не отказался, но вполне нормально можно жить и без него, на С, с указателями вместо методов и счетчиками ссылок. И возникающие в процессе работы проблемы С++, тем более современный, не решил бы.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Очень интересно, что за софт такой пишут любители сложных шаблонов и мув-семантики, что классического С++ им не хватает?
Очень интересно, что за софт такой пишут любители классического C++, что классического С11 им не хватает?
Очень интересно, что за софт такой пишут любители классического C11, что классического K&R C им не хватает?
Очень интересно, что за софт такой пишут любители классического K&R C, что классического макро-ассемблера им не хватает?
Очень интересно, что за софт такой пишут любители классического макро-ассемблера, что классических ассемблера им не хватает?
Очень интересно, что за софт такой пишут любители классического ассемблера, что классических машинных кодов им не хватает?
Здравствуйте, lpd, Вы писали:
lpd>Очень интересно, что за софт такой пишут любители сложных шаблонов и мув-семантики, что классического С++ им не хватает? lpd>Лично я когда занимался кодеками видео/графики, хорошо видел, что оптимизация алгоритма на порядки эффективнее, чем возня с тонкостями языка программирования.
Ты путаешь мягкое с тёплым, одно другому не мешает, не противоречит, и не исключает. Например когда занимался обработкой и сжатием граничных представлений, в том числе R&D — там были важны и алгоритмы и структуры данных, и возможность обобщённой И эффективной реализации — здесь как раз C++ проявляется в полный рост. В других прикладных областях наблюдаю абсолютно тоже самое.
В том числе и в графике: https://www.youtube.com/watch?v=sR8Wjg0pceE
lpd>Теперь снова занимаюсь ядром линукса, и от классов с наследованием бы не отказался, но вполне нормально можно жить и без него, на С, с указателями вместо методов и счетчиками ссылок.
Конечно можно, ведь есть полнота по Тьюрингу, да и вообще Блаб-парадокс. С простынями goto cleanup, вездесущим void*, и прочим ручным трудом.
lpd>И возникающие в процессе работы проблемы С++, тем более современный, не решил бы.
Современный упрощает код, причём местами на порядок.
Здравствуйте, Marty, Вы писали:
M>ЗЫ И да, мне нравится, что язык стал активно развиваться, и то, что код написанный 20 лет назад собирается и работает точно так же, как и раньше
Ну, это неверно, конечно. уже довольно часто встречается слово deprecated.
Здравствуйте, Videoman, Вы писали:
V>Как средства решения могут появиться раньше самой задачи.
Почему раньше? Шаблоны появились в ответ на желание сделать код максимально независимым от типа. Несколько десятков лет назад, в ответ на желание сделать код независимым от размера машинного слова, появилась операция sizeof. Точно так же, одновременно с появлением шаблонов или вскорости, обязаны были появиться и предикаты свойств типов/объектов.
V>Мой ответ — скорее всего раньше софт не был таким большим и сложным.
Сложным — был (те же самые промышленные 3D-дизайнеры, которые начали делать еще в 80-х). Настолько большим — не был, тогда еще на набрало такие обороты включение универсальных библиотек, в результате чего, вместо ожидаемого повторного использования кода, происходит его многократное дублирование.
V>Ты же сам критикуешь сложность современного С++, а с таким подходом вообще ахренеешь понимать что в итоге вызывается должно.
Тогда те же претензии должны быть и к const/volatile, которые тоже участвуют в выборе перегрузок.
V>После такого просто глядя на код ты не будешь понимать что вызывается
А для этого, безотносительно к правилам, нужна выдача компилятора о результатах его работы. Как ассемблерный листинг, только на уровне C++.
V>Поверь эти правила быстро станут не проще того кода на шаблонах который тебе не нравится
Да их достаточно самых простейших — "выбирать ближайший подходящий тип", "выбирать наиболее общий тип", ну и критерии подходящести — по размеру, набору операций и т.п.
V>ведь будут тут ныть на форуме: чего это дебажный код работает так медленно, невозможно отлаживаться. Кто-то тут ныл уже, не помню
Ну я ныл о том, что MS VC++ не позволяет мне свободно переключаться между режимами оптимизации хотя бы на уровне функций, не говоря уже об их фрагментах.
V>Если я работаю только с С++ и мне нужны быстрые исключения, то я их выбираю.
Быстрые — это которые? Я глубоко не копал, но, насколько мне известно, в винде плюсовые исключения всегда реализуются через системный SEH.
V>Ну С-то как-то с этим всем работает без исключений.
В MS VC есть __try/__except — то самое SEH, механизм технически не отличается от плюсовых исключений.
V>если ты так близко с железу работаешь, то используй средства OC и скорее всего ты уже и сами исключения в таком случае не будешь использовать.
Я и использую SEH, когда нужно ловить возможные ошибки адресации, или когда функции ядра сами возбуждают системные исключения. А исключений C++ я до сих пор избегаю, но у меня пока сложность не такая, чтоб без них стало прям тяжело.
Какие в языке есть средства отладочного слежения за тем, как раскручивается шаблон? Никаких. Какие есть средства диагностики ошибок, чтобы выдать пользователю шаблона осмысленное сообщение, а не вываливать потроха с кучей вспомогательных типов, классов и переменных? Опять никаких. Бассейн построили тридцать лет назад, а воду в него никак не нальют.
https://en.cppreference.com/w/c/language/generic
?! Как средства решения могут появиться раньше самой задачи. Мой ответ — скорее всего раньше софт не был таким большим и сложным. 
