Хех мда. Неожиданно, что так из коробки нельзя

да и так способов отстрелить себе ногу в плюсах достаточно, зачем ещё и raii ломать...

auto instance = std::move(_instances.top());
_instances.pop(); // Would call the destructor :(
return instance;

дикая семантика получается, чувствуется ошибка проектирования

Понятно

Ну современные бранч предикторы - это гибридные. Т.е. набор нескольких предикторов (которые могут выдавать разный предсказания - Бранч тейкен/нот тейкен), и верхний предиктор, который ведет таблицу, кто из них попадает чаще, и на основе этого делаются выбор на последующие предсказания.
Один из основных в этой пачке это как правило PHT (запоминание паттернов - ну например на этом бранче по истории повторяется паттерн 2 разе берется, 1 не берется и тп). Т.е. если мы делаем какой то хотябы как то предсказуемый по паттерну алогритм, у нас все шансы получить попадания. А тут уже зависит от конкретной модели процессора, сколько ресурсов под него выделено (т е какой сложности паттерны он может выявлять).
Но на саомом раннем этапе, когда он только прогревается (т е  инфы нет), обычно отрабатывают более простые предикторы, типа бранч нот тейкен. Или форвард нот тейкен - бекворд тейкен, т е если идет назад то скорее всего это луп и скорее всего его покрутят, а вперед врядли будет переход.
Так вот likely/unlikly нужны для этого разогрева (когда нет еще предистории). И по большому все сводится к тому чтобы правильно расположить базовые блоки - вероятные последовательно, маловероятные выкинуть подальше. У интеловцев были на сколько знаю толи префиксы толи инструкции для подсказок предикторам, но потом отказались, по понятным причинам.

так-то можно, но только для node-based контейнеров и с 17 стандарта. метод называется extract

Для стэка нет реализации =(

я бы сказал, что суть проблемы в том, что контейнеры STL спроектированы владеть своими объектами, а ваш объект, по всей видимости, некопируемый и неперемещаемый, по крайней мере с точки зрения операции, которая вам нужна

я ими сам не пользовался, но вам, кажется, могут подойти intrusive контейнеры

Спасибо! Стэк тривиален, попробую сам реализовать его интрусивным =)

Всем привет. Я новичок в этом деле, подскажите пожалуйста, в каком направлении идти.

У меня есть open source проект, который мне нужно скомпилировать на платформы armv7 и arm64 (получить статические библиотеки)

Этот проект можно собрать через CMake, для компиляции я использую Visual Studio 2019. Всё делаю с Windows 10 x64.
Вопрос: как скомпилировать проект для armv7 и arm64?

Когда я выбираю в CMake, в поле "Optional platform for generator" платформы ARM или ARM64, возникает ошибка:

error : The OutputPath property is not set for project 'VCTargetsPath.vcxproj'.  Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='ARM64'.  You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

нужен тулчейн, который умеет собирать для arm, если собираешь для Linux но напримую из VS это будет проблематично, если для android в vs есть отдельный тип проекта для этого

Я собираю для Android.

То есть, при компиляции проекта в Visual Studio, нужно где-то выбрать тип проекта, а именно Android?

спасибо!

Понял, спасибо

у меня очень наркоманский и немного оффтопный вопрос, но вдруг у коллективного разума есть позитивный ответ на него)

можно ли пропатчить существующий виндовый экзешник, чтобы он считал будто собран с longPathAware в соответствии с докой MS о поддержке длинных путей, и пользовался свежими функциями из винапи, умеющими в пути длиной >260символов?

конкретно интересует тулчейн из 2013й студии, у которого аллергия на пути к бусту из конана, в которых по 300+ символов
(и да, я знаю про конанский short_paths)

манифест должен в ресурсах exe валяться, можно открыть софтом и отредактировать