Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А причем здесь наличие метода? Мы ж не об ограничениях using в C# говорим
При чем тут юзинг.
ПК> Главное, что есть сущность с окончанием временем жизни которой нужно отписаться от события.
Проблема в том чтобы определить время окончания жизни. Автоматически его определить невозможно.
ПК> Псевдокод, который я привел, вполне соответствует моему пониманию твоемо описания проблемы.
Там нет главного — момента, когда произойдет освобождение.
Здравствуйте, AndrewVK, Вы писали:
A>>ОК, что там есть из API (я не про бизнес-логику) кроме сети и GUI? AVK>А там много чего есть. Например
многопоточность — это может быть везде
OO RPC — уточни о чём ты. Я это прочёл как Object Oriented Remote Procedure Call и не въехал.
механика деплоймента — автоматизировання установка программы? Это отдельная задача
система логирования и контроля производительности — это может быть везде
транзакции — все контекста БД?
поддержка сессий, управление жизненным циклом объектов — все веб контекста?
управление асинхронными задачами — это может быть везде
сервер печати — это как?
механика аутентификации и авторизации — не вижу здесь проблем достойных обсуждения. Это скорее административная чем программистская задача.
контроль безопасности бизнес-кода — поясни о чём речь
файловые и БД хранилища — разработка или использование?
масса кешей — ОК, принято
автоматические генераторы интерфейсов — ОК, принято
управление метаданными — ОК, принято
и много чего другого.
A>> Или алгоритмы по каким-то причинам лучше писать под .Net? AVK>И это то же.
Поясни
A>>ИМХО умение быстро и грамотно проектировать код к конкретным языкам перпендикулярно. AVK>Разумеется. Вопрос в том насколько просто запроектированное реализовать.
А это на 90% зависист от объёма стандартных библиотек.
A>>В обсуждении да, а на практике? Много ли кода пишется не с std::auto_ptr, а с boost::shared_ptr? AVK>И кто в этом виноват? Неужели опять всемирный заговор?
Нет, способы разработки софта.
A>>Целыми числами например. Я это использую не так уж и редко и как-то не хочу отказываться. AVK>А зачем используешь?
Ну про пример с факториалом ты знаешь? Типа метапрограммирование и всё такое. Если не встречал то это делается так.
Кроме того, я, с использованием параметризации шаблонов числами, написал однажды очень шустрый string_builder (правда по совсем другим причинам он был потом переписан)
Кроме того, вот чудесный пример http://www.rsdn.ru/Forum/Message.aspx?mid=751154
— крайне полезная вешь, что следует хотя бы из длины обсуждения!
Ну вобщем есть где применить.
A>>Мне так удобнее программировать. AVK>Т.е. ты не умеешь по другому?
Что значит не умею? Шаблоны и не получиться разделить, а я их часто использую, так что умею. Просто когда разделено мне удобнее. Код гораздо лучше обозревается. Щёлкать плюсики в левом столбце редактора как-то неудобно очень.
AVK>Напиши dll с привязкой на С++
Ну то есть проект выходит смешанным... Мне проще запустить утилитку, чем самом писать защиту, тем более что вряд ли я за неделю напишу лучше, чем спец по этому вопросу за день. А мои утилитки писали спецы и не за день
AndrewVK,
> ПК> Главное, что есть сущность с окончанием временем жизни которой нужно отписаться от события.
> Проблема в том чтобы определить время окончания жизни. Автоматически его определить невозможно.
Я чего-то явно не понимаю...
После очередной синхронизации старые сущности умирают и в этот момент их надо отписать от событий.
> ПК> Псевдокод, который я привел, вполне соответствует моему пониманию твоемо описания проблемы.
> Там нет главного — момента, когда произойдет освобождение.
Когда будут умирать "старые сущности", они автоматически будут отписаны от событий.
Если вопрос в том, когда же должны умирать старые сущности, то в языке с явным управлением временем жизни объектов этот вопрос без ответа оставить нельзя в любом случае, поэтому пропустить это тоже было бы очень сложно...
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я чего-то явно не понимаю... ПК>
ПК>После очередной синхронизации старые сущности умирают и в этот момент их надо отписать от событий.
Логически умирают. А физически не умирают.
>> Там нет главного — момента, когда произойдет освобождение.
ПК>Когда будут умирать "старые сущности", они автоматически будут отписаны от событий.
А они не умирают, потому что не отписаны от событий.
ПК>Если вопрос в том, когда же должны умирать старые сущности, то в языке с явным управлением временем жизни объектов этот вопрос без ответа оставить нельзя в любом случае, поэтому пропустить это тоже было бы очень сложно...
Как это соотносится с
пример типичной ошибки, которой при использовании RAII не совершают в принципе
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Следовательно, одну неделю на ловлю ошибки не пришлось бы терять и т.д... ГВ>Эксь. Ну а как насчёт того, что в сами-знает-каких-языках за счёт отсуствия сами-знаете-каких-способностей по сравнению с сами-наверняка-знаете-каким-языком приходится тратить больше времени на имплементацию одного и того же?
Если в языке нет возможности получения адреса объекта расположенного на стеке (впрочем как и вообще нет возможности получения какого бы ни было адреса), то и нет обсуждаемой здесь проблемы. Все остальное в сад...
> ПК>После очередной синхронизации старые сущности умирают и в этот момент их надо отписать от событий.
> ПК>
> Логически умирают. А физически не умирают.
Ага. Этот момент [для меня] оставался за кадром.
> ПК>Когда будут умирать "старые сущности", они автоматически будут отписаны от событий. > > А они не умирают, потому что не отписаны от событий.
Теперь понятно.
> ПК> Если вопрос в том, когда же должны умирать старые сущности, то в языке с явным управлением временем жизни объектов этот вопрос без ответа оставить нельзя в любом случае, поэтому пропустить это тоже было бы очень сложно... > > Как это соотносится с >
пример типичной ошибки, которой при использовании RAII не совершают в принципе
> ?
Дык, RAII — яркое выражение явного управления временем жизни объектов.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, adontz, Вы писали:
A>многопоточность — это может быть везде
И? Как это связано с неиспользуемостью Dispose? Ты же сам пример привел из этой оперы.
A>OO RPC — уточни о чём ты. Я это прочёл как Object Oriented Remote Procedure Call и не въехал.
Правильно прочел. А во что не вьехал? См. например здесь
A>механика деплоймента — автоматизировання установка программы?
Это автоматическая инсталляция пакетов с бизнес-логикой, а не программы.
A>Это отдельная задача
Отдельная от чего?
A>система логирования и контроля производительности — это может быть везде
И?
A>транзакции — все контекста БД?
Нет.
A>поддержка сессий, управление жизненным циклом объектов — все веб контекста?
Нет.
A>управление асинхронными задачами — это может быть везде
И?
A>сервер печати — это как?
Это так. См. SQL Server Reporting Services, Crystal Reports.
A>механика аутентификации и авторизации — не вижу здесь проблем достойных обсуждения.
А что ты обсуждать то хочешь?
A> Это скорее административная чем программистская задача.
Пробовал реализовать?
A>контроль безопасности бизнес-кода — поясни о чём речь
О том что бизнес-коду нужно запретить делать то, что он не имеет права делать.
A>файловые и БД хранилища — разработка или использование?
Разработка.
A>>> Или алгоритмы по каким-то причинам лучше писать под .Net? AVK>>И это то же.
A>Поясни
A>>>ИМХО умение быстро и грамотно проектировать код к конкретным языкам перпендикулярно. AVK>>Разумеется. Вопрос в том насколько просто запроектированное реализовать.
A>А это на 90% зависист от объёма стандартных библиотек.
Не только.
A>>>В обсуждении да, а на практике? Много ли кода пишется не с std::auto_ptr, а с boost::shared_ptr? AVK>>И кто в этом виноват? Неужели опять всемирный заговор?
A>Нет, способы разработки софта.
Т.е. в случае С++ виноваты эти способы, а в случае C# уже нет? Ну так тогда это тоже плюс, что C# от этих способов не страдает
A>>>Целыми числами например. Я это использую не так уж и редко и как-то не хочу отказываться. AVK>>А зачем используешь?
A>Ну про пример с факториалом ты знаешь?
Знаю. На редкость бесполезная вещь.
A> Типа метапрограммирование и всё такое.
Во, теперь добрались до сути. Осталось понять что в язык нужно добавлять нормальные средства программирования, а не извращаться с шаблонами и все встанет на свои места.
AVK>>Напиши dll с привязкой на С++ A>Ну то есть проект выходит смешанным...
пример типичной ошибки, которой при использовании RAII не совершают в принципе
>>> ?
> ПК> Дык, RAII — яркое выражение явного управления временем жизни объектов.
> Так Паша — еще раз. Ты утверждал что при применении RAII упомянутой ошибки не было бы. Ты по прежнему так считаешь, или уже нет?
Насколько я представляю происходящее, в случае использования RAII вместо "старые сущности" вместе с подпиской на события убивались бы детерминированно. Соответственно, если мои представления соответствуют реальному положению дел, то да, по-прежнему считаю.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, AVM, Вы писали:
CS>>>POSIX API например. Например API для всех версий Windows это С. AVM>>Я имел в виду не API как таковой, а API specification для какой нибудь native C library, которая бы покрывала много features, которые нужны при разработке и эта API specification имела бы реализации для различных платформ. CS>Например: CS>http://apr.apache.org/
Про этого зверя не знал, санкс за ссылку
CS>>>Если про XML то самый распространненый парсер это James Clark's Expat. Чистый C. AVM>>Как считаем степень распространенности? Я могу сказать что самый распространненый парсер это MSXML, потому что он используется в Windows, в виндовс стоит почти на 80% десктопов. CS> Кто тебе сказал что он там используется?
А то нет
CS>>>Посмотри список платформ поддерживаемых GCC компилятором. Там есть такие где Java VM не существует в принципе. AVM>>Переносимость GCC выше всяких похвал, а вот как с переносимостью библиотек? AVM>>Попробую пояснить на примере: Задача написать XML-редактор, который должен работать на Win и Linux. AVM>>Main stream для Win: VC++ and MFC ( как вариант C++ Builder and VCL, но IMHO это не лучшый вариант). AVM>>Main stream для Linux: GCC and Motif или QT. AVM>>Что использовать будем ? MFC для Linux IMHO из области фантастики, VCL через Kilix IMHO очень нетрадиционно, AVM>>QT для Windows IMHO наиболее реальный вариант, но мы выходим из main stream и рискуем в будущем нарваться на проблемы с тех поддержкой . AVM>>Еще возможен вариант с XUL, но я пока плотно с этим не разбирался, так что ничего сказать не могу. CS>wxWindows, FoxToolkit (fox-toolkit.org)
я бы не рекомендовал использовать их в серьезном проекте, IMHO сыроваты они еще. CS>fltk.org это на C++.
С или плюсы в данном контексте не принципиально
CS>На чистом C на вскидку http://www.gtk.org/ CS>run on most releases of the following operating systems: CS>Windows 95 CS>Windows NT CS>Solaris and SunOS CS>Linux CS>HP-UX CS>SGI IRIX CS>Digital Unix CS>AIX CS>SCO Unix CS>NetBSD, BSDi, FreeBSD CS>Most other Unix-like operating systems CS>Macintosh (68K and Power Mac)
Да про слона то я и позабыл, но gtk так же как и qt не есть main stream для window. И если MS делает финт ушами и добавляет в новую версию window какие нибудь серьезные изменения которые не совместимы с qt, то тогда разработчики начинаю ждать либо пока Trolltech сделает порт, либо срочно переписывать все на MFC, .net, или еще на что-то. С Java кстати такая же неприятность может случиться, но IMHO Sun более надежен как vendor.
AVM>>Если же использовать для этого java, то мы используем J2SE 1.4.x и получаем application, которая запускается через java web start (сокращение затрат на внедрение) и которая работает и под win и под linux. При этом мы остаемся в рамках j2se API specification. AVM>>Поправь меня пожалуйста, если я что то упустил.
.... AVM>>Так может быть так получилось, потому что эта задача уже более менее решена. Заметь если заказчик выдвигает требование что application shall be work on window and *nix operation systems, то java сразу попадает как рассматриваемый вариант имплементации. CS>Итить... "при всем богатсве выбора другой альтернативы нет" ? CS>Еще много разных критериев кроме "просто работало" или "шевелилось" CS>Выбирай вот toolkit и не морочь себе голову
да я уже давно выбрал
CS>>>Как только начинается UI вся run-everywhere и заканчивается. Причем не только на Java. CS>>>На C то же самое. Слишком много специфики на платформах. CS>>>Например у нас в нашем Java UI на Windows пользоваетели очень хотят крутить колесо мыши. CS>>>А на Mac такой штуки нет в принципе. AVM>>Ну и причем тут java, если Стив не сделал колесную мышь для мака? CS>А на Windows пользователи хотят. А нет! А что делать? CS>Ну и приделывают к той Java самопальные dll-ки. И идет вся run-everywhere прахом.
Давно вы наверное проект делали. C JDK 1.4 мышиные колеса поддерживаются. Правда Sun очень долго к этому шел, но как говорится лучше поздно, чем никогда.
CS>>>И вообще как только выходишь за рамки базовых input элементов — все — труба. CS>>>Мы даже вынуждены были выкинцть AWT из за этого — написали все с нуля и без ОС примитивов. Swing не пошел из-за тяжелости. AVM>>SWT не смотрели ? CS>Смотрели. Только три года назад там смотреть нечего было. И потом platform dependent, да?
3 года в IT почти вечность. SWT он типа как платформ депендед, и Sun c IBM даже немного погавкались, но порты под основные OC есть. Eclipse (это так IBM в отместку Сану, назвал свою IDE) построен на SWT и чудесно работает и под виндовс и под Linux.
CS>Я вот даже свою Java VM с тоски написал. Вот та переносимая (на С написана). И колесо в ней работает. Везде CS>http://www.terrainformatica.com/org/j-smile/index.htm
Прикольно, с какими версиями sun's jvm она совместима? И где ее можно взять чтобы посчупать?
CS>Я не спорю, Java язык хороший. и VM у него простая. CS>Только Sun почему-то перестала GUI его развивать.
Ну видимо считают, что все пока хватит. У большой компания большая инерция. Но у них есть такая процедура как Java Community Process. Практически любой может послать change request на на внесение изменений в JVM или API Specification и если сообщество признает, что this feature is useful, то ее включат в разработку. Процесс как ты догадываешься не быстрый, но что делать — такова селяви.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Насколько я представляю происходящее, в случае использования RAII вместо "старые сущности" вместе с подпиской на события убивались бы детерминированно.
Так, вернулись к тому с чего начали. Еще раз — насколько я понимаю RAII означает следующее: получение ресурса совпадает с инициализацией. Это позволяет в случае, если мы что то выделяем внутри блока автоматически освобождать ресурсы, потому что автоматически будут вызваны деструкторы. Но, если мы выделяем ресурс не в рамках метода, то RAII ничего не дает, поскольку никакой автоматики не будет. Даже если ты обернешь подписку на событие в спец. класс, все равно отписываться тебе придется руками. И если это забыть сделать то ты получишь ту самую проблему, о которой речь.
Здравствуйте, AndrewVK, Вы писали:
A>>многопоточность — это может быть везде AVK>И?
Я просто хочу сказать что написание многопоточных программ для конкретной платформы на любом не многопоточном языке (не поддерживающем многопоточность синтаксически) связано с одними и теми же проблемами (проблема на самом деле одна — синхронизация доступа) и использование конкретного языка не даёт преимуществ.
A>>OO RPC — уточни о чём ты. Я это прочёл как Object Oriented Remote Procedure Call и не въехал. AVK>Правильно прочел. А во что не вьехал? См. например здесь
Я не въёхал зачем это разрабатывать? Есть же DCOM, Remoting. Использование всех этих технологий ИМХО на любом языке достаточно прозрачно. На Си++ я не делаю особых телодвижений когда использую удалённый объект и я как-то не представляю чем C# в этом смысле может мне помочь
A>>механика деплоймента — автоматизировання установка программы? AVK>Это автоматическая инсталляция пакетов с бизнес-логикой, а не программы.
Угу. В Си++ я бы использовал "установку по требованию MSI" если список пакетов известен заранее, "COM/pure-DLL плагины и закачку по сети с сервера по требованию (скорее всего через WinInet)" если список пакетов заранее не известен (меняется, обновляется). На самом деле етсь решения от InstallShield, есть FlashUpdate, есть другие системы...
Чем C#/.Net лучше? Что он предоставляет вкусненького?
A>>Это отдельная задача AVK>Отдельная от чего?
Я думал речь об автоматического установке клиентского ПО по сети, что есть задача администраторская.
A>>система логирования и контроля производительности — это может быть везде AVK>И?
И чем C#/.Net в этом смысле лучше? Что он предоставляет вкусненького?
A>>транзакции — все контекста БД? AVK>Нет.
Извини, может ты не так понял. Опечатка. вне контекста БД?
A>>поддержка сессий, управление жизненным циклом объектов — все веб контекста? AVK>Нет.
Извини, может ты не так понял. Опечатка. вне веб контекста?
A>>управление асинхронными задачами — это может быть везде AVK>И?
И чем C#/.Net удобнее? Что он предоставляет вкусненького?
A>>сервер печати — это как? AVK>Это так. См. SQL Server Reporting Services, Crystal Reports.
Crystal Reports есть и под Си++. Чем же C# удобнее?
A>>механика аутентификации и авторизации — не вижу здесь проблем достойных обсуждения. AVK>А что ты обсуждать то хочешь?
Сложности и то как C# позволяет их решать быстрее, чем Си++ (или другой язык)
A>> Это скорее административная чем программистская задача. AVK>Пробовал реализовать?
Административно? Делал Integrated Security, документацию на 2-3 странички какие права доступа нужны и забывал об аутенфикации навсегда.
A>>контроль безопасности бизнес-кода — поясни о чём речь AVK>О том что бизнес-коду нужно запретить делать то, что он не имеет права делать.
Я это делаю запуская всю систему под отдельным пользователем. Обычно все довольны
A>>файловые и БД хранилища — разработка или использование? AVK>Разработка.
Файловое хранилище это обычно сериализация. В MFC она есть, Есть так же несколько сторонних библиотек для этой цели. Естьвелосипеды. Думаю свои БД вы не пишите, так что под разработкой БД хранилищ подразумевается проектирование таблиц, хранимок и всего такого.
Сериализация в C# наверное лучше, а вот что касается БД...Да, Rsdn.Framework.Data это круто! ОК, убедил что сериализация в .Net удобнее
A>>>> Или алгоритмы по каким-то причинам лучше писать под .Net? AVK>Re[13]: Почему я до сих пор пишу на MFC (заметки "старовера"
При классическом подходе (Дельфи, С++ без шаблонов) это примерно так. Но вот как только мы начинаем использовать сложные структурные решения, то сразу всплывают паттерны. И вот тут все становится не так просто — С++ к примеру, за счет шаблонов и техник а-ля Александреску позволяет создавать библиотеки паттернов, в C# и Java много частоупотребимых паттернов встроено в язык. А вот классический подход остается по эффективности далеко позади, поскольку каждый раз приходится изобретать велосипед, т.е. опять и опять реализовывать паттерн.
Например — если мне нужно создать ленивый потокобезопасный синглтон, то на шарпе я не задумываясь напишу статическое поле с инициализацией, на С++ один раз напишу шаблон. А на Дельфи? Не хочешь привести минимальный код?
Где же здесь неоспоримое преимущество С#/.Net? Победителей получилось много. На самом деле просто похоронили Object Pascal
AVK>>>Разумеется. Вопрос в том насколько просто запроектированное реализовать. A>>А это на 90% зависист от объёма стандартных библиотек. AVK>Не только.
А вот не скажи. С библиотекой PCRE обрабатывать тексты на Си++ не сложднее, чем на Perl/PHP. Личный опыт. Более того, я не редко всякие мелкие конвертеры на Си++ пишу, хотя и Perl и PHP знаю и регэкспами студии пользуюсь.
Хотя да, в той или иной степени язык должен подходить под задачу.
A>>>>В обсуждении да, а на практике? Много ли кода пишется не с std::auto_ptr, а с boost::shared_ptr? AVK>>>И кто в этом виноват? Неужели опять всемирный заговор? A>>Нет, способы разработки софта. AVK>Т.е. в случае С++ виноваты эти способы, а в случае C# уже нет? Ну так тогда это тоже плюс, что C# от этих способов не страдает
Он не успел пока от них пострадать
A>>Ну про пример с факториалом ты знаешь? AVK>Знаю. На редкость бесполезная вещь.
Это просто понятный пример.
A>> Типа метапрограммирование и всё такое. AVK>Во, теперь добрались до сути. Осталось понять что в язык нужно добавлять нормальные средства программирования, а не извращаться с шаблонами и все встанет на свои места.
Что есть тем и пользуюсь. Извратом это не считаю — просто на 100% использую возможности шаблонов.
A>>Ну то есть проект выходит смешанным... AVK>Да. А что в этом страшного?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Типа, сделал вид, что не понял?
A>Типа фраза по то, что система должна без человека работать попахивает керамикой.
Простите, чем?
A> Не в обиду, но звучало очень дико.
Фраза звучала не "система должна без человека работать", а "истема не должна зависеть от человека". Если для тебя это одно и тоже, то я тут не причем.
Паттерны вроде оберток и постоянного самоконтролья — это зависимость от человека. Это я называю плохим выбором.
А четкий алгоритм выявления и локализации утечек и ошибок исключающий зависимость от людей — это решение хорошее.
Ну, а реализация у этого решения может быть разная. Самая простая и логичная использование управляемых сред. В них любой контроль значительно упрощается.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Отсюда следует, что такая система не сожет быть создана человеком и не может быть созданна в даной Вселенной.
Не только может, но и не однократно создавались. Почти все серьезные серверные продукты имют ту или иную систему контроля ресурсов (причем неважно на чем они пишутся). Управляемые среды обеспечивают автоматическое управление памятью и простые средства контроля за ней. Поэтому являются идеальной основой для подобных решений.
ВП> Т. к. если система защиты от шибок, созданная человеком, априори содержит ошибки.
Неверно. Всегда возможно создать проверяемую систему. Это вопрос технологии, который как раз должны решать люди.
ВП> Даже (И особенно) если это компилятор компиляторов генераторов компиляторов [infinity_loop/] систем защиты от ошибок/средств разработки/иных систем. ВП>Просто делаем что можем и пытаемся придумать что бы ещё заморочить на тему борьбы против ошибок, а не борьбы вместе с ошибками против программ/людей
Ну, видимо ты так и действуешь. Но это не значит, что остальные делают тоже самое.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Насколько я представляю происходящее, в случае использования RAII вместо "старые сущности" вместе с подпиской на события убивались бы детерминированно. Соответственно, если мои представления соответствуют реальному положению дел, то да, по-прежнему считаю.
Блин, Пашь, ну, все просто как неучить уроков. Я думал, что вот такой код:
calss A
{
public EventHandler MyEvent;
}
class B
{
public void f(...)
{
}
}
...
A a = new A();
B b = new B();
a.Event += new EventHandler(b.f);
удерживает объект типа B только ссылкой b. Ошибочно думал. Ну, заклинило. Привык что память больше не ресурс. И что после выполнения кода:
b = null;
и первой сборки мусора объект типа B умрет. Но это не так и от события надо отвязываться явно.
Это привило к тому, что со временем в списке подключений к событию накапливалось слишком много объектов B и следующее подключение (в виду кривоватой реализации списка) начинало дико тормозить.
Полюдему оещиди заменой кода:
b = null;
на
a.Event -= new EventHandler(b.f);
b = null;
Деструктор тут непричем. Это все равно если в деструкторе забыть вызвать delete.
Я же предложил решать эту проблему путем создания кастом-подписке на викреференсе, но АВК сказал, что и так сойдет.
(это если на пальцах)
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AndrewVK,
> ПК>Насколько я представляю происходящее, в случае использования RAII вместо "старые сущности" вместе с подпиской на события убивались бы детерминированно.
> Так, вернулись к тому с чего начали. Еще раз — насколько я понимаю RAII означает следующее: получение ресурса совпадает с инициализацией.
+1
> Это позволяет в случае, если мы что то выделяем внутри блока автоматически освобождать ресурсы, потому что автоматически будут вызваны деструкторы.
Не только. Главное, чтобы с освобождением ресурса было ассоциировано прекращение времени жизни объекта.
> Но, если мы выделяем ресурс не в рамках метода, то RAII ничего не дает, поскольку никакой автоматики не будет. Даже если ты обернешь подписку на событие в спец. класс, все равно отписываться тебе придется руками. И если это забыть сделать то ты получишь ту самую проблему, о которой речь.
Не придется. В том месте, где я буду подписываться в очередной раз, я буду принимать решение: повторно использовать объекты, представляющие собой подписку на событие, или же создавать новые. Об этом забыть просто не получится.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AVM, Вы писали:
AVM>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, AVM, Вы писали:
AVM>>>Я с тобой почти готов согласиться, но есть одно маленькое но. На "голимом С" насколько я знаю никто ничего серьезного не пишет.
Ш>>Есть такая штука С++ EDG front-end. Написан на чистом C. На самом деле, слухи о смерти С сильно преувеличены. AVM>Я очень далек от мысли, чтобы хоронить C (как чистый так и в комбинации с различными библииотеками), но согласись, что человек отличается от обезьяны умением использовать инструменты в своей работе (некоторые продвинутые обезьяны, это исключение, которое подтверждает этот тезис) . Это я к тому что не совсем логично писать проект на чистом С, без использования каких либо библиотек (если конечно в требованиях это специально не оговаривается).
Ну зачем, без библиотек. В других языках мы же используем библиотеки/компоненты, почему в С зазорно их использовать? Тем не менее суть дела это не меняет, до сих пор С остаётся языком, активно используемым в серьёзных проектах. Не говоря уже об огромном объёме legacy кода.
AVM>Ты не можешь коротко в 2-х словах рассказать что это за штука (С++ EDG front-end) и как ты ее практически используешь?
С++ front-end -- это часть С++ компилятора, которая превращает исходный текст в промежуточный код. Собственно, про EDG лучше почитать на сайте компании. http://www.edg.com/cpp.html
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Следовательно, одну неделю на ловлю ошибки не пришлось бы терять и т.д... ГВ>>Эксь. Ну а как насчёт того, что в сами-знает-каких-языках за счёт отсуствия сами-знаете-каких-способностей по сравнению с сами-наверняка-знаете-каким-языком приходится тратить больше времени на имплементацию одного и того же?
СГ>Если в языке нет возможности получения адреса объекта расположенного на стеке (впрочем как и вообще нет возможности получения какого бы ни было адреса), то и нет обсуждаемой здесь проблемы. Все остальное в сад...
Да что ж за язык такой, как советский гастроном -- и того в нем нет, и этого тоже нет. Чтобы дети не устроили пожар, надо изъять из торговли спички.
.
