Хранить коллекцию в куче нормально значмт
Deleted Account
Aidar
Нет
Deleted Account
лан разыминую
Aidar
Это же лучше чем беги энд брать
Aidar
Бегин*
Aidar
Одинаково
Aidar
Даже быстрее
cyberzx 🇷🇺
что значит "такого не было"...
Значит не меняли 98 на 11-ый по дефолту. Сразу на 14-ый
Dmitry
Значит не меняли 98 на 11-ый по дефолту. Сразу на 14-ый
а clang с какой версии, не подскажешь?
Berkus
> Clang 3.3 and later implement all of the ISO C++ 2011 standard.
Berkus
> Download LLVM 4.0.1
текущая версия
Dmitry
http://clang.llvm.org/cxx_status.html здесь все подробно по версиям
здесь вроде нет, с какой версии стандарт 11 или 14 поумолчанию включен
Dmitry
By default, Clang builds C++ code according to the C++98 standard, with many C++11 features accepted as extensions.
Dmitry
Berkus
нет, написано конкретно
Berkus
если не указывать -std=c++11 то он использует c++98
Dmitry
значит только gcc переключился по дифолту
Berkus
ну им видимо на backwards-compat насрать
Dmitry
https://wandbox.org/permlink/NImikJ0Ntj7aDNx8
Dmitry
собирает, но варнингует
Dmitry
не. не собирает
Berkus
чего я тебе и сказал
Arseny
т.е. если threadC вмешается между acquire и relaxed потока threadB, то увидет ли поток threadB изменения threadC
О каких изменениях речь? Тут читается и изменяется одна переменная, код будет и с relaxed работать.
Grigory
например такой сценарий - threadA сделал compare_exchange_strong(release), затем threadB успешно сделал compare_exchange_strong(acquire) в этот момент эти 2 потока синхронизировались, затем threadC сделал compare_exchange_strong(release), после чего threadB возобновил работу и сделал compare_exchange_strong(relaxed). Вот в этот момент надо понимать увидит ли поток B изменения потока C или только свои последние изменения?
Grigory
т.е. как я понимаю при таком сценарии в атомике будет 134, но на x86_64 я получаю 1324
Arseny
В любом случае будет какая-то перестановка 1 2 3 4, где 3 идет до 4.
Arseny
Даже если все операции relaxed
Grigory
это понятно, т.к. они выполняются в одном потоке
Arseny
В трех же потоках. (я смотрю код на ideone)
Arseny
Смысл release/acquire часто в следующем.
Один поток делает какие-то изменения в памяти, а затем сохраняет в атомарную переменную значение с release семантикой.
Второй поток читает эту атомарную переменную с acquire семантикой. Он может прочитать и старое значение и новое. Но если он прочитал новое значение, то гарантируется, что он увидит и все остальные изменения, которые записал первый поток. Если он прочитал старое значение, то не гарантируется ничего.
Arseny
Я к тому, что я не очень понимаю, как можно говорить о видимости изменений, когда у нас нету других переменных кроме одного атомика.
Grigory
Хочешь сказать, что все изменения атомика во всех доступных потоках вне зависимости от упорядочивания будут видны без дополнительной синхронизации?
Danylo
ну так на то он и атомик, не?
Berkus
это только в x86 по-моему, есть гораздо более relaxed memory models
Grigory
power?
Berkus
на альфе вообще хуй ты чего увидишь без acquire-release
Berkus
павер вроде тоже более релаксед, даже арм
Grigory
ну так на то он и атомик, не?
атомик гарантируют только атомарность операций над ними, но "правила" синхронизации программист задает сам
Aidar
consume deprecetad я слышал
Aidar
А шаредмьютекс кстати в си++17 нсть
Aidar
Есть*
Arseny
Хочешь сказать, что все изменения атомика во всех доступных потоках вне зависимости от упорядочивания будут видны без дополнительной синхронизации?
На x86 acquire release есть всегда, чтобы он работал нужно только чтобы сам компилятор операции не переставлял.
На arm aquire release уже обязателен.
Но это все не имеет отношения к атомарным операциям по одному адресу.
Aidar
Насрать
Aidar
Это частный случай то что в х86 неявно онр
Aidar
Мы говорим о модели си++, она требует больших усилий для валидности программы чем ваш х86
Aidar
Смысл у этих штук в упорядочивании ниже и вышележащих доступов к памяти
Aidar
Этот пример минимальный я попросил написать чтобы понять что в каком потоке не более. Вопрос был более развернут
Grigory
Не, ну если утвержение @arseny о том, что операции над атомиками глобальны относительно всех потоков, то это и есть ответ на мой вопрос )
Grigory
и вопрос об упорядочивании операций уже становится другим вопросом
Aidar
Вопрос с последовательности доступа к памяти
Aidar
Ты спросил увидит ли изменения
Grigory
да, изменения над атомиком
Aidar
Одной то увидит тыж его ждешь
Aidar
А остальную помять не увидит
Grigory
остальная не интересна
Grigory
ладно, спасибо за помощь
Aidar
Может и не увидит если не успеет
Arseny
Почти всегда как раз остальная память и интересна. Нельзя что-то класть в стек и читать из него без release acquire семантики.
Grigory
в моем случае (не в том коде, который я привел) как раз хватает первого acquire, дальнейшей синхронизации не нужно. В реальном примере запись в атомик c семантикой relaxed происходит не в цикле и после acquire. И если запись relaxed не прошла, то запись acquire делается снова
Arseny
А где этот код в книжке?
Grigory
7.2.5 Применение модели памяти к свободному от блокировок стеку
Grigory
листинг 7.12
Ioann_
Ребят, привет. Вопрос такой : а как вы используя qt боретесь с различными разрешениями дисплеев ?
Ivan
Berkus
Ребят, привет. Вопрос такой : а как вы используя qt боретесь с различными разрешениями дисплеев ?
смысле "боретесь"
Ivan
Qt
https://t.me/qt_chat
Ioann_
У вас специальная фабрика - создающая разные объекты класса UI, или же просто загрузка xml файлов с нужным текстом для разных разрешений ?
Berkus
Berkus
неужели ты в 320х200 впихиваешь уи там?
Ioann_
Ну да - в том плане, что значения длин разные
Ioann_
Ну хотелось бы, чтобы на разных разрешения выглядело одинаково.
Deleted Account
Ну да - в том плане, что значения длин разные
там в qss есть разверы в пунктах а не пикселах