Size: a a a

2020 March 07

DS

Dmitry Sokolov in pro.cxx
Pepe 🐸
Ладно уже это обсуждали, так что подытожу: формально УБ но скорее всего работать будет

главное не попасть в ситуацию когда ты расчитываешь что считываемое значение обновится через другой пойнтер. Компайлер может просто проигнорить
Я дважды делаю punning, в push циклом перенос из T* в atomic<T>*. Всё работает, но была надежда что не на UB :)
источник

AB

Artöm Bakri Al-Sarmini in pro.cxx
Dmitry Sokolov
Я дважды делаю punning, в push циклом перенос из T* в atomic<T>*. Всё работает, но была надежда что не на UB :)
Сильно, учитывая что атомик не факт что standard layout
источник

DS

Dmitry Sokolov in pro.cxx
Типа как в пропозале distributed counters, но со структурами, struct broker:basic_broker{T a,b,c} => struct  metric: basic_metric{atomic<T> counters [3];}
источник

DS

Dmitry Sokolov in pro.cxx
Через cast к dummy broker/metric с единичными элементами перенос между массивами T* и atomic<T>*.
источник

FS

Flower Surgeon in pro.cxx
только сейчас заметил, что в C++20 появились семафоры и синк-барьеры
источник

FS

Flower Surgeon in pro.cxx
мечты сбываются
источник

VO

Vyacheslav Olkhovchenkov in pro.cxx
Pepe 🐸
Ладно уже это обсуждали, так что подытожу: формально УБ но скорее всего работать будет

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

DS

Dmitry Sokolov in pro.cxx
Artöm Bakri Al-Sarmini
Сильно, учитывая что атомик не факт что standard layout
cppreference говорит для integral факт.
источник

DS

Dmitry Sokolov in pro.cxx
Pepe 🐸
самое смешное вот:

It has been suggested that the aliasing rules should be extended to permit an object of an enumeration with a fixed underlying type to alias an object with that underlying type.

то есть сейчас даже такое нельзя
Это кстати не смешно, это очень круто и правильно.
источник

DS

Dmitry Sokolov in pro.cxx
Эх, похоже всё потому что нет определенного layout'а. Конечно layoutas хорошо, но лучше бы в любом месте структуры разрешить для последовательности T a,b,c конвертируемость &a в T* -> [a,b,c]... Тем более это скорее всего не расходится ни с одной реализацией.
источник

DS

Dmitry Sokolov in pro.cxx
И кстати я чот подумал, со strict aliasing'ом то похоже проблем как раз нет, я ж работаю с вложенным массивом, да, через unrelated родительский тип, но чтение/запись по честным T*...
источник

ПК

Побитый Кирпич in pro.cxx
Till Schneider
Я к тому, что вот в gcc вроде как в реализации offsetof разыменовывают нулевой указатель =) то есть это не особый показатель, что раз они так делают, то так делать можно
Всё правильно. Теоретически, компилятор может детектить код из стандартной библиотеки и строить какие нибудь оптимизации на основе гарантий стандарта.
источник

AT

Anatoly Tomilov in pro.cxx
Код:
 
std::vector<int> seq = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
std::shuffle(std::begin(seq), std::end(seq), std::mt19937{});
код для разных компиляторов и стандартных библиотек будет давать одну и ту последовательность?
Интересует "одинаковость" устройства std::shuffle.
источник

AT

Anatoly Tomilov in pro.cxx
Почему здесь написано "Possible output", текст в части "Notes" в русской и английской версиях не совпадает. В русской заметка касается устаревшего random_shuffle, в английской — похоже, что всех.
источник

AT

Anatoly Tomilov in pro.cxx
свой что ли писать? нужна воспроизводимость
источник

P

Pepe 🐸 in pro.cxx
Anatoly Tomilov
Код:
 
std::vector<int> seq = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
std::shuffle(std::begin(seq), std::end(seq), std::mt19937{});
код для разных компиляторов и стандартных библиотек будет давать одну и ту последовательность?
Интересует "одинаковость" устройства std::shuffle.
нет думаю не обязательно. Есть какие то общие требования не более.  Так же как и hash везде свой
источник

AP

Antony Polukhin in pro.cxx
Как вам идея сделать так, чтобы аггрегаты можно было использовать вместо std::tuple ?

https://apolukhin.github.io/papers/Aggregates%20are%20named%20tuples.html
источник

P

Pepe 🐸 in pro.cxx
Pepe 🐸
нет думаю не обязательно. Есть какие то общие требования не более.  Так же как и hash везде свой
Note that the implementation is not dictated by the standard, so even if you use exactly the same RandomFunc or URBG you may get different results with different standard library implementations.

на спп реф
источник

PK

Pavel Kazakov in pro.cxx
Antony Polukhin
Как вам идея сделать так, чтобы аггрегаты можно было использовать вместо std::tuple ?

https://apolukhin.github.io/papers/Aggregates%20are%20named%20tuples.html
Круто
источник

AT

Anatoly Tomilov in pro.cxx
Antony Polukhin
Как вам идея сделать так, чтобы аггрегаты можно было использовать вместо std::tuple ?

https://apolukhin.github.io/papers/Aggregates%20are%20named%20tuples.html
А какова судьба n4235. Я здесь спрашивал что-то подобное, мне ответили, что функционал какой-то планируется, который может быть полезен.
источник