если тебе именно как кодец выглядит не нравится

напиши функцию в которой будешь делать логирование и вызывай ее?

логирование разношерстное, мне перегрузки для всех объектов писать?

А почему бы и да?

А почему бы и да?

LOG_ADD_IF( detailedLog ) << L"Найдено " << contragents.Size() << L" закрепленных контрагентов"; вот как все такие кейсы учесть?

Всем привет! Нетиповый, может быть, вопрос для этого чата, но что есть. Делаю "бенчмарк" (просто много однотипных операций с разными типами, условия лабки, чего поделать) в C++. Компилирую g++ с -O1. Гоняю под Linux 64 bit. В моменте с действиями над float и double есть "просто деление на i", "просто умножение на i" и "деление, а потом умножение на i". Соответственно, в первом варианте получается inf (по идее) в результате, во втором 0, а в третьем начальное число. Теперь проблема: в случае компиляции с m64 всё более-менее предсказуемо ("деление + умножение" ~~ "просто деление" + "просто умножение" по времени, ну чуть дольше). В варианте же с m32 получаю внезапно катастрофу в случае умножения (т.е. там где будет inf). Добавляю скрины вывода: UPD скрины не могу, сейчас вставлю текст

https://1drv.ms/f/s!Ai564hcpa7h8iKxl3laMzhs8wI7A4A - там скрины

Кто-то знает, почему такой резкий просад? Может ли быть косяк в реализации действий с inf при запуске 32-битного приложения под 64-битной системой?

Компилятор не будет оптимизировать "деление, а потом умножение на i" в "начальное число" без -ffast-math И лучше бенчмаркать на -O2

Вот тут можно смотреть, во что компилятор превращает код: https://godbolt.org/ (идеальная штука, для отчётов по лабам )

Компилятор не будет оптимизировать "деление, а потом умножение на i" в "начальное число" без -ffast-math И лучше бенчмаркать на -O2

В том-то и дело, что мне не нужно "оптимизировать". Мне нужно именно продуктивность выполнения операций мерять. И как раз-таки мне не нужно, чтоб он убирал "деление и умножение" (не уверен, что он имеет на это право в случае дробных чисел, но ладно). Мне интересно, почему такая проблема при игре с inf

Можете код скинуть, а то я текстовое описание плохо понимаю :(

В том-то и дело, что мне не нужно "оптимизировать". Мне нужно именно продуктивность выполнения операций мерять. И как раз-таки мне не нужно, чтоб он убирал "деление и умножение" (не уверен, что он имеет на это право в случае дробных чисел, но ладно). Мне интересно, почему такая проблема при игре с inf

он имеет на это право только с -ffast-math флагом

Можете код скинуть, а то я текстовое описание плохо понимаю :(

https://pastebin.com/uXnpUWuS - извиняюсь за код до мейна (да и за весь код, наверное), сам мейн с 56-ой строчки

https://pastebin.com/uXnpUWuS - извиняюсь за код до мейна (да и за весь код, наверное), сам мейн с 56-ой строчки

Вот тут что-то показывается https://godbolt.org/z/sqBsMs На 32х битах трогается память, на 64х - всё в регистрах + в зависимости от железа, инструкции fild и fmul быдыт выполняться медленнее чем их аналоги на 64 битах

Вот тут что-то показывается https://godbolt.org/z/sqBsMs На 32х битах трогается память, на 64х - всё в регистрах + в зависимости от железа, инструкции fild и fmul быдыт выполняться медленнее чем их аналоги на 64 битах

Ого, спасибо большое!

Есть вопрос, существует ли механизм отмотки стека, на подобии того что используется в setjmp (возможно что-то подобное используется в бустовых корутинах)?

Ребят, привет.

Есть вопрос, существует ли механизм отмотки стека, на подобии того что используется в setjmp (возможно что-то подобное используется в бустовых корутинах)?

Есть несколько разной степени переносимости. Самое портабельное - это то что используется в бустовых корутинах. А именно - кинуть исключение.

Есть вопрос, существует ли механизм отмотки стека, на подобии того что используется в setjmp (возможно что-то подобное используется в бустовых корутинах)?

Нелокальный возврат ещё это называют...

Есть несколько разной степени переносимости. Самое портабельное - это то что используется в бустовых корутинах. А именно - кинуть исключение.

Просто от них то и пытаемся избавится

А чем не нравится?

А чем не нравится?

Андройд с ними при Оz корупитит стек

О_О

А санитайзер не ругается на приложение?

Андройд с ними при Оz корупитит стек

Что за Oz такой?

Что за Oz такой?

https://github.com/android-ndk/ndk/issues/573

А санитайзер не ругается на приложение?

Не пробовал

А сам Oz это что?

оптимизация размера

Но там не только в ней проблема, в целом у андройда exception криво притянут за уши

Но там не только в ней проблема, в целом у андройда exception криво притянут за уши

Ну... Ну не верю пока

> оптимизация размера > андроид

Ну... Ну не верю пока

по issues который скинул погуляй по связаным задачам

Ты просто более генерально заходишь...

Привет, можете подсказать причины, из-за которых последняя строчка может приводить к крашу? ATargetMissle* Missle = world->SpawnActor<ATargetMissle>(MissleToSpawn,GetActorLocation(),rotator,spawnParams); if(Missle) { Missle->Target = NearestObject; }

а уверены, что в случае "НЕУСПЕХА" вызова world->SpawnActor<ATargetMissle> вы возвращаете nullptr?

Эта строчка работает нормально и всегда создаёт объект, в краше указывает на ошибку доступа к памяти

Эта строчка работает нормально и всегда создаёт объект, в краше указывает на ошибку доступа к памяти

ну вижу причины для падения если в Missle лежит мусор

он может лежать там, если SpawnActor вернул мусор

он может лежать там, если SpawnActor вернул мусор

Хорошо, спасибо.

Привет, можете подсказать причины, из-за которых последняя строчка может приводить к крашу? ATargetMissle* Missle = world->SpawnActor<ATargetMissle>(MissleToSpawn,GetActorLocation(),rotator,spawnParams); if(Missle) { Missle->Target = NearestObject; }

В operator= еще стоит посмотреть

Target это публичная переменная типа ссылки на объект, наследующий AActor

AActor& Target;?

если так, то попытка ->Target = NearestObject приведёт к тому, что существующий объект, на который сейчас указывает таргет, попытается переинициализироваться значениями из NearestObject, вместо того чтобы таргет начал указывать на NearestObject

Есть стойкое ощущение, что в Missle мусор. внутри SpawnActor какой нибудь: Pointer *prt; .... return ptr; и на отладочке там красивый nullptr, а в релизе ад какой-нибудь

Привет, можете подсказать причины, из-за которых последняя строчка может приводить к крашу? ATargetMissle* Missle = world->SpawnActor<ATargetMissle>(MissleToSpawn,GetActorLocation(),rotator,spawnParams); if(Missle) { Missle->Target = NearestObject; }

Missile указывает на недопустимый объект.

Всем привет! Кто-нибудь знает почему у std::merge в компаратор сначала передаётся *iter2, а потом *iter1 ? см. возможную реализацию https://en.cppreference.com/w/cpp/algorithm/merge

Всем привет! Кто-нибудь знает почему у std::merge в компаратор сначала передаётся *iter2, а потом *iter1 ? см. возможную реализацию https://en.cppreference.com/w/cpp/algorithm/merge

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

4465 template <class _Compare, class _InputIterator1, class _InputIterator2, class _OutputIterator> 4466 _OutputIterator 4467 __merge(_InputIterator1 __first1, _InputIterator1 __last1, 4468 _InputIterator2 __first2, _InputIterator2 __last2, _OutputIterator __result, _Compare __comp) 4469 { 4470 for (; __first1 != __last1; ++__result) 4471 { 4472 if (__first2 == __last2) 4473 return _VSTD::copy(__first1, __last1, __result); 4474 if (__comp(*__first2, *__first1)) 4475 { 4476 *__result = *__first2; 4477 ++__first2; 4478 } 4479 else 4480 { 4481 *__result = *__first1; 4482 ++__first1; 4483 } 4484 } 4485 return _VSTD::copy(__first2, __last2, __result); 4486 } 4474 строчка почему не обратный порядок аргументов

при этом на cppreference про компаратор написано: The signature of the comparison function should be equivalent to the following: bool cmp(const Type1 &a, const Type2 &b); The types Type1 and Type2 must be such that objects of types InputIt1 and InputIt2 can be dereferenced and then implicitly converted to both Type1 and Type2

4465 template <class _Compare, class _InputIterator1, class _InputIterator2, class _OutputIterator> 4466 _OutputIterator 4467 __merge(_InputIterator1 __first1, _InputIterator1 __last1, 4468 _InputIterator2 __first2, _InputIterator2 __last2, _OutputIterator __result, _Compare __comp) 4469 { 4470 for (; __first1 != __last1; ++__result) 4471 { 4472 if (__first2 == __last2) 4473 return _VSTD::copy(__first1, __last1, __result); 4474 if (__comp(*__first2, *__first1)) 4475 { 4476 *__result = *__first2; 4477 ++__first2; 4478 } 4479 else 4480 { 4481 *__result = *__first1; 4482 ++__first1; 4483 } 4484 } 4485 return _VSTD::copy(__first2, __last2, __result); 4486 } 4474 строчка почему не обратный порядок аргументов

Наверно по алгоритму там надо ("больше либо равно"), а компаратор работает как "строго меньше"

ну сделали бы !comp(...)

вопрос в том, почему на cppreference сигнатура одна, а на деле ожидается другая

ну сделали бы !comp(...)

Неверно

ну, !(меньше) это тоже самое что (больше или равно)

А, туплю

Так на такт менее эффективно)

Нет, так нарушается порядок For equivalent elements in the original two ranges, the elements from the first range (preserving their original order) precede the elements from the second range (preserving their original order).

при этом на cppreference про компаратор написано: The signature of the comparison function should be equivalent to the following: bool cmp(const Type1 &a, const Type2 &b); The types Type1 and Type2 must be such that objects of types InputIt1 and InputIt2 can be dereferenced and then implicitly converted to both Type1 and Type2

Они могут как угодно вертеть компаратором, если он непротиворечивый - все ок

вот, цитата с cppreference: the signature of the comparison function should be equivalent to the following: bool cmp(const Type1 &a, const Type2 &b); The types Type1 and Type2 must be such that objects of types InputIt1 and InputIt2 can be dereferenced and then implicitly converted to both Type1 and Type2. ​

первым идёт тип InputIt1, вторым InputIt2