[k155la3 26]

CPP / GCC / Linux  Оператор присваивания, с делением на НОЛЬ

Прорабатываю чужой код (c Github), и встретилось НЕЧТО для меня непонятное, как черная дыра.

            if (right->type == NUMBER && right->data.value == 0.0) 
			{
                root->type = NUMBER;
>>>>            root->data.value = 1.0 / 0.0;   // root->data.value == long double
                delete_node(left);
                delete_node(right);
                break;
            }

А как же .... как же школа, 2/3 класс .... надо достать учебник и перечитать ....

Правда компилятор MSVS ругается error C2124: divide or mod by zero
Или это "закладка" автора от "тупой" компиляции и использования ?

[_4afc_ 24]

Попробуйте корень из -1. Возможно так NAN присваивают...

[_pv 52]

инициализация значения в inf? чтобы отличать "неинициализированную" переменную от числа

[k155la3 26]

9 minutes ago, _4afc_ said:

Попробуйте корень из -1. Возможно так NAN присваивают...

да, возможно. Наверное в GCC компилятор пропускает это (на рантайм все-равно вылезет).

9 minutes ago, _pv said:

инициализация значения в inf? чтобы отличать "неинициализированную" переменную от числа

по всей видимсти, да.

 

Всем спасибо за инф.

[jcxz 184]

19 минут назад, _4afc_ сказал:

Попробуйте корень из -1. Возможно так NAN присваивают...

Если так, то это ужасно кривой метод. Почему не сделать нормально?:

//спец.значения float: +NaN и -NaN
union {
  u32 i;
  float f;
} const constPNaN = {B31 - 1}, constNNaN = {B31 - 1 | B31};

 

[_pv 52]

1 hour ago, jcxz said:

Если так, то это ужасно кривой метод. Почему не сделать нормально?:

может потому что это ещё хуже, так как "The value representation of floating-point types is implementation-defined"
в коде похоже как раз разбирается арифметическое выражение, и автор просто переложил на компилятор расхлёбывать деление на 0, тем же образом как плавучка в этом компиляторе и реализована.

[jcxz 184]

7 минут назад, _pv сказал:

может потому что это ещё хуже, так как "The value representation of floating-point types is implementation-defined"
в коде похоже как раз разбирается арифметическое выражение, и автор просто переложил на компилятор расхлёбывать деление на 0, тем же образом как плавучка в этом компиляторе и реализована.

Чем же хуже? Тем что это работает, а то что заложил некий автор - не работает?  

И в каких современных компиляторах у нас плавучка не IEEE, а какой-то свой доморощенный формат?

Ну а если уж так этого бояться, то можно заложить соответствующий #ifdef/#endif для всех имплементаций.

[_pv 52]

51 minutes ago, jcxz said:

Чем же хуже? Тем что это работает, а то что заложил некий автор - не работает?  

И в каких современных компиляторах у нас плавучка не IEEE, а какой-то свой доморощенный формат?

Ну а если уж так этого бояться, то можно заложить соответствующий #ifdef/#endif для всех имплементаций.

не работает оно исключительно из-за своеобразного (как всегда впрочем) понимания микрософтом стандартов.

гцц и шланг знают что 1.0/0.0 == INF, а msvc почему-то нет.

не уверен точно, но вроде бы IAR и visualDSP умели в 16ти битные floatы. Ваш constPNaN им скорее всего тоже не понравится.

тем более что у ТС не float, а вообще long double с непонятной разрядностью.

[k155la3 26]

2 hours ago, jcxz said:

Если так, то это ужасно кривой метод. Почему не сделать нормально?: . . . 

Это интерпретатор формул. Возможно, сделано умышленно, тк "аффтар" формулы может написать в строке что угодно, в том числе и деление на ноль и "скормить" ЭТО интерпретатору. Хотя мне это тоже, подсазнательно, не нравится.

A parser and calculator for mathematical formulas written in C

https://github.com/ruester/fp  

 

Полностью скомпилировать код на MSVC не получиось по причине отсутствия нескольких макро-переменных и много-чего правки вручную.

 У меня нет необходимости компиляции, интересен подход в разборе формулы.

[k155la3 26]

26 minutes ago, _pv said:

. . . гцц и шланг знают что 1.0/0.0 == INF, а msvc почему-то нет. . . .

MS останавливает "шаловливые ручки" уже на этапе компиляции когда видит набор знаков "/ 0.0". Грубая ошибка, INHO, которую в здравом уме не сделаешь.

(разве что в контексте искуственного создания ошибочных значений inf-nan о которых упоминали выше)

Более правильные компиляторы дадут ошибку на этапе исполнения, дабы аффтар осознал свой IQ.

(в случае этого кода - автора строки с ошибочной формулой которую задали исполнять интерпретатору)

 

ps

Да, в коде есть упоминание об "inf" в виде строки

static char *ldtostr(long double d)
{
    unsigned int digits;
    char *ret;
    long double h;

    if (d == HUGE_VAL || d == -HUGE_VAL)
        return (strdup("inf"));

. . . . 
. . . .

 

[jcxz 184]

39 минут назад, _pv сказал:

не уверен точно, но вроде бы IAR и visualDSP умели в 16ти битные floatы. Ваш constPNaN им скорее всего тоже не понравится.

Мой constPNaN взят как раз из проекта IAR.  

[amaora 20]

Тоже так делаю, и да пришлось написать через union, чтобы все компиляторы понимали.

[dxp 32]

Если нужны эти магические числа NaN, INF, то почему бы их просто не взять из стандартной cmath?

[esaulenka 5]

On 4/25/2019 at 7:59 AM, dxp said:

Если нужны эти магические числа NaN, INF, то почему бы их просто не взять из стандартной cmath?

Вот он, голос разума! :-)

https://en.cppreference.com/w/cpp/numeric/math/NAN

https://en.cppreference.com/w/cpp/numeric/math/INFINITY

 

[k155la3 26]

1 hour ago, esaulenka said:

Вот он, голос разума! :-) . . .

Ok Спасибо за инф.