нет, нельзя сравнивать числа с плавающей точкой на полное равенство вообще.

так, ну это точно минус. Так как можно, да, не всегда - да.

так, ну это точно минус. Так как можно, да, не всегда - да.

Тупо логически относительная погрешность деления выше 100 не является степенью двойки На деле не знаю

так, ну это точно минус. Так как можно, да, не всегда - да.

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

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

float a = 0.5; float b = 0.5; a == b; Будут равны, если все по ieee754 делать.

Ну это из банального.

так себе арифмеика, конечно

ну да, потому что в двоичном представлении AFAIK 0.5 слишком легко представить

ну да, потому что в двоичном представлении AFAIK 0.5 слишком легко представить

да там хоть 0.3 напиши.

0.3 степенями двойки представить сложнее, а вот 0.5 это 2^-1

https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon realtimecollisiondetection.net/blog/?p=89

float a = 0.5; float b = 0.5; a == b; Будут равны, если все по ieee754 делать.

Тут скорее компилятор в true сам соптимизирует. В общем случае сравнивать вещественные числа в лоб нельзя.

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

Тут скорее компилятор в true сам соптимизирует. В общем случае сравнивать вещественные числа в лоб нельзя.

Если числа получены одним и тем же способом, то на == надеятся таки можно К примеру, если оба значения считаны с потока

вы б про мой вопрос не забывали

есть ли гарантия, что 123.23 == 12323. / 100.?

этот

Ну судя по комментарию Гугла почему нет Звучит логично

Но и почему да - тоже непонятно.

этот

какого рода гарантия? на x86 для конкретно этих литералов — да, равны. но это же дичь, пчем эти хаки

@Ioann_V ты там меня спрашивал для каких литералов не будет работать пока не потёр. например 0.2+0.2+0.2 == 0.6 должен дать false

омг

я спрашивал про мой пример

а у тебя тут summation

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

а у тебя тут summation

0.6 / 3. == 0.2 устроит?

не устроит

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

И повторюсь, вопрос в том, почему гуглоисты пмшут что все ок.

/cppref

https://en.cppreference.com/w/cpp/string/char_traits/length

как перехватить параметры у функций и очистить их от все мадефикаторов ?

std::remove_cvr вроде

а для вариайдик темплайты ?

так при чем тут это. 10 и его степени, могут быть точно представлены double ом, ащет.

Как раз нет. В этом и дело

Как раз нет. В этом и дело

вообще то, да. В каких случаях нет?

Кроме тех, когда степень огромна.

а для вариайдик темплайты ?

надо сделать рекурсивную специализацию

есть ли гарантия, что 123.23 == 12323. / 100.?

Нет, конечно, 123.23 нет в природе

есть ли гарантия, что 123.23 == 12323. / 100.?

123.23 округлится до ближайшего представимого значения

Скорее всего например 0.5 == 1.0/2, но лучше так не делать вообще.

В Boost.Spirit есть стандартное правило для парсинга имени переменной?

В Boost.Spirit есть стандартное правило для парсинга имени переменной?

Id?

Id?

Не понимаю, но нет, скорее всего

возможно как-то hbitmap перевести в массив байтов, чтобы отправить через сокет?

без лишних либ

gdi вылетает почему-то

без лишних либ

http://www.vsokovikov.narod.ru/New_MSDN_API/Bitmaps/fn_getdibits.htm

а если send для отпрвки принимает char*, то достаточно будет результат getDIBits привести к char*?

где-то писали, что в c++ char это посути байты

а есть что-то ещё?)

а есть что-то ещё?)

std::byte

возможно как-то hbitmap перевести в массив байтов, чтобы отправить через сокет?

Можно... Но слать bitmap куда-то как-то не айс наверное....

char это по сути целочисленный тип. а символы просто представленный каким-то значением

а если send для отпрвки принимает char*, то достаточно будет результат getDIBits привести к char*?

Да, будет достаточно

Вопрос из прографона: union foobar{ struct foo{ int bar() { return 5} } foo a; int b; } foobar x; x.b=8; x.a.bar()//UB?

да, потому что "не определено обращение к члену юниона, если был инициализирован другой"

Патамушта кроссплатформенность

Часто этим UB пользуются

union { char a[sizeof(int)]; int b; } e; e.b = 1; if (e.a[0]) // little endian platform else // big endian platformкак пример

да, потому что "не определено обращение к члену юниона, если был инициализирован другой"

Тут ключевой момент в том что можно ли вызвать функцию в поде которая не трогает поля

Я так понял нет

а почему бы её не сделать статической, если она не трогает поля?

Вопрос звучит именно так

ну, в целом можно считать, что UB

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

если у тебя в юнионе нетривиальный тип с vtable, то отладка может быть очень интересной

Уб не предполагает разрушений

уб не запрещает разрушения

https://habr.com/company/infopulse/blog/338812/