Re[12]: Другая опера
От: WolfHound  
Дата: 21.07.04 15:26
Оценка: 1 (1) +1
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Ну и чего вот Вы этим самым сказали? Кто Вас за язык-то тянул? Вы самолично только что расписались в том, что используя язык С++ для решения какой-либо (быть может очень сложной) задачи предметной области, Вы обрекаете самого себя еще и на решение (быть может не менее сложных) задач присущих самому языку С++ без относительно к задаче предметной области.

Хм!? Разве масте-поинтеры это сложно? Я один раз потратил пол часа на реализацию мастер-поинтеров и теперь спокойно их использую.
SYG>То есть вынуждены будете напрягаться больше чем необходимо. И все это в топике "Серьезный код", в котором уже не раз подразумевалось, что серьезный код должен быть на столько простым на сколько это вообще возможно.
Вот именно. В базовой реализации просто не возможно предусмотреть все что может понадобится и код получится больше и сложнее.
Я пару раз расширял интерфейс своих мастер-поинтеров для того чтобы упростить их использование. Короче написав десяток строк я съекономил десятки тысячь строк.
Слабо сделать такое с тем что реализовано в языке?

Я на счет finally это не в C++ при помощи автоматических деструкторов эмулируют finally, а в других языках при помощи finally эмулируют автоматические деструкторы.
Надеюсь не надо обьяснять почему код написаный однажды лучше кода написаного тысячи раз.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Супер безопасность
От: WolfHound  
Дата: 21.07.04 15:26
Оценка: +2
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Вот и слава богу, что для такого способа решения задач он не предназначен!

Таких задачь огромное колличество. Вот я писал OPC серверы. Я бы повесился если бы в С++ небыло исключений.

SYG>Думаю, что ПО для электростанции под эту категорию подходит в самый раз.

А я писал софт для нефтяных заводов. Там надежность тоже должна быть мягко говоря на высоте.

SYG>Опыт опыту — рознь, Я, благодаря интернету, знаю одного человека, который с Вами бы в этом вопросе сильно не согласился. В форуме на progz.ru он известен под ником ASU:

Ну давай его сюда. Пусть не соглашается.

SYG>А метода у него "простая": проектировать все сразу и, по возможности, без ошибок.

Он Бог? К томуже смотря на человечество я не уверен в том что Бог не совершает ошибок
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Супер безопасность
От: WolfHound  
Дата: 21.07.04 15:26
Оценка:
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Если система автономная, то в ней, обычно, нет исходников — только бинарники. Кроме того в ней, обычно, нет подсистемы компилятора.

Дык что она делать то будет? В случае сбоя нужно как минимум поднять аварийную тревогу для того чтобы люди успели отреагировать пока не стало слишьком позно.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Пример не серьезного и аналогичного ему серьезного ко
От: _pk_ Россия  
Дата: 21.07.04 16:05
Оценка:
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А теперь, почувствуйте разницу, пример серьезного кода:

SYG>
SYG>RESOURCESTRING
SYG>   STORE_FILE_NAME_IS_EMPTY = 'Не задано имя инициализационного файла (StoreFileName = "")';

SYG>//------------------------------------------------------------------------------

SYG>CONST
SYG>  IDENT_Form    = 'Form';
SYG>  IDENT_Left    = 'Left';
SYG>  IDENT_Top     = 'Top';
SYG>  IDENT_Width   = 'Width';
SYG>  IDENT_Height  = 'Height';

SYG>//------------------------------------------------------------------------------

SYG>PROCEDURE TMainForm.Save;
SYG>VAR f: IniFiles.TIniFile;
SYG>BEGIN
SYG>  f := NIL;
SYG>  TRY
SYG>    IF Self.FStoreFileName = '' THEN RAISE SysUtils.Exception.Create(STORE_FILE_NAME_IS_EMPTY);
SYG>    IF SysUtils.FileExists(Self.FStoreFileName) THEN Windows.DeleteFile(PAnsiChar(Self.FStoreFileName));
SYG>    TRY
SYG>      f := IniFiles.TIniFile.Create(Self.FStoreFileName);
SYG>      f.WriteInteger(IDENT_Form, IDENT_Left,   Self.Left);
SYG>      f.WriteInteger(IDENT_Form, IDENT_Top,    Self.Top);
SYG>      f.WriteInteger(IDENT_Form, IDENT_Width,  Self.Width);
SYG>      f.WriteInteger(IDENT_Form, IDENT_Height, Self.Height);
SYG>    FINALLY
SYG>      f.Free;
SYG>    END;
SYG>  EXCEPT ON e: SysUtils.Exception DO Error(e, 'TMainForm.Save') END
SYG>END;

SYG>//------------------------------------------------------------------------------

SYG>PROCEDURE TMainForm.Load;
SYG>VAR f: IniFiles.TIniFile;
SYG>BEGIN
SYG>  f := NIL;
SYG>  TRY
SYG>    IF NOT SysUtils.FileExists(Self.FStoreFileName) THEN EXIT;
SYG>    TRY
SYG>      f := IniFiles.TIniFile.Create(Self.FStoreFileName);
SYG>      Self.Left   := f.ReadInteger(IDENT_Form, IDENT_Left,   Self.Left);
SYG>      Self.Top    := f.ReadInteger(IDENT_Form, IDENT_Top,    Self.Top);
SYG>      Self.Width  := f.ReadInteger(IDENT_Form, IDENT_Width,  Self.Width);
SYG>      Self.Height := f.ReadInteger(IDENT_Form, IDENT_Height, Self.Height);
SYG>    FINALLY
SYG>      f.Free;
SYG>    END;
SYG>  EXCEPT ON e: SysUtils.Exception DO Error(e, 'TMainForm.Load') END
SYG>END;
SYG>


Вообще, если исключение возникает в конструкторе, то деструктор вызывается автоматом.
Так как здесь f "заниляется", ничего страшного не будет. Но такой код хоть немного, но избыточен, а "серьезный" код, я думаю, этим грешить не должен.
... << RSDN@Home 1.1.3 stable >>
Re[32]: Oberon, Java, .NET, MS Visual Studio
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 22.07.04 06:41
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Да, насколько мне известно (могу ошибаться), что в Black Box Oberon если не компилирировать в код Java VM, то память освобождается сразу же после того, как объект становитсья ненужным. Т. е. это не сборщик мусора в понимании .NET, это скорее подсчет ссылок как в интерфейсах в Delphi.


BlackBox — среда разработки и выполнения программ на языке Component Pascal созданная Oberon Microsystems работает под win32. BlackBox — не имеет отношения к Java и не имеет отношения к .NET. BlackBox — как среда поддерживающая компонентно ориентированную парадигму программирования имеет полноценный сборщик мусора — никаким подсчетом ссылок ее заменить в принципе невозможно (я тут уже обяснял почему — из-за возможных циклических ссылок объектов друг на друга). Раз уже зашла речь об отношениях между Оберонами и Java и .NET, то да, конечно существуют трансляторы Оберонов в Java, и существуют Обероны под .NET. (Сейчас разрабатывается клон Оберона — Zonnon будет работать под .NET)

Кстати, если кому интересно, то можно под MS Visual Studio 2002, 2003 на Component Pascal поработать http://www.citi.qut.edu.au/research/plas/projects/cp_files/cpnet.jsp
(бета версия)

А вообще, Обероны есть сами по себе (т.е. под ОС Оберон), под Linux, Solaris, MacOs X, Windows, Bluebottle. Скачивать можно отсюда: http://www.oberon.ethz.ch/download.html
Re[19]: Супер безопасность
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 22.07.04 06:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>>Если система автономная, то в ней, обычно, нет исходников — только бинарники. Кроме того в ней, обычно, нет подсистемы компилятора.

WH>Дык что она делать то будет? В случае сбоя нужно как минимум поднять аварийную тревогу для того чтобы люди успели отреагировать пока не стало слишьком позно.

Что запрограммируешь — то и будет делать.
Re[13]: А смысл?
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 22.07.04 06:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Хм!? Разве масте-поинтеры это сложно? Я один раз потратил пол часа на реализацию мастер-поинтеров и теперь спокойно их использую.

SYG>>То есть вынуждены будете напрягаться больше чем необходимо. И все это в топике "Серьезный код", в котором уже не раз подразумевалось, что серьезный код должен быть на столько простым на сколько это вообще возможно.
WH>Вот именно. В базовой реализации просто не возможно предусмотреть все что может понадобится и код получится больше и сложнее.
WH>Я пару раз расширял интерфейс своих мастер-поинтеров для того чтобы упростить их использование. Короче написав десяток строк я съекономил десятки тысячь строк.
WH>Слабо сделать такое с тем что реализовано в языке?

WH>Я на счет finally это не в C++ при помощи автоматических деструкторов эмулируют finally, а в других языках при помощи finally эмулируют автоматические деструкторы.

WH>Надеюсь не надо обьяснять почему код написаный однажды лучше кода написаного тысячи раз.


Например, в Component Pascal встроен сборщик мусора, там на мастер-поинтеры заморачиваться не надо в принципе. В чем состоит смысл Вашего замечания?
Re[3]: Пример не серьезного и аналогичного ему серьезного ко
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 22.07.04 06:52
Оценка:
Здравствуйте, _pk_, Вы писали:

__>Здравствуйте, S.Yu.Gubanov, Вы писали:


__>Вообще, если исключение возникает в конструкторе, то деструктор вызывается автоматом.

__>Так как здесь f "заниляется", ничего страшного не будет. Но такой код хоть немного, но избыточен, а "серьезный" код, я думаю, этим грешить не должен.

Я согласен с этим замечанием и уже написал об этом:
http://www.rsdn.ru/Forum/Message.aspx?mid=721624&amp;only=1
Автор: S.Yu.Gubanov
Дата: 15.07.04

там же я написал объяснение того почему я "по инерции" написал именно такой код.
Re[19]: Супер безопасность
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 22.07.04 06:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ну давай его сюда.

Как я его дам? Я с ним лично не знаком, даже не знаю как его зовут, знаю только его ник ASU и что он иногда бывает на progz.ru.
Re[19]: Супер безопасность
От: EyeGem Россия https://vk.com/enginya
Дата: 23.07.04 20:17
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

А я вот разделяю подход, который ув.С.Ю.Губанов безуспешно пытается донести
до всех вас. Более того! (тсссс) я и сам такой использую
Честно, хороший подход. А вы ему минусы, минусы...

SYG>>Вот и слава богу, что для такого способа решения задач он не предназначен!

WH> Таких задачь огромное колличество. Вот я писал OPC серверы. Я бы повесился если бы в С++ небыло исключений.

Просто твой сервер использует отказо-не-устойчивый софт, поэтому ловить исключения нужно.
Это IMHO, но ты поведай, для чего конкретно (какие части сервера) ты использовал механизм исключений?

SYG>>Думаю, что ПО для электростанции под эту категорию подходит в самый раз.

WH>А я писал софт для нефтяных заводов. Там надежность тоже должна быть мягко говоря на высоте.

(умалчивая)

SYG>>А метода у него "простая": проектировать все сразу и, по возможности, без ошибок.

WH>Он Бог? К томуже смотря на человечество я не уверен в том что Бог не совершает ошибок

Скажем, надо так проектировать подсистемы, чтобы в них были предусмотрены все необходимые
виды ошибок-возвратов. Если же возникнет _настоящая_ _отловимая_ исключительная ситуация,
то надо просто вырубить/перезагрузить весь сбойный модуль (как блок), вернуть признак
ошибки тому, кто этот блок вызывал (если он не автономный был) и т.о. использовать
механизм исключений только для целых блоков, но никогда — для их содержания.
... << RSDN@Home 1.1 beta 2 >>
^__^
Re[30]: Пример "незапланированной ситуации"?
От: prVovik Россия  
Дата: 23.07.04 23:49
Оценка:
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А я и не говорил что без механизма исключений будет проще или удобнее.

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

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

Это всеравно, что заявить мол наличие метода для захвата ресурсов (напр. new) и метода для их освобождения (напр. delete) делают сборщик мусора излишним. А ведь действительно, если каждый выделенный ресурс не забывать освобождать, то сборщик мусора в принцепе не нужен Дак для чего же он тогда? Наверное, ДЛЯ УДОБСТВА! Вот и исключения тоже ДЛЯ УДОБСТВА!!!!

SYG>А мне пытались "впарить" что без механизма исключений ничего серьезного сделать вообще нельзя. Без него можно, но проектировать все нужно по другому

В принцепе, до Китая можно "раком" добежать. Пусть кто-нибудь докажет обратное
лэт ми спик фром май харт
Re[31]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 26.07.04 11:27
Оценка:
Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>>А я и не говорил что без механизма исключений будет проще или удобнее.

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

Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей. Я и не говорил что без механизма исключений проще или удобнее, я говорю что без механизма исключений — ПОДРУГОМУ.

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

V> Это всеравно, что заявить мол наличие метода для захвата ресурсов (напр. new) и метода для их освобождения (напр. delete) делают сборщик мусора излишним. А ведь действительно, если каждый выделенный ресурс не забывать освобождать, то сборщик мусора в принцепе не нужен Дак для чего же он тогда? Наверное, ДЛЯ УДОБСТВА! Вот и исключения тоже ДЛЯ УДОБСТВА!!!!

Вот сколько ни объясняй что сборщик мусора вовсе не является прихотью или роскошью придуманной для ленивых программистов, все равно найдется кто-то кто так и не поймет! Что в этом такого сложного понять это??? Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.

Перечитайте мое прошлое сообщение на эту тему:
"Сборщик мусора — это не роскошь, а осознанная необходимость"
http://www.rsdn.ru/Forum/Message.aspx?mid=725451&amp;only=1
Автор: S.Yu.Gubanov
Дата: 19.07.04
Re[32]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.07.04 11:48
Оценка:
SYG>Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей.

И в чем именно проблема?
В .Net-е, Java-е, скриптах, Smalltalk-е и т.д. — это проблема же как-то решается.



SYG>Вот сколько ни объясняй что сборщик мусора вовсе не является прихотью или роскошью придуманной для ленивых программистов, все равно найдется кто-то кто так и не поймет!


Замечу, что подсчет ссылок и сборщик мусора — это две дополняющие друг друга стратегии.
Подсчет ссылок лучше работает на малом кол-ве ссылок, сборщик мусора работает лучше на большом кол-ве ссылок.

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

т.е. обобщенная стратегия, которая берут плюсы и минусы от обеих этих стратегий следующая:
считаем ссылки, но если ссылок стало слишком много переходим на сборщик мусора, также периодически сборщик мусора проверяет объекты с подсчетом ссылок, ищет циклы, и убивает их
Re[33]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 26.07.04 13:14
Оценка: :)
Здравствуйте, DarkGray, Вы писали:

SYG>>Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей.


DG>И в чем именно проблема?


Проблема в ответе на вопрос: "Что значит упростить?"

DG>В .Net-е, Java-е, скриптах, Smalltalk-е и т.д. — это проблема же как-то решается.


Java — интерпретатор (там может быть все что угодно), Smalltalk — не модульный, а в .Net встроен JIT компилятор — это явно не "упрощение", а "утяжеление".

DG>Замечу, что подсчет ссылок и сборщик мусора — это две дополняющие друг друга стратегии.

DG>Подсчет ссылок лучше работает на малом кол-ве ссылок, сборщик мусора работает лучше на большом кол-ве ссылок.
DG>В идеальном случае — лучше использовать и то, и другое, т.к. у подсчета ссылок — есть существенный плюс: правильный (детерминированный) момент времени освобождения ресурсов.
DG>т.е. обобщенная стратегия, которая берут плюсы и минусы от обеих этих стратегий следующая:
DG>считаем ссылки, но если ссылок стало слишком много переходим на сборщик мусора, также периодически сборщик мусора проверяет объекты с подсчетом ссылок, ищет циклы, и убивает их

Это уже детали реализации. Просто все еще находятся некоторые люди наивно полагающие что задачу освобождения ресурсов (каждому new свой delete) можно решить в момент написания модуля программы. В общем случае эта задача статически неразрешима и для ее решения надо использовать динамические методы, причем одного лишь подсчета ссылок в общем случае будет недостаточно (например, два объекта ссылающихся друг на друга можно удалить только если есть полноценный сборщик мусора.)
Re[4]: Серьёзный код :)
От: AndreyFedotov Россия  
Дата: 26.07.04 13:36
Оценка: +1
Здравствуйте, Demiurg, Вы писали:

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


AF>>>>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.


AR>>>А вот это бы я назвал именно сложным кодом.


AF>> Иногда да, иногда нет. В таких системах часто сам код очень простой, но именно наличие множества скрытых и не очевидных связей делает его написание делом не простым.


D> Может просто проблема проектирования? Код должен быть простым для понимания, тогда это хороший код. Смотря, конечно, для кого простым На асме писать очень просто, но при сложном алгоритме (да и просто по мере разбухания проекта, если его правильно не спроектировать) получается как раз такой "серьезный", по-твоему определению, код. На ЯВУ же этого запутывания имхо можно избежать.


Теоретически да. Практически, когда происходит упрощение кода, то (если код спроектирован и написан хорошо ) часто происходит добавление новых уровней абстракции и сущностей (что собственно и позволяет упростить код). Если чепловек с этими понятиями и моделями знаком — то для него код упрощается. Если же не знаком (что бывает гораздо чаще), то хотя каждая часть кода по отдельности возможно и стала проще — но код в целом может стать даже сложнее.
Простой пример. В своё время иногда писали на диск используя прерывания и аппаратуру контроллера. Код был довольно навороченным (прописывалась куча регистров и т.д.), но его суть очень проста. Если взять код, который пишет в файл под Windows — код будет гораздо яснее, очевиднее и проще. Но это только в том случае, если рассматирвать только клиентскую часть кода. А если рассматиривать и саму ОС — работу её кода, то всё стало намного сложнее и требует гораздо больше времени для понимания.
То же бывает и в других многоуровневых системах.
Re[2]: Серьёзный код :)
От: AndreyFedotov Россия  
Дата: 26.07.04 13:52
Оценка:
Здравствуйте, Glоbus, Вы писали:

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


G>я лично думаю, что формулировка плохая. Нет понятия серьезный код или несерьезный, как мнекажется. Есть понятие "серьезная задача".


Полностью согласен. Вопрос задал потому — что эта формулировка возникала слишком часто...
Re[4]: Серьёзный код :)
От: AndreyFedotov Россия  
Дата: 26.07.04 13:54
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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


D>>Серьезность кода и диплом не имееют ничего общего, по крайней мере везде где я знаю так оно и есть. Я знаю такие дипломные работы, котрые даже на лабораторную для 1-ого курса не потянут. А код которых и глядеть страшно.


D>>ЗЫ: Исключения бывают конечно, но это именно исключения, а не правила.

LVV>Ну так у нас сплошные исключения

Или сплошные изверги...
Re[32]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: prVovik Россия  
Дата: 26.07.04 17:36
Оценка: 1 (1)
Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей. Я и не говорил что без механизма исключений проще или удобнее, я говорю что без механизма исключений — ПОДРУГОМУ.

Ну в Windows'e же есть SEH! Вы скажете, что типа Windows — это не модульная ось, а потому там все подругому, или что-то в этом роде. Я не буду с вами спорить в этом вопросе, а только замечу, что любое поведение исключений всегда можно сэмулировать через коды возврата. Вы всем предлагаете делать это ВРУЧНУЮ. Да, действительно, это сделать можно, но это НЕУДОБНО. Мне, как программисту значительно удобней, когда это сделает компилятор
автоматически. В этом и заключается удобство. Я не вижу принципиальной разницы между исключениями и кодами возврата и я не понимаю, почему модули могут работать через коды возврата и не могут через исключения. В заключается неразрешимая проблема?

SYG>Вот сколько ни объясняй что сборщик мусора вовсе не является прихотью или роскошью придуманной для ленивых программистов, все равно найдется кто-то кто так и не поймет!

Это вы о ком? Случайно не обо мне? Что-то я не припоминаю за собой таких слов...
Я лишь говорил, что ТЕОРЕТИЧЕСКИ можно обойтись без сборщика мусора, точно так, как можно обойтись без исключений. Но в том и в другом случае это неудобно.

SYG>Что в этом такого сложного понять это??? Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.

Ой, сколько эмоций!
Вы понимаете, что в основе любого сборщика мусора лежит все тот же детерминированный вызов оператора delete? Вас это ни на какие мысли не наталкивает? Не кажется ли вам, что работа сборщика мусора может быть просто сэмулирована точно так, как вы предлагаете эмулировать обработку исключений через коды возврата? Выражаясь вашим языком, просто надо проектировать такую систему ПОДРУГОМУ. Да, это геморрой, да сборщик мусора — это хорошо, удобно и сладко, впрочем, так же как и исключения...
лэт ми спик фром май харт
Re[33]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: S.Yu.Gubanov Россия http://sergey-gubanov.livejournal.com/
Дата: 27.07.04 07:47
Оценка: :)
Здравствуйте, prVovik, Вы писали:

V>Я не вижу принципиальной разницы между исключениями и кодами возврата.


Исключения бывают двух сортов:
1) Псевдоисключения, которые вовсе никакие не исключения, а Ваши собственные доморощенные штуки, которые Вы используете как продвинутые коды возврата. Между ними и кодами возврата действительно нет никакой принципиальной разницы, а значит они в языке программирования в принципе излишни.

2) Истинные исключения, то есть те которые имеют свое происхождение от прерываний генерируемых процессором. Например, прерывание INT 0 — деление на ноль. По другому, "истинные исключения" можно назвать "недопустимые операции". Если программа совершает "недопустимую операцию", то она должна быть остановлена как не имеющая смысла.

Впрочем, если Вы не видите разницы, ну и не надо, мне не жалко. Если Вы полагаете что механизм исключений введен в язык только для удобства, а не потому что без этого механизма теоретически невозможно писать серьезные программы, то я согласен с Вами. Исключения — сами по себе излишни, можно обойтись и без них — вот моя точка зрения. Кажется наши точки зрения по этому пункту совпадают.


А вот по следующему пункту наши точки зрения противоположны:
V>Я лишь говорил, что ТЕОРЕТИЧЕСКИ можно обойтись без сборщика мусора

А Я лишь говорил, что в модульных системах без сборщика мусора обойтись ТЕОРЕТИЧЕСКИ нельзя.

И что дальше будем делать? Вы мне говорите "теоретически можно", а я Вам говорю "теоретически нельзя", и так до бесконечности будем, кто кого переговорит?

Предлагаю Вам решить такую задачу:
Вы являетесь автором одного динамически загружаемого модуля. Этот модуль создает объекты и отдает указатели на них другим динамически загружаемым модулям (другие модули написаны другими производителями, и у Вас есть/будут только их бинарники). На момент написания своего модуля Вы даже точно не знаете какие именно будут те самые другие модули. Как Вы будете принимать решение об уничтожении созданных в Вашем модуле объектов? Как Вы узнаете что созданный Вашим модулем объект больше никем не используется?
Re[34]: Задача вызова delete НЕРАЗРЕШИМА на момент написания
От: prVovik Россия  
Дата: 27.07.04 09:04
Оценка:
Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Исключения — сами по себе излишни, можно обойтись и без них — вот моя точка зрения. Кажется наши точки зрения по этому пункту совпадают.

Нет, не совсем. Я уже писал, что без исключний теоретически можно обходиться, но это неудобно. Приходится писать более громоздкий код, который сильнее подвержен ошибкам. Вот что пишет Страуструп об исключениях:

Автор библиотеки может обнаружить ошибки времени выполнения, но, в общем случае, не имеет ни малейшего представления что с ними делать. Пользователь библиотеки может знать как бороться с такими ошибками, но не может их обнаружить — в противном случае они бы обрабатывались в коде пользователя, и их обнаружение не было бы возложено на библиотеку. Для помощи в решении подобных проблем введено понятие "исключения". Фундаментальная идея состоит в том, что функция, обнаружившая проблему, но не знающая как ее решить, генерирует исключение в надежде, что вызвавшая ее(непосредственно или косвенно) функция сможет решить возникую проблему. Функция, которая хочет решать проблемы данного типа, может указать, что она перехватывает такие исключения.


SYG>Предлагаю Вам решить такую задачу:

SYG>Вы являетесь автором одного динамически загружаемого модуля. Этот модуль создает объекты и отдает указатели на них другим динамически загружаемым модулям (другие модули написаны другими производителями, и у Вас есть/будут только их бинарники). На момент написания своего модуля Вы даже точно не знаете какие именно будут те самые другие модули. Как Вы будете принимать решение об уничтожении созданных в Вашем модуле объектов? Как Вы узнаете что созданный Вашим модулем объект больше никем не используется?
Да хотябы вот так вот: http://www.rsdn.ru/article/cpp/GCcpp.xml
Автор(ы): Михаил Чащин
Дата: 18.11.2002
лэт ми спик фром май харт
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.