Именно так когда-то ещё учась в универе я узнал про точки следования на примере gcc для C++.
Сделал проект дома, прихожу в лабораторию, закидываю на местный компудахтер - а там другое значение выплёвывает. Путём проб и ошибок, а конкретно компилируя и запуская проект заново получал разные значения(отличия малые, но дальше ошибка расчётов шла по нарастающей и приводила к ошибке переполнения) :D
раскрыть ветку (29)
раскрыть ветку (27)
ещё комментарии
ну так-то жадный алгоритм компиляции и таблица приоритета операций говорит о том что операция будет выполнена в следующей последовательности:
1) пост-инкремент (i ++)
2) пре-инкремент (++i)
3) сложение
4) присваивание
Таким образом при исходном значении, скажем, 1, результат будет (в порядке применения операций):
0) i = i++ + ++ i;
1) i = 2 + ++ 1;
2) i = 2 + 2;
3) 4
раскрыть ветку (3)
Неверно. Не говорит. Выражение неопределено.
https://stackoverflow.com/questions/39900469/undefined-behav...
https://ru.wikipedia.org/wiki/Неопределённое_поведение
Причём это классический и широко известный пример.
раскрыть ветку (2)
раскрыть ветку (1)
Товарищ со Stackoverflow объяснил так (думаю, вы уже прочли). Хоть порядок операций над значпениям и определён, неизвестно в какой момент результат ++i превращается в значение.
Ещё есть вот тут:
https://en.cppreference.com/w/cpp/language/eval_order
Важный момент:
There is no concept of left-to-right or right-to-left evaluation in C++. This is not to be confused with left-to-right and right-to-left associativity of operators: the expression a() + b() + c() is parsed as (a() + b()) + c() due to left-to-right associativity of operator+, but the function call to c may be evaluated first, last, or between a() or b() at run time:
"В C++ нет понятия порядка вычисления. Это не стоит путать с порядком применения операторов. Выражение a() + b() + c() будет обработано как (a() + b()) + c(), из-за того, что оператор+ использует ассоциативность слева направо, но вызов функции c() может произойти первым, последним, или между a() и b() во время выполнения"
В случае с операторами ++, операторы имеют побочный эффект (увеличение значения i), который влияет на результат вычислений.
ещё комментарии
Нет. Если я правильно помню, грубо говоря, компилятор сам определяет в какой очерёдности выполнять ту или иную операцию в зависимости от текущего такта процессора, движения тектонических плит и движения небесных тел. И вот в эти моменты образуются для некоторых операций "сайдэффекты" или побочки. И вот как раз точки следования это места, которые гарантируют, что все такие "сайдэффекты" для отдельной операции пройдены.
Дальше в жизни с таким не сталкивался, да и C++ благополучно забыл)Но товарищи говорят, что сейчас такого вроде уже нет с новых стандартах)
Может, конечно, по прошествии лет чего путаю, так что лучше прочекать в англоязычных источниках называется "sequence point"
раскрыть ветку (21)
Это называется race condition и говорит о том что программа спроектирована логически неверно
раскрыть ветку (2)
Race condition - это, емнип, про многопоточную синхронизацию.
ТС же через вторые 90 пытался сказать, что есть случаи, в которых последовательность операций зависит от компилятора, например:
x = f() + g().
Какая функция будет вызвана первой - хъз. При этом если внутри f и g используется и меняется глобальная переменная - то результат неоднозначен, а программист - рукожоп.
ТС же через вторые 90 пытался сказать, что есть случаи, в которых последовательность операций зависит от компилятора, например:
x = f() + g().
Какая функция будет вызвана первой - хъз. При этом если внутри f и g используется и меняется глобальная переменная - то результат неоднозначен, а программист - рукожоп.
раскрыть ветку (1)
раскрыть ветку (17)
Я даже не знаю, что ответить на такое...
во-первых, рекомендую обратиться к Гуглу перед тем как писать такого рода комментарии,
во-вторых, я такой подход с использованием label и goto видел только в Fortran, в C++, я не сталкивался с кейсами, где его в принципе можно было применить
во-первых, рекомендую обратиться к Гуглу перед тем как писать такого рода комментарии,
во-вторых, я такой подход с использованием label и goto видел только в Fortran, в C++, я не сталкивался с кейсами, где его в принципе можно было применить
ещё комментарии
Вот я и удивился) С++ это ж ООПшная тема. Какие точки, если там можно нормально делать взаимодействие через объекты класса? Вот и спросил, что вы имели ввиду)
Отправлять меня в гугл не надо пожалуйста)
раскрыть ветку (15)
«Точка следования» это конкретный С++ термин. Если ты не знаешь что это такое... штош, я надеюсь ты не пишешь код на С++ в прод.
ещё комментарии
К счастью нет) И это С термин, перекочевавший в С++.
Точка следования конкретно устаревшая конструкция. Если ты пишешь в прод используя настолько архаичные методы, то твоим заказчикам я, мягко говоря, не завидую.
Не удивительно, что я его не знаю. Я не настолько стар, и с плюсами знакомился уже при наличии в них многопоточности.
раскрыть ветку (13)
«Точка следования» это такой же фундаментальный и вездесущей аспект языка, как «переменная», или «функция», или «константа». Как это, блин, может быть устаревшим? Это все равно что сказать что «переменные — архаичный метод»
ещё комментарии
Лол) Ты хрен с трамвайной ручкой перепутал. Читай мануал по многопоточности. Отправляли меня в гугл, а сами сходить не удосужились)
раскрыть ветку (8)
Чево блин? Я отлично разбираюсь в многопоточности. Я, блять, на работе пишу сраный многопоточный сервер. И я все ещё не понимаю твой доеб до точек следования. Весь код, который НЕ связан с синхронизаций разных потоков (а его большинство), точно так же описывается точками следования, как и 20 лет назад.
раскрыть ветку (6)
Тише, тише, дедуль. Тебе вредно волноваться) Открой хотя бы википедию, что ли. Если тяжело, давай скину скрин, вот, смотри: (с таким подходом надеюсь ты не пишешь сервер для чего-нибудь важного =) )
раскрыть ветку (4)
Новый стандарт С++ теперь использует более общую терминологию. И дальше что? В пределах одного потока все эти новые слова функционально эквивалентны точкам следования. Только код синхронизации потоков невозможно описать через точки следования.
ещё комментарии
А дальше то, что вместо нормального разговора ты выёбываться начал. Хотя в итоге мы пришли именно к тому, с чего я и начинал - точки следования сами по себе устарели и нах не нужны, поэтому не удивительно, что я о них не знал.
Будь ты норм человеком - извинился бы. Но я на это не надеюсь, не переживай)
раскрыть ветку (2)
Если ты понимаешь стандарт order of evaluation в С++11+, то я приношу извинения — мой наезд был необоснованный.
Но это довольно странно — понимать что-то более общее и не знать более частный и простой случай. Большая часть людей сначала изучает однопоточное программирование (и получает понимание о точках следования), а потом уже переходит к многопоточному. По этому я автоматически воспринял «не знаю что такое точки следования» как «не знаю что такое order of evaluation». Типа, если человек не знает частный случай, он скорее всего не знает и общий случай.
раскрыть ветку (1)
ещё комментарии
ещё комментарии
Смотри, проблема не в том, что используется "конструкция" устаревшая(оператор или архаичный подход). Это нормальное(для C++) поведение компилятора. Не зря этот ЯП является чуть ли не самым быстрым. Если утрировать то, вот такие "побочки", описанные коллегами по цеху выше, а именно вероятность смены порядка выполнения операций, являются одним из механизмов обеспечивающих эту высокую скорость работы за счёт оптимизаций производимых компилятором.
ещё комментарии
раскрыть ветку (2)
Ты про тс? Я вижу старички "плюсисты" те ещё высокомерные снобы) Нормально объяснить не могут, сразу выёбываться начинают. При том тем, что уже устарело сто лет в обед как. Печальное зрелище. Как дед, который считает, что ты пропадаешь по жизни, если не умеешь доить корову)
раскрыть ветку (1)
Да бывает такое, я тут тоже повыёбываться попробовал (хотя я даже не настоящий плюсист), получилось не очень :D
ещё комментарии
ещё комментарии
ещё комментарии
ещё комментарии
IT-юмор
7.5K поста53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору