Acaunt, Лучще не делать глобальных переменных без использования синглтона. Неизвестно, в каком порядке они будут созданы и удалены (зависит от порядка сборки).
И реализация внутри класса не всегда хорошо - это равнозначно объявлению inline.
std::cout реализованы ещё более "неприятным" способом с созданием кучи статических переменных, но там код очень хитрый.
floppa322, cache line разного размера всё же бывает. Если Entry больше размера cache line, то можно особо и не париться. Например, если это 64 байта, то из чего вообще Entry состоит, чтобы не только указатель на дочерний(дочерние) элементы хранить, но ещё и полезные даные были?
Возможно, я думаю не про то, но под выравниванием данных часто подразумевают выравнивание на 16 байт, чтобы всякие sse/avx инструкции смогли работать. Ну или на 4 байта для int, например.
floppa322,
Где в вопросе упоминание хотя бы архитектуры процессора, на котором будет работать? А какие данные в массиве? Entry размером намного меньше cache_line_size, что у тебя куча детей в неё умещается?
floppapa, Думаю, таких статических анализаторов не существует. std::atomic это очень частный случай использования всего одной единственной элементарной переменной. Даже две переменых через atomic уже не синхронизировать друг с другом. Анализатор, наверное, может тебе показать участок кода, к которому может быть обращение из разных потоков, но где ты, возможно, забыл сделать синхронизацию.
Если разрабатываешь программу с учётом race condition, то тебе не нужно ничего знать про модель памяти и прочие низкоуровневые дела, оставайся на уровне абстракции мьютексов и критических секций.
floppapa, Или не понимаю или не вижу смысла в вопросе. Если боишься, что будет race-condition - используешь объекты синхронизации.
Алгоритмов обхода нет, есть code coverage tool, которые проверяют, что каждая строчка кода была хоть раз выполнена. Для этого нужны горы тестов с разными входными данными. Если какие-то строки не выполнялись, то нужно написать дополнительные тесты, чтобы они покрыли этот участок кода... Но к race condition это отношения не имеет. Ведь один и тот же участок кода с одними и теми же данными может, в многопточной среде, выдавать разные результаты при неаккуратном обращении.
Не утверждаю, но лично я не верю, что можно написать комплексную многопоточную программу вообще без race condition, а значит, от объектов синхронизации не избавиться.
Evgenii, Я про это и пишу. В CameraRaw параметры задал, нажимаешь "открыть" и в фотошопе открывается уже другой файл. А исходный Raw остаётся без изменений, плюс появляется файл с теми настройками, которые в CameraRaw задавались. Если не открывать в фотошопе, то останется только Raw и файл с коррекциями.
Но вот после открытия в фото для редактирования и прочего, обратно в CameraRaw его же нельзя открыть. Только закрыть и по новой импортровать.
romaro, Не уверен. Никогда не проверял, можно ли raw фильтры использовать после того, как импортировал файл в фотошоп. Вроде после применения фильтров и нажатия "открыть" картинка в фотошопе создаётся независимая от raw файла и никак с ним не связана больше.
Если скрытый слой удалишь, файл в два раза меньше стать должен.
inq_1337, купить систему защиты, виртуализирующую код. Взламывается от почти сразу. Прост опо наличию пиратских версий программ можно понять, что 100% защшиты нет и, кому нужно, тот взломает.
none7, Вот только тут не функции, а методы класса, да ещё и с наследованием. Тут просто указатель не получится получить, так что вся задумка ТС изначально ошибочна.
rPman, если бы была проблема в json, то и все другие числа были бы неправильны. И не только у одного пользователя. Сервер это windows приложение, смотреть нечего.
PageUp, ну они находятся в разрешённой стране и их по IP не банят. но при подтверждени по паспорту и физическому адресу всё-арвн овед выяснят, где ты находишься. Да и банально 25 долларов сейчас проблематично заплатить
Ternick, вот такой прототип у фукнции: ostream& write (const char* s, streamsize n);
причём s это не строка, а любой массив байт, длиной n. Просто приводишь тип указателя на структуру к указателю на строку и записываешь. Так же делаешь при чтении.
Но делать так возможно только для POD структур, т.е. чтобы небыло никаких выделений памяти, указателей и подобного.
ubf.write( (const char*)&fstr, sizeof(fstr) );
Но так можно делать только для POD типов и лучше "дамп памяти" не сохранять. В конкретно этом случае проблемы будут только если изменится выравнивание полей структуры и байты сдвинутся, тогда может оказаться, что сохранено одно число байт, а структура уже занимает больше байт.
toster_bodnar, ну тут скорее вопрос, почему Container не шаблонный класс? Из контейнера надо получать Base и из Base уже получать USED_TYPE. А Base получать или по индексу, еслитам есть индексируемый список типов, либо прям полностью указывать тип.
Александр Ананьев, Да это понятно, но там нужно делать релизацию на WinAPI с сообщениями очереди сообщений Windows. Это выглядит костылями. Я был уверен, что Qt даёт это сделать своими средствами, без платформенно-зависимых костылей.
И реализация внутри класса не всегда хорошо - это равнозначно объявлению inline.
std::cout реализованы ещё более "неприятным" способом с созданием кучи статических переменных, но там код очень хитрый.