Какая приоритетная очередь быстрее?

но я на 99% уверен, что любое решение на основе deque (priority_queue или ручной вариант) будет самым быстрым, с учётом малого объёма данных и более частого попадания в кэш, чем при использовании деревьев

Твоя правда. Я, чес-говоря, пока тоже в этом уверен, пока автор не описал задачу, в решении которой должна участвовать очередь.

Какая приоритетная очередь быстрее?

Инструмент всегда выбирается исходя из задачи. Какую подзадачу должна будет решать приоритетная очередь и в рамках какой задачи она должна будет использоваться?

Какая приоритетная очередь быстрее?

std::deque не решает задач приоритетной очереди. Стандартная std::priority_queue, при этом, по умолчанию базируется на std::vector.

К базовым обязательным свойствам приоритетной очереди относятся мнимая предсортированность с возможностью легкого доступа к экстремуму коллекции и минимальная трудоемкость вставки с гарантией сохранения порядка сортировки элементов.

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

Как изучать С# после С++, и стоит ли вообще?

CuteDoge, относительно мук выбора между языками у меня некоторое время назад был такой комментарий.
Коротко, цитатами оттуда.

Язык программирования - это просто инструмент.

Инструмент всегда выбирается под конкретный проект.

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

Инструмент надо всегда начинать изучать с нуля. У разных инструментов разные подходы к работе с ними. Пропустив азы, ты рискуешь начать неправильно пользоваться инструментом и скатиться в идиосинкразию.
Для C++ "около года" - это ничего. В течении этих "около года" ты изучал общие основы программирования на примере работы с инструментом C++, а не сам C++. Стандарт языка просто невозможно изучить за такое время, особенно без плотной практики.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, а еще есть великая Вавилонская библиотека, где написано все, что когда-либо случалось или еще только может случиться. Сходи почитай, что с тобой завтра случится, если найдешь, конечно. :)
Это - аналогия.

Среди всех возможных строк - найдется коллизия. Среди всех осмысленных - математически доказывается что да или нет. Среди рабочего набора - легко математически доказывается что нет или делается выбор другого алгоритма. Ссылки на информацию по доказательствам уже приведены и доступны для твоего изучения.
Доказать правильность работы своего ПО для всех формальных случаев входных данных ты не способен, т.к. инструментов формального доказательства правильности ПО еще не разработано. Так что стоило бы повременить с демагогией про краши и русскую рулетку. Ты в нее каждый день играешь и каждый день садишь краши. Будут подходящие входные данные, будут у тебя и краши.
В текущей ситуации я вижу разговор завершенным.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, в 32 бита без учета знака кодируется 4294967296 значений. Цель хорошей хеш-функции - при незначительном изменении входных данных обеспечить как можно более равномерное распределение бит в выходном значении и давать как можно более равномерное распределение хешей от множества входных значений. "Выбор той или иной хеш-функции определяется спецификой решаемой задачи." ©

Ly обеспечивает неколлизионность и равномерное распределение для строк до 32 символов потому что в алгоритме используется циклический сдвиг на длине в 32 бита. Если длину хеша увеличить до 64 бит, то и гарантии хеширования распространятся на все значения до 64 символов.
Хеширование строк на этапе компиляции целесообразно ограничивать 32 символами, чтобы время сборки оставалось в приемлемых рамках. Хеширование произвольных текстов во время компиляции гарантированно приводит к неконтролируемому росту времени сборки проекта.
На деле Ly64 уже не нужен, особенно на этапе компиляции, т.к. для этих же целей лучше использовать xxh64 или CityHash64.
xxh64 тоже можно реализовать на этапе компиляции, но для этого уже надо применять смекалку и глубокие знания стандарта языка (и это не нужно). std::hash в некоторых реализациях обращается именно к функции CityHash64.

32 байта - это, очевидно, слишком слишком.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, довольно полезная в этом плане статья пользователя madcomaker была нагло выпилена с хабра, но осталась на одном из его зеркал.

Через анализ хеш-функции можно подтвердить ее коллизионную стойкость. Это помогает математически доказать избыточность дополнительного сравнения хешируемых значений при обращении к хеш-таблице.
Вероятность коллизии есть всегда. Просто иногда ее можно свести к малозначительной.

Ly так и вовсе начинает явно пестрить коллизиями только если длины хешируемых строк сильно пляшут через границу 32 символов.
При этом, до миллиона хешируемых значений получают приятное равномерное распределение без единой коллизии в том случае, если все строки меньше 32 символов.
32 символа - это ограничение используемого мной конгруэнтного генератора, заложенное в его алгоритме.

Есть ли в для C++14 map с поддержкой constexpr хэша?

rustler2000 , решает ли этот ответ твой вопрос?

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин, на самом деле хешируемое значение можно вынуть из hashed и положить в Out of line. Так будет даже удобнее. Сама hashed в таком случае станет очень легкой и сможет участвовать в операциях времени компиляции.
По опыту работы с подобными механизмами (а у меня такой уже в пятом поколении реализован) я с уверенностью могу говорить что хешируемое значение в работе требуется чуть чаще чем никогда. Его просто незачем таскать рядом со значением хеша.
А для задач автора я бы и вовсе предложил хешируемое значение не хранить.

И std::hash нам тут тоже не очень нужен. Мы вполне можем справиться (я очень уверенно справляюсь) с простой хеш-функцией, которая может быть и ненадежной, но давать максимально равномерное распределение значений. например, я работаю с конгруэнтным генератором - Ly.
Код у меня там довольно старый. Если там убрать приведение типов и воспользоваться std::byte, то inline можно смело менять на constexpr или consteval.

Есть ли в для C++14 map с поддержкой constexpr хэша?

Антон Жилин , в этом примере все хорошо за исключением пары моментов.
std::hashне может использоваться в контексте времени компиляции. Он не отвечает требованиям к составным объектам времени компиляции. Он не имеет constexprконструктора и его оператор не помечен как constexpr. Особенно у реализации для std::basic_string. В общем смысле, согласно стандарту, код в примере не будет работать на этапе компиляции.
Момент второй. std::unordered_map::find свой аргумент принимает по ссылке. Как только от constexpr объекта требуется указатель или ссылка, он сразу перестает быть constexpr. В последних строках ничего не этапе компиляции делаться не будет.

На деле же этот код даже не соберется, т.к. строка физически не может быть constexpr, но она находится в составе типа, объект которого в коде хочет создаваться на этапе компиляции.

Еще есть вопрос. Какая цель у того, чтобы все возможные инстанцирования шаблона std::hash объявлять друзьями для hashed? Доступ к приватному полю лучше организовать иначе.

Есть ли в для C++14 map с поддержкой constexpr хэша?

rustler2000 , расскажи про задачу, для решения которой тебе потребовался такой контейнер.
Думаю, твою задачу можно решить все так же на этапе компиляции, но без использования ассоциативных контейнеров.

Как записать бинарные данные в память (по адресу) моего процесса?

CakeCPP, так ты как проблему-то решил? Тебе стало понятно что в абы откуда взятые адреса виртуальной памяти писать нельзя потому что они еще не связаны с физической и вообще не размечены? Откуда тебе известно что 7623723 находится в области доступной виртуальной памяти? Если это адрес, то он не выравнен и с таким адресом работать нельзя. А если это адрес в секцию исполнения, то помаши еще ручкой кэшу процессора.
Что делает HexToBin? Метод c_str есть только у std::string. Напрашивается вопрос: зачем функция HexToBin возвращает не бинарные данные, а строковые? Она должна тогда называться HexToStr, а лучше - как-нибудь осмысленно.

Как записать бинарные данные в память (по адресу) моего процесса?

CakeCPP , так а чем memcpy тебе не угодила?
Вопроса, как бы, нет в "титлере". Что такое "титлер" - тоже не ясно.
Что именно тебе хочется сделать с данными? Куда записать? Как записать? По какому адресу? Какого размера? С каким выравниванием?

Нужна помощь со светодиодной матрицей 4x4 (?

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

Как std::initializer_list определяет количество элементов в {списке}?

Egorithm, понятно, статья старая и полезная для первого знакомства с инициализацией. С материалом там все нормально, просто цитата из контекста оказалась вырвана и создала не то впечатление.
Далее надо пойти в документацию. Я дам немного пояснений по документации в ответе.

Как std::initializer_list определяет количество элементов в {списке}?

Egorithm , необходима ссылка на источник этой цитаты.
В последних трех строчках приведенной цитаты информация о std::initializer_list сильно искажена.

Возможно ли подключить lua в namespace?

Евгений Иванович, питон не является встраиваемым языком. Питон допускает только расширение своей функциональности через встраиваемые модули. Встраиваемым из всех вариантов питона является только IronPython, с которым пойди поработай. И, снова, питон написан на C, а дальше можно читать мое уточнение выше.

Игра использует lua5.1 & luajit 2.0.2, что не подходит для класса Lua53Machine

Это обоснование использования двух версий Lua в проекте? Тогда чем ты можешь обосновать невозможность поднятия всего Lua кода до 5.3 и использования одной версии Lua?
Особенно учитывая твои слова о переделке всего на питон.

Возможно ли подключить lua в namespace?

Евгений Иванович , Lua разработан на C. В C нет пространств имен. Завести Lua в пространство имен ты можешь только переписав библиотеку полностью.
Чем ты можешь обосновать необходимость держать две версии Lua в проекте?

Как подключить библиотекту к проекту Qt Creator?

Egorithm, книга с драконом - это для глубокго изучения вопроса. Не, сейчас ради обретения фундамента будет достаточно некоторых статей. Например с хабра: [1], [2], [3], [4], [5], [6]. Или с SO: [1].

Шаблоны стека и очереди у тебя уже есть, их можно не делать. Но вот бинарное дерево операций сделать надо. И сами операции тоже. Думай о константе, как о унарной операции, которая всегда возвращает одно значение. О переменной можно думать как о унарной операции, которая возвращает значение из внешней памяти, которая будет доступна в момент исполнения.

В целом, да, ты прав. Сейчас легче будет начать именно с этапа реализации АСТ формулы в виде бинарного дерева операций. На этом этапе ты уже сможешь выполнять АСТ как функцию чтобы сформировать значения для графика.

Как подключить библиотекту к проекту Qt Creator?

Egorithm, да, разбор мат. выражений и его перевод в дерево операций с помощью обратной польской нотации - задача тривиальная и посильная для самостоятельной реализации студентом. Почитай теорию трансляторов, это очень интересная и простая тема.
В этом моем проекте даже виртуального процессора нет, там AST напрямую выполняется. Для тебя это сейчас - самое удобное и эффективное решение. Вот точное место, где производится разбор выражений. Вот как выглядит дерево операций. Это просто бинарное дерево.