Я только что выстрелил себе в ногу

А как оно должно было заработать?

хз, может потому что компилятор оптимизировал это и оно параллельно выполняется? ну а параллельная запись может ломать прогу в таком виде, попробуй атомарный тип использовать. Больше идей пока нет :)

Скопмилировалось, но не заработало... Пащиму?

Пащиму скомпилировалось или почему не заработало?

1. Скомпилировалось, потому что дизайн C++ — говно.

2. Не заработало, потому что значение переменной a используется до инициализации. Потому что см. пункт 1.

Насколько я понял отсюда http://stackoverflow.com/questions/19586893/double-assignment-of-the-same-var... в а всё равно должно было попасть value, но у мну c++03.

У тебя ж не double assignment, а инициализация.

параллельно

ух ты.

> параллельно

Надо устроить срач про VLIW и неупорядоченное выполнение команд. :D

Почему компилер вообще не ругается на выражения типа а = а...

Ну так хочешь по-порядку - ставь memory barrier )

Почему компилер вообще не ругается на выражения типа а = а...

А почему он должен ругаться? В «a = a = 1» нет UB. А в «A a = a = 1» — есть UB. С -Wall прекрасно ругается.

Ты уже определись, у тебя присваивание или инициализация?

Почему компилер вообще не ругается на выражения типа а = а...

Потому что у тебя не компилятор (clang), а говно (gcc).

warning: variable 'a' is uninitialized when used within its own initialization [-Wuninitialized]
    A a = a = 1;
      ~   ^

очевидно конструктор MyClass(const MyClass &orig) творит чудеса при orig===*this

С -Wall прекрасно ругается

Ничего подобного, g++ 4.9.1 съел и не подавился, даже с -Wextra.

Почему компилер вообще не ругается на выражения типа а = а...

Так повелось. И в операторе присваивания надо сравнивать адрес полученного объекта с this, да.

Пользуясь случаем, передаю привет конструктору boost::optional..

У меня был пример попроще:

struct A { A( int ){} };

int main() {
    A a = a = 1;
}

П.С. «this->v = v» - убиват!

Wow! =)

Что это было? :-D

П.С. «this->v = v» - убиват!

Я не большой знаток плюсов, но осмелюсь спросить. Должно быть this.v = v, так как это класс, а не структура?

Должно быть this.v = v, так как это класс, а не структура?

Нет, this - это указатель, поэтому ->. В плюсах структура и класс это одно и то же.

Окей, тогда что не так?

Вообще говоря, должен быть прямой вызов конструктора:

class MyClass {
	public:
	int v;
	MyClass(int _v)
	: v(_v) { }
};

Но поскольку я на крестах говнокожу от силы раз в год...

Потому, что, согласно стандарту, это UB.

Встречный вопрос: нафейхоа?

Отвечу за ТС: вероятно он копипастил куски кода и не заметил двойного присваивания.

а если быть точнее в терминологии, нужно использовать список инициализации конструктора.

Для UB принято задавать другой вопрос: почему оно работает?

Отвечу за ТС: вероятно он копипастил куски кода и не заметил двойного присваивания.

Типа того )

Потому что... UB, не? Кэп Т.е. вероятность «неработания» есть, но и другое не исключено - «возможно все».

Просто когда в коде есть «i++ + ++i», то всем пофиг - ибо работает. Потом меняется версия компилятора или ещё чё-нить и возникает такой вопрос: как оно работало?

Вообще есть санитайзеры, да даже clang/gcc с -Wall, -pedantic понаходит такие UB.

Оба на!

1. Скомпилировалось, потому что дизайн C++ — говно.

Многие так думают. А ещё они считают, что С - гораздо лучше. На самом деле, эта странность С++, как и многие другие, являются наследием С.

«работает» - это частный случай UB

Многие так думают. А ещё они считают, что С - гораздо лучше. На самом деле, эта странность С++, как и многие другие, являются наследием С.

В данном случае говно унаследовано от plain C. Но это не оправдывает кресты ни в малейшей мере.

Но это не оправдывает кресты ни в малейшей мере.

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

А зачем их оправдывать? Это язык, который частично совместим с С, который вырос из него, и который не ломает совместимость при своей эволюции.

Так в чем же тут совместимость, если унаследовано UB? Ни одна корректная программа не пострадала бы от слома данной конкретной «совместимости».

Так в чем же тут совместимость, если унаследовано UB?

У UB торчат ноги из тех самых 80-х, когда компиляторы не были такими продвинутыми. Кроме того UB (не все, но многие) это просто неотъемлемая часть продвинутых ассемблеров, коими во многом С и С++ и являются, стоит вылезти из уютной песочницы - и они поджидают тебя со всех сторон.

И какой уровень продвинутости компилятора необходим, чтобы запрещать использовать объект в той же sequence point, в которой он инициализируется? Это должно элементарно делаться на уровне резолвинга имён переменных при синтаксическом анализе. (Который Си неотделим от семантического - грамматика не КС.)

И какой уровень продвинутости компилятора необходим, чтобы запрещать использовать объект в той же sequence point, в которой он инициализируется?

В 80-е при борьбе за каждый байт и такт, и при том, что обезьян к программированию допускали меньше, это были вполне допустимые упрощения, чтоб облегчить жизнь авторам компиляторов. Сейчас же никто не мешает взять clang, выставить -Werror, и спокойно заниматься делом. А насчет стандарта - если в С изменят, то и в С++ подхватят, последний не зря так называется.

«работает» - это частный случай UB

Эпичная фраза, надо запомнить.

Потому что за это должен страдать

Два чаю этому господину.

Два некрофила, ёпта...

Упс ;)

А всё ты начал.. )