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 соприкасается с шаблонным кодом, тебе нужно понять что плохо написано просто всё.
Идеи появились буквально сразу. Только не подумай что так все на самом деле и есть. Ноут у тебя надо диагностировать. Желательно это делать руками куда более квалифицированного в починке железа чем я человека.
14-е поколение Intel очень и очень плохое. В нем откиснуть может все что угодно и когда угодно, а менять придется весь камень целиком.
14-е поколение является провальной попыткой Intel применять разгон своей старой архитектуры ради достижения конкурентного паритета с AMD, но без внесения в свою уже старую архитектуру хоть каких-то изменений. Вместе с провальной тактикой, Intel еще с 12-го поколения не могли справиться с загрязнением кристалла процессора на производстве. 14-е поколение тоже грязное, сильно и бесповоротно деградирует со временем.
И деградация у 14-го поколения усиливается за счет все того же заводского разгона. Высокое энергопотребление, очень быстрое достижение пиковых температур, несбалансированность и нестабильность работы самого чипа лишь ускоряет процесс деградации чипа.
У тебя скорее всего с завода встройка испорчена. Я еще с 11-го поколения принципиально не советую брать синие CPU. Голосовать за действия компании мы можем только рублем. Ни в коем случае нельзя кормить своими деньгами компанию, которая создает откровенный шрот под видом продукта.