ContentUIElement::SetContent у тебя сейчас реализует прямой контроль. Код работает с переданным контекстом и указывает ему что-то делать.ContentUIElement::SetContent полностью все объекты, включая и объект по указателю this имеют два типа: статический тип и динамический тип. Оба типа могут быть одинаковыми, но нередко они разные.content имеет один динамический тип, то выполнить А. А если content имеет другой динамический тип, то выполнить Б. В иных же случаях выполнить общее поведение.IData появится еще один метод:void SetupContentElement( ContentUIElement& element )else метода ContentUIElement::SetContent, а реализации для UIElement и TextContent выполняют свой код настройки самостоятельно.ContentUIElement::SetContent сводится к вызову content->SetupContentElement( *this );.ContentUIElement больше не надо знать о типах UIElement и TextContent.IData определенный виртуальный метод, делая его абстрактным классом, а не интерфейсом, то решение простое: плюс один шаг базового типа от IData, в котором и определено общее поведение, и наследоваться уже от этого типа дальше, а не от IData напрямую. ABC.intptr_t и uintptr_t [?], а еще ptrdiff_t [?].enum class MemoryAddress : uintptr_t;. Пустое перечисление с достаточной шириной и выравниванием избавит от возможности случайно что-то куда-то прибавить или умножить, да и от неявных преобразований убережет. А перегрузка операторов поможет разрешить только определенные операции.::), через все пространства имен и пространства составных типов, написано имя выражения.Process::WaitForExit, хоть и является уже квалифицированным за счет указания пространства типа, в котором метод объявлен, все еще остается недостаточно квалифицированным чтобы считаться полностью квалифицированным.process.::base::Process::WaitForExit(&exit_code);base::Process::WaitForExit[?] не является виртуальным чтобы сделать предположение о невиртуальном вызове.Я конечно могу найти луч и потом искать пересечения со всеми объектами на сцене и рассчитывать координату z уже из этого, но мне кажется это слишком ресурсозатратно
glReadPixels в сотни раз более ресурсозатратнее обычного оптимизированного алгоритма проверки на пересечение луча с объектами сцены.glReadPixels в покадровых рутинах. Ни в мобильной разработке, ни в десктопной, ни под консоли.glReadPixels с проходом по матрице пикселей. __imp_glClear и __imp_glDrawArrays - это стандартные функции OpenGL, определены они в библиотеке opengl32.lib, которую и требуется подключить как внешнюю зависимость к твоему проекту.cat1 -> sound();cat1 как переменную в локальном пространстве с типом Cat*.Cat есть метод sound.Cat::sound запустится ADL и найдет в пространстве только одну перегрузку - метод без параметров. ADL вернет объявление этой перегрузки, т.к. она удовлетворяет условиям вызова метода.sound. Алгоритм ADL довольно строг и не будет искать объявления где-либо еще.Cat код cat1 -> sound(1); трансляцию никогда не пройдет. Просто потому что в пространстве класса написана только одна перегрузка метода.using[?].Cat должно быть таким.class Cat : public Animal
{
public:
// Delegate all overloads of `sound`.
using Animal::sound;
void sound () override
{
std::cout << "Cat.sound()" << '\n';
}
};cat1 -> sound(1); пройдет трансляцию и приведет к вызову void Animal::sound(int i). int может иметь размер не меньше 16 бит.int может иметь размер в 16 бит. А может иметь и 64 бита.int32_t к int и дальше к стандарту. В то время как стандарт определяет и требования к типу int32_t тоже.int32_t всегда и для любой модели памяти выбирается таким образом чтобы гарантировать размер в 32 бита.int32_t является псевдонимом int - это не более чем временное совпадение. Test::clone является std::shared_ptr<Test>.Test1 asd = v[1]->clone(); эквивалентна строчке Test1 asd = std::shared_ptr<Test>{ ... };.std::shared_ptr<Test> у типа Test1 нет. Трансляцию строчка Test1 asd = v[1]->clone(); не пройдет.std::shared_ptr<Test> asd = v[1]->clone();.Test1 asd{ *std::static_pointer_cast<Test1>( v[1] ) };.cpp файл, в котором шаблон инстанцируется, или определение должно быть добавлено через директиву #include..cpp файле определение шаблона вписано в том же .cpp файле, определение шаблона будет достижимо только в данном .cpp файле и больше нигде. В этом случае попытка инстанцировать шаблон в другом модуле трансляции приведет к ошибке трансляции, т.к. там определние шаблона будет уже недостижимо.#include - это дурной тон и прямой путь к нарушению ODR..h файлах обычно делают или объявления шаблонов функций, или определения шаблонов классов. В .hpp/.inl файлах обычно делают определения шаблонов функций и шаблонов методов..hpp/.inl файл очень часто включается в самом низу .h файла с его объявлениями..inl (от слова inline), т.к. для .hpp столь же широко закреплено взаимоисключающее с .h значение заголовка C++ кода. И видеть эти два расширения в одном проекте обычно бывает странно.