Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>

Большинство нынешних программистов не мыслит использования Си++ в отрыве от стандартной библиотеки шаблонов (STL)

Мне довелось контрибутить в проект без STL, со своими собственными велосипедами, без exceptions.
Я теперь илитка?

ЕМ>[q]исходно Си++ представлял собой интереснейшее явление в мире программирования — единственный в своём роде язык произвольного уровня, то есть такой, который позволял заниматься как низкоуровневым (почти ассемблерным), так и сколь угодно высокоуровневым программированием, причём все нужные здесь и сейчас абстракции высокого уровня можно было тут же и создать, не полагаясь на «доброго дядю».

Это словоблудие. Первая часть утверждения верна, потому что мы все понимаем, что C++ создавался буквально как "C с классами", и совместимость с C в нём by design.
Вторая часть про "какие угодно абстракции высокого уровня" — это вообще что такое? Можно мне, например, рефлексию типов данных здесь и сейчас, без "добрых дядей"? Нет? До свидания.

Здравствуйте, landerhigh, Вы писали:

ЕМ>>Под них можно писать не на "плюсах", а на определенном подмножестве языка.

L>Ну так и технических возможностей у них тоже, как бы это сказать, весьма ограниченное подмножество.

Никто в здравом уме и не ожидает, что на МК с памятью в десяток килобайт будут многопоточность и файловая система. Но вот исключения в C++ действительно могли бы реализовать гораздо разумнее, хотя передавать параметром исключения не весь произвольный объект, а только указатель на него. Это позволило бы обойтись без RTTI и прочей шелухи, которая в механизме исключений принципиально не важна, но очень сильно его усложняет и утяжеляет.

L>На тех же атмегах шаблонную магию вообще можно использовать без проблем.

Так магию, которая реализуется только на этапе компиляции, и не тащит своего кода, можно использовать везде, независимо от платформы. Но необходимость использовать магию только потому, что язык не предлагает адекватных средств — извращение, и опять же где угодно.

L>Некоторое подможество STL — тоже.

Что там есть реально удобного, не завязанного на исключения?

Здравствуйте, Pzz, Вы писали:

ЕМ>>если писать на C, то с ростом сложности и объема трудоемкость растет экспоненциально, а C++ позволяет достаточно долго удерживать ее почти линейной.

Pzz>Вот с этим не соглашусь. Экспоненциально она растет, когда сложность переполняет голову автора, и он теряет контроль над собственной программой.

Одна из типичных проблем разработки сложных систем на чистом C — то самое наследование. Там можно по-разному комбинировать базовые/производные структуры, но затем все упирается в преобразование типов указателей, и автоматического способа следить за его правильностью нет. Остается только снабжать структуры идентификаторами типов, и во время выполнения везде проверять, но опять же вручную. Если забыть где-то поставить соответствующий assert, компилятор сам ничего не проверит.

Ну и сами преобразования типов/указателей в C слишком либеральные. Когда я в 90-х переписывал свои ранние программы с C на C++ (еще до C++98), я везде менял C-style cast на function-style cast. Когда в языке появились операции XXX_cast — стал менять на них, и с тех пор несколько раз было, что компилятор, молча переваривавший какой-нибудь мудреный function-style cast, начинал ругаться даже на reinterpret_cast, и при внимательном рассмотрении я обнаруживал в нем логическую неправильность, которая могла создать проблемы, например, при другой разрядности платформы.

Pzz>Что в сишечке все же раздражает, это отсутствие более-менее стандартной и общепринятой библиотечной поддержки уровня абстракции чуть выше, чем printf(). Ну раздражает в каждом проекте опять делать реализацию динамических строк и протокола HTTP, ну честное слово. Это не сложно, это муторно.

Это хоть можно сделать нормальными языковыми средствами. А для многого из того, что делается шаблонной магией, нормальных языковых средств нет и не предвидится. Поэтому приходится либо делать свое на той же магии, но проще и понятнее, либо использовать стандартную, и тупить на простыни диагностики с ее заголовками при каждой ошибке.

Pzz>А не попытка ли это сделать программиста взаимозаменяемым

Дык, я ж только за. Но хочется языка, который для этих целей даст возможность как в явном виде объяснить компилятору все, о чем тот не может догадаться сам, так и получить от компилятора все сведения о программе, которые тот имеет, не прибегая к уродливому шаманству.

Pzz>Я б не стал сейчас начинать новый проект ни на Си, ни на C++. Ну, по крайней мере, при наличии у меня выбора.

Если б я был чисто прикладным программистом — возможно, я б вообще не связался ни с C, ни с C++. Но, пока я делаю драйверы ядра или код под голое железо, где необходимо четко представлять себе объем занятых и свободных ресурсов, психологически трудно параллельно делать тот же высокоуровневый гуй на каком-нибудь C# или Java. Грубо говоря, когда в модуле драйвера избыточность в районе 10%, в отдельных местах — до 20%, а в сопутствующем управляющем приложении эта избыточность измеряется тысячами процентов, очень трудно сохранять душевное равновесие.

Здравствуйте, Pzz, Вы писали:

Pzz>Вот в автомобилестроении, по большому счету, за последние 100 лет не произошло ничего нового. Автомобили можно смело ставить на конвеер и выпускать на заводе. Что Генри Форд, собственно, и сделал.

В автомобилях принципиально не изменились только основное устройство ДВС, трансмиссии и подвески, но управление всем этим радикально изменилось где-то в районе 70-80-х, с переходом на электронный впрыск. Если до тех пор приходилось шаманить с запуском холодного двигателя, регулярно чистить и подстраивать карбюратор, чистить/менять свечи и т.п., то после этого ситуация "двигатель не запускается" или "двигатель заглох" перестала означать "автомобиль капризничает" или "в автомобиле что-то слегка не в порядке", и стала означать "автомобиль категорически неисправен".

Pzz>А с програмизьмом поторопились.

В программизме фактически то же самое: принципы работы и архитектура железа принципиально не изменились, но многие способы управления им поменялись радикально. Но, если продолжать аналогию с автомобилями, то после внедрения электронного впрыска, АКПП, ABS/ESP, ремней безопасности, круиз-контроля, парковочных радаров и прочего, вплотную стали заниматься только формой/раскраской кузова, отделкой салона, мультимедийной системой и подобным.

Здравствуйте, Pzz, Вы писали:

Pzz>C++ пытается превратить смысловую сложность в синтаксическую сложность

Так это не "C++" пытается, а как раз те люди, которые изо всех сил (и непонятно зачем) стремятся сохранить в языке минимальный набор ключевых слов и синтаксических элементов, навешивая на символы и их комбинации все новые и новые смыслы.

В то время, когда я впервые увидел программу на C где-то в середине 80-х, из ЯВУ я использовал только Pascal, а большей частью писал на ассемблерах. И в паскале меня, как и многих, очень раздражала многословность в виде BEGIN/END, хотя по факту на любом ассемблере получается куда бОльшая многословность. Все эти фигурные скобочки и инкременты/декремент в C тогда буквально очаровали. Но "синтаксическая плотность", которой уже лет тридцать стараются придерживаться в C++, давно не лезет ни в какие ворота.

Pzz>История знает примеры успешного построения невероятно сложных проектов на чистом Си. То же ядро Linux, например.

Откуда в ядре любой ОС "невероятная" сложность? Ядро вообще весьма компактно по сравнению с изрядной частью современного прикладного софта. В ядрах мало что заранее закладывается "на вырост", кроме достаточно очевидных вещей, в то время как прикладной софт стараются делать максимально абстрактным, так как непонятно, куда через год-другой повернутся тенденции и запросы пользователей. Поэтому и меняются они не так быстро и странно, как прикладной софт. Опять же, в ядре обычно стараются не разбрасываться ресурсами, а при таком подходе не получится быстро наращивать сложность.

Pzz>Но в конечном итоге, рискну предположить, что контроль над проектом теряется в тот момент, когда остается критически малое количество людей, способных его понимать на должном уровне. И синтаксическая сложность в этом деле не помощник.

Синтаксическая сложность, наоборот, усложняет понимание. Это как в математике: можно описывать задачу в понятиях "рассмотрим функцию со следующими свойствами...", а можно — "рассмотрим f (x, y, p, t) такую, что <трехэтажный интеграл>". Иной раз компактная формула с достаточно типичными и очевидными элементами выглядит проще, чем словесное описание, но понять какую-нибудь двух-трехуровневую шаблонную конструкцию навскидку можно, лишь годами оперируя такими конструкциями почти непрерывно. Это похоже на известную проблему разворачивания определения указателя на функцию, возвращающую указатель на массив и т.п., но для них есть хотя бы typedef/using, а для шаблонов ничего подобного нет.

Здравствуйте, qqqqq, Вы писали:

Q>если бы ядро Linuxа было сделано на C++ то возможно в его разработке могли бы принимать активное участие не обязательно суперпрограммисты типа самого его и красноглазиков а обычные люди.

В этом случае ядро постигла бы участь бОльшей части современного прикладного софта на C++ — оно бы неимоверно раздулось и стало безбожно тормозить. Избежать этого можно было бы лишь строжайшим контролем — еще более строгим, чем контролируется проект ядра на C.

Q>считается что ОС должна быть написана кровью на С или ассемблере потому что типа надо очень быстро а C++ это очень медленно. Это в общем случае заблуждение

О том и речь. Но большинство таки понимает это заблуждение, как "на C++ то же самое будет лишь немногим объемнее/медленнее", хотя, при должной внимательности, эквивалентные по смыслу конструкции C++ дают тот же самый код, что и в C. Но, если нужно удерживать объем/скорость кода в достаточно жестких рамках, в C++ нужна гораздо большая внимательность, поскольку возможностей неочевидного увеличения объема или снижения скорости гораздо больше.

Q>В общем разница не столько в синтаксе языка а в несколько другом подходе к разработке и образе мысли, который невозможен на С.

C++ хорош тем, что в нем есть много возможностей сказать компилятору "я задумал вот такое, оно должно работать вот так, и дай мне по рукам, если увидишь, что я нарушаю эти условия". Но таких возможностей в языке могло бы быть гораздо больше, однако их упорно не включают, а компиляторы десятилетиями столь же упорно обучают угадывать отдельные потенциальные несоответствия, которые можно было бы указывать явно.

Здравствуйте, cppguard, Вы писали:

C>С++ стал заложником корпораций с их неуёмных желанием объять и уничтожить

Ну вот тот же MS добавил в свой VC++ расширения в виде некоторого количества предикатов (__has_assign, __is_class, __is_convertible_to и т.п.), квалификатор __interface для определения интерфейсного (чисто абстрактного) класса, __if_exists/__if_not_exists для условной компиляции по наличию/отсутствию определения, __forceinline для принудительной вставки функции, и так далее. Ничего из этого в стандартный язык не пошло. Свойства типов — по-прежнему только магия, интерфейсный класс извольте описывать ручками с "= 0" при каждой функции, для принудительного inline каждый копилятор тащит свои атрибуты, нормальной условной компиляции так и нет — выкручивайтесь магией.

C>Я могу почти весь дом построить с помощью одного молотка

Вы хотели сказать "барак"?

C>Я люблю и могу смешивать в проектах разные языки и программы. Мне нравится кодо-генерация, мне нравится интероперабельность.

Я тоже могу, но не люблю. Особенно когда библиотека на C++, бОльшая часть которой собирается как под прикладной пользовательский уровень, так и под ядро. При желании ее можно чуть переделать, и собирать под МК.

C>Ни для одной другой задачи я не буду использовать Ruby, потому что как язык сам по себе — так себе, но Rails закрывает 99.9% того, что мне может понадобиться в типичном CRUD. А если мне нужно простенькое приложения с парой контроллеров, я возьму Flax, потому что я не хочу держать весь путь, который проходит запрос от браузера до контроллера, со всеми рельсовыми middleware. Я пишу на Си, если мне нужно дёрнуть пару системных библиотек, но если нужно работать со строками или массивами, я пишу на С++, потому что безопасность важнее. Если я обрабатываю данные, то, конечно же, я смотрю в сторону R или Python.

А после всего этого Вы пишете в системных требованиях что-нибудь вроде "необходима Windows 10 версии XXX или старше с .NET YYY или старше". Или дистрибутив Вашего проекта в процессе установки сообщает "требуется JRE версии XXX", скачать-установить? Юзер соглашается, и тут, внезапно, или у установщика нет прав доступа к сети, или возбуждается антивирус, или еще что. А после установки десятка таких проектов пользовательская система оказывается набита гигабайтами не пойми чего, оно завязано друг на друга, и аккуратно/чисто удалить отдельные части оказывается проблематично, если вообще возможно.

C>Английский очень бедный язык в плане описательности или выражения чувств и эмоций

Шекспир нервно переворачивается в гробу.

C>Если со стандартом самого языка всё выглядит более-менее, то попытка добавить в стандарт работу с ФС или графикой ничего кроме смеха не вызывает.

И не надо. А если уж это делать, то непременно в виде "сопутствующей библиотеки", которая может быть реализована, а может и нет. Любая работа с ФС или графикой всегда будет написана на самом языке, поэтому любой желающий может написать ее сам. А вот сделать то, что сам язык не позволяет, или невозможно, или очень геморройно. Поэтому прежде всего нужно развивать возможности самого языка, а удобные дополнения/надстройки всегда можно разрабатывать в виде библиотек.

Здравствуйте, student__, Вы писали:

__>Можно мне, например, рефлексию типов данных здесь и сейчас, без "добрых дядей"?

Если б сразу, как в C++ мало-мальски освоили метапрограммирование, а Александреску со товарищи открыли магию и увлеклись ею, неравнодушный к развитию языка народ задался бы вопросом "что должно быть в языке для адекватной поддержки рефлексии?", то все необходимое (или бОльшая его часть) давным-давно было бы в стандарте. Но эйфория от "смотрите, а можно еще вот так!", "это все херня, а вот что я нашел!" прочно овладела умами большинства разработчиков "высшего уровня", силами которых в основном и развивался язык. По их логике, все, что хоть как-то можно сделать посредством магии (пусть даже оно выглядит донельзя громоздко, уродливо и неудобно), следует делать именно на ней. А большинство разработчиков более низких уровней или хавало (кто охотно, кто через силу) все, что спускали сверху, или материлось и ограничивалось подмножествами, или вовсе уходило в другие языки.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если б сразу, как в C++ мало-мальски освоили метапрограммирование, а Александреску со товарищи открыли магию и увлеклись ею, неравнодушный к развитию языка народ задался бы вопросом "что должно быть в языке для адекватной поддержки рефлексии?", то все необходимое (или бОльшая его часть) давным-давно было бы в стандарте. Но эйфория от "смотрите, а можно еще вот так!", "это все херня, а вот что я нашел!" прочно овладела умами большинства разработчиков "высшего уровня", силами которых в основном и развивался язык. По их логике, все, что хоть как-то можно сделать посредством магии (пусть даже оно выглядит донельзя громоздко, уродливо и неудобно), следует делать именно на ней. А большинство разработчиков более низких уровней или хавало (кто охотно, кто через силу) все, что спускали сверху, или материлось и ограничивалось подмножествами, или вовсе уходило в другие языки.

Евгений, вам пора патентовать слоган "C++, который мы потеряли".

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Никто в здравом уме и не ожидает, что на МК с памятью в десяток килобайт будут многопоточность и файловая система. Но вот исключения в C++ действительно могли бы реализовать гораздо разумнее, хотя передавать параметром исключения не весь произвольный объект, а только указатель на него.

Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe. Короче, невелика потеря.

L>>На тех же атмегах шаблонную магию вообще можно использовать без проблем.

ЕМ>Так магию, которая реализуется только на этапе компиляции, и не тащит своего кода, можно использовать везде, независимо от платформы. Но необходимость использовать магию только потому, что язык не предлагает адекватных средств — извращение, и опять же где угодно.

Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?

L>>Некоторое подможество STL — тоже.
ЕМ>Что там есть реально удобного, не завязанного на исключения?

Да хотя бы алгоритмы.
В STL исключения отрастают в первую очередь от динамической памяти.

Здравствуйте, landerhigh, Вы писали:

L>Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe.

Исключения, в силу своей чрезмерно абстрактной/универсальной реализации, на любой платформе создают изрядную избыточность, и по объему, и по выполнению. Из-за этого их чревато применять там, где исключение может возникать достаточно часто (чаще где-то десятков раз в секунду). В результате на одних исключениях всей обработки ошибок не построишь — нужно сочетать обычный возврат ошибок для более-менее регулярных ситуаций с исключениями для серьезных и относительно редких. В итоге проблема толком не решается, но избыточность присутствует, плюс сложности с объединением модулей, использующих и не использующих исключения. Палка о двух концах.

L>Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?

С помощью магии — извращение. Особенно когда встроенные средства условной компиляции достаточно просты в реализации.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну вот тот же MS добавил в свой VC++ расширения в виде некоторого количества предикатов (__has_assign, __is_class, __is_convertible_to и т.п.), квалификатор __interface для определения интерфейсного (чисто абстрактного) класса, __if_exists/__if_not_exists для условной компиляции по наличию/отсутствию определения, __forceinline для принудительной вставки функции, и так далее. Ничего из этого в стандартный язык не пошло. Свойства типов — по-прежнему только магия, интерфейсный класс извольте описывать ручками с "= 0" при каждой функции, для принудительного inline каждый копилятор тащит свои атрибуты, нормальной условной компиляции так и нет — выкручивайтесь магией.

А #pragma once стала стандартом де-факто. Я не об этом говорил, а о том, что комитет это не сообщество идейных людей, а представители FAANG и компаний поменьше. В фаанге бардак в кодовой базе, вот и стандарт превращается в бардак. Что-то похожее происходит с линуксом, но там сообщество пока ещё слишком разношёрстное.

ЕМ>Вы хотели сказать "барак"?

Да почему, обычный дом. Просто это будет сложно и дорого. И кран будет переодически подтекать, а полки — падать. Если вы поняли, о чём я

ЕМ>Я тоже могу, но не люблю. Особенно когда библиотека на C++, бОльшая часть которой собирается как под прикладной пользовательский уровень, так и под ядро. При желании ее можно чуть переделать, и собирать под МК.

Это миф. Или программа на МК будет неоптимальной, или программировать для сервера будет сложно и неприятно.

ЕМ>А после всего этого Вы пишете в системных требованиях что-нибудь вроде "необходима Windows 10 версии XXX или старше с .NET YYY или старше". Или дистрибутив Вашего проекта в процессе установки сообщает "требуется JRE версии XXX", скачать-установить? Юзер соглашается, и тут, внезапно, или у установщика нет прав доступа к сети, или возбуждается антивирус, или еще что. А после установки десятка таких проектов пользовательская система оказывается набита гигабайтами не пойми чего, оно завязано друг на друга, и аккуратно/чисто удалить отдельные части оказывается проблематично, если вообще возможно.

Каюсь, для винды не писал лет 20 уже. На серверах есть пакетные менеджеры, контейнеры. Вероятно, на винде я бы выбрал .NET для фронта и C++ для ядра. Или Java + C++.

ЕМ>Шекспир нервно переворачивается в гробу.

Современный английский и Шекспира объединяет только слово "английский", всё остальное у них разное.

ЕМ>И не надо. А если уж это делать, то непременно в виде "сопутствующей библиотеки", которая может быть реализована, а может и нет. Любая работа с ФС или графикой всегда будет написана на самом языке, поэтому любой желающий может написать ее сам. А вот сделать то, что сам язык не позволяет, или невозможно, или очень геморройно. Поэтому прежде всего нужно развивать возможности самого языка, а удобные дополнения/надстройки всегда можно разрабатывать в виде библиотек.

Так и я о том же. Я хотел подчеркнуть, что разработка текущих страндартов это специальная олимпиада, где участники уже сами забыли, в чём состоит суть мероприятия. Не 100%, но 80% точно. Вот std::span мне понравился, я даже когда-то начал писать хобби-проект на базе LLVM, где такая штука была бы встроенной в язык. Вместе с операторами, которые позволяют использовать идиому head/tail, как в функциональщине. И ещё RAII там, но простой, без всяких нелепостей, которые мешают писать программу. Время тогда не хватило закончить.

Здравствуйте, Евгений Музыченко

Евгений, мне удалось сформулировать несколько причин, из-за которых невозможно удержаться и не постебать ваши сентенции по поводу "С++, который мы потеряли" (точнее, потеряли то вы, Евгений). Итак:

Во-первых, зачастую вы просто являетесь наглядной демонстрацией эффекта Даннинга-Крюгера.

Во-вторых, в ваших рассуждениях о том, насколько не туда ушел C++ и насколько извращенно сейчас пишут некоторые адепты "современного C++", сильно не хватает реальных примеров кода. Типа вот как извращаются сейчас в C++, а вот как оно следовало бы быть.

Хотя с этим-то как раз понятно. Чтобы приводить такие примеры нужно быть хотя бы Шоном Бакстером, который в одиночку запилил Circle и наглядно демонстрирует как те же самые проблемы можно решать более простым и понятным способом.

В-третьих, самое главное: ну хорошо, допустим, вы правы, C++ пошел не туда, используется не так, адепты Александреску извратили первозданную чистоту и красоту того самого праведного С++ и все такое. Допустим. Дальше-то что?

Что вы предлагаете?

Из ваших сентенций не понятно что должны делать современные C++ программисты.

Грубо говоря вот у нас есть существующий инструмент. Кого он не устраивает имеет возможность уйти на любой другой язык (хоть на Python, хоть на Java или C#, хоть на Rust или Ada). Что, как я понимаю, большинство недовольных уже давным-давно и сделали. Остались те, кому C++ нужен. И у кого есть именно тот C++, который есть здесь и сейчас, а не какой-то мифический "праведный C++" из вашей головы.

Вот нам-то, кто живет с современным C++, что делать?

Рыдать вместе с вами о том, что магистраль развития C++ 30 лет назад свернула не туда?
Отказываться от части возможностей C++ (каких?) и писать только на подмножестве C++ (каком?)?
Писать пропозалы по изменению языка в какую-то другую сторону?

-----

Короче, вы беретесь проповедовать, но не отвечаете на два главных вопроса русской интеллигенции: "Кто виноват?" и "Что делать?"
И если ответ на первый вопрос лично мне не интересен, то вот отсутствие ответа на второй вопрос и ведет к тому, чтобы в очередной раз спросить у вас: "А зачем вы лужи газифицируете?"

Здравствуйте, so5team, Вы писали:

S>* в C нет жесткого контроля за преобразованиями типов;
S>* в C нет встроенных средств поддержки динамического полиморфизма;
In pointer to void we trust!

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>преподаватель
ЕМ>дядька понимает суть программирования, как профессии
Взаимоисключающие понятия и это нормально.

По сути поста: кажется, что вам не нравится, что ваша ниша и ваш способ использовать С++ не самый востребованный на рынке. Но это нормально.

Я вот пишу на С++, и ежедневные проблемы, которые мне приходиться решать, с вашими не пересекаются вообще никак. (И программа занимает 100 Мб после установки!

Здравствуйте, Skorodum, Вы писали:

S>>* в C нет жесткого контроля за преобразованиями типов;
S>>* в C нет встроенных средств поддержки динамического полиморфизма;
S>In pointer to void we trust!

It's robust, reliable, understandable, and maintainable, just trust me.

Здравствуйте, so5team, Вы писали:

S>Что вы предлагаете?
Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

не содержали UB.

Здравствуйте, B0FEE664, Вы писали:

S>>Что вы предлагаете?
BFE>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

не содержали UB.

Вообще-то это не решение, а непонимание автором вопроса собственных желаний и возможностей ЯП. Причем здесь вопрос даже не C++, а в том, что у человека проблемы с пониманием принципов работы статической типизации.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, landerhigh, Вы писали:

L>>Про исключения теоретически согласен, но опять же, на подобных MK реально исключительная ситуация должна приводить к перезагрузке или failsafe.

ЕМ>Исключения, в силу своей чрезмерно абстрактной/универсальной реализации, на любой платформе создают изрядную избыточность, и по объему, и по выполнению. Из-за этого их чревато применять там, где исключение может возникать достаточно часто (чаще где-то десятков раз в секунду). В результате на одних исключениях всей обработки ошибок не построишь — нужно сочетать обычный возврат ошибок для более-менее регулярных ситуаций с исключениями для серьезных и относительно редких. В итоге проблема толком не решается, но избыточность присутствует, плюс сложности с объединением модулей, использующих и не использующих исключения. Палка о двух концах.

Это уже все было перетерто миллионы раз.
Применительно задачам, которые решаются "классическими МК" (а не замаскированными под них гигагерцовыми процессорами с гигабайтом оперативки), исключение — это что-то из ряда вон выходящее вроде "Device is on fire". Это же по сути КА, и должен реализовываться как КА.

L>>Так средство, которое позволяет условную компиляцию с нулевым оверхедом в рантайме или все же извращение?
ЕМ>С помощью магии — извращение. Особенно когда встроенные средства условной компиляции достаточно просты в реализации.

	Скрытый текст
	Картинку нашел, убрал м*т с нее.

Здравствуйте, so5team, Вы писали:

BFE>>Я не знаю, что предложит Евгений Музыченко, но многими востребовано, чтобы, например, решения подобные этому

Автор: _agg
Дата: 15.07 12:37

не содержали UB.
S>Вообще-то это не решение, а непонимание автором вопроса собственных желаний и возможностей ЯП. Причем здесь вопрос даже не C++, а в том, что у человека проблемы с пониманием принципов работы статической типизации.

Зато намерения автора прозрачны: иметь прямой и простой доступ к байтовому представлению базовых типов в памяти.