Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.141.31.240] |
|
Страницы: (5) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
До сих пор не допилено в Стандарте, ИМХО. Особенно это "радует":
f(++i, ++i); // undefined behavior until C++17, unspecified after C++17 Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#2
,
|
|
|
Ну а что не так - низзя так рисовать, низзя. Как ни назови.
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#3
,
|
|
|
А отчего нельзя то? Если i вначале было равно 2, то первый должен пойти параметр 3, второй - 4, а потом вызов. То, что в стэк аргументы наоборот кладутся - проблема компилятора, а не синтаксиса с семантикой.
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#4
,
|
|
|
Цитата Славян @ С чего ты так решил? Написано же до C++17 это было undefined behavior, а начиная с C++17 - unspecified.Если i вначале было равно 2, то первый должен пойти параметр 3, второй - 4, а потом вызов. То есть раньше компилятор мог в такой ситуации делать что бог на душу положит, причем каждый раз по-разному. Теперь он должен выбрать определённое поведение (не обязательно совпадающее с твоим мнением, и даже не обязательно разумное) и следовать ему. Он может передать пару значений 3, 4, как ты думаешь, или пару значений 4, 3, если вычисляет значения параметров в обратном порядке, или значения 3, 3, если имитирует параллельное вычисление аргументов, или значения 4 и 4, если сперва выполняет оба инкремента. Более того он может заносить в стек любые два значения на выбор разработчиков. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#5
,
|
|
|
Да начхать же как сейчас работает компилятор! Код же написан, понимается человеком весьма просто и прямо: вызвать f, у коей первый аргумент 2++ (то бишь 3), а потом снова переменная++ (то бишь 4). Всё абсолютно чётко. Нет никаких параллельных вычислений!! Как записано, так пусть и считает!
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#6
,
|
|
|
Цитата Славян @ Всё абсолютно чётко. Нет никаких параллельных вычислений!! Как записано, так пусть и считает! Точек следования нет + работа ведется с одной и той же областью памяти. Из за чего при оптимизации, могут возникнуть конфликты. Для обеспечения скорости, компилятор может переупорядочивать выражения по своему усмотрению во время оптимизации программы, что приводит к тому, что у тебя даже код программы может выполнятся не в том порядке, в каком он написан тобою. Предположим ты написал вот так: int i = 2; f(++i, ++i); // undefined behavior until C++17, unspecified after C++17 И ожидаешь внутри функции получить первый аргумент равным - 3, и второй аргумент равным - 4. Но так как в этом выражении нет точек следования, компилятор в праве переупорядочить по своему усмотрению данную инструкцию, и ты можешь получить что то типа того: f(i=4, i=3) Или например вообще вот такое: f(i+1, i+1) { i += 2; } Или еще что то другое. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#7
,
|
|
|
Вот второе - не должно быть. Ибо префиксный оператор должен отработать до входа в функцию.
А с первым - да, печально. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#8
,
|
|
|
Цитата JoeUser @ Вот второе - не должно быть. Ибо префиксный оператор должен отработать до входа в функцию. Ну с этим возможно я погорячился, но я когда писал - старался донести саму идею, как оно вообще может преобразовать параметры функции, не особо заморачиваясь на работе конкретного оператора. Добавлено Цитата JoeUser @ Ибо префиксный оператор должен отработать до входа в функцию. А если учесть именно вот это, то вообще можно получить вот такой результат: int i = 2; f(++i, ++i); // undefined behavior until C++17, unspecified after C++17 { param1 = 4; param2 = 4; } Т.е. внутри функции оба аргумента будут равны 4. Мы ведь инкрементировали одну и ту же переменную, результат посчитался до тела функции. Как результат - Славян ожидает 3, 4, а на деле имеет 4, 4 - что более логично. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#9
,
|
|
|
Цитата Wound @ а деле имеет 4, 4 - что более логично. По идее - да! Сперва инкремент, и только потом передача параметров. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#10
,
|
|
|
Цитата Wound @ А) Годьте! Если только на этапе оптимизации, то это проблема недоделанного оптимизатора. Пусть осторожней работает! Если же не только, то давайте смотреть этот обыденный случай.Точек следования нет + работа ведется с одной и той же областью памяти. Из за чего при оптимизации, могут возникнуть конфликты. Б) Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений), так что расскажите попроще на этом простом примере, что тут не так? Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд! Так что f(3,4); Цитата Wound @ Ещё раз напомню, что шаманство компилятора при оптимизации - его изъян; пусть хуже оптимизирует, но не допускает ошибок/двузначностей.Для обеспечения скорости, компилятор может переупорядочивать выражения по своему усмотрению во время оптимизации программы, что приводит к тому, что у тебя даже код программы может выполнятся не в том порядке, в каком он написан тобою. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#11
,
|
|
|
Цитата Славян @ Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений) Читать тут. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#12
,
|
|
|
Это:
Цитата звучит как "считайте, как захочется". Чуть ли не аксиоматически=законодательно. Бред какой-то. Зачем так сделали?Порядок вычисления операндов любого C++ оператора, включая порядок вычисления аргументов функции в выражении вызова функции, и порядок вычисления вложенных выражений внутри любого выражения, не определён Впрочем, тема обсуждения явно рвётся в холиварчики. Добавлено А-а-а-а! Дочитал ниже, и всё становится понятно! Школота малограмотная пишет же! Так надо: Цитата Точка следования, это точка последовательности выполнения, в которой все побочные эффекты от вычислений, стоящих раньше в последовательности, завершены, и никакие побочные эффекты, относящиеся к последующим вычислениям, не начали выполняться. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#13
,
|
|
|
Цитата Славян @ Я не шибко улавливаю фразу "точка следования" Тынц. Правда, в новых стандартах, ЕМНИП, термина "точка следования" уже нет, но суть в значительной степени осталась прежней. Цитата Славян @ Собственно, выделенное и есть "не так". так что расскажите попроще на этом простом примере, что тут не так? Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд! Цитата Славян @ Ещё раз напомню, что шаманство компилятора при оптимизации - его изъян; пусть хуже оптимизирует, но не допускает ошибок/двузначностей. UB, и как следствие - оптимизации, делающиеся в предположении, что он никогда не возникает - тоже изъян, как, например, тут? Цитата Славян @ Бред какой-то. Зачем так сделали? Полагаю, это связано с порядком передачи аргументов в функцию - на каких-то платформах она одна, на каких-то другая, и поэтому вычисление аргументов в порядке, не совпадающем с порядком передачи, приведёт к ненужному (хоть и небольшому) оверхеду. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#14
,
|
|
|
Жертвовать логикой ради убирания "оверхеда"!?? Бред. Жесть. Идиотизм...
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#15
,
|
|
|
Цитата Славян @ Бред. Жесть. Идиотизм... О да, это достойный аргумент против оверхеда, особенно в контексте языков С/C++, которые как раз от оверхеда и стараются избавиться Да и где ты логику-то увидел? По-моему "порядок вычисления аргументов не определён" не менее логично, чем "строгий порядок слева направо". Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |