(или N/4 интов или еще любая поебень)

когда ты кусок памяти так интерпретируешь то intel endianness превратит твой тип в фарш

Для всех типов, у которых размер не больше 8 байт, ага

ты сказал POD и array-of-PODs, нет?

ты сказал POD и array-of-PODs, нет?

Да. std::array<double, 5> как влезет в 8 байт?

Да. std::array<double, 5> как влезет в 8 байт?

ну сверху обертка еще три строки чтобы выбрать нужный элемент

ну вот вывод на будущее: у тебя UB, у меня работает)

Я буду знать, какие тонкости могут возникнуть при реализации всяких variant, как вообще reinterpret_cast может выстрелить, и что говорить компилятору, чтобы всё было ок

ну сверху обертка еще три строки чтобы выбрать нужный элемент

http://ru.cppreference.com/w/cpp/utility/bitset ну и еще немного методов

Да. std::array<double, 5> как влезет в 8 байт?

у битсета есть «

Хотя ощущение такое, что и правда легче написать обёртку, которая держит референс на объект и даёт интерфейс к битам

http://ru.cppreference.com/w/cpp/utility/bitset ну и еще немного методов

тебе нужны они все, включая to_string? Формулируй яснее тогда

потому что я понял что нужные операции с битами, т.е. set, reset, flip

тебе нужны они все, включая to_string? Формулируй яснее тогда

Я сразу сформулировал. Мне нужна обертка для работа с битами

to_string - конечно. Для отладки не помешает

to_string - конечно. Для отладки не помешает

а тип в котором данные лежат распечатать нельзя?

а тип в котором данные лежат распечатать нельзя?

По битам тоже нужно

to_string - конечно. Для отладки не помешает

и вообще, ты что, дебажишь принтами?

и вообще, ты что, дебажишь принтами?

Не придирайся. Логгирование никто не отменял

и вообще, ты что, дебажишь принтами?

а что ты имеешь против дебага принтфами??

а что ты имеешь против дебага принтфами??

gdb

gdb

Удачи отлаживать многопоточный код ?

который взаимодействует с системными процессами, в которые не залезешь дебаггером

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

anecdotal evidence?

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

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

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

У Евгения Охотникова как раз в блоге есть запись на эту тему. Printf vs debugger

принтфы рулят. можно ещё пописать своих принтфов. например, (раз уж у вас тут у всех c++) для сложных выражений очень полезна функция типа template<typename t>t debug_print(const char*s,t x){std::cerr<<s<<": "<<x<<"\n";return x;}. можно использовать в середине любого выражения, обернув то, что хочется вывести в debug_print(...). bonus points -- #define debug_print(x) debug_print(#x,x)

Принтфы запросто ломают воспроизведение бага.

А вот assert-ы куда менее инвазивны

извини, а чем assert отличается от printf(int)?

тем что printf запустит огромную машинерию про преобразования твоего инта в строку, потом запись в консоль и пошло поехало. Огромные задержки. Многопоточные баги запросто перестанут воспроизводиться. А ассёрт, это просто проверка условия и если фейл, то сразу INT 3

Гораздо менее инвазивно, я же сказал.

надо чтобы на гонках не работало и тогда отлаживаться принтами ок

int 3 -- то есть у тебя к процессу подключён дебаггер. и что там про инвазивность?

и чепятать надо в другом треде

тогда и гонка ок воспроизводится

int 3 -- то есть у тебя к процессу подключён дебаггер. и что там про инвазивность?

у меня на винде есть ::DebugBreak, и отладчик можно на лету подключить.

у меня нет винды ;D

И вообще в целом на винде гораздо комфортнее отлаживаться в студийном дебагере, по сравнению с gdb

На линуксах я бы еще подумал. Но всё равно, я предпочитаю отладку assert-ами

в силайоне же вроде бы приличное что-то для отладки наворотили?

в силайоне же вроде бы приличное что-то для отладки наворотили?

ложь

не понял, при чём тут винда.

в силайоне же вроде бы приличное что-то для отладки наворотили?

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

в силайоне же вроде бы приличное что-то для отладки наворотили?

там и сейчас всё отвратно

в силайоне же вроде бы приличное что-то для отладки наворотили?

с VS не сравнимо имхо

с VS не сравнимо имхо

+

не понял, при чём тут винда.

При том, что у студии отличный отладчик.

ну у меня в нем и проект-то не собирался ;D

может через пару лет, если тщательно репортить и фичреквестить

и у этого отличного отладчика какой-то отличный от других оверхед?

принты ван лав

и у этого отличного отладчика какой-то отличный от других оверхед?

Ты сейчас обсуждаешь printf vs debug или ищешь очередной повод прикопаться к так называемым проблемам со студией? :D

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

У студийного отладчика есть один очень крупный плюс — он не тормозит на ооочень больших файлах.

и у этого отличного отладчика какой-то отличный от других оверхед?

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

по моим ощущениям, мы обсуждаем (зачем-то, мне эта тема не то чтобы сильно интересна) сравнительный оверхед printf и подключённого дебаггера

С gdb приходится изгаляться.

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

докинь плашку

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

так себе аргумент

докинь плашку

не помогает, линкеру разрядности не хватает)

какое отношение символы имеют к отладчику?

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

или у тебя там файл подкачки тоже заканчивается?

какое отношение символы имеют к отладчику?

типа собрать в дебаге не может

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

а?

по моим ощущениям, мы обсуждаем (зачем-то, мне эта тема не то чтобы сильно интересна) сравнительный оверхед printf и подключённого дебаггера

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

не помогает, линкеру разрядности не хватает)

в студии 32-битный линкер? ?

по-моему, мы разные вещи называем "подключением"

ERROR: S client not available

в студии 32-битный линкер? ?

got no idea about vs. а у нас есть реальные платформы, где надо собирать 32 тулчейном и с дебажными символами там oom

Ага помню, у кого-то пробелмы были собрать 65536 объектников :D

чтобы по int 3 произошло что-то хорошее, твой процесс уже должен выполняться под управлением отладчика

Ага помню, у кого-то пробелмы были собрать 65536 объектников :D

у меня была на винде с мингв.

чтобы по int 3 произошло что-то хорошее, твой процесс уже должен выполняться под управлением отладчика

Господи, ты понимаешь, что int 3 это для красного словца.

Естественно там не int 3

>тем что printf запустит огромную машинерию про преобразования твоего инта в строку, потом запись в консоль и пошло поехало. Огромные задержки. Многопоточные баги запросто перестанут воспроизводиться. А ассёрт, это просто проверка условия и если фейл, то сразу break

break куда?

если отладчика нет

хинт: перед printf можно тоже проверить условие, если хочется

Не уверен как на линуксе, но на винде можно на лету подключить отладчик

как ты догадываешься, это очень даже не бесплатно

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

Печать на экран — это всегда недостаточно. Мне надо посмотреть на стек, мне надо посмотреть в переменные.

Одним лишь принтом получить информацию о стейте программы — тяжело.

печатай стектрейсы

Не уверен как на линуксе, но на винде можно на лету подключить отладчик

Attach to process?

Вместе с @berkus разобрались в тонкостях стандартной библиотеки и выявили суть бага :) и дело не в оптимизациях компилятора, а в конкретной реализации bitset с некоторыми хитростями. За объяснение ему огромное спасибо

на линуксе тоже можно

напомню то утверждение, которое мы обсуждаем

Принтфы запросто ломают воспроизведение бага.

А вот assert-ы куда менее инвазивны

печатай стектрейсы

Об этом и речь, что если я буду печатать стектрейсы — я поменяю профиль нагрузки.

Вместе с @berkus разобрались в тонкостях стандартной библиотеки и выявили суть бага :) и дело не в оптимизациях компилятора, а в конкретной реализации bitset с некоторыми хитростями. За объяснение ему огромное спасибо

:)

а для стектрейсов нам подходит... Boost.Stacktrace :)

а для стектрейсов нам подходит... Boost.Stacktrace :)

Отлично! у меня приложение без 3rd party, давайте в него еще буст притараканим для отладки :D

Отлично! у меня приложение без 3rd party, давайте в него еще буст притараканим для отладки :D

ну кто ж виноват ?

надо было сразу буст использовать!

а когда в c++ добавят до кучи гуй, приложения на этом ужасе тоже будут "без 3rd party"?

надо было сразу буст использовать!

надо мем сделать наподобие "Надо было ставить Linux" ?

а когда в c++ добавят до кучи гуй, приложения на этом ужасе тоже будут "без 3rd party"?

жди cairo

зачем мне его ждать?