ща попробуем #define ACE_NO_INLINE значит...

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

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

надо будет перепроверить может починилось в рц3

короче как-то пока сыровато чтобы свитчится

ну мне грустно, я согласен, но вдруг, есть что-то лучше...

Есть 11,14 и в некоторых случаях 17 :)

Есть идеи как красиво и без макросни сделать is_complete<T> на с++03? https://stackoverflow.com/questions/1625105/how-to-write-is-complete-template - хотелось бы альтернативу

https://engineering.instagram.com/open-sourcing-a-10x-reduction-in-apache-cassandra-tail-latency-d64f86b43589

в чем тогда прикол

можно в двух словах?)

Не видел примеров, когда сильно

Блин, я тут достиг полного просветления по поводу модели future/promises

все используют О2

Я и дома и на всех работах -O3 собственно к черту полумеры

Надеюсь на gcc? Там список багнутых эвристик длиной в километр

Gcc притом юзался по долгу службы и gnu arm none и gnu arm linux и под х86. Полет нормальный. Хотелось бы конечно шланг, но ни.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Known to work: 4.4.5, 4.8.3, 4.9.0 Known to fail: 4.7.2, 4.7.4, 4.8.2

Мы же сейчас о разнице О3 О2 и полумерах :)

В O3 больше багнутых эвристик)

Ок, мне везло. но они есть везде, вопрос в вероятности проявления.

потому что любая специализация по is_complete крайне рискует словить ODR violation

Да, в это и упираемся. Но очень хочется, чтобы не как статик ассерт было)

а почему хз

А что вы хотите сделать?

потому что O3 это нестабильные оптимизации которые могут ухудшить код

Почему-то в документации gcc таких слов нет

Почему-то в документации gcc таких слов нет

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

Но прохождение этого места с полным и неполным типом уже ODR violation если проверка зависит от полноты типа

Стремно там в общем, в любом случае(

Это чтобы идиоты всё собирали с O3 и страдали, Столлман любит шутки

Блин, я тут достиг полного просветления по поводу модели future/promises

Короче, после долгой медитации я понял, что принципиально речь идет о следующей математической модели. Есть некоторая once_callable_function f и набор ее параметров A, B, C, ... Функция f указывается сразу, каждый аргумент может быть записан не более одного раза Если все аргументы f записаны, то инструкция выполнить f передается исполнителю. Существует два принципиальных способа записи аргумента: отзываемая и неотзываемая. Запись аргумента обязательна. В случае отзываемой записи если аргумент записан, а потом отозван, то если исполнитель еще не начал вызов f то вызов f не произойдет.

Короче, после долгой медитации я понял, что принципиально речь идет о следующей математической модели. Есть некоторая once_callable_function f и набор ее параметров A, B, C, ... Функция f указывается сразу, каждый аргумент может быть записан не более одного раза Если все аргументы f записаны, то инструкция выполнить f передается исполнителю. Существует два принципиальных способа записи аргумента: отзываемая и неотзываемая. Запись аргумента обязательна. В случае отзываемой записи если аргумент записан, а потом отозван, то если исполнитель еще не начал вызов f то вызов f не произойдет.