Железо: 16.0" 2560 x 1600, IPS, 165 Гц, Intel Core i7 14700HX, 16 ГБ DDR5, SSD 1024 ГБ, видеокарта NVIDIA GeForce RTX 4070 8ГБ (TGP 140 Вт)
list по сути представлет собой несколько структур пусть называются они node, в которой указатели на следующий и предыдущий и значение.
std::forward_list - это односвязный список.map вроде схожа на лист(в плане тоже есть node) только они предсталены в виде дерева и в нем производится двоичный поиск
std::map реализует структуру данных: Бинарное дерево. Чаще всего реализуют в виде RB-дерева.std::set реализуется тем же способом, но не хранит данные. Это просто дерево ключей.unordered_map особо не вникал как что там. Но вроде представлется вектор листов? по крайнер мере стандратная реализация. Гланое что я передаю ключ он хешируется через std hash и я получаю нужное мне значение.
std::unordered_map реализует структуру данных: Хэш-таблица. Организуются такие таблицы по-разному, но типовая реализация - это разреженный массив двусвязных списков. И тут я прервусь.std::deque реализует т.н. разреженный или постраничный массив. Или - Двусвязную очередь. Структура данных в основе: двусвязный список. Элементами списка являются массивы одинаковой длины. Такая организация позволяет манипулировать блоками элементов вместо цельного куска, как в векторе, и добиваться лучшей производительности на вставке, удалении и добавлении элементов по концам деки.std::queue и std::stack - это адаптеры, а не контейнеры. А подлежащим по умолчанию в них является именно std::deque.std::deque как бы не беря это во внимание.std::vector, std::list, std::deque, std::map и std::unordered_map. Как это не может если все может?
В качетсве примера function wrapper я и использую std::function, а не свою реализацию чтобы все поняли. Определение std::function взято из cppreference
На примере стандартного function wrapper
Всегда думал что методы просто функции которые первым аргументом принимают указатель
Или ссылка неявно к указателю преобразовывается.
std::function, не умеет захватывать указатели на методы. Он умеет захватывать только указатели на функции или функциональные объекты по значению. Когда тебе нужно через делегат вызвать метод объекта, тебе нужно знать целевой объект для метода, захватить этот объект в замыкании лямбды, в теле которой и вызвать относительно объекта метод. И уже эту лямбду сможет захватить делегат.template<typename TSender, typename TEventArgs. using EventHandler = std::function<void(TSender&, TEventArgs)>;
EventHandler<MyType> не начнет для тебя принимать методы. Он будет принимать просто указатели функции, первым аргументом которых ожидается ссылка на объект типа MyType. this иным образом невозможно.стандартный function wrapper
std::function
При сигнатуре void(T&, ars...)
T? Что такое ars?При сигнатуре void(T&, ars...) может принимать &T::Method.
Разве у всех методов не указатель первый аргумент?
this, я говорю что не всегда оно так, как у тебя в цитате. this может приходить вообще не так, как приходят аргументы. И проблема то еще заключается в том что не только же для ContentUIElement нужен шаблон данных. Например если реализовать следующие элементы с шаблонами данных ItemsControl, DataGrid, Expander, TabControl и т.д. И что мне тогда делать для каждого свой метод в IData?
IData у тебя остается только один, но теперь он возвращает ссылку на интерфейс провайдера данных. А уже провайдер данных пусть развивается так, чтобы удовлетворять все потребности в поставках шаблонов данных. Через реализацию посетителя снова или уже через прямой контроль.IData, который уже вернет голову стратегии. А от этой точки входа стратегия уже будет ветвиться сперва по элементу UI, а потом уже по реализации IData. Ну или наоборот, порядок не столь важен.dynamic_cast не нужен. У тебя в коде он все равно неправильно применяется.dynamic_cast соприкасается с шаблонным кодом, тебе нужно понять что плохо написано просто всё.
Dyikot , интерфейс. А что интерфейс? Идиома не поясняет каким из сотен способов ты планируешь тут ее применять. :)
Вот такого в твоем коде быть априори не должно. Выход на такой результат говорит только о том, что код надо удалить и переосмыслить.
У каждого объекта есть свой статический и динамический тип. И детерминизм этих типов в каждой строке кода программы является залогом ее безотказной работы. Иного код создавать не должен. Иного - это как у тебя в вопросе.
Это путь к тому чтобы забить на код и отказаться даже переосмыслять его. Результатом будет такой комбинаторный взрыв, что у тебя в один день рука не поднимется продолжить его писать.
Ответ на твой вопрос находится в документации языка. Пункт 7.e.
И обольщаться трактовками тут не стоит. "base class subobject of an object of type Derived" говорит именно о том, что аргумент каста д.б. именно базовым объектом объекта приводимого типа.