Это что за жесть?

Ответ на этот вопрос настолько разжеван и попахивает троллингом, что тема скорее всего превратится в тупой срач. Тем более, в первом посте уже ответили.

romanlinux

Короч по идее ++i работает чуть быстрее чем i++, хотя эти обе операции и являются атомарными.

С каких это пор ++i и i++ являются атомарными?

Киньте в Talks тогда эту тему, он ведь для того и существует.

Киньте в Talks тогда эту тему, он ведь для того и существует.

Я бы так и сделал, да. Не я закрывал.

С каких это пор ++i и i++ являются атомарными?

Мне скорее интересно, чем он скорость мерял.

Ух только что погуглил и понял, что да инкремент и декремент не являются атомарными. Сорян за дезинфу :(

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

Потому что только они в этом деле шарят )

Про скорость это довольно давно известный кейс. Старые компиляторы генерировали больше инструкций для i++, чем для ++i, поэтому форма написания ++i в каком-нибудь for (int i = 0; i < 1000; ++i) действительно была оправдана, так как была быстрее.

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

Вот только привычки людей не изменить, поэтому программиста-деда «старой школы» всегда видно по ++i в его циклах.

Для атомарности вместо i++ надо использовать какой-нибудь __atomic_fetch_add(&i, 1, __ATOMIC_SEQ_CST).

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

Ну вот и я думаю, что о таком слышал году в 2005 где-то, наверное. Поэтому и интересно, чем он мерял скорость =)

Я же задал обычный вопрос

Нет.

С каких это пор ++i и i++ являются атомарными?

Для атомарных типов — со времён их появления.

Для атомарных типов — со времён их появления.

В каких языках вместе с атомарными типами используются постфиксные и префиксные декременты/инкременты?

C, C++.

C

Покажи.

Что показать? Язык C?

++i на атомарном типе вместо какого-нибудь g_atomic_int_add()

C11 6.5.3.1 Prefix increment and decrement operators

1 The operand of the prefix increment or decrement operator shall have atomic … type …

2 … The expression ++E is equivalent to (E+=1) …

6.5.16.2 Compound assignment

3 A compound assignment of the form E1 op = E2 is equivalent to the simple assignment expression E1 = E1 op (E2), except that the lvalue E1 is evaluated only once, and with respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation. If E1 has an atomic type, compound assignment is a read-modify-write operation with memory_order_seq_cst memory order semantics.

Ты не осилил это найти сам?

и в нормальных языках разницы между ++i и i++ нет

В нормальных языках нет ++i и i++.

Есть i += 1.

++i на атомарном типе вместо какого-нибудь g_atomic_int_add()

Так можно писать, но будет выдавать предупреждения, и возможно делает не совсем то, что нужно, так как неявно выбирается модель memory_order_seq_cst:

https://gcc.godbolt.org/z/Mv91qYdh6

https://en.cppreference.com/w/c/atomic/memory_order

++i на атомарном типе вместо какого-нибудь g_atomic_int_add()

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

Ты всегда с -Weverything компилируешь? 🤡🤡🤡

Ты всегда с -Weverything компилируешь?

Свои да. А так нет, так как многие проекты писались без этого и сейчас там будут миллиарды предупреждений. А в чём проблема? Ты компилируешь с -w ?

А так нет, так как многие проекты писались без этого и сейчас там будут миллиарды предупреждений.

Вангую, чуть менее чем полностью бесполезных.

А в чём проблема?

Нинужно. К тому же, есть только у clang.

Ты компилируешь с -w ?

-Wall -Wextra хватит всем.

Кстати «Ответ разжёван» != «Проблема решена». Я в спецразделе несколько раз попадал в темы, в которых понимание ещё не было достигнуто, а тему уже быстро закрыли для комментирования. При том, что я в этих случаях был готов предложить какие-то компромиссные формулировки.

Может, не ограничивать комментирование хотя бы в течении трёх суток, например? Дать людям возможность высказаться.

P.S. Но в данном случае, как я понимаю, речь немного про другое. Тема не из спецраздела, и её в итоге, смотрю, таки разблокировали. Правда, перемещение в Talks вызывает сильное сомнение. Можно, наверное, и в Development анонимное комментирование закрыть было?..

Это в книжке по практическому программированию на сях 97 года написано в контексте плюсов

Вот только привычки людей не изменить, поэтому программиста-деда «старой школы» всегда видно по ++i в его циклах.

Давайте вспомним про итераторы (которые могут использоваться для структур хитрее, чем массив или список) и соответствующие перегрузки ++. Это значит, что размер условного i может быть разным, его поведение при копировании (которое требуется для i++) - тоже разным. Что делает актуальным заботу о разнице быстродействия (или даже корректности применения) ++i и i++ . Кейзы, конечно, разные, но, по-моему, писать i++ в C++ - моветон и поныне.

Атомарность тут ваще побоку и не важна в контексте.

g_atomic_int_add()

Зачем на пустом месте создавать зависимость от glib? Есть встроенные функции компилятора, они те же самые в GCC и Clang.