Есть ли парсер-надстройка sdlang, который позволяет импортировать каскадно другие файлы? Например, в файле пишу: import blabla.sdl.

Полюбому придумали  общие    препроцессоры, которые так могут.

зависимости?

какой кейс для импорта?

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

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

а у тебя там краш хендлеры свои или из стандартной библиотеки что-то вызывается?

а тут нельзя шаблоном сделать наследование?

template <typename DomainComponent> 
class BaseUniComponent : DomainComponent {...};

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

>а тут нельзя шаблоном сделать наследование?
наверное, это дает какие-нибудь преимущества?

> наверное, это дает какие-нибудь преимущества?

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

шаблоном решается

если я правильно там понял

кгм... но по смыслу происходящего ведь это и должно быть. Это сделано для того, чтобы получить компонент фреймворка, снабженный специфическими службами, не трогая при этом ядра. можно обойтись и без этого, тогда многие вещи облегчаются, навроде выделения core в либы, но для некоторых проектов могут быть сложности и нужно либо делать глобальную какую статику или еще как.
Лучше вопрос, почему там Base...., когда его могло бы и не быть). Это сделано для упрощения выпиливания служб при переезде на другой проект, на каком-то проекте я замудохался оттуда выпиливать десятки служб,  так появился Base, хотя это не очень хорошо, конечнож...

поэтому компоненты поделены в нескольких местах, хотя для маленького количества служб это выглядит бессмысленным.

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

собственно, для решения этой проблемы и был выдуман ioc-контейнер, который снимает все проблемы... ну кроме самой проблемы контейнера)

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

так что будет null и сработает контракт.

А Денис, говорил не взлетит. А оно пока летит выше его рантайма, потому что применено в реальном достаточно сложном случае. :D

Так Денис же что-то на своём рантайме пилит