Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.135.183.187] |
|
Сообщ.
#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++, которые как раз от оверхеда и стараются избавиться Да и где ты логику-то увидел? По-моему "порядок вычисления аргументов не определён" не менее логично, чем "строгий порядок слева направо". Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#16
,
|
|
|
Ну хочется прогерам жить так - пущай, чёрт с вами. Впрочем, думается мне, что с годами всё же будут стараться избавиться от неопределённостей.
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#17
,
|
|
|
Цитата Славян @ А) Годьте! Если только на этапе оптимизации, то это проблема недоделанного оптимизатора. Пусть осторожней работает! Если же не только, то давайте смотреть этот обыденный случай. Так он и так работает осторожно, это кто то просто не понимает ЯП до конца. Цитата Славян @ Б) Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений), так что расскажите попроще на этом простом примере, что тут не так? Не так тут то, что запятая в аргументах функций - не является точкой следования, только в выражениях. Соответственно компилятор - в праве переупорядочивать операции по своему усмотрению. И это с точки зрения языка - правильно. Другими словами тут есть неоднозначности, на которые выше уже указал тебе. Ты ждешь 3,4 - а почему не 4,4? Цитата Славян @ Всё же просто: вызов с двумя аргументами, кои записаны подряд, а значит и вычисляться должны подряд! Так что f(3,4); Так ты передаешь в эти аргументы одну и ту же область памяти - при чем два раза инкрементировав ее содержимое, и на выходе ожидаешь почему то 3,4. Цитата Славян @ Ещё раз напомню, что шаманство компилятора при оптимизации - его изъян; пусть хуже оптимизирует, но не допускает ошибок/двузначностей. Это такое соглашения в ЯП, а не ошибка оптимизации. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#18
,
|
|
|
Цитата Wound @ Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично. Ты ждешь 3,4 - а почему не 4,4? Цитата Wound @ Нет никаких "двух раз"! Есть вызов, с двумя аргументами. Рубим первый, а потом - второй. Как и пишем!!! Всё железобетонно!Так ты передаешь в эти аргументы одну и ту же область памяти - при чем два раза инкрементировав ее содержимое, и на выходе ожидаешь почему то 3,4. Не понимаю ваших аргументов, абсолютно. Причём, очень хочу понять, честно, но никак не вижу. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#19
,
|
|
|
Цитата Славян @ Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично. Где логично то? По твоему после передачи первого аргумента в функцию - должно выполнится тело функции? Бред какой то. Ты передаешь одну переменную, не две. А одну. Куда компилятор запишет значение 3, а куда 4? Цитата Славян @ Нет никаких "двух раз"! Есть вызов, с двумя аргументами. Рубим первый, а потом - второй. Как и пишем!!! Всё железобетонно! Как это нет? У тебя переменная 1 - i, куда будут сохранены значения двух аргументов по твоему? Цитата Славян @ Не понимаю ваших аргументов, абсолютно. Причём, очень хочу понять, честно, но никак не вижу. Что не понятного? Сначало вычисляются значения переменных, а уж потом идет передача в функцию. А ты как хотел? Сначало передать, а потом вычислить? Ну тогда логичнее ожидать 2,2, а не 3,4. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#20
,
|
|
|
Цитата Wound @ Он о том, что, по его мнению, аргументы должны вычисляться слева направо и между их вычислениями должны быть точки следования. Возможно, для какого-то абстрактного языка это будет хорошо и правильно, но точно не для С++.Ты передаешь одну переменную, не две. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#21
,
|
|
|
Цитата Wound @ Нет такого по-моему! Я такого не вещал. Сначала - аргументы, потом - тело, всё по порядку! Где логично то? По твоему после передачи первого аргумента в функцию - должно выполниться тело функции? Цитата Wound @ Я не передаю переменную!!! Я передаю число=значение, посредством изменения такой-то переменной! Запишет он 3 в переменную, значение коей надо передать в первом аргументе, а потом запишет в неё 4, что и надо послать вторым. Как он выпутается - его грабли, а не мои, писателя проги!!! Ты передаешь одну переменную, не две. А одну. Куда компилятор запишет значение 3, а куда 4? Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#22
,
|
|
|
Цитата Славян @ Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично. Вот у тебя есть переменная X И есть функция Sum, принимающаяя 2 аргумента -> int Sum(int x, int y) Изначально X = 2 передай в эту функцию одну переменную X, в два аргумента так, чтобы внутри функции первый был равен 3, а второй 4, без использования других токенов. Вызов функции должен быть такой: int X = 2; //! Тут твой код Sum(X, X); Напиши код на месте коментария, чтоб внутри функции один аргумент был равен 3, а второй 4. Добавлено Цитата Славян @ Нет такого по-моему! Я такого не вещал. Сначала - аргументы, потом - тело, всё по порядку! Пиши вот так: Func(i+1, i+2) И будет тебе счастье. Цитата Славян @ Я не передаю переменную!!! Я передаю число=значение, Нет, ты передаешь конкретный идентификатор к которому применяется инкремент - это есть сайд эффект. Вот если бы ты просто передавал переменную, без ее изменения, вопросов бы не возникало. Цитата Славян @ Я передаю число=значение, посредством изменения такой-то переменной! Представь что вместо числа, у тебя std::string, а вместо ++ - у тебя replace который изменяет вызывающий его объект, два раза причем. Цитата Славян @ Запишет он 3 в переменную, значение коей надо передать в первом аргументе, а потом запишет в неё 4, что и надо послать вторым. Как он выпутается - его грабли, а не мои, писателя проги!!! Ээээ... В какую переменную? Добавлено 1 + 2 * 6 = 9 Все логично. Пущай там математики покумекают, и сделают мне чтобы было так, как я хочу Добавлено Цитата OpenGL @ Он о том, что, по его мнению, аргументы должны вычисляться слева направо и между их вычислениями должны быть точки следования. Возможно, для какого-то абстрактного языка это будет хорошо и правильно, но точно не для С++. Да я понимаю о чем он. Просто пытаюсь в рамках текущего стандарта пояснить ему что происходит. Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#23
,
|
|
|
Цитата Wound @ Идеал выглядел бы как-то так:Напиши код на месте коментария, чтоб внутри функции один аргумент был равен 3, а второй 4. int X = 2; //! Тут мой код: // 1.Создаём область памяти в две ячейки, к коим никто не может обратиться (дабы не ломали, ...); // 2.Пишем в каждую ячейку: ++X в первую, ++X во вторую (получили пару (3;4); // 3.Кормим функции Sum значения из ячеек. Бинго. Sum(еда1, еда2); Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#24
,
|
|
|
Цитата Славян @ int X = 2; //! Тут мой код: // 1.Создаём область памяти в две ячейки, к коим никто не может обратиться (дабы не ломали, ...); // 2.Пишем в каждую ячейку: ++X в первую, ++X во вторую (получили пару (3;4); // 3.Кормим функции Sum значения из ячеек. Бинго. Sum(еда1, еда2); А как быть с указателями и ссылочными типами данных? Как быть со сложными объектами? Ты понимаешь что передавать int по ссылке не имеет смысла, так как все сведетя к указателю, кой и есть по сути int ? И в чем тогда будет преимущество С++ перед другими ЯП? Добавлено Т.е. передача любого объекта в функцию - делает копию объекта, в итоге как передавать массив из 1000000 элементов? Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#25
,
|
|
|
Ага! Т.е. выход нашёлся, но теперь начались наезды на какие-то другие последствия? Давайте всё же разбирать тогда каждый, а то ваш способ заваливать горой вопросов, конечно, неплох, но труден для развёрнутых ответов.
Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#26
,
|
|
|
А я, пожалуй, дровишек подкину ...
Один: Скрытый текст 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) Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#27
,
|
|
|
Цитата Славян @ Ага! Т.е. выход нашёлся, но теперь начались наезды на какие-то другие последствия? В смысле выход нашелся? Не нашелся ведь. Твоя проблема в том, что ты рассматриваешь только int'ы, а другие типы данных не рассматриваешь. Я тебя специально подтолкнул к тому, чтобы ты написал - как по твоему это должно работать. Ты и написал по твоему мнению решение, которое должно работать для int'ов, но упускаешь из виду другие типы данных + другую семантику передачи параметров в функции. А ведь это примитивный случай. Плюс ко всему, аргументы функций - не зависят друг от друга, соответственно могут быть вычисленны вообще паралельно друг от друга. Если тебе нужен строгий порядок выполнения - переходи на Java/C#, там порядок строго определен, ну и с указателями нет мороки тоже. Сообщения были разделены в тему "undefined/unspecified" Это сообщение было перенесено сюда или объединено из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#28
,
|
|
|
Цитата Wound @ Нашёлся, - я ж показал правильный ход построения вызова функции.В смысле выход нашелся? Не нашелся ведь. Цитата Wound @ Нет у меня проблем, не сочиняйте. Твоя проблема в том, что ты рассматриваешь только int'ы, а другие типы данных не рассматриваешь. Цитата Wound @ Так в том же и фишка, что на предложенный вариант - предложил решение. А вы сразу задались вопросом про общий случай. Да чёрт его знает как в общем, это проблема компилятора, но в этом конкретном частном - всё должно решиться без ваших UB.Ты и написал по твоему мнению решение, которое должно работать для int'ов, но упускаешь из виду другие типы данных + другую семантику передачи параметров в функции. А ведь это примитивный случай. Цитата Wound @ Может выполнить компилер параллельно, не впадая в Плюс ко всему, аргументы функций - не зависят друг от друга, соответственно могут быть вычисленны вообще паралельно друг от друга. Добавлено Цитата JoeUser @ Ну здесь Clang справился на отлично (не считая того, что он забил на i).А я, пожалуй, дровишек подкину ... Один: Эта тема была разделена из темы "Текущий Стандарт С++ и перспективы его развития" |
Сообщ.
#29
,
|
|
|
Цитата Славян @ Нашёлся, - я ж показал правильный ход построения вызова функции. С чего это он правильный? Потому что тебе так кажется? Цитата Славян @ Нет у меня проблем, не сочиняйте. Ну как нет, если есть. Тебе же не понятно почему вот так, а не вод эдак. Цитата Славян @ Так в том же и фишка, что на предложенный вариант - предложил решение. Так не предложил же. Ты исказил условие данной тебе задачи. Т.е. ты подогнал задачу под свой ответ. Я то тебе другой вопрос задал. Цитата Славян @ А вы сразу задались вопросом про общий случай. Да чёрт его знает как в общем, это проблема компилятора, но в этом конкретном частном - всё должно решиться без ваших UB. Нет не должно. Тут уж тебе нужно выбрать - не нравится инструмент берешь тот, который тебе по душе. А ты предлагаешь убить быстродействие в угоду каких то своих хотелок. Почему бы тогда не взять соответствующий для этого инструмент? Цитата Славян @ Может выполнить компилер параллельно, не впадая в депрессию UB, - пусть делает; а не может - пусть делает по порядку аргументов. Всё норм! Так порядок вычисления аргументов не определен. Ты странный какой то. Ей богу. |
Сообщ.
#30
,
|
|
|
Цитата Wound @ Потому что я аргументировал: читается текст слева направо, параллельно сделать нельзя, пусть делает как читается.С чего это он правильный? Потому что тебе так кажется? Цитата Wound @ Неправда. Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода. Можно сделать быстро - делайте, нельзя - начхать, не судьба.А ты предлагаешь убить быстродействие в угоду каких то своих хотелок. Цитата Wound @ Так инструменты ж создаются для той или иной записи выражений, языка расчёта. Си (Си++) был выбран таким, пусть теперь ворочается на своих, местами трудных, тропинках. А не так что: ничего не знаем - выполняем как захотим.Почему бы тогда не взять соответствующий для этого инструмент? Цитата Wound @ Да я понял. Не понял только отчего забили. Так порядок вычисления аргументов не определен. |
Сообщ.
#31
,
|
|
|
Цитата Славян @ Потому что я аргументировал: читается текст слева направо, параллельно сделать нельзя, пусть делает как читается. Чем интересно ты аргументировал? Или твоя хотелка по умолчанию является неоспоримым аргументом? Почему это параллельно сделать нельзя? Расскажи пожайлуйста, почему в выражении: X = 3 + 5 + 6 +7 Я не могу паралельно вычислить сумму 3 + 5 и 6 + 7, а потом сложить это все воедино? Или почему я не могу сложить 3 + 7 и 5 + 6, а потом сложить все это воедино? Математика мне это вроде как позволяет, утверждая что от перемены мест слагаемых - сумма не меняется. А ты какой аргумент привел? Потому что тебе слево на право удобнее читать? А арабам с права на лево удобнее, и что теперь? Цитата Славян @ Неправда. Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода. Можно сделать быстро - делайте, нельзя - начхать, не судьба. Эта запись кода абсолютно понятна и естественна, она не понятно только лишь тебе. Цитата Славян @ Так инструменты ж создаются для той или иной записи выражений, языка расчёта. Си (Си++) был выбран таким, пусть теперь ворочается на своих, местами трудных, тропинках. А не так что: ничего не знаем - выполняем как захотим. И? Он ничего не нарушает, это просто ты не хочешь понять как это работает. Цитата Славян @ Да я понял. Не понял только отчего забили. На что забили? Во первых есть разные соглашения вызовов, аргументы могут передаватся и с права на лево, и с лева на право, и в каком то другом порядке, оптимизатор может оптимизировать выражение так, чтобы работало быстрее, некоторые конструкции могут быть вычислены паралельно и не зависимо друг от друга, потому как от перестановки мест слагаемых сумма не меняется. Это твои проблемы что ты одновременно читаешь и пишешь в одну и ту же область памяти без транзакции, а не компилятора. |
Сообщ.
#32
,
|
|
|
Цитата Wound @ Потому что так уcтроены законы математики/логики.Расскажи пожайлуйста, почему в выражении: X = 3 + 5 + 6 +7 Я не могу паралельно вычислить сумму 3 + 5 и 6 + 7, а потом сложить это все воедино? Цитата Wound @ См. выше.Или почему я не могу сложить 3 + 7 и 5 + 6, а потом сложить все это воедино? Цитата Wound @ Именно, что "вроде". В действительности - нет, не позволяет. Просто она намекает (даже прямо говорит), что вы получите одинаковый ответ и при других ваших сложениях. Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7.Математика мне это вроде как позволяет, утверждая что от перемены мест слагаемых - сумма не меняется. Цитата Wound @ Да. Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем.А ты какой аргумент привел? Потому что тебе слево на право удобнее читать? Цитата Wound @ Они вынуждены пойти лесом. На всех не угодишь. Мы ж не пишем:А арабам с права на лево удобнее, и что теперь? int главное(int argc, char *argv[]) |
Сообщ.
#33
,
|
|
|
Цитата Славян @ Я предлагаю забить на быстродействие в угоду понятливости да естественности записи кода. На практике это вовсе не будет естественным. По факту, единственный вариант, где последовательное вычисление удобно и активно используется на практике это булевские выражения вида if(index < size && list[index] != "Славян). Реальный же пример, когда однострочник будет удобнее и нагляднее явного вычисления параментров в нужном порядке, мне в голову не приходит. |
Сообщ.
#34
,
|
|
|
Цитата Славян @ Потому что так уcтроены законы математики/логики. Значит ли это что ты сам ответил на свой вопрос? Цитата Славян @ Именно, что "вроде". В действительности - нет, не позволяет. Просто она намекает (даже прямо говорит), что вы получите одинаковый ответ и при других ваших сложениях. Позволяет, более того это основные законы арифметики. Цитата Славян @ Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7. Где написано что я обязан считать подряд? Вот например тут - https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%...%B8%D1%81%D1%8C считают вообще в другом порядке, чем ты. Цитата Славян @ Да. Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем. Причем тут англо-саксы? Я просто пытаюсь показать на сколько твоя фраза бессмыслена. Что ж у англосаксов тогда стек идет не с лева на право? Цитата Славян @ Они вынуждены пойти лесом. На всех не угодишь. Мы ж не пишем: А кто тебе запрещает так писать? |
Сообщ.
#35
,
|
|
|
Цитата Славян @ Язык (Си) был придуман высокоуровневым на замену низкоуровневому ассемблеру. Остальное от лукавого, Славян.Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем. Цитата Славян @ Никто ничего никому не обязан, ровно потому, что это разрешено самой математикой. Если тебя в школе учителя учили иначе, они были неправы или лентяи. Но всё же обязаны считать подряд: 3+5, (3+5)+6, ((3+5)+6)+7. Но дело даже не в этом. Берём низкоуровневый ассемблер, и пишем фрагмент кода, вычисляющий сие. Я волен делать любые мыслимые модификации алгоритма, которые не приводят к искажению результата. Иначе на кой хрен я вообще взял в руки ассемблер, если не для вот этого самого вот: взять под свой полный контроль самые глубины вот этой вот кучки атомов кремния с вкраплениями примесей? Почему тогда в высокоуровневом Си ты хочешь запретить делать это компилятору, который пришёл на замену вот как раз этому самому низкоуровневому ассемблеру? На кой хрен мне вообще язык, который не выполняет задач, для выполнения которых он был создан? |
Сообщ.
#36
,
|
|
|
Было 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 /" Добавлено Еще недавно улыбнул коммент с ЛОРа https://www.linux.org.ru/forum/development/...omment-14422493 Цитата Чё ты мне стандартом в морду тычешь? У прадедов работало, у дедов работало, у меня всё работало, пока какой-то моржовый хер стандарт не почитал и не сломал всё. |
Сообщ.
#37
,
|
|
|
Цитата Qraizer @ 1. Не разрешено; вычислять подряд обязан. Разъяснения - ниже.Никто ничего никому не обязан, ровно потому, что это разрешено самой математикой. Если тебя в школе учителя учили иначе, они были неправы или лентяи. Но дело даже не в этом. 2. Школа тут не при делах, объяснение даётся исключительно в ВУЗе. Впрочем, наличие школы с таким архимощным уклоном в мат. сторону всё же не исключаю, хоть и выглядит почти невероятным. 3. Дело именно в этом! Итак, наука: 1. Нет никаких записей "a+b", есть записи только вида "+(a,b)". Поэтому при написании вводится определение понимания таковой записи и даётся как "читать 'a+b' как '+(a,b)'". 2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым. 3. Мораль: вы (и компиляторы) конечно можете считать как вздумается, однако (с т.з. строгой науки), вы будете считать вовсе не то, что записано (!!!), хучь ответ и получите такой же. Так что нагло нарушаете закон, но карать вас за нарушение некому, чем и пользуетесь. Собственно, ну и чёрт с вами. |
Сообщ.
#38
,
|
|
|
В математике нет мутабельности в таком виде, соответственно и проблемы такой нет. О чем вы спорите?
|
Сообщ.
#39
,
|
|
|
Цитата Славян @ Т.е. с твоей точки зрения, если результат гарантировано не отличается, то процесс всё равно неправильный? А почему, объяснишь? Ну, и эта... ты ж понимаешь, что что-то типа "потому что" за ответ считаться не будет.2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым. Цитата Славян @ С точки зрения точной науки процессы эквивалентны. Абсолютно. Они дают одинаковые результаты. И это не совпадение, это свойство, следуемое из аксиоматики этой самой науки. Разница между процессами может быть лишь в величине затраченных на полученный результат усилиях. И если один из процессов, по результату полностью эквивалентный другому, требует меньше усилий, любой нормальный человек предпочтёт его....однако (с т.з. строгой науки), вы будете считать вовсе не то, что записано (!!!), хучь ответ и получите такой же. Когда я пишу программу, я могу делать что угодно и как угодно, что не выходит за рамки аксиоматики используемой мною мат.модели. Если я пишу на ассемблере, я минимизирую усилия руками и сам. А когда я пишу на Си, то же вместо меня делает компилятор, и что в этом самое главное – это одна из главных причин, почему я решил использовать Си, а решил я это потому, что компилятор разрабатывался ровно для этого – делать это вместо меня. Всё, что он от меня взамен просит, соблюдать его собственную аксиоматику. И поверь, мнение Славяна на предмет "как удобно" мало кого интересует. Это мнение реализовано в других языках. |
Сообщ.
#40
,
|
|
|
Цитата Славян @ 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 Ты что сначало складываешь, а потом умножаешь? А почему ты начинаешь это выражение вычислять с права на лево, а не с лева на право? Цитата Славян @ Нет никаких записей "a+b", есть записи только вида "+(a,b)". Поэтому при написании вводится определение понимания таковой записи и даётся как "читать 'a+b' как '+(a,b)'". Я тебе как раз ссылку выше дал на обратную польскую запись. Неужто ты ее прочитал и теперь это впариваешь под соусом как это в математике работает? Когда есть у тебя такое выражение - читается оно последовательно и кладется в стек, да вот вычисляется уже в обратном порядке - потому как такое свойство стека. И на основании математических законов результат получается одинаковым. Цитата Славян @ При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым. Сам придумал про намек? Типа так и написано - это такой намек, что от перемены мест слагаемых сумма не меняется? Добавлено Славян, ты когда уравнение решаешь, наверное тоже понимаешь что решаешь не то, что написано, хоть и ответ получаешь правильный? А что, там ведь как раз разными методами получают одинаковый результат. |
Сообщ.
#41
,
|
|
|
Правильное решение проблемы: операторы "++"/"--" не нужны. Просто не используйте их. Никогда.
Правда, уже слишком поздно. Поэтому С++ не нужен. Просто не используйте его. Никогда. А если серьезно, то просто избегайте этих операторов везде, где можете. В Rust его выпилили и правильно сделали. |
Сообщ.
#42
,
|
|
|
Ну так Rust же не C++. А C++ наследует всё лучшее Cшное, а C – ассемблерное.
|
Сообщ.
#43
,
|
|
|
Цитата Qraizer @ Я бы и в C++ их использовал как можно реже. Стремные операторы. Профита от них в наше время никакого. Ну так Rust же не C++. А C++ наследует всё лучшее Cшное, а C – ассемблерное. |
Сообщ.
#44
,
|
|
|
Цитата Qraizer @ Это не моя точка зрения, а точка зрения науки, формальной науки. Объясняю:Т.е. с твоей точки зрения, если результат гарантировано не отличается, то процесс всё равно неправильный? А почему, объяснишь? Ну, и эта... ты ж понимаешь, что что-то типа "потому что" за ответ считаться не будет. когда задание дано "вычислить", то изначально подразумевалось, что нужно просто записать понимание выражения, т.е. уйти от общепринятой записи к сугубо формальной. И вот в этом виде и получается "3+4+5+6" надо понимать как "(((3+4)+5)+6)". Просто ещё и со времён школы под "вычислить" стали размыто понимать и "придумать алгоритм для вычисления чего-то, что даст совпадающий ответ с начально вычисляемым". Цитата Qraizer @ Именно!!! Предпочитает другой, а не тот прямой, равный определению! Потому и закрываем глазки и разрешаем. Но вычисляем всё равно не то, что дано. С точки зрения точной науки процессы эквивалентны. Абсолютно. Они дают одинаковые результаты. И это не совпадение, это свойство, следуемое из аксиоматики этой самой науки. Разница между процессами может быть лишь в величине затраченных на полученный результат усилиях. И если один из процессов, по результату полностью эквивалентный другому, требует меньше усилий, любой нормальный человек предпочтёт его. Цитата Wound @ Тут ужо сильный отход в другую область. А именно: уравнение не вычисляется, а решается. И решение - суть алгоритм, дающий что-то. Так что тут (в каком-то смысле) вообще иное, нежели вычислить "i=2, f(++i,++i)". Славян, ты когда уравнение решаешь, наверное тоже понимаешь что решаешь не то, что написано, хоть и ответ получаешь правильный? |
Сообщ.
#45
,
|
|
|
Ну т.е. объяснения не будет?
Добавлено К примеру, мне нужно вычислить 1452. Я пишу: 14*15 == 140+140/2 == 210 => 1452 == 21025. Я всё сделал неправильно? Добавлено Когда нам в школе говорят, мол, (a2-b2) == (a-b)(a+b), нам, получается лгут, что мы можем вычислять либо правой формулой, либо левой, как нам удобнее, в зависимости от конкретных a и b? Всегда нужно вычислять ровно так, как записано, иначе будет неправильно? |
Сообщ.
#46
,
|
|
|
Было в переводе Добавлено Цитата applegame @ Я бы и в C++ их использовал как можно реже. Стремные операторы. Профита от них в наше время никакого. Запись короче Цитата applegame @ В Rust его выпилили и правильно сделали. В расте никто не запрещает писать так fn foo(a: i32, b: i32) { println!("{} {}", a, b); } fn main() { let mut a = 0; foo({a += 1; a}, {a += 1; a}); } |
Сообщ.
#47
,
|
|
|
Ну хотя бы нет путаницы с префиксным и постфиксным инкрементом/декрементом.
Цитата OpenGL @ Сомнительный профит в данном случае. Запись короче |
Сообщ.
#48
,
|
|
|
Цитата Славян @ А именно: уравнение не вычисляется, а решается. И решение - суть алгоритм, дающий что-то. Так что тут (в каком-то смысле) вообще иное, нежели вычислить "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; А можешь вообще распаралеллить первый цикл, и считать в несколько потоков. И результат у тебя будет идентичный. И тут нет никаких намеков на то, что я могу сделать так или эдак. Это факт вытекающий из самой теории чисел. На этом основана по сути вся математика. А ты тут глаголишь - что вычислять нужно именно вот так и никак иначе. Где ты такое вычитал, ума не приложу. Математике вообще плевать как ты будешь считать, главное чтоб результат совпал и доказательство было. |
Сообщ.
#49
,
|
|
|
Цитата applegame @ В Rust его выпилили и правильно сделали. В Rust можно добиться примерно того же. Регламентируется ли там порядок вычисления аргументов - хз. Эх, продолжаю с ним эксперементировать, но никак не могу привыкнуть к синтаксическим и стилистическим особенностями. Вкусовщина, но, блин, таки важно, если писать на языке постоянно. Добавлено Цитата Славян @ Это не моя точка зрения, а точка зрения науки, формальной науки. А можно немного ссылок привести? Цитата когда задание дано "вычислить", то изначально подразумевалось, что нужно просто записать понимание выражения, т.е. уйти от общепринятой записи к сугубо формальной. Пруф? Цитата И вот в этом виде и получается "3+4+5+6" надо понимать как "(((3+4)+5)+6)". Пруф? Цитата Именно!!! Предпочитает другой, а не тот прямой, равный определению! Потому и закрываем глазки и разрешаем. Но вычисляем всё равно не то, что дано. |
Сообщ.
#50
,
|
|
|
Лично я каких-то явных недостатков у операторов инкремента и декремента не вижу. Есть - ну и фиг с ними, не мешают. Сыр-бор то не из-за них сейчас. С тем же успехом вместо них мог бы быть вызов неких функций с сайд-эффектами - точно такое же неопределёное поведение было бы.
|
Сообщ.
#51
,
|
|
|
Цитата Wound @ На чём это "на этом" основана "по сути вся математика"??? И тут нет никаких намеков на то, что я могу сделать так или эдак. Это факт вытекающий из самой теории чисел. На этом основана по сути вся математика. Цитата Wound @ Я не говорю, что "никак иначе". Просто вычисления, проходящие "иначе", вычисляют другое выражение, формулу, вот и всё. А то, что результат совпадёт с первоначальной - ну так это, конечно, фишка выводов в математике! Просто люди частенько забивают на эту мелочь ("вычисляют другое выражение"), но всё же неплохо было бы сие видеть. А ты тут глаголишь - что вычислять нужно именно вот так и никак иначе. Цитата Wound @ Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта, и только потом уже люди решают как они поступят при подсчёте. Но правило одно! По́мните это, и будет немножко понятнее/очевиднее как быть в таком-то необычном случае (аки f(++i,++i)). Где ты такое вычитал, ума не приложу. Цитата D_KEY @ Не, я ж пишу по памяти/наученому, а не глядя куда-то на страничку в сети, так что ссылками не владею, увы и ах. А можно немного ссылок привести? |
Сообщ.
#52
,
|
|
|
Цитата Славян @ Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта, и только потом уже люди решают как они поступят при подсчёте. Так вот, эвивалентность записей «3+4+5» и «(3+5)+4» доказана наукой, и все, кому оно надо, этим пользуются. Видимо, кроме тебя. |
Сообщ.
#53
,
|
|
|
Эх, korvin, korvin... Услышали звон, да не знаете... Суть же разговора не про эту запись (сложение чисел), а про запись f(++i,++i).
Добавлено Цитата korvin @ Ну, кстати говоря, сказанное вами - ложь, ибо в науке такое не утверждается. Так вот, эквивалентность записей «3+4+5» и «(3+5)+4» доказана наукой А утверждается, что запись «3+4+5» будет означать запись «(3+5)+4», кою уже́ можно посчитать введёнными ранее определениями! Впрочем, вы (с высокой долей вероятности) хотели сказать, что "эквивалентность записей «3+(4+5)» и «(3+5)+4» доказана наукой". Так вот, даже это - тоже ложно. Ибо наукой утверждается, что "вычисления обеих записей дадут равный результат". И этим действительно многие пользуются. Ну и далее мы возвращаемся к разговору о записи f(++i,++i). Добавлено Цитата Славян @ Пардон, не уследил. Правильно так: "запись «3+4+5» будет означать запись «(3+4)+5», ...". «3+4+5» будет означать запись «(3+5)+4» |
Сообщ.
#54
,
|
|
|
Хуже тролля может быть только тролль-зануда
|
Сообщ.
#55
,
|
|
|
Цитата Славян @ На чём это "на этом" основана "по сути вся математика"??? Я же тебе ссылку кидал. Ты че вообще не читатель? На держи еще раз: Основные законы арифметики Цитата Про свойства этих операций сформулированы пять законов, которые считаются основными законами арифметики[17]: ... Цитата Славян @ Я не говорю, что "никак иначе". Просто вычисления, проходящие "иначе", вычисляют другое выражение, формулу, вот и всё. Какую другую? Расскажи пожалуйста в каком порядке нужно вычислять выражение: 3 + 2 ? С учетом того, что выше ты написал что в математике эта запись представляется как +(3, 2) Если я ее представлю как +(2 3) - это будет другое выражение? Или все тоже? То есть с твоей точки зрения есть разница между 3+2 и 2+3 ? Цитата Славян @ Просто люди частенько забивают на эту мелочь ("вычисляют другое выражение"), но всё же неплохо было бы сие видеть. Какое другое выражение? Любой ребенок знает что 3+2 это равносильно 2 + 3, ну кроме тебя естественно. Цитата Славян @ Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Пруф приведи как работает наука. А то ты тут озвучиваешь какую то ересь ничем не подкрепленную, просто свою отсебятину выдаешь за науку. Я вот допустим тебе не верю, хочу убедиться что твои слова правдивые, ты можешь это доказать ссылкой на научную литературу? Или это всего лишь твои личные фантазии? Цитата Славян @ Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта Кто она? Цитата Славян @ Но правило одно! По́мните это, и будет немножко понятнее/очевиднее как быть в таком-то необычном случае (аки f(++i,++i)). Где про это правило можно почитать? Ниразу не встречал такого бреда. Наоборот на математике рассказывали что разные задачи можно и нужно решать разными способами, и по всюду приведенные тобою правила нарушаются, сокращаются целые выражения, перестанавливаются местами переменные и т.д. и т.п. Ты чушь какую то несешь ИМХО. |
Сообщ.
#56
,
|
|
|
Можно не спорить, ибо пруфов нет, какая-то отсебятина. Не понятно на чем основана. Конечно, неприятно, что такой по сути антинаучный подход выдаётся за науку. Но да фиг с ним
|
Сообщ.
#57
,
|
|
|
Цитата Wound @ Конечно другое! Просто свойства кольца целых чисел таковы, что значения выражений совпадут!С учетом того, что выше ты написал что в математике эта запись представляется как +(3, 2) Если я ее представлю как +(2 3) - это будет другое выражение? Или все тоже? Цитата Wound @ Меж выражениями разница огромна, меж значениями оных разница нулевая. Ваш кэп. То есть с твоей точки зрения есть разница между 3+2 и 2+3 ? Цитата Wound @ Значения равносильны, но не сами выражения. Сколько ж повторять то!!? Какое другое выражение? Любой ребенок знает что 3+2 это равносильно 2 + 3, ну кроме тебя естественно. Цитата Wound @ Ну откройте определение плюсика, увидите, что это бинарное отношение, с определёнными свойствами, а потому запись 3+4+5 лишена смысла в своём начальном определении плюсика. Однако далее, раскрывается коммутативность, ассоциативность и прочие детали, кои показывают=доказывают одинаковость выражений (3+4)+5 и 3+(4+5), что указывает на то, что запись "3+4+5" будем читать любым способом, коли дают одинаковый результат оба варианта.Я вот допустим тебе не верю, хочу убедиться что твои слова правдивые, ты можешь это доказать ссылкой на научную литературу? Или это всего лишь твои личные фантазии? Цитата Wound @ Наука.Кто она? Цитата Wound @ Там, где с азов, с определений натуральных чисел в теории множеств, дают определение бинарного отношения 'сложение', очевидно. Где про это правило можно почитать? Цитата Wound @ Эмоции... Печально, но для прогеров, коим вы, возможно, являетесь, допустимо. Ты чушь какую то несешь ИМХО. |
Сообщ.
#58
,
|
|
|
Славян, в математике запись 3+4+5 означает то же самое, что и 5+4+3, или 5+3+4, или 3+2+4-2+5.
С твоими ограничениями математика никому была бы не нужна. Кроме продавцов и покупателей в магазине. Возьми любую книгу с математическими выкладками и обнаружь, как её автор вовсю переставляет слагаемые в выражениях, приводит однородные члены, разбивает слагаемые на части, прибавляет/отнимает слагаемое (как 2 в последнем варианте), чтобы получить нужную ему формулу, часть которой можно как-нибудь преобразовать, чтобы получить совсем другую формулу. Вообще, в математике запись 3+4+5 означает сумму трёх указанных чисел без какого-либо ограничения порядка суммирования. Единственный случай, когда на порядок накладывают ограничение - это суммирование бесконечных рядов, не являющихся абсолютно сходящимися. Поскольку в этом случае изменение порядка суммирования меняет предел, к которому сходится его сумма. Ну и в какой-то мере это же ограничение присутствует в определении не сходящихся абсолютно несобственных интегралов (с бесконечными пределами). |
Сообщ.
#59
,
|
|
|
Цитата Славян @ Эх, korvin, korvin... Услышали звон, да не знаете... Суть же разговора не про эту запись (сложение чисел), а про запись f(++i,++i). Я-то тему с начала прочитал, и просто фейспалмил с каждого твоего поста. Цитата Славян @ Ну, кстати говоря, сказанное вами - ложь, ибо в науке такое не утверждается. А утверждается, что запись «3+4+5» будет означать запись «(3+5)+4», кою уже́ можно посчитать введёнными ранее определениями! Расскажи-ка, мистер словоблуд, в чём же разница между эквивалентностью и «будет означать». Приведи-ка научное определение термина «будет означать». Желательно со ссылкой на соответствующий научный труд. Цитата Славян @ Ну откройте определение плюсика, увидите, что это бинарное отношение, с определёнными свойствами А может ты просто процитируешь это «определение плюсика», с его определёнными свойствами? Добавлено Вопрос по теме: в чём разница между UB и unspecified? |
Сообщ.
#60
,
|
|
|
Цитата korvin @ Насколько я понимаю. UB - вообще неопределенный результат, например одно и тоже выражение может давать различный результат в зависимости от опций компилятора. Unspecified - стандарт не описывает как именно оно должно выполняться, но компилятор должен всегда выполнять код определенным образом, каким именно образом решают создатели компилятора. Вопрос по теме: в чём разница между UB и unspecified? |
Сообщ.
#61
,
|
|
|
Цитата korvin @ Вопрос по теме: в чём разница между UB и unspecified? UB - Не определенное поведение. Unspecified - Значит по разному на разных платформах/компиляторах. Например sizeof(int) - Unspecified. На разных платформах может иметь разный размер. Это на сколько я понял. |
Сообщ.
#62
,
|
|
|
Цитата OpenGL @ Может: гуманитарий, возомнивший себя спецом в точных науках. Ему невозможно объяснить, почему именно Эйнштейн получил нобелевку, и почему не за ТО, зато он непоколебим в своих выводах из этого, что Эйнштейн плагиатор, а все вокруг пользуются ТО, чтобы делать деньги на ничего неделаньи в науке и врать статьями в arXiv.org. Я поначалу хотел напомнить Славяну, что математика вообще-то начала развиваться, чтобы изучить законы счёта и тем упростить его, а не наоборот, и что именно доказанные коммутативный и ассоциативный законы дают нам возможность опускать скобки, а не ...хм, наоборот, но передумал. Хуже тролля может быть только тролль-зануда Добавлено Кинуться в него ссылкой на общие алгебры, что ли... где в других, отличных от арифметики, частных случаях коммутативность и/или ассоциативность не соблюдаются... а ещё делители нуля попадаются... Добавлено Цитата korvin @ Неопределённое поведение означает возможность абсолютно любого итога. Вызов нигде не вызываемой функции в случае разыменования пустого указателя, например. Неспецифицированное поведение означает конечность множества итогов, которое определяется конкретикой ситуации. Порядок вычисления операндов в выражениях хороший пример. Есть ещё определяемое реализацией поведение, когда итог в целом неспецифицирован, но всегда одинаков для конкретной реализации в конкретных условиях. Поведение кода при знаковом целочисленном переполнении, например. Вопрос по теме: в чём разница между UB и unspecified? |