Новое сообщение в форум Компьютерные священные войны

Форум	Компьютерные священные войны
Тема	Как правильно задавать вопросы

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

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

S>>есть некий перечень этих самых возможностей. Раз он есть, значит его можно озвучить. Озвучте, пожалуйста.

ЕМ>Да Вы сами их прекрасно знаете. Спецификация того, как данные размещаются в памяти и выравниваются в ней (если и не для всего языка, то для [i]любой[/i] реализации), возможность слепого/принудительного преобразования типов, обязательная спецификация ABI для каждой реализации

S>>Пока не видно никакой общей идеи.

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

ЕМ>>>Насколько я понимаю, Вы приличных макропроцессоров вообще не видели даже на примерах

S>>Вы неправильно понимаете.

ЕМ>Тогда что ж Вам мешает вообразить макропроцессор, работающий не перед фазой компиляции, а во время нее? Ведь шаблоны обрабатываются именно так, в них есть черты и макросов, и функций. Вот и представьте шаблон, в котором вместо псевдофункционального синтаксиса - примерно тот же язык, что и базовый C++, с условными операторами вроде if constexpr, с циклами, локальными переменными, включая массивы, одним из которых является массив фактических параметров. Неужто скажете, что это будет менее функционально, удобно, понятно, наглядно и гибко, чем имеющийся формат с трюками и множеством чисто вспомогательных, служебных шаблонов, без которых нужный функционал попросту не реализуется?

S>>Вы код пишете для того, чтобы ассемблерный выхлоп изучать или чтобы задачу решить?

ЕМ>Когда решается задача "написать программу для микроконтроллера с памятью в восемь килобайт на код и два килобайта на данные", или "написать быстродействующий модуль ядра, где полностью отсутствуют средства профилирования", ассемблерный выхлоп становится сверхценным. А задачи под гигабайты/гигагерцы я могу написать и на Java/JavaScript, где ассемблерного выхлопа и вовсе нет.

S>>Насколько я знаю, в том же GCC можно использовать "-fno-rtti", но при этом сохранять исключения.

ЕМ>Это уже вынужденные особенности реализаций, вызванные заведомо избыточной концепцией исключений в C++.

ЕМ>>>а в виде "как получить информацию о типе у компилятора, чтоб далее использовать ее имеющимися средствами языка", то 
S>>то C++ные шаблоны вам дают именно это.

ЕМ>Они дают не [i]это[/i]. Они, грубо говоря, дают примерно то же, что и технологии Meltdown/Spectre - сугубо косвенными методами (то есть, через задницу) определить значение в памяти, которое нельзя просто прочитать. Попробуйте представить себе аппаратную платформу, где прямое чтение из памяти по каким-то странным причинам оказалось вовремя не реализованным, и какие-то забавные ребята, развлечения ради, придумали аналог Meltdown, добывающий содержимое памяти какими-нибудь косвенными, статистическими методами. Каков будет шанс на реализацию прямого чтения в будущем, если та хитрая техника добывания будет быстро возведена в ранг высокой технологии, вокруг нее соберется толпа энтузиастов-поклонников, а противники будут объявлены ретроградами, неспособными постичь новое и современное? :)

S>>когда люди не могут платить за штатный RTTI они делают свои минимальные реализации как раз за счет шаблонов.

ЕМ>Ну да - люди, которые не могут (или не хотят) платить за какой-нибудь Porsche, вынуждены ездить исключительно в инвалидных колясках, поскольку свысока авторитетно объявлено, что это в чистом виде бинарная альтернатива, и любые промежуточные варианты - от лукавого.

S>>Так-то в C++ можно и [tt]throw 42[/tt] написать.

ЕМ>Но платить-то придется за весь банкет, поскольку любой throw или try/catch непременно потянет за собой [i]все[/i] зависимости, предназначенные для обработки исключений. Конечно, можно покопать конкретную реализацию, найти, какие функции там подтягиваются, и сделать для них заглушки, но это может быть непросто, если от каких-то функций ожидается принятие определенных решений в ходе раскрутки, а решения эти должны быть основаны на состоянии стека, выброшенных/ожидаемых типах и т.п. Но главное-то в том, что всем этим приходится заниматься не потому, что мир таков, а потому, что одни люди в свое время поленились подумать чуть лучше, а другие не нашли смелости их поправить.

S>>Другое дело, что в любом большом проекте с включенными исключениями за такое по рукам надают, скорее всего.

ЕМ>А в больших проектах такого и не нужно. Нужно только там, где главная задача - аккуратно и надежно передать управление снизу вверх, а ситуаций, определяемых передаваемыми попутно данными, может быть всего две-три.

S>>Правильно ли я понимаю, что список "низкоуровневые и архитектурно-зависимые возможности C++, унаследованные от C" состоит из одного пункта -- поддержка SEH на платформе Windows?

ЕМ>Так SEH нет ни в C, ни в C++. :) А остальные низкоуровневые возможности одинаково успешно используются на любой платформе, где важна привязка именно к низкому уровню.

S>>Вы точно уверены, что все реализации C++ных исключений сделаны на базе Windows-ного SEH?

ЕМ>Как они могут быть сделаны на базе SEH в каком-нибудь линуксе, где SEH попросту нет? Но, если ОС предоставляет подобные средства, и они технически позволяют реализовать плюсовые исключения, что может помешать реализовать их именно так?

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail