Информация об изменениях

Сообщение Re[3]: c++ matches like rust от 13.11.2023 16:09

Изменено 11.01.2024 18:06 watchmaker

Re[3]: c++ matches like rust
Здравствуйте, reversecode, Вы писали:

_>>"Program terminated with signal: SIGSEGV" не смущает?


R>нет ;)

R>это последний ассерт, показать что оно работает
R>не.. можно конечно было сравнить с false

При чём тут сравнение? У тебя происходит падение из-за проезда по памяти есть ещё до проверки результата assert'ом — https://godbolt.org/z/1rv7jKGcr

R> можно конечно было сравнить с false

R> но так не интересно

Если это тест, то пиши в проверяемом условии то, что должно выполняться — и другим было бы понятнее, и тебе бы писали больше по делу, а не про глупые ошибки или про стиль.


Иногда, конечно, в системах тестирования нужно уметь сказать, что тест сейчас падает и для этого используется статус xfail, но assert такие нюансы не умеет выражать.

R> может кто улучит или дополнит


Кстати, о стиле: криво расставлены forward и ссылки.
Выглядит забавно, что сначала у аргументов старательно сохраняются типы при рекурсивных вызовах, но только чтобы в функции cmp их проигнорировать в строках
R>    return val(arr[idx]);
R>    else    return arr[idx] == val;

Впрочем, обычно это только производительность ухудшает.

Но вот выше в условии if constexpr (!std::is_integral<Arg>::value) эта проблема с неправильными ссылочными типами может влиять куда сильнее. Из-за неё вызовы заходят в разные ветки и начинаются проблемы:
    int b[1]={23};
    const int j = 23;
    assert(matches(std::span(b), 23));           //          компилируется
    assert(matches(std::span(b), j));            //       не компилируется
    assert(matches(std::span(b), std::move(j))); //    снова компилируется
Re[3]: c++ matches like rust
Здравствуйте, reversecode, Вы писали:

_>>"Program terminated with signal: SIGSEGV" не смущает?


R>нет ;)

R>это последний ассерт, показать что оно работает
R>не.. можно конечно было сравнить с false

При чём тут сравнение? У тебя происходит падение из-за проезда по памяти ещё до проверки результата assert'ом — https://godbolt.org/z/1rv7jKGcr

R> можно конечно было сравнить с false

R> но так не интересно

Если это тест, то пиши в проверяемом условии то, что должно выполняться — и другим было бы понятнее, и тебе бы писали больше по делу, а не про глупые ошибки или про стиль.


Иногда, конечно, в системах тестирования нужно уметь сказать, что тест сейчас падает и для этого используется статус xfail, но assert такие нюансы не умеет выражать.

R> может кто улучит или дополнит


Кстати, о стиле: криво расставлены forward и ссылки.
Выглядит забавно, что сначала у аргументов старательно сохраняются типы при рекурсивных вызовах, но только чтобы в функции cmp их проигнорировать в строках
R>    return val(arr[idx]);
R>    else    return arr[idx] == val;

Впрочем, обычно это только производительность ухудшает.

Но вот выше в условии if constexpr (!std::is_integral<Arg>::value) эта проблема с неправильными ссылочными типами может влиять куда сильнее. Из-за неё вызовы заходят в разные ветки и начинаются проблемы:
    int b[1]={23};
    const int j = 23;
    assert(matches(std::span(b), 23));           //          компилируется
    assert(matches(std::span(b), j));            //       не компилируется
    assert(matches(std::span(b), std::move(j))); //    снова компилируется