Но всеже анализатор нужен.
Как видим, для Того, чтобы писать надежный код, требуются +- одни практики, вне зависимости от того, rust это, c++ или haskell
Когда я смотрю на исключение, выванное at, я понимаю, что лучше бы он упал с нормальным core dump-ом.
Все эти обработки ошибок внутри блиотечных функций никак не уменьшают работу программиста на написание надежного (с точки зрения требований его компании) кода. Потому что мы не можем полагаться на то, что вылетит из функции
Ну вот я не понимаю. Вот был код под линукс, который както вызывал эту функцию. Все работает, не падает. Потом переносим этот код под винду. Почему он вдруг упадет в compile time?
Отдельно можно разобрать пример лэшем в разных системах, который упомянут, но почемуто не разобран.
Я бы решил его, обмазавшись проверками по максимому. Проверка, что результирующая строка не пустая, проверка, что файл открылся, еще к-нибудь. Как решть эоо завтипами?
Ну посмотрел, не нашел ничего, что нельзя было бы покрыть обычными типами с проверкой в конструкторе. Да и тесты никто не отменял, чтоже в них плохого?
А вот вы скажите мне одну вещь. В этой статье рассматривается пример деления на 0. И для этого вводится специальный тип, который заставляет проверять, является ли делитель нулем. Но (не знаю, так ли в haskell) исключительной также является ситуация деления maxint на -1. Где это учитывается? Автор об этом забыл?
К сожалению я не понял, что от меня требуется. Гарантировать безопасность cnt>=64? Если сильно упороться, то в oop языках можно создать целый класс cnt, который принимает по ссылке вектор и имеет метод с выразительным именем, который проверяет, что не превысили размер вектора
У встроенных проверок есть одна неприятная особенность. Они могут неудовлетворять имеющейся инфраструктуре. Например, есть метод at, который бросает исключение. Но какое исключение? Есть ли в этом исключении нормальное описание проблемы? Stacktrace? А проект все это требует
Но всеже анализатор нужен.
Как видим, для Того, чтобы писать надежный код, требуются +- одни практики, вне зависимости от того, rust это, c++ или haskell
Анализаторы и в c++ можно использовать
Но смысл то не в том, чтобы дождаться паники, а в том, чтобы избавиться от всех unwrap
Это понятно. Я имею в виду как найти все такие места. И что делать с типами у которых unwrap метода нет
Когда я смотрю на исключение, выванное at, я понимаю, что лучше бы он упал с нормальным core dump-ом.
Все эти обработки ошибок внутри блиотечных функций никак не уменьшают работу программиста на написание надежного (с точки зрения требований его компании) кода. Потому что мы не можем полагаться на то, что вылетит из функции
Обычно я не разговариваю о производительности до предоставления замеров. И да, я писал кодер jpeg-а, и там было полно проверок
Не понял, при чем тут долго собирается.
И как потом убирать все unwrap из кода? Плюс хорошо, когда они есть.
Ну вот я не понимаю. Вот был код под линукс, который както вызывал эту функцию. Все работает, не падает. Потом переносим этот код под винду. Почему он вдруг упадет в compile time?
Но это в том числе усложняет прототипирование, когда нужно 2 дня разбираться в иерархии классов вместо написания кода.
Просто для того, чтобы за ними следить, нужно терпение, которого не хватает и на завтипы
Ну я не увидел что хотел. Думал увидеть как это используется. Не получится ли так, что ошибка "скроется" типами и под виндой также проскочит?
Ну и как бы это выглядело хотябы в псевдокоде?
Я не понял, а если деление вещественное, разве на него действуют правила деления на 0?
Отдельно можно разобрать пример лэшем в разных системах, который упомянут, но почемуто не разобран.
Я бы решил его, обмазавшись проверками по максимому. Проверка, что результирующая строка не пустая, проверка, что файл открылся, еще к-нибудь. Как решть эоо завтипами?
Ну посмотрел, не нашел ничего, что нельзя было бы покрыть обычными типами с проверкой в конструкторе. Да и тесты никто не отменял, чтоже в них плохого?
А вот вы скажите мне одну вещь. В этой статье рассматривается пример деления на 0. И для этого вводится специальный тип, который заставляет проверять, является ли делитель нулем. Но (не знаю, так ли в haskell) исключительной также является ситуация деления maxint на -1. Где это учитывается? Автор об этом забыл?
А нам предлагают еще и подушкой безопасности защитить
Нужно смотреть конкретный пример, а не гадать почем зря
А извиняюсь, с мобильника не удобно. Но проблем все равно не вижу. Проверки, тесты, что-то можно повыносить в классы
К сожалению я не понял, что от меня требуется. Гарантировать безопасность cnt>=64? Если сильно упороться, то в oop языках можно создать целый класс cnt, который принимает по ссылке вектор и имеет метод с выразительным именем, который проверяет, что не превысили размер вектора
У встроенных проверок есть одна неприятная особенность. Они могут неудовлетворять имеющейся инфраструктуре. Например, есть метод at, который бросает исключение. Но какое исключение? Есть ли в этом исключении нормальное описание проблемы? Stacktrace? А проект все это требует
А о каком проекте вообще речь?