true(204) в C++ что за зверь?

[MGM]

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

-- Чт ноя 10, 2022 19:32:14 --

TheRuinedMap в сообщении #1569647 писал(а):

mihaild в сообщении #1569637 писал(а):

Покажите более содержательный кусок кода, и без bb тегов. Что такое true(204) - непонятно, это не скомпилируется.

Речь, очевидно, идет не о коде в программе, а об выводе значения переменной в окне дебаггера

mihaild в сообщении #1569637 писал(а):

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

Стандарт - не требует. Стандарт говорит, что оно implementation-defined (как, впрочем, и почти все остальные представления), то есть битовое представление будет требовать конкретная реализация. И, разумеется, показываться валидный bool в уважающем себя дебаггере конкретной реализации будет не "как угодно", а как true или false. А вот true(204) в дебаггере MSVC говорит о проблемах...

А почему true(204), а не false(204)?
По смыслу это значение именно false

[TheRuinedMap]

MGM в сообщении #1569649 писал(а):

Есть подозрение, что что позоимсвованный в сети самописный класс C++ для integer произвольной точности и байтовой длины перемнной имеет некие дефекты, которые выходят боком при инициализации.

Туманных подозрений можно напридумывать много.

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

-- 10.11.2022, 07:36 --

MGM в сообщении #1569649 писал(а):

А почему true(204), а не false(204)?

Потому что так выводит это значение дебаггер MSVC. Правильнее, конечно, было бы выводить его как undefined (204) или invalid (204).

MGM в сообщении #1569649 писал(а):

По смыслу это значение именно false

Это откуда вы такое взяли? О каком "смысле" вы здесь ведете речь?

[mihaild]

TheRuinedMap в сообщении #1569647 писал(а):

Речь, очевидно, идет не о коде в программе, а об выводе значения переменной в окне дебаггера

Мне не очевидно, что должно быть где-то написано, чтобы это цитировать как

MGM в сообщении #1569536 писал(а):

if([b]true [/b]&& [b]true(204)[/b]) = false;

Я спросил выше у ТС, о чем там была речь, но ответа пока не получил.

MGM в сообщении #1569649 писал(а):

А почему true(204), а не false(204)?

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

[MGM]

Выход за границы памяти в MS VS дебагере отслеживается очень точно прерыванием.
А вот если определен некий класс на базе <vector>, это уже трудно отследить.

[TheRuinedMap]

MGM в сообщении #1569652 писал(а):

Выход за границы памяти в MS VS дебагере отслеживается очень точно прерыванием.

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

[MGM]

TheRuinedMap в сообщении #1569650 писал(а):

MGM в сообщении #1569649 писал(а):

По смыслу это значение именно false

Это откуда вы такое взяли? О каком "смысле" вы здесь ведете речь?

Чисто функционально. По результату работы.
из bool a == 204 следует, что код рассматривает переменную а, как false.

Ну и код в рассширенном варианте (тело функции даю в явной форме):

bool equ_y = equal(BQ_LTYPE a = rct_fr[fr_i].qy, BQ_LTYPE b = rct_fl[fl_i].qy)
{
return a.ch == b.ch && a.z == b.z;
}
bool equ_x = equal(BQ_LTYPE a = rct_fr[fr_i].qx, BQ_LTYPE b = rct_fl[fl_i].qx)
{
return a.ch == b.ch && a.z == b.z;
}
if (equ_x  && equ_y) {
      rct_fr[fr_i].qx = set_BQ_LT(0, 1);
      rct_fr[fr_i].qy = set_BQ_LT(0, 1);
      rct_fr[fr_i].tx = set_BQ_LT(0, 1);
      rct_fr[fr_i].ty = set_BQ_LT(0, 1);
      return 0;
   }

Если equ_y == 204 и equ_x == true
То блок

if (equ_x * equ_y) {
      rct_fr[fr_i].qx = set_BQ_LT(0, 1);
      rct_fr[fr_i].qy = set_BQ_LT(0, 1);
      rct_fr[fr_i].tx = set_BQ_LT(0, 1);
      rct_fr[fr_i].ty = set_BQ_LT(0, 1);
      return 0;
   }

Не выполнялся. После того, как заменил последовательность вычисления
переменных equ_x и equ_y перестановкой строк, все заработало и 204 пропало.

[TheRuinedMap]

MGM в сообщении #1569663 писал(а):

TheRuinedMap в сообщении #1569650 писал(а):

MGM в сообщении #1569649 писал(а):

По смыслу это значение именно false

Это откуда вы такое взяли? О каком "смысле" вы здесь ведете речь?

Чисто функционально. По результату работы.
из bool a == 204 следует, что код рассматривает переменную а, как false.

Я, кажется, детально объяснил вам выше, что "код" может рассматривать такую переменную и как false, и как true, и как ни false, ни true, и как false и true одновременно.

В одном if ваша переменная повела себя как false, а в следующем if в вашем же коде она запросто поведет себя как true. А вы зачем-то прицепились к этому первому if и делаете на его основе какие-то далеко идущие выводы, хотя на самом деле поведение этого if не значит вообще ничего.

MGM в сообщении #1569663 писал(а):

Ну и код в рассширенном варианте (тело функции даю в явной форме):

bool equ_y = equal(BQ_LTYPE a = rct_fr[fr_i].qy, BQ_LTYPE b = rct_fl[fl_i].qy)
{
return a.ch == b.ch && a.z == b.z;
}
bool equ_x = equal(BQ_LTYPE a = rct_fr[fr_i].qx, BQ_LTYPE b = rct_fl[fl_i].qx)
{
return a.ch == b.ch && a.z == b.z;
}

Это что за язык программирования? Что это за загадочный синтаксис?

[MGM]

TheRuinedMap в сообщении #1569665 писал(а):

В одном if ваша переменная повела себя как false, а в следующем if в вашем же коде она запросто поведет себя как true. А вы зачем-то прицепились к этому первому if и делаете на его основе какие-то далеко идущие выводы, хотя на самом деле поведение этого if не значит вообще ничего.

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

TheRuinedMap в сообщении #1569665 писал(а):

MGM в сообщении #1569663 писал(а):

Ну и код в рассширенном варианте (тело функции даю в явной форме):

bool equ_y = equal(BQ_LTYPE a = rct_fr[fr_i].qy, BQ_LTYPE b = rct_fl[fl_i].qy)
{
return a.ch == b.ch && a.z == b.z;
}

Это что за язык программирования? Что это за загадочный синтаксис?

Вариант классического С:

inline bool  equal(BQ_LTYPE a, BQ_LTYPE b)
{
return a.ch == b.ch && a.z == b.z;
}

bool equ_y = equal(rct_fr[fr_i].qy,  rct_fl[fl_i].qy);
bool equ_x = equal(rct_fr[fr_i].qx,  rct_fl[fl_i].qx);

как-то не зашел.
Спасибо всем за полезные советы.

[mihaild]

Я ставлю на то, что либо fr_i выходит за границу, либо внутри rct_fr что-то не инициализированное.

TheRuinedMap в сообщении #1569665 писал(а):

Я, кажется, детально объяснил вам выше, что "код" может рассматривать такую переменную и как false, и как true, и как ни false, ни true, и как false и true одновременно.

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

[Schrodinger's cat]

mihaild в сообщении #1569672 писал(а):

Я ставлю на то, что либо fr_i выходит за границу, либо внутри rct_fr что-то не инициализированное.

Поддерживаю. Такие же ощущения.

[MGM]

Понял, что ничего не понял.
Код:

   bool fls = false;
   memset(&fls, 204, 1);
   int n = fls ? 1 : 0;
   cout << n << endl; 
   if (fls) exit(204);

Четко выплевывает процесс со значением n=1;
1

F:\Problem\Release\segment.exe (process 13024) exited with code 204.
То есть в все, как в Букваре.
Значит, в моем коде дебагер неправильно засветил значение переменной.
И на самом деле моя функция сравнения чисел вместо очевидного (по всем другим значениям из того же дебагера) true (!=0) возвращала false (0).
Могила. Ну да ладно, баг купировал горбушкой, и ладно.

[mihaild]

MGM в сообщении #1569746 писал(а):

Понял, что ничего не понял.

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

TheRuinedMap в сообщении #1569644 писал(а):

Ничего вы не купировали. Вы просто "спугнули" неопределенное поведение, скорее всего временно.

[TheRuinedMap]

MGM в сообщении #1569746 писал(а):

Значит, в моем коде дебагер неправильно засветил значение переменной.

Дебагер "засветил" все правильно. Но вы соврешенно ничего не поняли из тех объяснений, что вам тут приводили. Или даже не читали их?

MGM в сообщении #1569746 писал(а):

И на самом деле моя функция сравнения чисел вместо очевидного (по всем другим значениям из того же дебагера) true (!=0) возвращала false (0).

"...вместо очевидного true (!=0)..." Вы продолжаете пребывать в плену каких-то загадочных инопланетных теорий о том, что такое true... ¯\_(ツ)_/¯

[MGM]

mihaild в сообщении #1569752 писал(а):

MGM в сообщении #1569746 писал(а):

Понял, что ничего не понял.

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

TheRuinedMap в сообщении #1569644 писал(а):

Ничего вы не купировали. Вы просто "спугнули" неопределенное поведение, скорее всего временно.

И чего делать?
Если не принимать во внимание радикальное решение: просто выкинуть позаимствованный из сети класс BigInteger.
Собственно основной алгорим (даже серия алгоритмов) работал и работает правильно. Плюс начальная простая визуализация процесса.
Однако захотелось построить более внятную математическую модель с более детальной визуализацией. И все как-то поехало.
Не принципиально, поначалу.

А теперь вот даже не могу обмануть компилятор в простой передаче (int) параметра.

float a = 0;
int st =0; while(st++<N)a+=tree(...,..,  st,...);
inline int tree(...,.., int st,...){
cout << st <<endl;
a code;
}

То есть перед выполнением inline функции tree() значение st одно, а сразу же перед певым оператором внутри функции другое ( согласно cout << st).
Причем все остальные параметры, включая как простые, так и указатели на довольно стложные структуры - передаются правильно.
Иакое впечатление, что компилятор оптимизируя создает какие-то свои представления о значениях параметра. Повторяя предыдущий параметр цикла.


Но самое смешное, что если код функции непосредвсвенно вписать ручками - все ОК.

[TheRuinedMap]

MGM в сообщении #1570064 писал(а):

А теперь вот даже не могу обмануть компилятор в простой передаче (int) параметра.

float a = 0;
int st =0; while(st++<N)a+=tree(...,..,  st,...);
inline int tree(...,.., int st,...){
cout << st <<endl;
a code;
}

То есть перед выполнением inline функции tree() значение st одно, а сразу же перед певым оператором внутри функции другое ( согласно cout << st).

И это тоже, как и в предыдущем случае, скорее всего говорит о том, что вы чего-то не договариваете.

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

Чудес не бывает. Баги компиляторов - бывают. Но я почти уверен, что дело здесь все таки в ваших косяках, а не в багах компилятора.