undefined/unspecified , точки следования, короче

До сих пор не допилено в Стандарте, ИМХО. Особенно это "радует":

f(++i, ++i);       // undefined behavior until C++17, unspecified after C++17

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Ну а что не так - низзя так рисовать, низзя. Как ни назови.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

А отчего нельзя то? Если i вначале было равно 2, то первый должен пойти параметр 3, второй - 4, а потом вызов. То, что в стэк аргументы наоборот кладутся - проблема компилятора, а не синтаксиса с семантикой.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Славян @ 16.09.18, 03:48

Если i вначале было равно 2, то первый должен пойти параметр 3, второй - 4, а потом вызов.

С чего ты так решил? Написано же до C++17 это было undefined behavior, а начиная с C++17 - unspecified.
То есть раньше компилятор мог в такой ситуации делать что бог на душу положит, причем каждый раз по-разному. Теперь он должен выбрать определённое поведение (не обязательно совпадающее с твоим мнением, и даже не обязательно разумное) и следовать ему. Он может передать пару значений 3, 4, как ты думаешь, или пару значений 4, 3, если вычисляет значения параметров в обратном порядке, или значения 3, 3, если имитирует параллельное вычисление аргументов, или значения 4 и 4, если сперва выполняет оба инкремента. Более того он может заносить в стек любые два значения на выбор разработчиков.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Да начхать же как сейчас работает компилятор! Код же написан, понимается человеком весьма просто и прямо: вызвать f, у коей первый аргумент 2++ (то бишь 3), а потом снова переменная++ (то бишь 4). Всё абсолютно чётко. Нет никаких параллельных вычислений!! Как записано, так пусть и считает!

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Славян @ 16.09.18, 18:57

Всё абсолютно чётко. Нет никаких параллельных вычислений!! Как записано, так пусть и считает!

Точек следования нет + работа ведется с одной и той же областью памяти. Из за чего при оптимизации, могут возникнуть конфликты.
Для обеспечения скорости, компилятор может переупорядочивать выражения по своему усмотрению во время оптимизации программы, что приводит к тому, что у тебя даже код программы может выполнятся не в том порядке, в каком он написан тобою.
Предположим ты написал вот так:

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;
}

Или еще что то другое.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Вот второе - не должно быть. Ибо префиксный оператор должен отработать до входа в функцию.
А с первым - да, печально.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата JoeUser @ 17.09.18, 07:44

Вот второе - не должно быть. Ибо префиксный оператор должен отработать до входа в функцию.

Ну с этим возможно я погорячился, но я когда писал - старался донести саму идею, как оно вообще может преобразовать параметры функции, не особо заморачиваясь на работе конкретного оператора.

Добавлено 17.09.18, 08:11

Цитата JoeUser @ 17.09.18, 07:44

Ибо префиксный оператор должен отработать до входа в функцию.

А если учесть именно вот это, то вообще можно получить вот такой результат:

    int i = 2;
    f(++i, ++i);       // undefined behavior until C++17, unspecified after C++17
    {
      param1 = 4;
      param2 = 4;
    }

Т.е. внутри функции оба аргумента будут равны 4. Мы ведь инкрементировали одну и ту же переменную, результат посчитался до тела функции. Как результат - Славян ожидает 3, 4, а на деле имеет 4, 4 - что более логично.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Wound @ 17.09.18, 08:01

а деле имеет 4, 4 - что более логично.

По идее - да!
Сперва инкремент, и только потом передача параметров.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Wound @ 17.09.18, 06:59

Точек следования нет + работа ведется с одной и той же областью памяти. Из за чего при оптимизации, могут возникнуть конфликты.

А) Годьте! Если только на этапе оптимизации, то это проблема недоделанного оптимизатора. Пусть осторожней работает! Если же не только, то давайте смотреть этот обыденный случай.
Б) Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений), так что расскажите попроще на этом простом примере, что тут не так? Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд! Так что f(3,4);

Цитата Wound @ 17.09.18, 06:59

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

Ещё раз напомню, что шаманство компилятора при оптимизации - его изъян; пусть хуже оптимизирует, но не допускает ошибок/двузначностей.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Славян @ 17.09.18, 14:27

Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений)

Читать тут.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Это:

Цитата

Порядок вычисления операндов любого C++ оператора, включая порядок вычисления аргументов функции в выражении вызова функции, и порядок вычисления вложенных выражений внутри любого выражения, не определён

звучит как "считайте, как захочется". Чуть ли не аксиоматически=законодательно. Бред какой-то. Зачем так сделали?
Впрочем, тема обсуждения явно рвётся в холиварчики.

Добавлено 17.09.18, 15:31
А-а-а-а! Дочитал ниже, и всё становится понятно! Школота малограмотная пишет же! Так надо:

Цитата

Точка следования, это точка последовательности выполнения, в которой все побочные эффекты от вычислений, стоящих раньше в последовательности, завершены, и никакие побочные эффекты, относящиеся к последующим вычислениям, не начали выполняться.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Славян @ 17.09.18, 14:27

Я не шибко улавливаю фразу "точка следования"

Тынц. Правда, в новых стандартах, ЕМНИП, термина "точка следования" уже нет, но суть в значительной степени осталась прежней.

Цитата Славян @ 17.09.18, 14:27

так что расскажите попроще на этом простом примере, что тут не так? Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд!

Собственно, выделенное и есть "не так".

Цитата Славян @ 17.09.18, 14:27

Ещё раз напомню, что шаманство компилятора при оптимизации - его изъян; пусть хуже оптимизирует, но не допускает ошибок/двузначностей.

UB, и как следствие - оптимизации, делающиеся в предположении, что он никогда не возникает - тоже изъян, как, например, тут?

Цитата Славян @ 17.09.18, 15:26

Бред какой-то. Зачем так сделали?

Полагаю, это связано с порядком передачи аргументов в функцию - на каких-то платформах она одна, на каких-то другая, и поэтому вычисление аргументов в порядке, не совпадающем с порядком передачи, приведёт к ненужному (хоть и небольшому) оверхеду.

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Жертвовать логикой ради убирания "оверхеда"!?? Бред. Жесть. Идиотизм...

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"

Цитата Славян @ 17.09.18, 15:41

Бред. Жесть. Идиотизм...

О да, это достойный аргумент против оверхеда, особенно в контексте языков С/C++, которые как раз от оверхеда и стараются избавиться
Да и где ты логику-то увидел? По-моему "порядок вычисления аргументов не определён" не менее логично, чем "строгий порядок слева направо".

Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития"