"Тру" и "не тру" программирование

@Panic · Регистрация: 03.06.2015

Студворк — интернет-сервис помощи студентам

Здравствуйте. Ниже два куска простейшего кода, которые по функция совершенно идентичны (проверка чисел на соответствие опр. параметру).
Первый:

C++
1
2
3
4
5
6
7
8
9
10
11
12
do
{
    cin >> m >> y;
 
    if ( (m != int(m)) || (y != int(y)) )
    {
        cout << "Сообщение";
        continue;
    }
    break;
}
while (true);

Второй:

C++
1
2
3
4
5
6
7
8
9
10
11
do
{
    cin >> m >> y;
 
    if ( (m != int(m)) || (y != int(y)) )
    {
        cout << "Сообщение";
    }
 
}
while ( (m != int(m)) || (y != int(y)) );

Вопросы: Почему первый вариант, по словам моего преподавателя, "не тру", а второй "тру"? И предпочтительнее ли, в таком случае, второй вариант?

@SatanaXIII · 04.06.2015, 15:57

Не по теме:

Tulosba, плохая шутка. Не понравилась.

Tulosba · 04.06.2015, 16:01

Сообщение от Enno

Доступ к любому стеку есть у любого потока процесса (это ж просто кусок памяти), если мы windows обсуждаем.

Ой ли? Так может и с одного процесса можно в память другого нагадить без лишних хлопот? А как же защищенный режим и виртуальное адресное пространство?

Сообщение от Enno

Тему не читал, сразу отвечал.

Вот что было действительно абсурдно.

Добавлено через 1 минуту

Не по теме:

Сообщение от SatanaXIII

плохая шутка. Не понравилась.

Почему? Он любит флаги и паровозы :)

@SatanaXIII · 04.06.2015, 16:08

Не по теме:

Сообщение от Tulosba

Почему? Он любит флаги и паровозы

Потому что я не знаю кто это; а загуглив, я выяснил, что это какой-то хрен из какого-то сериала.
Может, для осведомленных людей шутка и знатная, но не для этого раздела она. На мой взгляд. В обовсеме наверное больше народу смотрит всякую фигню.

@ct0r · 04.06.2015, 16:13

Сообщение от Enno

Разумеется

Разумеется нет

Без синхронизации этот код абсолютно бесполезен. Его поведение непредсказуемо.

@Enno · 04.06.2015, 16:44

Сообщение от Tulosba

А как же защищенный режим и виртуальное адресное пространство?

Потоки это не касается. В пределах одного процесса живём. Как минимум я дал понять что двойное проведение проверки совсем ни к чему и описал возможные причины неопределённого поведения. Можно сюда присовокупить затраты на проведение проверки.

@mymedia · 04.06.2015, 18:03

Сообщение от Enno

Потоки это не касается. В пределах одного процесса живём. Как минимум я дал понять что двойное проведение проверки совсем ни к чему и описал возможные причины неопределённого поведения. Можно сюда присовокупить затраты на проведение проверки.

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

@Kastaneda · 04.06.2015, 18:14

Сообщение от ct0r

Без синхронизации этот код абсолютно бесполезен

А с синхронизацией полезен? Кто будет писать

C++
1
std::cin >> value; // value шарится между потоками

в двух потоках?

@ct0r · 04.06.2015, 22:17

Сообщение от Kastaneda

А с синхронизацией полезен

Может быть полезен. По крайней мере он будет делать то, что должен.

Сообщение от Kastaneda

Кто будет писать в двух потоках?

Не понял. Кто сказал, что эту строчку надо писать в других потоках?

@Enno · 05.06.2015, 04:33

Сообщение от mymedia

присовокупить работу оптимизатора

Ну-ка, что за оптимизатор такой, который вызов 10 операций/функций в различных местах переводит в 5 в одном месте.

Сообщение от mymedia

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

Это я и дал понять несколькими постами выше. Хорошо что вы со мной согласны.

@ct0r · 05.06.2015, 12:51

Сообщение от mymedia

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

Кстати volatile совсем не об этом и совсем не для этого.

@mymedia · 05.06.2015, 13:05

Сообщение от Enno

Ну-ка, что за оптимизатор такой, который вызов 10 операций/функций в различных местах переводит в 5 в одном месте.

Ну, тут я имел ввиду, что в оригинальном посте

Сообщение от Panic

C++
1
2
3
4
5
6
7
8
9
do
{
  cin >> m >> y;
  if ( (m != int(m)) || (y != int(y)) )
  {
    cout << "Сообщение";
  }
}
while ( (m != int(m)) || (y != int(y)) );

оптимизатор может выкинуть вторую проверку условия цикла: ведь если сообщение выводится, то ясно, что цикл уйдёт на следующую итерацию, т.к. в теле условной инструкции m и y не изменяются. Однако и в правду, gcc версии 5.1 с опцией -O3 оптимизирует код как-то наполовину: после ввода m и y происходит проверка условия, если оно ложно, то сразу происходит выход из цикла, иначе выводится сообщение и снова (!) проверяется неизменившееся условие. Т.е. оптимизация произошла, но как-то наполовину…

Сообщение от ct0r

Кстати volatile совсем не об этом и совсем не для этого.

Как раз-таки именно для этого. Чтение volatile объекта вызывает побочные эффекты, а, следовательно, это действие нельзя выкинуть из программы.

@ct0r · 05.06.2015, 13:25

Сообщение от mymedia

Чтение volatile объекта вызывает побочные эффекты, а, следовательно, это действие нельзя выкинуть из программы.

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

Сообщение от mymedia

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

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

volatile нужен для работы со специальной памятью типа memory-mapped IO, где оптимизация чтений/записей приводит к незапланированному поведению. А потоки тут мимо кассы.

Добавлено через 8 минут

Сообщение от mymedia

оптимизатор может выкинуть вторую проверку условия цикла: ведь если сообщение выводится, то ясно, что цикл уйдёт на следующую итерацию, т.к. в теле условной инструкции m и y не изменяются. Однако и в правду, gcc версии 5.1 с опцией -O3 оптимизирует код как-то наполовину: после ввода m и y происходит проверка условия, если оно ложно, то сразу происходит выход из цикла, иначе выводится сообщение и снова (!) проверяется неизменившееся условие. Т.е. оптимизация произошла, но как-то наполовину

Потому что компилятору сложно понять, что же делает строка cout << "Сообщение" - там довольно нетривиальный код. Достаточно поменять этот вызов на вызов простой функции, и оптимизация пройдет.

@DrOffset · 05.06.2015, 13:43

Сообщение от ct0r

вызывает мягко говоря недоумение

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

Добавлено через 6 минут
Насчет стандартного поведения volatile (и того, почему он не подходит для организации синхронизации для потоков) есть очень хороший ответ здесь. Лично я с ним полностью согласен.

@ct0r · 05.06.2015, 14:01

Сообщение от DrOffset

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

Вот оно как.

Оказывается, у них есть магическая опция компилятора, которая позволяет писать непортируемый код c volatile, внезапно реализующей модель памяти release-acquire. Но мне это знание точно не пригодится

Evg · 05.06.2015, 14:19

Не по теме:

Извините, не удержался. Знатокам оптимизаций и стандартов. Соптимизирует ли компилятор два обращения из указателя p, который смотрит на const (хоть и volatile)?

C
int foo (volatile const *p)
{
  return *p + *p;
}

@mymedia · 05.06.2015, 14:21

Сообщение от ct0r

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

Сообщение от mymedia

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

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

Вы, кажется, не так пониммаете volatile. Вот код (конечно, не образец, но как примитивная реализация блокировки сойдёт):

C++
1
2
3
4
5
6
7
8
9
volatile bool flag = true;
void thread1() {
  pause();
  flag = false;
}
void thread2() {
  while (flag) { }
  do_something();
}

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

Сообщение от ct0r

Потому что компилятору сложно понять, что же делает строка cout << "Сообщение" - там довольно нетривиальный код. Достаточно поменять этот вызов на вызов простой функции, и оптимизация пройдет.

Да, забыл дописать: когда я проверял тот код, я объявлял m и y как локальные в функции main. Поэтому вот это странно, потому что в функцию operator<< мы не передаём адреса m и у и мы не объявили их как volatile. Следовательно, operator<< не может изменить значения этих перемнных (без создания неопределённого поведения).

Evg · 05.06.2015, 14:24

Не по теме:

Кстати, ct0r, всё правильно написал, volatile придумали вовсе не для синхронизации

@mymedia · 05.06.2015, 14:41

DrOffset, хорошо, согласен. Мой код с потоками не стоит так писать.

@ct0r · 05.06.2015, 15:36

Сообщение от mymedia

Если запустить эти потоки одновременно, то функция do_something всё-таки будет вызвана. Однако если вы уберёте volatile, код отработает не так, как ожидалось

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

Сообщение от Evg

Соптимизирует ли компилятор два обращения из указателя p, который смотрит на const (хоть и volatile)?

Не должен. volatile говорит не оптимизировать разыменования, а const просто говорит о том, что лично я не собираюсь менять объект, а не то, что он не может изменяться.

Evg · 05.06.2015, 15:56

Сообщение от ct0r

const просто говорит о том, что лично я не собираюсь менять объект, а не то, что он не может изменяться

Ога. Но не все про это знают.Многие считают что const от слова "константа", а на самом деле правильно переводить как "немодифицируемый"

Новые блоги и статьи Все статьи Все блоги /
сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .	Сукцессия 20. Война автоботов. Делаем ставки. Лёд против "пш-пш!". anaschu 11.07.2026 Битва ИИ в ризосфере: Как мы скрестили жесткие ОДУ, закон Фика и «подземный шантаж» Уважаемые коллеги! Хочу поделиться уникальным опытом ведения междисциплинарной компьютерной разработки. Прямо. . .	Сукцессия 19. Какие выводы я сделал из модели? Часть 2.Внутримикоризный стехиометрический буфер и хроно-дискретные зоны экспансии anaschu 11.07.2026 Био-Инженерный Ликбез: Архитектура Модели Ризосферы Математический аппарат моделирования	Сукцессия 18. Какие выводы я сделал из войны грибов с деревьями? Часть 1- рассказ и немного про термины anaschu 11.07.2026 Био-Инженерный Ликбез: Архитектура Модели Ризосферы Математический аппарат моделирования Система ОДУ описывает динамику изменения массы различных компонентов системы во времени. Ключевой. . .
Просветление в 5 секунд kumehtar 10.07.2026 Андрей Веретенников выдал фразу недавно: "Вам не обязательно кем-то себя считать"	Эксперимент с картинкой-обложкой на CodinGame Adler 10.07.2026 Решил на днях провести эксперимент. У меня есть аккаунт на CodinGame, ТОП-3 по РФ среди 2200 участников (в разделе соревнования по программированию ИИ-ботов). Там есть обложка, куда можно влепить. . .	GitDOS: Когда я решил скрестить MS-DOS, GitHub и Claude MaGz GoLd 08.07.2026 Привет, Киберфорум! Хочу поделиться своим проектом, который, надеюсь, вас заинтересует. GitDOS — это веб-приложение, которое позволяет запускать DOS в браузере с тремя крутыми фичами: диски живут в. . .	Учебный мини "цифровой двойник" = (Сервер = Java + Flask_питон )+(3D = Гугловскаая 4T nvideo + google colab) +( WMS = Odoo на Docker) anaschu 07.07.2026 Увидел в требованиях к вакансии создателя имитационных моделей связку (REst + Api + WMS + Anylogic + питон + 3D Nvideo), и решил посмотреть, что это такое. Из этого всего я работал более менее. . .

@SatanaXIII
	04.06.2015, 15:57
	Не по теме: Tulosba, плохая шутка. Не понравилась. 0

Evg
	05.06.2015, 14:19
	Не по теме: Извините, не удержался. Знатокам оптимизаций и стандартов. Соптимизирует ли компилятор два обращения из указателя p, который смотрит на const (хоть и volatile)? C int foo (volatile const p) { return p + *p; } 0

Evg
	05.06.2015, 14:24
	Не по теме: Кстати, ct0r, всё правильно написал, volatile придумали вовсе не для синхронизации 0

@mymedia 196 / 197 / 120 Регистрация: 27.05.2011 Сообщений: 545
	05.06.2015, 14:41
	DrOffset, хорошо, согласен. Мой код с потоками не стоит так писать. 0