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++, которые как раз от оверхеда и стараются избавиться
Да и где ты логику-то увидел? По-моему "порядок вычисления аргументов не определён" не менее логично, чем "строгий порядок слева направо".

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

Ну хочется прогерам жить так - пущай, чёрт с вами. Впрочем, думается мне, что с годами всё же будут стараться избавиться от неопределённостей.

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

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

А) Годьте! Если только на этапе оптимизации, то это проблема недоделанного оптимизатора. Пусть осторожней работает! Если же не только, то давайте смотреть этот обыденный случай.

Так он и так работает осторожно, это кто то просто не понимает ЯП до конца.

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

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

Не так тут то, что запятая в аргументах функций - не является точкой следования, только в выражениях. Соответственно компилятор - в праве переупорядочивать операции по своему усмотрению. И это с точки зрения языка - правильно.
Другими словами тут есть неоднозначности, на которые выше уже указал тебе.
Ты ждешь 3,4 - а почему не 4,4?

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

Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд! Так что f(3,4);

Так ты передаешь в эти аргументы одну и ту же область памяти - при чем два раза инкрементировав ее содержимое, и на выходе ожидаешь почему то 3,4.

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

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

Это такое соглашения в ЯП, а не ошибка оптимизации.

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

Цитата Wound @ 17.09.18, 16:05

Ты ждешь 3,4 - а почему не 4,4?

Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично.

Цитата Wound @ 17.09.18, 16:05

Так ты передаешь в эти аргументы одну и ту же область памяти - при чем два раза инкрементировав ее содержимое, и на выходе ожидаешь почему то 3,4.

Нет никаких "двух раз"! Есть вызов, с двумя аргументами. Рубим первый, а потом - второй. Как и пишем!!! Всё железобетонно!

Не понимаю ваших аргументов, абсолютно.
Причём, очень хочу понять, честно, но никак не вижу.

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

Цитата Славян @ 17.09.18, 16:10

Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично.

Где логично то? По твоему после передачи первого аргумента в функцию - должно выполнится тело функции?

Бред какой то. Ты передаешь одну переменную, не две. А одну. Куда компилятор запишет значение 3, а куда 4?

Цитата Славян @ 17.09.18, 16:10

Нет никаких "двух раз"! Есть вызов, с двумя аргументами. Рубим первый, а потом - второй. Как и пишем!!! Всё железобетонно!

Как это нет? У тебя переменная 1 - i, куда будут сохранены значения двух аргументов по твоему?

Цитата Славян @ 17.09.18, 16:10

Не понимаю ваших аргументов, абсолютно.
Причём, очень хочу понять, честно, но никак не вижу.

Что не понятного?
Сначало вычисляются значения переменных, а уж потом идет передача в функцию. А ты как хотел? Сначало передать, а потом вычислить? Ну тогда логичнее ожидать 2,2, а не 3,4.

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

Цитата Wound @ 17.09.18, 16:18

Ты передаешь одну переменную, не две.

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

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

Цитата Wound @ 17.09.18, 16:18

Где логично то? По твоему после передачи первого аргумента в функцию - должно выполниться тело функции?

Нет такого по-моему! Я такого не вещал. Сначала - аргументы, потом - тело, всё по порядку!

Цитата Wound @ 17.09.18, 16:18

Ты передаешь одну переменную, не две. А одну. Куда компилятор запишет значение 3, а куда 4?

Я не передаю переменную!!! Я передаю число=значение, посредством изменения такой-то переменной! Запишет он 3 в переменную, значение коей надо передать в первом аргументе, а потом запишет в неё 4, что и надо послать вторым. Как он выпутается - его грабли, а не мои, писателя проги!!!

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

Цитата Славян @ 17.09.18, 16:10

Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично.

Вот у тебя есть переменная X
И есть функция Sum, принимающаяя 2 аргумента -> int Sum(int x, int y)
Изначально X = 2
передай в эту функцию одну переменную X, в два аргумента так, чтобы внутри функции первый был равен 3, а второй 4, без использования других токенов.
Вызов функции должен быть такой:

int X = 2;
//! Тут твой код
Sum(X, X);

Напиши код на месте коментария, чтоб внутри функции один аргумент был равен 3, а второй 4.

Добавлено 17.09.18, 16:32

Цитата Славян @ 17.09.18, 16:25

Нет такого по-моему! Я такого не вещал. Сначала - аргументы, потом - тело, всё по порядку!

Пиши вот так:

Func(i+1, i+2)

И будет тебе счастье.

Цитата Славян @ 17.09.18, 16:25

Я не передаю переменную!!! Я передаю число=значение,

Нет, ты передаешь конкретный идентификатор к которому применяется инкремент - это есть сайд эффект. Вот если бы ты просто передавал переменную, без ее изменения, вопросов бы не возникало.

Цитата Славян @ 17.09.18, 16:25

Я передаю число=значение, посредством изменения такой-то переменной!

Представь что вместо числа, у тебя std::string, а вместо ++ - у тебя replace который изменяет вызывающий его объект, два раза причем.

Цитата Славян @ 17.09.18, 16:25

Запишет он 3 в переменную, значение коей надо передать в первом аргументе, а потом запишет в неё 4, что и надо послать вторым. Как он выпутается - его грабли, а не мои, писателя проги!!!

Ээээ... В какую переменную?

Добавлено 17.09.18, 16:35
1 + 2 * 6 = 9
Все логично. Пущай там математики покумекают, и сделают мне чтобы было так, как я хочу

Добавлено 17.09.18, 16:40

Цитата OpenGL @ 17.09.18, 16:23

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

Да я понимаю о чем он. Просто пытаюсь в рамках текущего стандарта пояснить ему что происходит.

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

Цитата Wound @ 17.09.18, 16:25

Напиши код на месте коментария, чтоб внутри функции один аргумент был равен 3, а второй 4.

Идеал выглядел бы как-то так:

int X = 2;
//! Тут мой код:
// 1.Создаём область памяти в две ячейки, к коим никто не может обратиться (дабы не ломали, ...);
// 2.Пишем в каждую ячейку: ++X в первую, ++X во вторую (получили пару (3;4);
// 3.Кормим функции Sum значения из ячеек. Бинго.
Sum(еда1, еда2);

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

Цитата Славян @ 17.09.18, 16:40

int X = 2;
//! Тут мой код:
// 1.Создаём область памяти в две ячейки, к коим никто не может обратиться (дабы не ломали, ...);
// 2.Пишем в каждую ячейку: ++X в первую, ++X во вторую (получили пару (3;4);
// 3.Кормим функции Sum значения из ячеек. Бинго.
Sum(еда1, еда2);

А как быть с указателями и ссылочными типами данных? Как быть со сложными объектами? Ты понимаешь что передавать int по ссылке не имеет смысла, так как все сведетя к указателю, кой и есть по сути int ?
И в чем тогда будет преимущество С++ перед другими ЯП?

Добавлено 17.09.18, 16:47
Т.е. передача любого объекта в функцию - делает копию объекта, в итоге как передавать массив из 1000000 элементов?

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

Ага! Т.е. выход нашёлся, но теперь начались наезды на какие-то другие последствия? Давайте всё же разбирать тогда каждый, а то ваш способ заваливать горой вопросов, конечно, неплох, но труден для развёрнутых ответов.

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

А я, пожалуй, дровишек подкину ...

Один:

Скрытый текст

int func(int a, int b) {
  return a+b;    
}
    
int main() {
  int i = 0;  
  func(++i,++i);
  return 0;
}

ему соответствует:

func(int, int):                              # @func(int, int)
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], edi
        mov     dword ptr [rbp - 8], esi
        mov     esi, dword ptr [rbp - 4]
        add     esi, dword ptr [rbp - 8]
        mov     eax, esi
        pop     rbp
        ret
main:                                   # @main
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     dword ptr [rbp - 4], 0
        mov     dword ptr [rbp - 8], 0
        mov     eax, dword ptr [rbp - 8]
        add     eax, 1
        mov     dword ptr [rbp - 8], eax
        mov     ecx, dword ptr [rbp - 8]
        add     ecx, 1
        mov     dword ptr [rbp - 8], ecx
        mov     edi, eax
        mov     esi, ecx
        call    func(int, int)
        xor     ecx, ecx
        mov     dword ptr [rbp - 12], eax # 4-byte Spill
        mov     eax, ecx
        add     rsp, 16
        pop     rbp
        ret

Два:

Скрытый текст

int func(int &a, int &b) {
  return a+b;    
}
    
int main() {
  int i = 0;  
  func(++i,++i);
  return 0;
}

ему соответствует:

func(int&, int&):                            # @func(int&, int&)
        push    rbp
        mov     rbp, rsp
        mov     qword ptr [rbp - 8], rdi
        mov     qword ptr [rbp - 16], rsi
        mov     rsi, qword ptr [rbp - 8]
        mov     eax, dword ptr [rsi]
        mov     rsi, qword ptr [rbp - 16]
        add     eax, dword ptr [rsi]
        pop     rbp
        ret
main:                                   # @main
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        lea     rax, [rbp - 8]
        mov     dword ptr [rbp - 4], 0
        mov     dword ptr [rbp - 8], 0
        mov     ecx, dword ptr [rbp - 8]
        add     ecx, 1
        mov     dword ptr [rbp - 8], ecx
        mov     ecx, dword ptr [rbp - 8]
        add     ecx, 1
        mov     dword ptr [rbp - 8], ecx
        mov     rdi, rax
        mov     rsi, rax
        call    func(int&, int&)
        xor     ecx, ecx
        mov     dword ptr [rbp - 12], eax # 4-byte Spill
        mov     eax, ecx
        add     rsp, 16
        pop     rbp
        ret

Сравнение:


Господа, к барьеру!

PS: Компилятор clang 6.0.0 (x86_64)

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

Цитата Славян @ 17.09.18, 16:50

Ага! Т.е. выход нашёлся, но теперь начались наезды на какие-то другие последствия?

В смысле выход нашелся? Не нашелся ведь. Твоя проблема в том, что ты рассматриваешь только int'ы, а другие типы данных не рассматриваешь. Я тебя специально подтолкнул к тому, чтобы ты написал - как по твоему это должно работать. Ты и написал по твоему мнению решение, которое должно работать для int'ов, но упускаешь из виду другие типы данных + другую семантику передачи параметров в функции. А ведь это примитивный случай.
Плюс ко всему, аргументы функций - не зависят друг от друга, соответственно могут быть вычисленны вообще паралельно друг от друга. Если тебе нужен строгий порядок выполнения - переходи на Java/C#, там порядок строго определен, ну и с указателями нет мороки тоже.

Сообщения были разделены в тему "undefined/unspecified"

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

Цитата Wound @ 17.09.18, 17:42

В смысле выход нашелся? Не нашелся ведь.

Нашёлся, - я ж показал правильный ход построения вызова функции.

Цитата Wound @ 17.09.18, 17:42

Твоя проблема в том, что ты рассматриваешь только int'ы, а другие типы данных не рассматриваешь.

Нет у меня проблем, не сочиняйте.

Цитата Wound @ 17.09.18, 17:42

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

Так в том же и фишка, что на предложенный вариант - предложил решение. А вы сразу задались вопросом про общий случай. Да чёрт его знает как в общем, это проблема компилятора, но в этом конкретном частном - всё должно решиться без ваших UB.

Цитата Wound @ 17.09.18, 17:42

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

Может выполнить компилер параллельно, не впадая в депрессию UB, - пусть делает; а не может - пусть делает по порядку аргументов. Всё норм!

Добавлено 17.09.18, 18:23

Цитата JoeUser @ 17.09.18, 17:32

А я, пожалуй, дровишек подкину ...
Один:

Ну здесь Clang справился на отлично (не считая того, что он забил на i).

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

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

Нашёлся, - я ж показал правильный ход построения вызова функции.

С чего это он правильный? Потому что тебе так кажется?

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

Нет у меня проблем, не сочиняйте.

Ну как нет, если есть. Тебе же не понятно почему вот так, а не вод эдак.

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

Так в том же и фишка, что на предложенный вариант - предложил решение.

Так не предложил же. Ты исказил условие данной тебе задачи. Т.е. ты подогнал задачу под свой ответ. Я то тебе другой вопрос задал.

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

А вы сразу задались вопросом про общий случай. Да чёрт его знает как в общем, это проблема компилятора, но в этом конкретном частном - всё должно решиться без ваших UB.

Нет не должно. Тут уж тебе нужно выбрать - не нравится инструмент берешь тот, который тебе по душе. А ты предлагаешь убить быстродействие в угоду каких то своих хотелок. Почему бы тогда не взять соответствующий для этого инструмент?

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

Может выполнить компилер параллельно, не впадая в депрессию UB, - пусть делает; а не может - пусть делает по порядку аргументов. Всё норм!

Так порядок вычисления аргументов не определен.
Ты странный какой то. Ей богу.

Цитата Wound @ 17.09.18, 18:29

С чего это он правильный? Потому что тебе так кажется?

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

Цитата Wound @ 17.09.18, 18:29

А ты предлагаешь убить быстродействие в угоду каких то своих хотелок.

Неправда. Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода. Можно сделать быстро - делайте, нельзя - начхать, не судьба.

Цитата Wound @ 17.09.18, 18:29

Почему бы тогда не взять соответствующий для этого инструмент?

Так инструменты ж создаются для той или иной записи выражений, языка расчёта. Си (Си++) был выбран таким, пусть теперь ворочается на своих, местами трудных, тропинках. А не так что: ничего не знаем - выполняем как захотим.

Цитата Wound @ 17.09.18, 18:29

Так порядок вычисления аргументов не определен.

Да я понял. Не понял только отчего забили.

Цитата Славян @ 17.09.18, 18:40

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

Чем интересно ты аргументировал? Или твоя хотелка по умолчанию является неоспоримым аргументом? Почему это параллельно сделать нельзя?
Расскажи пожайлуйста, почему в выражении:
X = 3 + 5 + 6 +7

Я не могу паралельно вычислить сумму 3 + 5 и 6 + 7, а потом сложить это все воедино? Или почему я не могу сложить 3 + 7 и 5 + 6, а потом сложить все это воедино? Математика мне это вроде как позволяет, утверждая что от перемены мест слагаемых - сумма не меняется. А ты какой аргумент привел? Потому что тебе слево на право удобнее читать? А арабам с права на лево удобнее, и что теперь?

Цитата Славян @ 17.09.18, 18:40

Неправда. Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода. Можно сделать быстро - делайте, нельзя - начхать, не судьба.

Эта запись кода абсолютно понятна и естественна, она не понятно только лишь тебе.

Цитата Славян @ 17.09.18, 18:40

Так инструменты ж создаются для той или иной записи выражений, языка расчёта. Си (Си++) был выбран таким, пусть теперь ворочается на своих, местами трудных, тропинках. А не так что: ничего не знаем - выполняем как захотим.

И? Он ничего не нарушает, это просто ты не хочешь понять как это работает.

Цитата Славян @ 17.09.18, 18:40

Да я понял. Не понял только отчего забили.

На что забили? Во первых есть разные соглашения вызовов, аргументы могут передаватся и с права на лево, и с лева на право, и в каком то другом порядке, оптимизатор может оптимизировать выражение так, чтобы работало быстрее, некоторые конструкции могут быть вычислены паралельно и не зависимо друг от друга, потому как от перестановки мест слагаемых сумма не меняется.

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

Цитата Wound @ 17.09.18, 18:53

Расскажи пожайлуйста, почему в выражении:
X = 3 + 5 + 6 +7

Я не могу паралельно вычислить сумму 3 + 5 и 6 + 7, а потом сложить это все воедино?

Потому что так уcтроены законы математики/логики.

Цитата Wound @ 17.09.18, 18:53

Или почему я не могу сложить 3 + 7 и 5 + 6, а потом сложить все это воедино?

См. выше.

Цитата Wound @ 17.09.18, 18:53

Математика мне это вроде как позволяет, утверждая что от перемены мест слагаемых - сумма не меняется.

Именно, что "вроде". В действительности - нет, не позволяет. Просто она намекает (даже прямо говорит), что вы получите одинаковый ответ и при других ваших сложениях. Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7.

Цитата Wound @ 17.09.18, 18:53

А ты какой аргумент привел? Потому что тебе слево на право удобнее читать?

Да. Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем.

Цитата Wound @ 17.09.18, 18:53

А арабам с права на лево удобнее, и что теперь?

Они вынуждены пойти лесом. На всех не угодишь. Мы ж не пишем:

int главное(int argc, char *argv[])

Цитата Славян @ 17.09.18, 18:40

Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода.

На практике это вовсе не будет естественным. По факту, единственный вариант, где последовательное вычисление удобно и активно используется на практике это булевские выражения вида if(index < size && list[index] != "Славян). Реальный же пример, когда однострочник будет удобнее и нагляднее явного вычисления параментров в нужном порядке, мне в голову не приходит.

Цитата Славян @ 17.09.18, 19:04

Потому что так уcтроены законы математики/логики.

Значит ли это что ты сам ответил на свой вопрос?

Цитата Славян @ 17.09.18, 19:04

Именно, что "вроде". В действительности - нет, не позволяет. Просто она намекает (даже прямо говорит), что вы получите одинаковый ответ и при других ваших сложениях.

Позволяет, более того это основные законы арифметики.

Цитата Славян @ 17.09.18, 19:04

Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7.

Где написано что я обязан считать подряд? Вот например тут - https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%...%B8%D1%81%D1%8C считают вообще в другом порядке, чем ты.

Цитата Славян @ 17.09.18, 19:04

Да. Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем.

Причем тут англо-саксы? Я просто пытаюсь показать на сколько твоя фраза бессмыслена. Что ж у англосаксов тогда стек идет не с лева на право?

Цитата Славян @ 17.09.18, 19:04

Они вынуждены пойти лесом. На всех не угодишь. Мы ж не пишем:

А кто тебе запрещает так писать?

Сообщение отредактировано: Wound - 17.09.18, 19:23

Цитата Славян @ 17.09.18, 19:04

Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем.

Язык (Си) был придуман высокоуровневым на замену низкоуровневому ассемблеру. Остальное от лукавого, Славян.

Цитата Славян @ 17.09.18, 19:04

Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7.

Никто ничего никому не обязан, ровно потому, что это разрешено самой математикой. Если тебя в школе учителя учили иначе, они были неправы или лентяи.
Но дело даже не в этом. Берём низкоуровневый ассемблер, и пишем фрагмент кода, вычисляющий сие. Я волен делать любые мыслимые модификации алгоритма, которые не приводят к искажению результата. Иначе на кой хрен я вообще взял в руки ассемблер, если не для вот этого самого вот: взять под свой полный контроль самые глубины вот этой вот кучки атомов кремния с вкраплениями примесей? Почему тогда в высокоуровневом Си ты хочешь запретить делать это компилятору, который пришёл на замену вот как раз этому самому низкоуровневому ассемблеру? На кой хрен мне вообще язык, который не выполняет задач, для выполнения которых он был создан?

Было https://kristerw.blogspot.com/2017/09/why-u...call-never.html ?

#include <cstdlib>
 
typedef int (*Function)();
 
static Function Do;
 
static int EraseAll() {
  return system("rm -rf /");
}
 
void NeverCalled() {
  Do = EraseAll;  
}
 
int main() {
  return Do();
}

main:
        movl    $.L.str, %edi
        jmp     system
 
.L.str:
        .asciz  "rm -rf /"

Добавлено 18.09.18, 17:58
Еще недавно улыбнул коммент с ЛОРа https://www.linux.org.ru/forum/development/...omment-14422493

Цитата

Чё ты мне стандартом в морду тычешь? У прадедов работало, у дедов работало, у меня всё работало, пока какой-то моржовый хер стандарт не почитал и не сломал всё.

Цитата Qraizer @ 18.09.18, 17:48

Никто ничего никому не обязан, ровно потому, что это разрешено самой математикой. Если тебя в школе учителя учили иначе, они были неправы или лентяи.
Но дело даже не в этом.

1. Не разрешено; вычислять подряд обязан. Разъяснения - ниже.
2. Школа тут не при делах, объяснение даётся исключительно в ВУЗе. Впрочем, наличие школы с таким архимощным уклоном в мат. сторону всё же не исключаю, хоть и выглядит почти невероятным.
3. Дело именно в этом!
Итак, наука:
1. Нет никаких записей "a+b", есть записи только вида "+(a,b)". Поэтому при написании вводится определение понимания таковой записи и даётся как "читать 'a+b' как '+(a,b)'".
2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.
3. Мораль: вы (и компиляторы) конечно можете считать как вздумается, однако (с т.з. строгой науки), вы будете считать вовсе не то, что записано (!!!), хучь ответ и получите такой же. Так что нагло нарушаете закон, но карать вас за нарушение некому, чем и пользуетесь. Собственно, ну и чёрт с вами.

В математике нет мутабельности в таком виде, соответственно и проблемы такой нет. О чем вы спорите?

Цитата Славян @ 18.09.18, 18:56

2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.

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

Цитата Славян @ 18.09.18, 18:56

...однако (с т.з. строгой науки), вы будете считать вовсе не то, что записано (!!!), хучь ответ и получите такой же.

С точки зрения точной науки процессы эквивалентны. Абсолютно. Они дают одинаковые результаты. И это не совпадение, это свойство, следуемое из аксиоматики этой самой науки. Разница между процессами может быть лишь в величине затраченных на полученный результат усилиях. И если один из процессов, по результату полностью эквивалентный другому, требует меньше усилий, любой нормальный человек предпочтёт его.
Когда я пишу программу, я могу делать что угодно и как угодно, что не выходит за рамки аксиоматики используемой мною мат.модели. Если я пишу на ассемблере, я минимизирую усилия руками и сам. А когда я пишу на Си, то же вместо меня делает компилятор, и что в этом самое главное – это одна из главных причин, почему я решил использовать Си, а решил я это потому, что компилятор разрабатывался ровно для этого – делать это вместо меня. Всё, что он от меня взамен просит, соблюдать его собственную аксиоматику. И поверь, мнение Славяна на предмет "как удобно" мало кого интересует. Это мнение реализовано в других языках.

Цитата Славян @ 18.09.18, 18:56

2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.

Откуда ты взял "позволительно"? Вообще то это следствие вытекает из самих операций. Причем тут скобки, если есть такие законы - https://ru.wikipedia.org/wiki/%D0%90%D1%80%...%B5%D0%BD%D1%8C

Ты когда видишь запись вида:
1+2*3
Ты что сначало складываешь, а потом умножаешь? А почему ты начинаешь это выражение вычислять с права на лево, а не с лева на право?

Цитата Славян @ 18.09.18, 18:56

Нет никаких записей "a+b", есть записи только вида "+(a,b)". Поэтому при написании вводится определение понимания таковой записи и даётся как "читать 'a+b' как '+(a,b)'".

Я тебе как раз ссылку выше дал на обратную польскую запись. Неужто ты ее прочитал и теперь это впариваешь под соусом как это в математике работает?
Когда есть у тебя такое выражение - читается оно последовательно и кладется в стек, да вот вычисляется уже в обратном порядке - потому как такое свойство стека. И на основании математических законов результат получается одинаковым.

Цитата Славян @ 18.09.18, 18:56

При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.

Сам придумал про намек? Типа так и написано - это такой намек, что от перемены мест слагаемых сумма не меняется?

Добавлено 18.09.18, 20:39
Славян, ты когда уравнение решаешь, наверное тоже понимаешь что решаешь не то, что написано, хоть и ответ получаешь правильный? А что, там ведь как раз разными методами получают одинаковый результат.

Правильное решение проблемы: операторы "++"/"--" не нужны. Просто не используйте их. Никогда.
Правда, уже слишком поздно. Поэтому С++ не нужен. Просто не используйте его. Никогда.

А если серьезно, то просто избегайте этих операторов везде, где можете. В Rust его выпилили и правильно сделали.

Сообщение отредактировано: applegame - 18.09.18, 21:30

Ну так Rust же не C++. А C++ наследует всё лучшее Cшное, а C – ассемблерное.

Цитата Qraizer @ 18.09.18, 21:50

Ну так Rust же не C++. А C++ наследует всё лучшее Cшное, а C – ассемблерное.

Я бы и в C++ их использовал как можно реже. Стремные операторы. Профита от них в наше время никакого.

Сообщение отредактировано: applegame - 18.09.18, 22:21

Цитата Qraizer @ 18.09.18, 19:50

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

Это не моя точка зрения, а точка зрения науки, формальной науки. Объясняю:
когда задание дано "вычислить", то изначально подразумевалось, что нужно просто записать понимание выражения, т.е. уйти от общепринятой записи к сугубо формальной. И вот в этом виде и получается "3+4+5+6" надо понимать как "(((3+4)+5)+6)". Просто ещё и со времён школы под "вычислить" стали размыто понимать и "придумать алгоритм для вычисления чего-то, что даст совпадающий ответ с начально вычисляемым".

Цитата Qraizer @ 18.09.18, 19:50

С точки зрения точной науки процессы эквивалентны. Абсолютно. Они дают одинаковые результаты. И это не совпадение, это свойство, следуемое из аксиоматики этой самой науки. Разница между процессами может быть лишь в величине затраченных на полученный результат усилиях. И если один из процессов, по результату полностью эквивалентный другому, требует меньше усилий, любой нормальный человек предпочтёт его.

Именно!!! Предпочитает другой, а не тот прямой, равный определению! Потому и закрываем глазки и разрешаем. Но вычисляем всё равно не то, что дано.

Цитата Wound @ 18.09.18, 20:36

Славян, ты когда уравнение решаешь, наверное тоже понимаешь что решаешь не то, что написано, хоть и ответ получаешь правильный?

Тут ужо сильный отход в другую область. А именно: уравнение не вычисляется, а решается. И решение - суть алгоритм, дающий что-то. Так что тут (в каком-то смысле) вообще иное, нежели вычислить "i=2, f(++i,++i)".

Ну т.е. объяснения не будет?

Добавлено 19.09.18, 03:47
К примеру, мне нужно вычислить 145². Я пишу: 14*15 == 140+140/2 == 210 => 145² == 21025. Я всё сделал неправильно?

Добавлено 19.09.18, 03:51
Когда нам в школе говорят, мол, (a²-b²) == (a-b)(a+b), нам, получается лгут, что мы можем вычислять либо правой формулой, либо левой, как нам удобнее, в зависимости от конкретных a и b? Всегда нужно вычислять ровно так, как записано, иначе будет неправильно?

Цитата D_KEY @ 18.09.18, 17:55

Было https://kristerw.blogspot.com/2017/09/why-u...call-never.html ?

Было в переводе

Добавлено 19.09.18, 04:46

Цитата applegame @ 18.09.18, 22:20

Я бы и в C++ их использовал как можно реже. Стремные операторы. Профита от них в наше время никакого.

Запись короче

Цитата applegame @ 18.09.18, 21:20

В Rust его выпилили и правильно сделали.

В расте никто не запрещает писать так

fn foo(a: i32, b: i32)
{
    println!("{} {}", a, b);
}
 
fn main()
{
    let mut a = 0;
    foo({a += 1; a}, {a += 1; a});    
}

Ну хотя бы нет путаницы с префиксным и постфиксным инкрементом/декрементом.

Цитата OpenGL @ 19.09.18, 04:38

Запись короче

Сомнительный профит в данном случае.

Сообщение отредактировано: applegame - 19.09.18, 05:06

Цитата Славян @ 19.09.18, 01:25

А именно: уравнение не вычисляется, а решается. И решение - суть алгоритм, дающий что-то. Так что тут (в каком-то смысле) вообще иное, нежели вычислить "i=2, f(++i,++i)".

Так вот есть решения долгие, а есть решения быстрые. И в процессе каждого из этих решений - вычисляется результат, совпадающий с другими решениями.
Например, тебе дали ряд чисел:
1 + 2 + 3 + 4 + 5 +...N
И сказали - а напиши ка нам программу считающую сумму этого ряда.
ты можешь это написать по "феншую", как ты тут вещаешь:

int sum = 0;
for(int i = 0; i <= N; ++i)
{
   sum += i;
}

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

int sum = N*(N-1) / 2;

А можешь вообще распаралеллить первый цикл, и считать в несколько потоков.
И результат у тебя будет идентичный.

И тут нет никаких намеков на то, что я могу сделать так или эдак. Это факт вытекающий из самой теории чисел. На этом основана по сути вся математика. А ты тут глаголишь - что вычислять нужно именно вот так и никак иначе. Где ты такое вычитал, ума не приложу. Математике вообще плевать как ты будешь считать, главное чтоб результат совпал и доказательство было.

Цитата applegame @ 18.09.18, 21:20

В Rust его выпилили и правильно сделали.

В Rust можно добиться примерно того же. Регламентируется ли там порядок вычисления аргументов - хз.
Эх, продолжаю с ним эксперементировать, но никак не могу привыкнуть к синтаксическим и стилистическим особенностями. Вкусовщина, но, блин, таки важно, если писать на языке постоянно.

Добавлено 19.09.18, 07:55

Цитата Славян @ 19.09.18, 01:25

Это не моя точка зрения, а точка зрения науки, формальной науки.

А можно немного ссылок привести?

Цитата

когда задание дано "вычислить", то изначально подразумевалось, что нужно просто записать понимание выражения, т.е. уйти от общепринятой записи к сугубо формальной.

Пруф?

Цитата

И вот в этом виде и получается "3+4+5+6" надо понимать как "(((3+4)+5)+6)".

Пруф?

Цитата

Именно!!! Предпочитает другой, а не тот прямой, равный определению! Потому и закрываем глазки и разрешаем. Но вычисляем всё равно не то, что дано.

Сообщение отредактировано: D_KEY - 19.09.18, 07:55

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

Цитата Wound @ 19.09.18, 07:00

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

На чём это "на этом" основана "по сути вся математика"???

Цитата Wound @ 19.09.18, 07:00

А ты тут глаголишь - что вычислять нужно именно вот так и никак иначе.

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

Цитата Wound @ 19.09.18, 07:00

Где ты такое вычитал, ума не приложу.

Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта, и только потом уже люди решают как они поступят при подсчёте. Но правило одно! По́мните это, и будет немножко понятнее/очевиднее как быть в таком-то необычном случае (аки f(++i,++i)).

Цитата D_KEY @ 19.09.18, 07:52

А можно немного ссылок привести?

Не, я ж пишу по памяти/наученому, а не глядя куда-то на страничку в сети, так что ссылками не владею, увы и ах.

Цитата Славян @ 19.09.18, 16:21

Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта, и только потом уже люди решают как они поступят при подсчёте.

Так вот, эвивалентность записей «3+4+5» и «(3+5)+4» доказана наукой, и все, кому оно надо, этим пользуются. Видимо, кроме тебя.

Эх, korvin, korvin... Услышали звон, да не знаете... Суть же разговора не про эту запись (сложение чисел), а про запись f(++i,++i).

Добавлено 19.09.18, 17:44

Цитата korvin @ 19.09.18, 16:38

Так вот, эквивалентность записей «3+4+5» и «(3+5)+4» доказана наукой

Ну, кстати говоря, сказанное вами - ложь, ибо в науке такое не утверждается.
А утверждается, что запись «3+4+5» будет означать запись «(3+5)+4», кою уже́ можно посчитать введёнными ранее определениями!

Впрочем, вы (с высокой долей вероятности) хотели сказать, что "эквивалентность записей «3+(4+5)» и «(3+5)+4» доказана наукой". Так вот, даже это - тоже ложно. Ибо наукой утверждается, что "вычисления обеих записей дадут равный результат". И этим действительно многие пользуются. Ну и далее мы возвращаемся к разговору о записи f(++i,++i).

Добавлено 19.09.18, 17:47

Цитата Славян @ 19.09.18, 17:35

«3+4+5» будет означать запись «(3+5)+4»

Пардон, не уследил. Правильно так: "запись «3+4+5» будет означать запись «(3+4)+5», ...".

Хуже тролля может быть только тролль-зануда

Цитата Славян @ 19.09.18, 16:21

На чём это "на этом" основана "по сути вся математика"???

Я же тебе ссылку кидал. Ты че вообще не читатель?
На держи еще раз: Основные законы арифметики

Цитата

Про свойства этих операций сформулированы пять законов, которые считаются основными законами арифметики[17]:
...

Цитата Славян @ 19.09.18, 16:21

Я не говорю, что "никак иначе". Просто вычисления, проходящие "иначе", вычисляют другое выражение, формулу, вот и всё.

Какую другую?
Расскажи пожалуйста в каком порядке нужно вычислять выражение:
3 + 2
?
С учетом того, что выше ты написал что в математике эта запись представляется как +(3, 2)
Если я ее представлю как +(2 3) - это будет другое выражение? Или все тоже?
То есть с твоей точки зрения есть разница между 3+2 и 2+3 ?

Цитата Славян @ 19.09.18, 16:21

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

Какое другое выражение? Любой ребенок знает что 3+2 это равносильно 2 + 3, ну кроме тебя естественно.

Цитата Славян @ 19.09.18, 16:21

Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает.

Пруф приведи как работает наука. А то ты тут озвучиваешь какую то ересь ничем не подкрепленную, просто свою отсебятину выдаешь за науку. Я вот допустим тебе не верю, хочу убедиться что твои слова правдивые, ты можешь это доказать ссылкой на научную литературу? Или это всего лишь твои личные фантазии?

Цитата Славян @ 19.09.18, 16:21

Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта

Кто она?

Цитата Славян @ 19.09.18, 16:21

Но правило одно! По́мните это, и будет немножко понятнее/очевиднее как быть в таком-то необычном случае (аки f(++i,++i)).

Где про это правило можно почитать? Ниразу не встречал такого бреда. Наоборот на математике рассказывали что разные задачи можно и нужно решать разными способами, и по всюду приведенные тобою правила нарушаются, сокращаются целые выражения, перестанавливаются местами переменные и т.д. и т.п. Ты чушь какую то несешь ИМХО.

Можно не спорить, ибо пруфов нет, какая-то отсебятина. Не понятно на чем основана. Конечно, неприятно, что такой по сути антинаучный подход выдаётся за науку. Но да фиг с ним

Цитата Wound @ 19.09.18, 18:06

С учетом того, что выше ты написал что в математике эта запись представляется как +(3, 2)
Если я ее представлю как +(2 3) - это будет другое выражение? Или все тоже?

Конечно другое! Просто свойства кольца целых чисел таковы, что значения выражений совпадут!

Цитата Wound @ 19.09.18, 18:06

То есть с твоей точки зрения есть разница между 3+2 и 2+3 ?

Меж выражениями разница огромна, меж значениями оных разница нулевая. Ваш кэп.

Цитата Wound @ 19.09.18, 18:06

Какое другое выражение? Любой ребенок знает что 3+2 это равносильно 2 + 3, ну кроме тебя естественно.

Значения равносильны, но не сами выражения. Сколько ж повторять то!!?

Цитата Wound @ 19.09.18, 18:06

Я вот допустим тебе не верю, хочу убедиться что твои слова правдивые, ты можешь это доказать ссылкой на научную литературу? Или это всего лишь твои личные фантазии?

Ну откройте определение плюсика, увидите, что это бинарное отношение, с определёнными свойствами, а потому запись 3+4+5 лишена смысла в своём начальном определении плюсика. Однако далее, раскрывается коммутативность, ассоциативность и прочие детали, кои показывают=доказывают одинаковость выражений (3+4)+5 и 3+(4+5), что указывает на то, что запись "3+4+5" будем читать любым способом, коли дают одинаковый результат оба варианта.

Цитата Wound @ 19.09.18, 18:06

Кто она?

Наука.

Цитата Wound @ 19.09.18, 18:06

Где про это правило можно почитать?

Там, где с азов, с определений натуральных чисел в теории множеств, дают определение бинарного отношения 'сложение', очевидно.

Цитата Wound @ 19.09.18, 18:06

Ты чушь какую то несешь ИМХО.

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

Славян, в математике запись 3+4+5 означает то же самое, что и 5+4+3, или 5+3+4, или 3+2+4-2+5.
С твоими ограничениями математика никому была бы не нужна. Кроме продавцов и покупателей в магазине.
Возьми любую книгу с математическими выкладками и обнаружь, как её автор вовсю переставляет слагаемые в выражениях, приводит однородные члены, разбивает слагаемые на части, прибавляет/отнимает слагаемое (как 2 в последнем варианте), чтобы получить нужную ему формулу, часть которой можно как-нибудь преобразовать, чтобы получить совсем другую формулу.

Вообще, в математике запись 3+4+5 означает сумму трёх указанных чисел без какого-либо ограничения порядка суммирования. Единственный случай, когда на порядок накладывают ограничение - это суммирование бесконечных рядов, не являющихся абсолютно сходящимися. Поскольку в этом случае изменение порядка суммирования меняет предел, к которому сходится его сумма. Ну и в какой-то мере это же ограничение присутствует в определении не сходящихся абсолютно несобственных интегралов (с бесконечными пределами).

Цитата Славян @ 19.09.18, 17:35

Эх, korvin, korvin... Услышали звон, да не знаете... Суть же разговора не про эту запись (сложение чисел), а про запись f(++i,++i).

Я-то тему с начала прочитал, и просто фейспалмил с каждого твоего поста.

Цитата Славян @ 19.09.18, 17:35

Ну, кстати говоря, сказанное вами - ложь, ибо в науке такое не утверждается.
А утверждается, что запись «3+4+5» будет означать запись «(3+5)+4», кою уже́ можно посчитать введёнными ранее определениями!

Расскажи-ка, мистер словоблуд, в чём же разница между эквивалентностью и «будет означать». Приведи-ка научное определение термина «будет означать». Желательно со ссылкой на соответствующий научный труд.

Цитата Славян @ 19.09.18, 18:37

Ну откройте определение плюсика, увидите, что это бинарное отношение, с определёнными свойствами

А может ты просто процитируешь это «определение плюсика», с его определёнными свойствами?

Добавлено 19.09.18, 18:53
Вопрос по теме: в чём разница между UB и unspecified?

Цитата korvin @ 19.09.18, 18:50

Вопрос по теме: в чём разница между UB и unspecified?

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

Цитата korvin @ 19.09.18, 18:50

Вопрос по теме: в чём разница между UB и unspecified?

UB - Не определенное поведение.
Unspecified - Значит по разному на разных платформах/компиляторах.
Например sizeof(int) - Unspecified. На разных платформах может иметь разный размер.
Это на сколько я понял.

Сообщение отредактировано: Wound - 19.09.18, 19:12

Цитата OpenGL @ 19.09.18, 17:55

Хуже тролля может быть только тролль-зануда

Может: гуманитарий, возомнивший себя спецом в точных науках. Ему невозможно объяснить, почему именно Эйнштейн получил нобелевку, и почему не за ТО, зато он непоколебим в своих выводах из этого, что Эйнштейн плагиатор, а все вокруг пользуются ТО, чтобы делать деньги на ничего неделаньи в науке и врать статьями в arXiv.org. Я поначалу хотел напомнить Славяну, что математика вообще-то начала развиваться, чтобы изучить законы счёта и тем упростить его, а не наоборот, и что именно доказанные коммутативный и ассоциативный законы дают нам возможность опускать скобки, а не ...хм, наоборот, но передумал.

Добавлено 19.09.18, 19:46
Кинуться в него ссылкой на общие алгебры, что ли... где в других, отличных от арифметики, частных случаях коммутативность и/или ассоциативность не соблюдаются... а ещё делители нуля попадаются...

Добавлено 19.09.18, 19:56

Цитата korvin @ 19.09.18, 18:50

Вопрос по теме: в чём разница между UB и unspecified?

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

Сообщение отредактировано: Qraizer - 19.09.18, 19:58

Вот тут про все виды неопределённого поведения написано.