юнионы в C++

И опять ты занимаешься манипуляциями. Странно, что ещё не начал про космическое излучение, которая может бит в памяти переключить

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

А это вообще говорит о том, что понятие «ансейф» у тебя какое-то своё. Ну да, чтение или запись могут завершиться ошибкой, но никакого ансейфа, если интерфейс нормально спроектирован, тут нет

Системные вызовы, которые изначально являются эдаким внешним черным ящиком, которому мы пытаемся отправить запрос в принятом формате и молимся о том, чтобы ответная сторона всё сделала правильно. Чисто теоретически можно было бы придумать какую-то модель, которая давала бы гарантии, но на практике этого не случится при нашей жизни. Мы умрем, когда в банках всё еще будут поддерживать системы на коболе — можете скринить, чтобы вспомнить, когда будете умирать.

Оптимизации так-то разные бывают. Это может быть и более удачный алгоритм, не обязательно сразу хаки с указателями

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

Разбираться с которым будет сложнее, чем с нормально написанным. Просто потому, что люди не способны удерживать большой контекст в поле своего внимания. И что в функции на 350 строк этого контекста будет в разы больше, чем в функции на 25 строк

Чтобы понять 300 строк кода, нужно понять 300 строк кода. Поняв 250 строк кода ты не поймешь 300 строк кода, пока ты не поймешь оставшиеся 50 строк кода, независимо от организации этого кода. Если человек не смог понять 300 строк код, то он не смог их понять. Он может пропустить их и заняться чем-то другим. Основное назначение подпрограмм — оформить повторяющиеся строчки кода в сущность, для чтения и понимания которой нужно затратить чуть больше усилий, но сделать это надо только один раз, и дальше применять полученное знание везде по коду. Если тело подпрограммы используется ровно один раз, то можно спорить, что от такого разделения читаемость упала, а не повысилась. Если тело подпрограммы состоит из одной строки, то подпрограмма по сложности восприятия эквивалентна одной строке, и потому подпрограмма бессмысленна.

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

Его за это и выбирают, т.к. отсутствие гарантий обеспечивает a) высокую скорость работы кода и b) возможность работать напрямую с железом

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

Чтобы понять 300 строк кода, нужно понять 300 строк кода.

Человеку с мозгами я мог бы попробовать объяснить, что это работает не так.

Но то человеку с мозгами, а не Д’Артаньяну, который весь в белом.

Ну вот в гугле неграмотный коллектив. Вообще не представляю, как они что-то пишут. Дикие люди, не то что на LOR-е.

Это не ответ, опять сливаетесь…

В гугл фуксии запрещена большая часть STL. В начале треда давали ссылку на ихний стиль кода. STL претендует на универсальность, но она совсем не универсальная, потому ее использование не является критерием грамотности коллектива.

Как уже говорилось ранее, бесполезно приплетать в разговоре про особенности C++ другие языки

Ну да, все ж знают, что кроме C++ языков больше нет. Потому что даже если есть, то они все написаны на C/C++.

Ну да, все ж знают, что кроме C++ языков больше нет.

Вам не надоело позориться и демонстрировать непроходимую тупость?

Картина маслом - рассуждая о всякого рода UB и небезопасных крестах ты своими руками наговнокодил логическую ошибку - size некорректен

Да, каким-то образом я запостил ссылку на промежуточный, а не конечный вариант кода: тут size не просто некорректен — он вообще нигде не задается. Но суть из кода всё равно ясна и не меняется.

Я же тебе говорил, что без константности не написать дешевый (в смысле производительности) интерфейс, давая возможность смотреть кишки и не ломать при этом консистентность внутри объекта

В каком месте const позволяет делать то, что ты пишешь? Я смотрю кишки объекта зачем? Чтобы что-то прочитать, что-то проанализировать, куда-то сохранить. Если я думаю про производительность и минимизацию копирования, то я неизбежно прихожу к тому, что где-то как-то входные и выходные данные пересекаются, что приводит к проблеме, канонично именуемой «x=x», когда ты внезапно меняешь данные, которые тебе были переданы как const, потому что где-то в другом месте держишь неконстантный указатель на них же.

то я неизбежно прихожу к тому, что где-то как-то входные и выходные данные пересекаются, что приводит к проблеме, канонично именуемой «x=x»

сочувствую, я к этому не прихожу.

«Мне стыдно, что я пишу софт»(c) юнионы в C++ (комментарий)

«Мне стыдно, что я пишу софт»(c) юнионы в C++ (комментарий)

Фирменное передергивание и вырывание из контекста. Ну-ну.

то я неизбежно прихожу к тому, что где-то как-то входные и выходные данные пересекаются, что приводит к проблеме, канонично именуемой «x=x»

сочувствую, я к этому не прихожу

Да я уже понял, что для тебя «тесты прошли, остальное меня не колышет».

Мне кажется что за такие вещи надо вешать символический значок «лжец». Есть звезды, а это должна быть какая то антизвезда (пара бубенцов). Что бы все видели - с этим юзером в дискуссии не вступать, ничего кроме флейма не будет.

https://allll.net/wiki/Тролль,_лжец_и_девственник

(извините)

Таки да, но Вы сами напросились… Шо там с Вашим утверждением «на С++ ничего работоспособного написать нельзя»(c) ?

(извините)

За неровный почерк?;-)

Вообще такие треды надо показывать психологу, интересно что он расскажет. Или спектакль поставить… Но боюсь дело ограничится только ток-шоу.

Э, секунду, можно цитату на стандарт, где написано «применение модификатора const в коде обязательно?». Я пролистал, но почему-то не нашел.

Правила «применение const в коде обязательно» нет. Но когда я говорил про то, что вы не играете по имеющимся правилам, то подразумевалось другое.

Вы сознательно игнорируете const. Что не дает вам возможность применять его там, где применение const разумно.

Тогда как более-менее вменяемые разработчики стараются учитывать правила игры (например, тот факт, что const T & – это не гарантия иммутабельности объекта типа T, а всего лишь read-only view на объект типа T) и получают от этого бенефиты там, где эти бенефиты есть.

Вы же от получения этих бенефитов отказываетесь.

Const настолько плохо спроектирован, что в плане оптимизации ничего не дает, компиляторы вынуждены его игнорировать при оптимизации.

Зуб даете так же уверено, как и в случае с Turbo Pascal 1.0 в 16k?

Кроме того, тут даже оптимизаторы не причем, если вы можете использовать

inline const std::string my_str{"Hello!"};

вместо

#define MY_STR "hello"s

list<list<char*>>. Всё, приехали, ты уже не сможешь написать шаблонный код template function(list<list>), чтобы поместить в список и list<char >, и list<const char>.

Я все еще не вижу какой-то вменяемой задачи.

Но на самом деле проблема может выстрелить даже раньше, если потребуется list<char *> * хранить в банальной переменной, чтобы с этой переменной работать из двух удаленных частей системы.

Что более чем естественно когда мы вспоминаем про то, что С++ – это императивный язык с мутабельностью данных.

Это я уже не пытался апеллировать к новым проблемам, которые привносят шаблоны, как то читаемость, поддерживаемость, и время компиляции.

Вот не нашли в C++ другого способа писать обобщенный код с таким же уровнем контроля в compile-time и скоростью исполнения в run-time.

Да и в других языках что-то как-то не сильно лучше в этом плане.

области жизни в C++ сломаны by-design

по-хорошему в таких случаях использование RAII недопустимо

все объекты должны вручную выделяться и высвобождаться

Уходит в мой «золотой фонд» цитат.

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

(а) что вы знаете о регрессиях

(б) вам поговорить не с кем

?

в грамотных коллективах за шаблоны бьют по лапкам.

…

Ну вот в гугле неграмотный коллектив.

В гугле очень даже обмазываются шаблонами. Посмотри что ли на abseil.

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

Мало кто пишет и это нормально. Сам же должен понимать чего бы это стоило и что далеко не всегда оно нужно, даже без оглядки на «общество потребления».

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

Это о чём я и говорю. Тебе действительно лучше подошло бы быть политиком или «хотя бы» менеджером, которых ты так не любишь. Отлично получается забалтывать отходя от изначальной темы непонятно куда.

необходимость оптимизаций иногда приводит к необходимости пользоваться опасными приемами

Ой, а как же «машина Тьюринга не оставляющая шансов для безопасных оптимизаций» из соседнего сообщения?..

Шо там с Вашим утверждением «на С++ ничего работоспособного написать нельзя»(c) ?

Слушай, ну хватит уже. Там было дописано «за вменяемое время». Ты, когда кого-то громогласно обвиняешь во лжи, да еще и дергаешь за штанину модератора, хотя бы сам не обрезай цитируемое по живому.

Там было дописано «за вменяемое время»

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

Так что в реальной жизни невозможность написать работающий код за вменяемое время означает невозможность написать работающий код вообще.

Хотя могу предположить, что есть какой-то 1% случаев, в которых временем можно пожертвовать ради качества.

Если что то не может быть сделано за вменяемое время, то оно не может быть сделано с практической точки зрения. Теоретически любую задачу можно решить на любом тьюринг-полном ЯП, но это не значит что любую задачу может решить на любом тьюринг-полном ЯП с практической точки зрения.

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

И заявления о том, что на C++ ничего нельзя сделать работоспособного от букози звучали неоднократно

Лично я такие заявления читаю как «не шмогла я», а не «невозможно». Обратное то, очевидно, доказано.

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

А такой, чтобы можно было цитировать без некорректного обрезания, не нашлось?

Я не считаю это обрезание некорректным - вне зависимости от того производит обрезание или не производить, смысл высказывания не измениться. Цитировать все что тут букози выдает целиком мне кажется неуважением к тем кто читает мои комментарии.

const T & – это не гарантия иммутабельности объекта типа T, а всего лишь read-only view на объект типа T

Это работает только при условии, что «объект тип T» является тривиальным, у него нет динамического выделения ресурсов, ссылок, и прочих очень популярных среди кодеров на C/C++ штучек. Правда, в таких случаях зачастую можно просто копировать значение и не париться вообще, поскольку компилятор выоптимизирует копирование. Иначе получаем read-only view, через который можно изменить какую-то часть объекта, но не всегда, и прочие радости жизни, которые становится тем веселее, чем сложнее объекты.

Const настолько плохо спроектирован, что в плане оптимизации ничего не дает, компиляторы вынуждены его игнорировать при оптимизации.

Зуб даете так же уверено, как и в случае с Turbo Pascal 1.0 в 16k?

Еще попроси меня вернуть деньги за консультацию.

необходимость оптимизаций иногда приводит к необходимости пользоваться опасными приемами

Ой, а как же «машина Тьюринга не оставляющая шансов для безопасных оптимизаций» из соседнего сообщения?

Построить маленькую безопасную абстракцию на базе небезопасной машины Тьюринга.

Это работает только при условии

Это просто работает.

Тем, у кого не работает, остается только посоветовать включить голову и вытащить руки из известного места.

Иначе получаем read-only view, через который можно изменить какую-то часть объекта, но не всегда, и прочие радости жизни, которые становится тем веселее, чем сложнее объекты.

– Доктор, когда я делаю вот так, то мне больно…

– А вы не делайте так.

Так safe Rust и есть такая абстракция. Я не совсем понял, к чему у тебя претензии

Const настолько плохо спроектирован, что в плане оптимизации ничего не дает, компиляторы вынуждены его игнорировать при оптимизации.

Ого, да это почти Саттер 81!

Difficulty: 3 / 10

В гугл фуксии запрещена большая часть STL.

Странно, не нашёл об этом упоминания на https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/library_restrictions

Если процесс ревью доставляет дискомфорт, можно попробовать что-нибудь из XP. Например, парное программирование. Созвониться ревьюерам с автором и совместно поработать над кодом.

Разница в терминах c и c++.

c++: integer literal

c: integer constant

c++: integer literal

Спасибо!

Странно, не нашёл об этом упоминания на https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/library_restrictions

Вотъ: https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx
У меня почему-то выдает 403 при попытке перейти по ссылке с LOR-а.

Хотя я не спорю с тем, что дефолтный гугл стайл не запрещает STL. Зато запрещает большую часть Boost.

Это просто работает.
Тем, у кого не работает, остается только посоветовать включить голову и вытащить руки из известного места

Ну вот у меня поле unique_ptr в константной структуре. Я считал значение из него, у меня при этом потерялся const. И где ваш конст теперь?

Так safe Rust и есть такая абстракция. Я не совсем понял, к чему у тебя претензии

Да, я же не спорю.

Если процесс ревью доставляет дискомфорт, можно попробовать что-нибудь из XP. Например, парное программирование. Созвониться ревьюерам с автором и совместно поработать над кодом

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

Я все-таки имел в виду «очень быстрое поверхностное ревью, поскольку в глубоком нет принципиальной посредственности — код скорее всего хорош и без него».

Разница в терминах c и c++.
c++: integer literal
c: integer constant

Забавно. В Си продолжили называть буквальные константы константами, а поскольку в C++ константы уже зарезервированы для названия переменных, то для названия переменных задействовали термин «буквальное значение».

Const настолько плохо спроектирован, что в плане оптимизации ничего не дает, компиляторы вынуждены его игнорировать при оптимизации.

Ого, да это почти Саттер 81!
Difficulty: 3 / 10

По поводу большинства из выпусков Guru of the Week можно посоветовать просто избегать кода, который может вызывать вопросы. То есть, если у вас в коде есть строка «+++a», то это не «давайте посмотрим, как на самом деле группируются операторы», а говнокод и его нужно переписать так, чтобы вопросов не возникало.

Хотя я не спорю с тем, что дефолтный гугл стайл не запрещает STL. Зато запрещает большую часть Boost.

И что? Мы тоже запрещаем. Я один из первых буду отрывать причинные места деятелям которые злоупотребляют лямбдами и тому подобным. В отличие от многих здесь присутствующих мне не шашечки, мне ехать. И апеллировать я буду к asm на выхлопе и объективным метрикам снятым в проде (там на самом деле не всё так просто, даже если asm чистенький - от конкретного чипа сильно зависит), а не к тому как код выглядит «на бумажке».

Еще хуже. XP рождает нечитаемую дристню в устрашающих объемах

Да да да. Вы не котиков не любите, вы их готовить не умеете.

И вообще - чем больше я за вами наблюдаю, тем больше я убеждаюсь в вашей неадекватности и ужасающей некомпетентности. Одну из своих миссий на ЛОРе вижу в попытке оградить как можно больше неокрепших умов от последствий вашего словесного поноса. Кто-то ведь правда это за истину может воспринять.

Хотя я не спорю с тем, что дефолтный гугл стайл не запрещает STL. Зато запрещает большую часть Boost

Я один из первых буду отрывать причинные места деятелям которые злоупотребляют лямбдами и тому подобным. В отличие от многих здесь присутствующих мне не шашечки, мне ехать

Профессионал, тебе забыли рассказать о том, что лямбды умеют полностью инлайниться, как и любые другие варианты функторов? И что шаблоны как бы создавались для переноса логики из runtime в compile-time, а значит ты первый должен был бы топить за них, как якобы оптимизатор — и тогда при чем тут твой ответ к моей фразе?

Ты больше похож на понтореза, который что-то где-то вычитал или услышал из уважаемых источников, и теперь под соусом авторитетности продает это кому попало, якобы «вот, все продвинутые знают, и я знаю, да куда вам понять...» — именно с такой недосказанностью и «мне некогда, мое время много стоит» ты и подаешь большую часть своих сообщений. Справедливости ради, даже я повелся, и вполне возможно, твой работодатель тоже купился на гонор, не увидив за ним пустышку.

А вот меня уже достало и я покупать твое ЧСВ не намерен. Впрочем, как и игнорить тебя или кого бы то ни было — я всегда оставляю возможность людям взяться за ум.

И где ваш конст теперь?

На колу мочало… Не было там конста изначально, некуда ему и деваться было.

В C++ если объект B не является частью объекта A, то константность объекта A на B не распространяется. Т.е.

struct B {...};

struct A {
  B m_b;
  ...
};

void f() {
  const A a;
  const B & b1 = a.m_b; // Здесь A::m_b константен.
  B & b2 = a.m_b; // ОШИБКА!
}

struct C {
  B * m_b;
  ...
};

void g() {
  B ext_b;
  const C c{ &ext_b, ...};
  B * b = c.m_b; // Здесь все OK, т.к. константность 'c' на
                 // экземпляр типа B не распространяется.
}

Вот так в C++ устроено. И это логично, т.к. позволяет делать, например, вот так:

struct app_context_t {
  logger_t & m_logger;
  const app_args_t & m_args;
  ...
}

int main(int argc, char ** argv) {
  const auto ctx = make_app_ctx(argc, argv);

  std::thread listener{ [&ctx]() {
    ctx.m_logger.debug(...);
    ...
  } };
  
  std::thread worker{ [&ctx]() {
    ctx.m_logger.debug(...);
    ...
  } };
  ...
}

Т.е. можно передавать ссылку на константный объект ctx и знать, что получатели ctx не будут менять сам ctx. Но в ctx будут ссылки на неконстантные объекты (типа логгера).

Если бы константность была транзитивной в том числе и по ссылкам/указателям, такая простая операция бы требовала либо плясок с бубном, либо слишком частого использования const_cast или mutable .

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

class byko3y_wanted_style {
  some_class * external_object_;
  ...
public:
  some_class * external_object() noexcept
  { return external_object_; }

  const some_class * external_object() const noexcept
  { return external_object_; }
  ...
};

Но что-то мне подсказывает, что за такое вас будут поминать незлым тихим словом.

Профессионал, тебе забыли рассказать о том, что лямбды умеют полностью инлайниться, как и любые другие варианты функторов?

Я готов начать это с вами обсуждать когда вы сможете читать asm.

Ты больше похож на понтореза, который что-то где-то вычитал или услышал из уважаемых источников, и теперь под соусом авторитетности продает это кому попало

Искандеры улыбнулись.

Справедливости ради, даже я повелся, и вполне возможно, твой работодатель тоже купился на гонор, не увидив за ним пустышку.

Я так думаю, за 20ть то лет разглядеть можно было кто чего стоит.

А вот меня уже достало и я покупать твое ЧСВ не намерен.

Конкретно вам я продавать ничего не собирался.

Впрочем, как и игнорить тебя

Да вы же тупо балабол кому общаться не с кем. Игнор кого-либо вам смерти подобен. Где ещё такие «уши» то найти.

или кого бы то ни было — я всегда оставляю возможность людям взяться за ум.

Сделайте одолжение - выпилитесь.

а поскольку в C++ константы уже зарезервированы для названия переменных, то для названия переменных задействовали термин «буквальное значение».

О боже, какую хрень я только что прочитал?

Вы уж определитесь, для вас в C++ числовой литерал ‘42’ – это таки константа (как в математике) или переменная. Потому что если переменная, то define уж точно никак не может использоваться для задания констант (хотя вы это и утверждали).

А если думаете, что константа, то у меня для вас сюрприз:

#include <iostream>

#define MY_VAL 42

void f(int && v) {
    std::cout << "Temporary int: " << v << std::endl;
}

int main() {
    f(MY_VAL);
}

Ты как-то спорил с местным быдланом про тойоту. Может быть интересно будет: https://blogs.fsfe.org/agger/2022/05/12/devops-inspiration-from-toyota-production-system-and-lean-considered-harmful/

Ну в грамотных коллективах за шаблоны бьют по лапкам

И в команде разработки boost?

Сделайте одолжение - выпилитесь.

Надеюсь, имелось в виду с ЛОР-а? Лучше не надо, byko3y таки хороший флеймогенератор

а что тут рассказывать?

реализация в виде библиотеки ограниченная (даже, можно сказать, фиктивная: Bitfields are internally stored in an ubyte, ushort, uint or ulong depending on the number of bits used. The bits are filled in the order given by the parameters, starting with the lowest significant bit. The name of the (private) variable used for saving the bitfield is created by a prefix _bf and concatenating all of the variable names, each preceded by an underscore).

Это сразу обрубает так нелюбимые опытными Разработчиками разные трюки (так удобные при работе с железом!)

ну и просто сравним:

struct A { int x:2; int y:3; bool z; };

void test() { A a;

a.x = 2;
a.y = 5;
a.z = true;

}

test(): push rbp mov rbp, rsp movzx eax, BYTE PTR [rbp-4] and eax, -4 or eax, 2 mov BYTE PTR [rbp-4], al movzx eax, BYTE PTR [rbp-4] and eax, -29 or eax, 20 mov BYTE PTR [rbp-4], al mov BYTE PTR [rbp-3], 1 nop pop rbp ret

// — c —

import std.bitmanip;

struct A { int a; mixin(bitfields!( uint, «x», 2, int, «y», 3, uint, «z», 2, bool, «flag», 1) ); }

void test() { A a;

a.x = 2;
a.y = 5;
a.z = true;

}

// ————— pure nothrow @property @nogc @safe void example.A.x(uint): cmp esi, 3 ja .L8 mov eax, esi movzx esi, BYTE PTR [rdi+4] and esi, -4 or esi, eax mov BYTE PTR [rdi+4], sil ret .L8: sub rsp, 8 mov r8d, 6 mov edx, 22 mov ecx, OFFSET FLAT:.LC0 mov edi, 55 mov esi, OFFSET FLAT:.LC1 call _d_assert_msg

    movzx   eax, BYTE PTR [rdi+4]
    and     eax, 28
    shr     eax, 2
    mov     edx, eax
    or      edx, -8
    cmp     eax, 3
    cmova   eax, edx
    ret

.LC2: .ascii «Value is smaller than the minimum value of bitfield ‘y’» .zero 1 .LC3: .ascii «Value is greater than the maximum value of bitfield ‘y’» .zero 1 pure nothrow @property @nogc @safe void example.A.y(int): sub rsp, 8 cmp esi, -4 jl .L15 cmp esi, 3 jg .L16 movzx eax, BYTE PTR [rdi+4] sal esi, 2 and esi, 28 and eax, -29 or eax, esi mov BYTE PTR [rdi+4], al add rsp, 8 ret .L15: mov r8d, 8 mov edx, 22 mov ecx, OFFSET FLAT:.LC0 mov edi, 55 mov esi, OFFSET FLAT:.LC2 call _d_assert_msg .L16: mov r8d, 8 mov edx, 22 mov ecx, OFFSET FLAT:.LC0 mov edi, 55 mov esi, OFFSET FLAT:.LC3 call _d_assert_msg

pure nothrow @property @nogc @safe void example.A.z(uint): cmp esi, 3 ja .L23 movzx eax, BYTE PTR [rdi+4] sal esi, 5 and eax, -97 or eax, esi mov BYTE PTR [rdi+4], al ret .L23: sub rsp, 8 mov r8d, 10 mov edx, 22 mov ecx, OFFSET FLAT:.LC0 mov edi, 55 mov esi, OFFSET FLAT:.LC4 call _d_assert_msg const pure nothrow @property @nogc @safe bool example.A.flag(): movzx eax, BYTE PTR [rdi+4] shr al, 7 ret pure nothrow @property @nogc @safe void example.A.flag(bool): movzx eax, BYTE PTR [rdi+4] mov edx, eax and eax, 127 or edx, -128 test sil, sil cmovne eax, edx mov BYTE PTR [rdi+4], al ret void example.test(): sub rsp, 8 mov r8d, 8 mov edx, 22 mov ecx, OFFSET FLAT:.LC0 mov edi, 55 mov esi, OFFSET FLAT:.LC3 call _d_assert_msg

Ну вот кому мешало?!