GDC и LDC тем более генерируют совместимые бинари, так что это еще лучше. Другое дело, что они поддерживают не весь D пока что, насколько я знаю (DConf, май 2013).
Хотя знаете, я попробую сделать на С11 атомиках, но что-то мне подсказывает, что с инлайном та же фигня получится, потому, что они через те же интринсики и реализованы, скорее всего.
В том-то и дело, что в интринсиках gcc-шных с точки зрения барьеров сомневаться как-то странно, тем более, пока что на десктопном линуксе и макоси даже, а не на какой-то богом забытой железке, а больше по логике барьеры не нужны нигде, кроме как, собственно, в CAS.
1. В си нет стандартных атомиков. Я использую openpa и gcc intrinsics (результат один и тот же в обоих вариантах).
3. Там итак такое есть.
4. Ну, с багом компилятора я ничего поделать не могу.
А LTO с shared library мне врятли, к счастью, грозит. И да, уверен, во-первых, это очень просто, а, во-вторых, я долго-долго на разных ОС и машинах тестировал, все было хорошо, пока я не поставил -O2.
Более того, я даже не могу предоставить код, на котором крашится, просто в рандомном месте указатель принимает значение навроде 0x2. Я очень долго искал причину всего этого, в итоге сегодня сел сравнивать -O1 и -O2 сгенерированный ассемблер (-O1 работает ОК) и понял, что таки instruction reordering + inlining виноваты, починил ноинлайном, и теперь хочу портабельно сделать.
Это очень низкоуровневый аппаратно зависимый код, все верно. А имеено, вход в критическую секцию по аглогитму test and test-and-set via atomic cas.
Но реализация оной вещи у меня есть для кучи платформ, так что вполне есть смысл поддержать много компиляторов.
Ах вот оно что! То есть это даже не движок, а больше платформа? Типа юнити, добавляешь мультимедиа, немного скриптов и готово? Тогда лучше по Юнити туториал и делать. Или там анриал энджин. Край энджин, кстати, тоже интересно.
Ну да, динамический полиморфизм, если данные приходят с формы, вам приходит обьект B, а вы оборачиваете его в обьект класса Q, если же вы генерируете обьект B сами, то оборачиваете его в обьект класса W, тогда, если и W и Q отнаследованы от F, то вы можете передавать в public A(F context) и new W(context) и new Q(context), все правильно. С тем, что в F работать просто: вы реализуете у F тот же интерфейс, что есть у B, или не тот же — по вашему желанию, просто маппите методы B на методы F.
Если нельзя унаследовать, то может можно создать интерфейс и в A заменить B на этот интерфейс, а потом отнаследовать и B и D от этого интерфейса. Если же и это нельзя, то по-хорошему не выйдет.