Здравствуйте, jyuyjiyuijyu, Вы писали:
J>i = (i++,1) J>это же явно бажный код хоть вроде как и точка следования есть ? J>i = f(++i) J>тоже вроде и точка следования есть а смотрится омерзительно
J>тут везде двойная модификация но вроде как из за точек следования J>такой код законен или нет ?
Да нормально вроде.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
спасибо всем ответившим
я раньше встречал и даже сам пытался что то подобное
написать а тут еще на днях встретил подобный код в одном топике
с припиской "корректный код" нет чтобы написать это "кака хоть
и работающая"
>>> Законен. Но нужен ли ?
ну например i = f(++i) вполне часто можно
заюзать аргумент под возвращаемое значение
а i = (i++,1) это просто бред конечно же
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>ну например i = f(++i) вполне часто можно J>заюзать аргумент под возвращаемое значение
Ты имеешь в виду, что f берёт на вход неконстатнтную ссылку?
Тогда это упс, вообще-то...
J>а i = (i++,1) это просто бред конечно же
Очень зависит от типа i
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ты имеешь в виду, что f берёт на вход неконстатнтную ссылку? E>Тогда это упс, вообще-то...
да нет не по ссылке по значению ну например
int var = ...
var = f(++var)
int f(int)...
для каких то сложных типов и в голову не придет так извращаться
J>>а i = (i++,1) это просто бред конечно же E>Очень зависит от типа i
это да но я считаю если кто то перегрузит "," (оператор запятая) или "++" (инкремент) семантикой отличной от привычной то он ССЗБ например в boost::assign единственное что спасает от статуса говнокода это известность библиотеки если какой то одиночка начнет придавать "особенную" семантику привычным операциям то ничего тут хорошего для всех остальных нет
Здравствуйте, Erop, Вы писали:
J>>ну например i = f(++i) вполне часто можно J>>заюзать аргумент под возвращаемое значение
E>Ты имеешь в виду, что f берёт на вход неконстатнтную ссылку? E>Тогда это упс, вообще-то...
Это не упс! Здесь семантика прозрачна:
1) ++i
2) f() — строго после автоинкремента; и пусть оно там внутри изменяет что угодно как угодно
3) i= — строго после выхода из функции; если f поменяло i, то здесь мы запишем самую последнюю новость
Даже если f принимает по значению — всё равно есть точка следования между вычислением аргумента и входом.
К тому же f может иметь ссылку на i в обход — через глобальные переменные там... На семантику это влиять не должно.
Может ли компилятор расщепить автоинкремент на 3 под-действия:
— взятие адреса
— получение нового значения
— запись
так, что для f(int) получим, например, i=f(i+1), ++i ?
Из соображения, что бывают алиасы (ссылки в обход) — нет, нельзя.
Так что всё в порядке.
Вот с пост-инкрементом ситуация трагичнее, там действительно возникает двойная модификация, т.к. автоинкремент отложенный.
Здравствуйте, Кодт, Вы писали:
К>Может ли компилятор расщепить автоинкремент на 3 под-действия: К>- взятие адреса К>- получение нового значения К>- запись К>так, что для f(int) получим, например, i=f(i+1), ++i ? К>Из соображения, что бывают алиасы (ссылки в обход) — нет, нельзя. К>Так что всё в порядке.
Это только если не включена опция волшебная...
Ну и даже без опции у компилятора, если i -- автоматическая, есть шанс проверить, что ссылок тиаки нет и ошибиться
К>Вот с пост-инкрементом ситуация трагичнее, там действительно возникает двойная модификация, т.к. автоинкремент отложенный.
Зато он не l-value возвращает
В любом случае так писать -- искать приключений на одно место, IMHO, разумеетс...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Кодт, Вы писали:
К>Это не упс! Здесь семантика прозрачна:
Но, вообще-то, я имел в виду другой сценарий.
Если i -- POD, то можно представить себе компилятор, который возврщаемое значение передаёт через RVO, даже при присваивании.
Это, в свою очередь, обозначает, что порядок присвоения результата присваивания и изменений, которые с i делаются внутри f не совсем определён.
Конечно RVO включится уже после всего кода f, но i могут менть из какого-то scope-gard'а, например...
В общем мутное весьма такое место.
Но а амечание спасибо, я действительно очень непонятно выразился. А потом забыл о чём вообще речь.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском