E0070 говорит о том, что ты пробуешь пользоваться экземпляром определенного типа там, где этот тип еще не является полным.Спасибо за ответ, разобрался - нужно было llvm-strip сделать.
llvm-strip? Это поведение точно то, которое тебе нужно? Или ты просто оценил выполненную работу через размер выходного файла и успокоился на этом? Во-вторых, это проблема из-за правил поиска операторов. Они ищутся только в типах, которые участвуют в выражении, т.е. int и WidthProperty.
Ranges::FirstOrDefault::ByValue и Ranges::FirstOrDefault::ByCriteria. std::function, как ты планируешь выбирать перегрузку Ranges::FirstOrDefault?а не опасно в холодную вытягивать кабель и тем более подключать его заново?
Причем если первый был во время часовой и более сессии, то последующие могли продолжаться каждые 15 минут.
Есть предположение насчет 2х видеоадаптеров (одновременно с основной видеокартой работает встроенная от ryzen).
int numbers[rows][columns] = { {1, 2}, {5, 4}, {9, 7} };using IntColumns = int[ columns ];
using IntMatrix = IntColumns[ rows ];
IntMatrix numbers = { {1, 2}, {5, 4}, {9, 7} };numbers в обоих случаях?std::begin( numbers ); в обоих случаях и какой тип будет у этого результата? auto&& тогда уж. Действительно, зачем человеку разбираться в тонкостях и деталях, когда можно просто бахнуть обобщение и пойти дальше. :) std::function из параметров шаблона события.template< typename >
class Event;template< typename TResult, typename... TArguments >
class Event<TResult ( TArguments... )> final
{
};TResult и TArguments для определения оператора функционального вызова.std::function здесь? Для чего ты обязываешь своего пользователя инстанцировать шаблон события именно таким образом?template< typename > можно получить и тип результата функции, и типы всех ее параметров всего за одну частичную специализацию шаблона.Event никуда не годится. Он неконтролируемый вообще.void operator+=(auto&& handler)auto&& - это универсальное обобщение. Конкретный тип из него будет выведен в момент передачи аргумента._handlers.emplace_front(std::forward<decltype(handler)>(handler));THandler.template<typename TObject, typename TEventArgs> requires std::derived_from<TEventArgs, EventArgs>
void operator()(TObject* sender, const TEventArgs& e) constTHandler.std::function. Постарайся разобраться с возможностями, которые тебе открывает мой совет.
Давай коротко скажу. Даже в 25-м году пенять на неполную поддержку C++20 все еще рано.
Да, уже вышел 23-й стандарт. Да, уже готовится фиксация 26-го стандарта. И что? подавляющее большинство производственного кода как было на C++17 и ранних стандартах, так и остается.
Стимула быстро и точно вводить полную поддержку C++20 нет ни у кого из разработчиков трансляторов.
Да, вот тут у тебя отрыгнуло студию. Нет, это не показатель. Потому что в другом месте отрыгнет GCC или Clang. Или Xcode дуба даст. Или плойкин/боксовый/сычевый транслятор, которые базируются на тех же LLVM и GCC. Или андроид тебе скажет: "А мы такое не поддерживаем, держите заглушечку".
И я сейчас не занимаюсь адвокатурой проблемы в студии. Но вот о чем говорю: Ты ведь уже создал тикет в поддержке студии со своей проблемой? Создал же? Поди нет. А обсуждать проблему надо там. И людей надо туда звать, чтобы разработчики студии поскорее чесаться начали для исправления проблемы. Я так делаю с каждой проблемой поддержки стандарта, с которой сталкиваюсь. И мои тикеты довольно хорошо закрывают.