dynamic_cast не нужен. У тебя в коде он все равно неправильно применяется.dynamic_cast соприкасается с шаблонным кодом, тебе нужно понять что плохо написано просто всё.у меня не транслятор ошибку пишет, а компилятор
type arr[N]; у тебя уже сконструирован. И транслятор тебе сообщает именно об этом. А подходящего конструктора по умолчанию c_function у тебя в коде вообще нет. Он удален по умолчанию. Потому что ты так написал, чтобы он стал удаленным по умолчанию.E0070 говорит о том, что ты пробуешь пользоваться экземпляром определенного типа там, где этот тип еще не является полным.Спасибо за ответ, разобрался - нужно было llvm-strip сделать.
llvm-strip? Это поведение точно то, которое тебе нужно? Или ты просто оценил выполненную работу через размер выходного файла и успокоился на этом? Во-вторых, это проблема из-за правил поиска операторов. Они ищутся только в типах, которые участвуют в выражении, т.е. int и WidthProperty.
Не, не надо. В этом случае надо отходить от просто посетителя, но сохранять инверсию контроля.
Например, у тебя может быть реализация на базе стратегии. Мне в данный период моей жизни более привлекательным для тебя видится реализация провайдера данных.
По сути метод в
IDataу тебя остается только один, но теперь он возвращает ссылку на интерфейс провайдера данных. А уже провайдер данных пусть развивается так, чтобы удовлетворять все потребности в поставках шаблонов данных. Через реализацию посетителя снова или уже через прямой контроль.Реализация стратегии будет иметь точку входа в виде все того же метода
IData, который уже вернет голову стратегии. А от этой точки входа стратегия уже будет ветвиться сперва по элементу UI, а потом уже по реализацииIData. Ну или наоборот, порядок не столь важен.Но самое главное всегда - это закрывать задачу ровно настолько, чтобы она была решена. Не больше того. :)
Поэтому твой подход сейчас поди для тебя на этом этапе подходит лучше всего.