Re[30]: error is not an exception
От: reductor  
Дата: 30.11.05 17:45
Оценка:
Здравствуйте, eao197, Вы писали:


E>>>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы?


R>>Да.


E>

E>А мужики-то и не знают...


счастье — в неведении.


E>Лично со мной на эту тему спорить бесполезно. Разве что опубликовать этот способ.


Все значимые публикации по теории типов, лямбда-исчислению, комбинаторной логике, SKI-исчислению, изоморфизму Карри-Говарда и теории категорий лежат в свободном доступе и находятся через любой поисковик.


E>Чей-то мне она вспомнилась. :xz:


Замечательный и важный для темы случай.
Очень интересная, наверное, конференция была. И очень научная.


На этом позвольте прекратить свое участие в этой теме.
Re[31]: error is not an exception
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.05 17:51
Оценка:
Здравствуйте, reductor, Вы писали:

R>счастье — в неведении.


Причем неведают все. Ладно сообщество Linux-оидов никак баги из ядра вычистить не могут. Но вот MS-то чего глюкавый софт пишет? Уж они-то могли себе позволить лучшие наработки в этой области на службу поставить.

R>Замечательный и важный для темы случай.

R>Очень интересная, наверное, конференция была. И очень научная.

Конференция-то нормальная была. Просто на открытии в президиуме сидел какой-то мужик, замминистра какого-то, вот он ее и выдвинул на трибуну, вместо какого-то профессора, который должен был свой доклад прочитать. Любят во власти такого рода шарлатанов.

А в науке, похоже, верят, что программы можно писать без ошибок.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: error is not an exception
От: GlebZ Россия  
Дата: 30.11.05 18:22
Оценка:
Здравствуйте, eao197, Вы писали:

E>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы?

Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать. До некоторой степени можно проверить простейшие случаи опытным путем с помощью unit-тестов. Но тут есть одна проблемка. Все это работает до тех пор, пока мы можем доказанно описать входные и выходные параметры. Ну например, у нас на входе есть некоторая грамматика, допустим состоящая из 20 лексем. Тогда всего количество цепочек лексем у нас будет 20^20, считай что неисчеслимо. В результате, проверить все мы физически не сможем. Если мы сможем из этих лексем построить вполне понятную мат. модель соответсвия к результатам, то добавив полученную мат. модель вычислений из функционального языка вполне возможно.
Для доведения до некоторого уровня надежности, обычно применяют свои методики(коих дост. много). Ну например, у нас входной параметр находится на некоторой числовой прямой. Мы берем минимальное значение, максимальное значение и некоторое значение из середины. После unit теста с некоторой эвристической вероятностью мы можем утверждать что функция работает.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Вот подумалось
От: _Winnie Россия C++.freerun
Дата: 30.11.05 18:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, _Winnie, Вы писали:


V>Вот у тебя очень показательная ошибка. Надо писать так:

V>
V>goto ошибка_снять;
V>goto ошибка_положить;
V>goto ошибка_журналировать;
V>


V>а последний кусок вообще надо в обратном порядке:

V>
V>ошибка_журналировать:
V>    rollback(&бо_журнализовать);
V>ошибка_положить:
V>    rollback(&бо_положить);
V>ошибка_снять:
V>    rollback(&бо_снять);
V>    return false;
V>



V>Т.е. самому вручную раскручивать стек в правильном порядке. Если бы ты использовал исключения, то тебе правильный порядок был бы гарантирован.



Не-не-не.

Я не написал, но подразумевал, что объект, который инициализирован по-умолчанию — можно безопасно убить.
банковская_операция_t бо_снять = { 0 };


Товарищ, вы мало программировали на C

Вот такой же безопасный код:

void f()
{
    FILE *file = NULL;
    char *name = NULL;
    char *last_name = NULL;

    file = fopen("data.txt", "rb");
    if (!file)  goto error;

    name = (char*)malloc(name_len + 1);
    if (!name)  goto error;

    last_name = (char*)malloc(last_name_len + 1);
    if (!last_name)  goto error;

    /* работаем с файлом и памятью */
error:
    if (file)
        fclose(file);
    free(name);
    free(last_name);
}


это общеизвестный goto cleanup паттерн.

Ну хорошо.
То, что это на С, это я выпендрился.


Кстати, у меня в коде настоящая ошибка, которую вы не заметили.
локал_строка("TRANSER_MONEY_FROM_TO") 
локал_строка("TRANSFER_MONEY_FROM_TO")




bool снять_положить_записать_на_C_plus_plus(банк_t *банк, аккаунт_t *откуда, аккаунт_t *куда, кол_денег_t сколько) 
{
    банковская_операция_t снять = банк->снять_деньги(откуда, сколько);
    if (!снять) return false;
    банковская_операция_t положить = банк->положить_деньги(куда, сколько);
    if (!положить) return false;
    std::string формат_мессаги;
    if (!локал_строка("TRANSER_MONEY_FROM_TO", формат_мессаги))
        return false;
    банковская_операция_t журнализовать = банк->записать(формат_мессаги, откуда->имя(), куда->имя(), сколько.m_количество_в_копейках);
    if (!журнализовать) return false;

    commit(снять, положить, журнализовать);
    
    return true;
}


Мда. Всё-таки с исключениями проще...
Придётся согласиться.

#define CHECK(x) if (!x) return false;

void снять_положить_записать_на_C_plus_plus(банк_t *банк, аккаунт_t *откуда, аккаунт_t *куда, кол_денег_t сколько) 
{
    банковская_операция_t снять = банк->снять_деньги(откуда, сколько);
    банковская_операция_t положить = банк->положить_деньги(куда, сколько);
    банковская_операция_t журнализовать = 
        банк->записать(
            локал_строка("TRANSFER_MONEY_FROM_TO", формат_мессаги), 
            откуда->имя(), куда->имя(), сколько.m_количество_в_копейках);
    commit(снять, положить, журнализовать);
}
Правильно работающая программа — просто частный случай Undefined Behavior
Re[9]: error is not an exception
От: GlebZ Россия  
Дата: 30.11.05 19:44
Оценка:
Здравствуйте, IT, Вы писали:

IT>У меня есть как минимум две причины.

[...skipped]
Занятно. Только что нашел на блоге Tess Ferrandes Are you aware that you have thrown over 40,000 exceptions in the last 3 hours?
Оттуда:

So why are they so bad? If they are handled and the end users don’t see them are they really harmful?
I can think of 3 reasons off the top of my head.
Exceptions are expensive.
Exceptions can take you into unnecessary code paths.
Exceptions are generally thrown when something went wrong.


С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: error is not an exception
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.05 23:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

E>>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы?

GZ>Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать.

Ребята, ни в моем вопросе, ни в утверждениях Губанова или reductor-а не было ограничений на функциональные языки или объемы программ.
Поэтому все это отговорки, мол где-то когда-то и пр...
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Вот подумалось
От: Костя Ещенко Россия  
Дата: 01.12.05 01:16
Оценка:
Здравствуйте, reductor, Вы писали:

R>>>Но конечно основной смысл в том, что если у нас есть

R>>>
R>>>// некий абстрактный код
R>>>int y = 5;
R>>>if (x == 1) return y;
R>>>y++;
R>>>if (x == 2) return y;
R>>>return y + 5
R>>>

R>>>То понять что здесь происходит невозможно ни компилятору (та самая проблема с автоматами) ни человеку.

V>>Я в очередной раз ловлю себя на ступоре после прочтения подобной фразы. Может я чего-то не понимаю? Откуда у компилятора или у человека сложности с прочтением? Насчет обязательности соответствия y<=f(x) мне понятно, насчет каких-то затруднений компиляции — нет. Хочешь, прямо здесь и сейчас граф детерминриованного автомата нарисую по этому куску кода? Не знаю, как другие программисты трассируют исходники в голове, но я, когда трассирую куски алгоритмов именно думаю как автомат — т.е. перехожу из состояние в состояние (состояние — множество значений всех локальных/глобальных переменных и проч. ячеек данных быстрой и медленной памяти, прямо или коссвено принимающих участие в алгоритме) в ответ на некие действия над этими переменными.


R>http://en.wikipedia.org/wiki/Halting_problem


[]

Конкретно с этим постом я согласен.
Но насколько я понял, этот текст должен был "доказать" вред множественного return, и с этим я совершенно не согласен. Произошла подмена понятий — вместо мифических сложностей верификации кода с множественным return, ты говорил о невозможности верификации в общем случае.
Сорри, если я чего не так понял.
На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
Re[15]: Вот подумалось
От: reductor  
Дата: 01.12.05 01:22
Оценка:
Здравствуйте, Костя Ещенко, Вы писали:


КЕ>Конкретно с этим постом я согласен.

КЕ>Но насколько я понял, этот текст должен был "доказать" вред множественного return,

Нет. Если вы перечитаете все сверху вниз.

КЕ>и с этим я совершенно не согласен.


Нет проблем.

КЕ>Сорри, если я чего не так понял.


Ничего, бывает.
Re[27]: error is not an exception
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 01.12.05 08:12
Оценка:
Здравствуйте, reductor, Вы писали:

R>Вам, совершенно очевидно, просто необходимо познакомиться с язками, произведенными от ML и ISWIM — Haskell или на худой конец SML


Спасибо, как-нибудь познакомлюсь...
Re[30]: Что вы предлагаете на замену эксепшенов?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 01.12.05 08:19
Оценка: :)
Здравствуйте, IT, Вы писали:

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


Фигнёй страдаете, однако .


---------

Кстати, символ "~" в Modula/Oberon-ах обозначает инструкцию логического отрицания, т.е. то же что в Си-образных языках обозначается символом "!".

if ( ! b) { ... }

эквивалентно:

IF ~b THEN ... END
Re[31]: Что вы предлагаете на замену эксепшенов?
От: Пацак Россия  
Дата: 01.12.05 08:38
Оценка: 18 (1) :))) :))) :)
Здравствуйте, Сергей Губанов, Вы писали:

IT>>Может посчитать количество строчек.

СГ>Фигнёй страдаете, однако .

Сергей, и это говорите Вы?
Ку...
Re[29]: error is not an exception
От: Cyberax Марс  
Дата: 01.12.05 10:39
Оценка:
GlebZ wrote:

> E>Не совсем понял... Из этого следует, что уже 40 лет есть способ

> писать безошибочные программы?
> Вообще-то reductor <http://rsdn.ru/Users/Profile.aspx?uid=48135&gt; в
> отношении функциональных языков прав. С помощью редуцирования лямбда
> функций можно построить глобальную мат. модель вычислений и
> математически проверить ее на соответвие.

На соответствие ЧЕМУ? Как вы будете составлять reference model?

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

Иногда это имеет смысл, например, была доказана "правильность" софта
управления парижским метрополитеном. Под "правильностью" понимается
невозможность такой ситуации, при которой два поезда столкнутся.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[30]: error is not an exception
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.12.05 10:44
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>У вас просто сместится сложность с проверки программного кода на

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

Кстати, о птичках:

Формальная верификация — конструирование некорректного доказательства, изоморфного по отношению к некорректной программе.

Escape-cловарь терминов программной инженерии
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: error is not an exception
От: GlebZ Россия  
Дата: 01.12.05 11:52
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>На соответствие ЧЕМУ? Как вы будете составлять reference model?

А что такое reference model в терминах функционального языка?

C>У вас просто сместится сложность с проверки программного кода на

C>соответствие с требованиями задачи на проверку мат. модели на
C>соответствие требованиям задачи.
Нет. Сложность получения модели можно автоматизировать. Если не иметь императива, можно получить и даже одно уравнение. Единственная проблема — это выявление мат. модели между входными и выходными параметрами.

C>Иногда это имеет смысл, например, была доказана "правильность" софта

C>управления парижским метрополитеном. Под "правильностью" понимается
C>невозможность такой ситуации, при которой два поезда столкнутся.
+1

С уважением, Gleb.
PS никогда не думал что буду защищать функциональные языки
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[30]: error is not an exception
От: GlebZ Россия  
Дата: 01.12.05 11:52
Оценка:
Здравствуйте, eao197, Вы писали:

GZ>>Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать.


E>Ребята, ни в моем вопросе, ни в утверждениях Губанова или reductor-а не было ограничений на функциональные языки или объемы программ.

Поэтому я и развернул ответ на всякий случай. То есть говорить что можно или нельзя сразу для всех стилей, невозможно. А reductor привел в пример именно функциональные языки.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Вот подумалось
От: srggal Украина  
Дата: 01.12.05 12:45
Оценка:
Здравствуйте, Belsen, Вы писали:

[]

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

Есть же люди, которые шуток не понимают, вот и пишут потом точно такой код в продакшн Ж(
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[6]: Вот подумалось
От: srggal Украина  
Дата: 01.12.05 12:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, это уже религия. Все нормальные программисты уже давно перестали

C>флеймить по поводу GOTO и структурного программирования, так как по
C>нынешним меркам это уже далеко не самый главный вопрос. Все
C>программисты, которых я знаю, думают примерно так: "GOTO это плохо?" —
C>"Плохо". "Структурное программирование хорошо?" — "Да". "Единый return,
C>выход из вложенных циклов по флагам, отсутствие break — оно надо?" — "А
C>нафига?"

МОЩНО, но есть и ещё одно, единственный ретурн заставляет писать очень маленькие по функционалц функции, в противном случае страдает читабельность, каждое ветвление, — это отступ в программе, чем больше отступ — тем больше нужна диагональ монитора. А я уже высказывал свой ИМХО: зависимость от диагонали монитора не есть гуд.

А если ещё и н епользоваться исключениями — то производители мониторов перестанут успевать за потребностями програмистов.

Пример навскидку, не жизненный, просто для демонстации того, о чем грю:

int foo()
{
    bool    RetVal = S_ERROR; // из-за единственной точки выхода

    CXXRecordset* pRs = new( nothrow ) CXXRecordset;
    
    if( pRs )
    {
        if ( pRS->Open() )
        {
            if ( !pRS->Eof() )
            {
                pRs->MoveFirst();
                while( !pRs->Eof() )
                {
                    ...
                    
                    if ( pRs->Next() )
                    {
                        RetVal = RSNEXT_ERROR;
                        break;
                    }
                }
                RetVal = S_OK; // ГЛАВНОЕ не забыть, а где именно у нас успешно выполнилась функция ;)
            }
        }
    }
    
    return bRetVal 
}
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[31]: Что вы предлагаете на замену эксепшенов?
От: IT Россия linq2db.com
Дата: 01.12.05 14:15
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Фигнёй страдаете, однако .


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

СГ>Кстати, символ "~" в Modula/Oberon-ах обозначает инструкцию логического отрицания


Мне как-то всё равно. После того, что я увидел в твоём исполнении, я уже вряд ли когда-нибудь буду интересоваться этими языками.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Вот подумалось
От: vdimas Россия  
Дата: 02.12.05 00:01
Оценка:
Здравствуйте, _Winnie, Вы писали:


_W>Не-не-не.


_W>Я не написал, но подразумевал, что объект, который инициализирован по-умолчанию — можно безопасно убить.




_W>Товарищ, вы мало программировали на C


пожалуй, черезчур много, надо было раньше на С++ переходить (перешел только в 1993-94-м)

_W>Вот такой же безопасный код:

_W>
_W>error:
_W>    if (file)
_W>        fclose(file);
_W>    free(name);
_W>    free(last_name);
_W>}
_W>


_W>это общеизвестный goto cleanup паттерн.


Я бы поверил, если бы видел в жизни хоть один RollBack, который не кидает исключениями при применении его к отсутствующей транзакции (метке транзакции)

_W>Ну хорошо.

_W>То, что это на С, это я выпендрился.

Почему обязательно на С? На С++ тоже достаточно мест, где лучше и правильней использовать коды возврата, а не исключения. Там выше давались факторы, влияющие на конкретное решение. Поэтому я как бы считал что это С++. Разумеется, если написано на С, и если операция rollback ничего фатального не сделает в случае невалидных аргументов (я никакие неупомянутые сразу "если" не забыл?), то ты почти отмазался


_W>Мда. Всё-таки с исключениями проще...

_W>Придётся согласиться.

Да, но в С++ свои сложности с исключениями. Навскидку:
— нет единого стандартного базового исключения, соответственно зачастую или непонятно что ловить, или ловить приходится много несвязанных типов
— безопасно можно использовать только семантику по значению, ввиду этого:
— сложно вкладывать исключения друг в друга (как в Java/C#), из-за этого невозможно получить цепочку на некоем верхнем уровне после серии фильтраций на нижних
— если взять иерархию от STL-ексепшена, то возникают вопросы по формированию char* what() динамически. Нам же надо обеспечить конструкторы копирования, т.е. приходится возиться со смарт-поинтерами для строки сообщения — накладные расходы, и в этом случае ситуацию нехватки памяти приходится обрабатывать сквозняком через все уровни отдельно, без фильтрации и динамических выделений.

В общем, я неоднократно строил свои иерархии ексепшенов, и боком и раком, но никогда не получалось сделать так, чтобы остался полностью доволен. Ввиду этого, наборы исключений и их фильтрацию в разных сценариях необходимо проектировать вместе с системой. Но при эттом теряется весьма удобное св-во ексепшенов — расширения множества оных "по мере надобности".
Re[8]: Что вы предлагаете на замену эксепшенов?
От: vdimas Россия  
Дата: 02.12.05 00:08
Оценка:
Здравствуйте, Дарней, Вы писали:

ПК>>Несложно и недолго начиная с VC++ 6 SP4 или GCC 2.95. Вы используете что-нибудь более старое?


Д>это давно уже было, да и компилятор — специально заточенная под девайс версия GCC

Д>в общем, с шаблонами там проблематично было

Ну... можно еще макросами генерить код, не только шаблонами

#define DEF_DELEGATE1(arg_type1) ...

#define DEF_DELEGATE2(arg_type1, arg_type2) ...

вот как бы исходник, который несложно переделать http://www.rsdn.ru/Forum/Message.aspx?mid=908731&amp;only=1
Автор: vdimas
Дата: 21.11.04


-------
там где с компиляторами С++ сложно, имхо с .Net еще сложнее
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.