call_info или exec_info вполне отличные варианты

ну я просто пытаюсь понять, если юзер создаст самостоятельно какой-нибудь exec_point ep(my_func), что полезного сможет он из него извлечь

Например вот так может быть полезно: #include <signal.h> // ::signal #include <stacktrace> #include <iostream> // std::cout void print_signal_handler() { typedef void(*function_t)(int); function_t old_signal_function = ::signal(SIGSEGV, SIG_DFL); std::function_info f(old_signal_function); std::cout << f << std::endl; }

function_info норм, callable_info более обще

callable звучит как контракт, как признак

callable звучит как контракт, как признак

нечто, что можно вызвать

нечто, что можно вызвать

callable может быть слишком общим... кажется, что оно подразумевает возможность конструировать подобный класс из объектов с перегруженным operator()

callable может быть слишком общим... кажется, что оно подразумевает возможность конструировать подобный класс из объектов с перегруженным operator()

info отсекает эту возможность

ну я к тому что exec_point получается вообще мимо, потому что в примере выше ep не несёт ровно никакой информации о выполнении, стеках, фреймах и так далее

и соответственно, exec_point - это скорее уж именно информация о стеке и фрейме, которую можно запихнуть в func_prettifier fp(ep) и получить string fp::name() и typename fp::signature

callable может быть слишком общим... кажется, что оно подразумевает возможность конструировать подобный класс из объектов с перегруженным operator()

а нельзя под крыло std::function попроситься? ) внутренним классом

и соответственно, exec_point - это скорее уж именно информация о стеке и фрейме, которую можно запихнуть в func_prettifier fp(ep) и получить string fp::name() и typename fp::signature

так весь stacktrace про это. говорю же, надо от stacktrace отказываться в пользу чего-то более общего

в любом случае, от function отходить нельзя, там и name, source_name, source_line, тогда function_info

в любом случае, от function отходить нельзя, там и name, source_name, source_line, тогда function_info

+1

function_desc ?

function_desc ?

ооо!.. что-то в этом есть

тут могут у людей возникнуть неприятные ассоциации с std::type_info, который в отличие от subj * не копируемый * не дофолтно конструкируемый * name() возвращает const char*, а не std::string

А по-моему как раз хорошо, что имена похожие.

Думаю остановиться на function_info + переименовать name() в pretty_name() В качестве второго варианта предложу комитету function_desc + name()

Всем большое спасибо за идеи!

справки ради, а почему name() возвращает const char* а не string?

и почему у type_info всё наоборот

function_info не может возвращать char*, так как имя функции может быть где-то очень далеко (например в pdb сервере, в отдельном процессе) type_info yt возвращает string потому что legacy (разработчики компиляторов не хотели, чтобы класс, тесно связанный с ядром языка, зависил от библиотекчного класса строки)

function_def(inition)

function_def_info

function_symbol

https://msdn.microsoft.com/ru-ru/office/dd145217(v=vs.90) мб? хотя не..

Безопасно ли из разных потоков читать одну область памяти не изменяя её?

Безопасно ли из разных потоков читать одну область памяти не изменяя её?

да

Безопасно (если действительно нет изменений

Спасибо

просто дело в том что синхронизация там будет в момент создания потока ну или пропихивания таски

Ну это перфоманс, тут вопрос был про безопасность

Безопасно ли из разных потоков читать одну область памяти не изменяя её?

Что ты под этим понимаешь?

а во, живём $ ./arm-hisiv300-linux-uclibcgnueabi-g++ -E -dM foo.h | grep __SIZE_TYPE__ #define __SIZE_TYPE__ unsigned int

г-спода, я тут как-то спрашивал как выдрать из гццшки builtin defines, был найден ^ способ, а вот как из него выдрать builtin functions? clang code model в какой-то момент начал плеваться на ненайденные функции вида m128 __builtin_ia32_psubb128(m128 a, m128 b), в потрохах аля #include <random> -> gccrandom.h -> ia32random.h в попытках борьбы не придумал ничего лучше чем в конфиг проекта сунуть прорву #define __builtin_ia32_psubb128(...) {} чтобы успокоить анализатор (нет, на компиляцию это не влияет) проблема ушла но осадочек остался, потому что вместо дефайнов можно было бы сунуть нормальные сигнатуры, их просто было слишком дохрена и разных, чтобы нормально обработать

г-спода, я тут как-то спрашивал как выдрать из гццшки builtin defines, был найден ^ способ, а вот как из него выдрать builtin functions? clang code model в какой-то момент начал плеваться на ненайденные функции вида m128 __builtin_ia32_psubb128(m128 a, m128 b), в потрохах аля #include <random> -> gccrandom.h -> ia32random.h в попытках борьбы не придумал ничего лучше чем в конфиг проекта сунуть прорву #define __builtin_ia32_psubb128(...) {} чтобы успокоить анализатор (нет, на компиляцию это не влияет) проблема ушла но осадочек остался, потому что вместо дефайнов можно было бы сунуть нормальные сигнатуры, их просто было слишком дохрена и разных, чтобы нормально обработать

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

Зачем что-то "выдирать"?

Разве что, сигнатуры завернуты в препроцессорную магию, но их тоже можно получить, если остановиться на препроцессинге

Ну это перфоманс, тут вопрос был про безопасность

это консистентность

Зачем что-то "выдирать"?

затем, что у моего qt creator большие проблемы с разбором проекта, который генерится самопальными скриптами в формате proj.files, proj.includes, proj.creator, proj.config, и в который гцц и системные либы тянутся из левого chroot в прошлый раз, он например не мог распарсить typedef __SIZE_TYPE size_t в недрах stdlib, пока я ему не сказал что #define __SIZE_TYPE unsigned int, и ещё пачку дефайнов выдернутых из gcc -E -dM

Что ты под этим понимаешь?

То что написано

Много потоков будут читать из одной области

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

а вот за указание на доку компилятора спасибо, нашёл https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/X86-Built-in-Functions.html#X86-Built-in-Functions , попробую воспользоваться в следующий раз

Много потоков будут читать из одной области

Ну и что? Эта операция безопасна в принципе, если ты "владеешь" этой памятью. Формулируйте точнее

Ты даже можешь читать и писать. Это тоже безопасно, в каком-то смысле

Вот в память другого процесса нельзя просто так ходить. А между тредами одного приложения невозбраняется

@Devel29A Да, мне надо узнать про потоки, как я и написал, не про процессы

@Devel29A Да, мне надо узнать про потоки, как я и написал, не про процессы

Если всё-таки речь о thread safety то она имеет место быть рассмотрена в каждом конкретном случае

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

Или вообще освободил

Если всё-таки речь о thread safety то она имеет место быть рассмотрена в каждом конкретном случае

Есть 3хмерный массив со структурами, у структуры одно из полей bool active Все структуры, у которых actice == true делятся между потоками для расчётов Результаты расчётов структуры зависят от состояния смежный структур

Если тебя просто интересует шаринг памяти между тредами, то это безопасно. Сегментейген фолт не получишь. Ну, есть ещё тредлокал сторадж

Есть 3хмерный массив со структурами, у структуры одно из полей bool active Все структуры, у которых actice == true делятся между потоками для расчётов Результаты расчётов структуры зависят от состояния смежный структур

Все зависит от того, как это в коде смотрится :)

Я подозреваю, что там ещё и векторизация будет

Помимо разбивки на треды

г-спода, я тут как-то спрашивал как выдрать из гццшки builtin defines, был найден ^ способ, а вот как из него выдрать builtin functions? clang code model в какой-то момент начал плеваться на ненайденные функции вида m128 __builtin_ia32_psubb128(m128 a, m128 b), в потрохах аля #include <random> -> gccrandom.h -> ia32random.h в попытках борьбы не придумал ничего лучше чем в конфиг проекта сунуть прорву #define __builtin_ia32_psubb128(...) {} чтобы успокоить анализатор (нет, на компиляцию это не влияет) проблема ушла но осадочек остался, потому что вместо дефайнов можно было бы сунуть нормальные сигнатуры, их просто было слишком дохрена и разных, чтобы нормально обработать

Такая же херня с армовскими интрисиксами Так и не победил Если решишь проблему - напиши плиз сюда

Такая же херня с армовскими интрисиксами Так и не победил Если решишь проблему - напиши плиз сюда

Мне помогла куча дефайнов наподобие процитированного

Ехх

Ехх

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

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

Там список слишком большой, что б для каждого сигнатуру прописывать + poky обновит тулчейн и всё заново придётся переgbkbdfnm

перепиливать*

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

У меня была проблема, что кланговская модель не парсила этот тулчейн нормально из-за того, что нужные флаги компилятора находились в переменных окружения решилось просто подпихиванием нужного флага в codegen flags для компилятора В итоге вот только с этими builtin осталась проблема, но её флаги не решают

у меня кланг громче всего ругался на конкретный файл, в котором использовались практически все "недостающие" команды, решалось это примерно так: скопипастить файл в вим :g!/__builtin//d удалить все строчки не содержащие __builtin :%s/.*__builtin/__builtin/g удалить всё перед __builtin, потому что там всякие return, =, касты и т.п. :%s/ \+(.*).*$//g удалить все скобки вместе с содержимым и лидирующими пробелами, чтобы оставить только :g/^$/d удалить все пустые строчки :%sort u оставить только уникальные имена глазами удостовериться что всё выглядит одинаково :%s/^\(.*\)$/#define \1 (...) {}/g обернуть все оставшиеся имена __builtin в вариадик-дефайны, ибо где-то просто вызывалась __builtin(args), а где-то нужно было вернуть её результат после этого в список не попадала буквально пара функций, ну и ещё пару кланг ВНЕЗАПНО откуда-то подцеплял и жаловался на "redefining built-in function x"

Кстати, а как сейчас дела с clang под виндой? Я о том, насколько он стал юзабелен как компилятор для проектов? Избавился ли он от костылей и зависимостей для работы нативно под виндой?

что, скотина, характерно: теперь если весь этот дефайновый ад из конфига удалить, то всё равно ни на что не ругается больше :(

прочитал "что, скотина" и замахнулся уж было :)))

свят-свят-свят, хорошо хоть не стал четырёхбуквенный оригинал оставлять, тогда наверное вообще без раздумий прилетело бы :D

//кек, буквально вчера эту вакансию видел в спаме на хабре

@itrecruiter1 вакансии через @AlexFails в отдельный канал, пожалуйста

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

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

ничего не долетает

Плюсач

Кароч, тут такая беда. как правильно сконвертировать long int в unsigned long long ?

static_cast<unsigned long long?x) ?

Кароч, тут такая беда. как правильно сконвертировать long int в unsigned long long ?

что хочешь получить?

в общем, пытаюсь взаимодействовать по sip с firefox webrtc

у меня есть число long int, которое надо перевести в unsigned long long так, чтобы оно не стало больше, чем 1 « 63 - 1

static_cast -1 в unsigned это unspecified вроде

так что это надо вроде делать явно