Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не придется. В том месте, где я буду подписываться в очередной раз, я буду принимать решение: повторно использовать объекты, представляющие собой подписку на событие, или же создавать новые. Об этом забыть просто не получится.
Сколько тебе раз повторить. Никто ничего не забывл. Просто неверно интерпретировалась зависимость времени жизни от наличия ссылки в виде подписки на событие. Я думал, что там используется викреференс (если тебе это что-то говорит).
Присваивать ты ничего не можешь, так как на событие может быть подписано много подпичиков.
Это как помещение в вектор и удаление из него.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, Зверёк Харьковский, Вы писали:
Ш>>>>I Robot смотрел?.. ЗХ>>> Оригинал надо читать.
Ш>>Не совсем понял замечание. Я, кстати, Азимова не люблю. Но мысль то в фильме вполне понятная. Если ты намекаешь, что типа кино -- убогая поделка, ну а что ты хочешь -- Голливуд. ЗХ>Угу, я убогую поделку имел в виду ЗХ>Азимова, кстати, тоже не очень люблю, но я на нем вырос, так что он у меня в крови.
Но надо все же отдать должное — могли снять и похуже.
Кто тут Азимова не любит?
... << RSDN@Home 1.1.4 beta 3 rev. 241>> ... <<Winamp is playing "Kimiko Itoh — 12 Follow Me">>
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, AVM, Вы писали:
AVM>>Здравствуйте, Шахтер, Вы писали:
Ш>>>Здравствуйте, AVM, Вы писали:
AVM>>>>Я с тобой почти готов согласиться, но есть одно маленькое но. На "голимом С" насколько я знаю никто ничего серьезного не пишет.
Ш>>>Есть такая штука С++ EDG front-end. Написан на чистом C. На самом деле, слухи о смерти С сильно преувеличены. AVM>>Я очень далек от мысли, чтобы хоронить C (как чистый так и в комбинации с различными библииотеками), но согласись, что человек отличается от обезьяны умением использовать инструменты в своей работе (некоторые продвинутые обезьяны, это исключение, которое подтверждает этот тезис) . Это я к тому что не совсем логично писать проект на чистом С, без использования каких либо библиотек (если конечно в требованиях это специально не оговаривается).
Ш>Ну зачем, без библиотек. В других языках мы же используем библиотеки/компоненты, почему в С зазорно их использовать? Тем не менее суть дела это не меняет, до сих пор С остаётся языком, активно используемым в серьёзных проектах. Не говоря уже об огромном объёме legacy кода.
Я имею ввиду не то что С голимый, а то что возможности языка в большей степени определяюся библиотеками, которые на нем написаны. C остается, и я думаю еще долгое время будет оставаться, активно используемым языком. Просто Java и С# потеснили его в некоторых областях, в частности java в области создания кроссплатформеных решений.
Видимо мы не поняли друг друга.
AVM>>Ты не можешь коротко в 2-х словах рассказать что это за штука (С++ EDG front-end) и как ты ее практически используешь?
Ш>С++ front-end -- это часть С++ компилятора, которая превращает исходный текст в промежуточный код. Собственно, про EDG лучше почитать на сайте компании. Ш>http://www.edg.com/cpp.html
ок, спасибо за ссылку, наверное найду что нибудь интересное для себя
Здравствуйте, Павел Кузнецов, Вы писали:
>> Это позволяет в случае, если мы что то выделяем внутри блока автоматически освобождать ресурсы, потому что автоматически будут вызваны деструкторы.
ПК>Не только. Главное, чтобы с освобождением ресурса было ассоциировано прекращение времени жизни объекта.
Только без автоматического деструктора смысла в этом уже немного.
>> Но, если мы выделяем ресурс не в рамках метода, то RAII ничего не дает, поскольку никакой автоматики не будет. Даже если ты обернешь подписку на событие в спец. класс, все равно отписываться тебе придется руками. И если это забыть сделать то ты получишь ту самую проблему, о которой речь.
ПК>Не придется. В том месте, где я буду подписываться в очередной раз, я буду принимать решение: повторно использовать объекты, представляющие собой подписку на событие, или же создавать новые.
Т.е. вручную котроллировать управление ресурсами, или создавать специальный контейнер для потребителей.
ПК> Об этом забыть просто не получится.
Возможно. Но RAII тут уже совершенно не при чем.
На самом деле все очень просто — узкая трактовка RAII, как например здесь предполагает наличие детерменированных автоматических деструкторов
RAII can be used with:
Languages which can have user-defined types allocated on the stack (“automatic” objects in C/C++ terminology) and cleaned up during normal stack cleanup (whether because of a function returning, or an exception being thrown). E.g. C++.
Languages which have reference-counted garbage collection and hence predictable cleanup of an object for which there is only one reference. E.g. VB6
В дотнете она не применима по определению.
Широкая же трактовка, как например здесь, в дотнете соблюдается, более того там это фактически часть идеологии, поскольку использовать голые хендлы в дотнете просто таки моветон.
Но и та и другая трактовка от вышеупомянутой ошибки не спасают, поскольку там не потеря ресурса происходит (ресурсов то никаких не выделяется, а память в дотнете ресурсом не является), там приключается неверное формирование графа объекта программы. Ошибка чисто логическая.
На самом деле подобные вещи в дотнете можно избежать (если интересно — могу рассказать как). Только методы решения ничего общего с RAII не имеют.
Здравствуйте, adontz, Вы писали:
A>>>многопоточность — это может быть везде AVK>>И?
A>Я просто хочу сказать что написание многопоточных программ для конкретной платформы на любом не многопоточном языке (не поддерживающем многопоточность синтаксически)
Что значит "поддерживать многопоточность синтаксически"?
A> связано с одними и теми же проблемами (проблема на самом деле одна — синхронизация доступа) и использование конкретного языка не даёт преимуществ.
А я и не говорил про преимущества. Это ответ на то что ты считаешь что я только сетью и GUI занимался.
A>>>OO RPC — уточни о чём ты. Я это прочёл как Object Oriented Remote Procedure Call и не въехал. AVK>>Правильно прочел. А во что не вьехал? См. например здесь
A>Я не въёхал зачем это разрабатывать? Есть же DCOM, Remoting.
Это низкоуровневые технологии.
A>>>механика деплоймента — автоматизировання установка программы? AVK>>Это автоматическая инсталляция пакетов с бизнес-логикой, а не программы.
A>Угу. В Си++ я бы использовал "установку по требованию MSI" если список пакетов известен заранее, "COM/pure-DLL плагины и закачку по сети с сервера по требованию (скорее всего через WinInet)" если список пакетов заранее не известен (меняется, обновляется). На самом деле етсь решения от InstallShield, есть FlashUpdate, есть другие системы...
Это немного не то. Инсталляция бизнес-пакета это не просто перемещение набора файлов. В дополнение это обычно довольно много телодвижений — генерация оберток, контейнеров, модификация БД, заполнение внутренних реестров и кешей и т.п.
A>Чем C#/.Net лучше? Что он предоставляет вкусненького?
Ну прежде всего наличием встроенной в язык компонентности. Еще наличием компиляции в рантайме. Возможностью в рантайме легко управлять ресолвингом ссылок.
A>>>система логирования и контроля производительности — это может быть везде AVK>>И?
A>И чем C#/.Net в этом смысле лучше? Что он предоставляет вкусненького?
Компонетность.
A>>>транзакции — все контекста БД? AVK>>Нет. A>Извини, может ты не так понял. Опечатка. A>вне контекста БД?
Да.
A>>>поддержка сессий, управление жизненным циклом объектов — все веб контекста? AVK>>Нет. A>Извини, может ты не так понял. Опечатка. A>вне веб контекста?
Какие то у тебя уж больно стабильные опечатки . Нет никакого веба — сервер приложений это не веб-странички. Контекст разумеется свой.
A>>>управление асинхронными задачами — это может быть везде AVK>>И?
A>И чем C#/.Net удобнее? Что он предоставляет вкусненького?
Встроенная синхронизация инициализации классов, наличие в языке lock, атрибутов синхронизации.
Только мне кажется ты отклоняешься от исходной темы. Напоминаю твои слова:
AVK>Есть конечно и дорогие, но их обычно можно по пальцам одной руки пересчитать. Я уже не раз тебе говорил — де факто с проблемами забытых Dispose я не сталкивался ни разу.
A>Я за тебя рад, но разрабатывая приложения в которых только сеть и GUI на такие проблемы и вряд ли натолкнёшься.
AVK>А с чего ты взял? Если ты думаешь что я на работе пишу янусы, то ты глубоко ошибаешься. Моя специализация вобще то сервера приложений.
Причем здесь удобство/неудобство дотнета?
A>>> Это скорее административная чем программистская задача. AVK>>Пробовал реализовать?
A>Административно?
Нет, внутри программы. Насчет административно я еще помню .
A> Делал Integrated Security, документацию на 2-3 странички какие права доступа нужны и забывал об аутенфикации навсегда.
Про авторизацию уже забыл? До недавнего времени на эту тему для программера у МС ничего не было.
A>>>контроль безопасности бизнес-кода — поясни о чём речь AVK>>О том что бизнес-коду нужно запретить делать то, что он не имеет права делать.
A>Я это делаю запуская всю систему под отдельным пользователем. Обычно все довольны
Это потому что ты не писал сервера приложений. Отдельный пользователь не спасет во-первых потому что у разных пользователей разные права, а имперсонация не очень хорошее решение, во-вторых подсистема безопасности виндов контроллирует только системные ресурсы, контроль ресурсов программы надо делать самостоятельно, в-третьих назначение прав коду удобнее назначения прав пользователю хотя бы потому что служебный код может обладать значительно большими нежели бизнес-код правами в том же потоке. Короче — нужно защищать не только от порчи системы, но и от порчи самого сервера.
A>>>файловые и БД хранилища — разработка или использование? AVK>>Разработка.
A>Файловое хранилище это обычно сериализация.
Не только. Есть еще задачи по организации этого хранилища — размещение, поиск, удаление ненужного.
A> В MFC она есть,
По сравнению с дотнетовской весьма убогая.
A> Есть так же несколько сторонних библиотек для этой цели.
Тем не менее все они предполагают ручное кодирование. На сайте есть статья на эту тему, там описано пожалуй лучшее, что можно реализовать на С++.
A> Естьвелосипеды. Думаю свои БД вы не пишите, так что под разработкой БД хранилищ подразумевается проектирование таблиц, хранимок и всего такого.
Нет. Подразумевается опять же управление.
A>Где же здесь неоспоримое преимущество С#/.Net? Победителей получилось много. На самом деле просто похоронили Object Pascal
Ты имеешь ввиду по сравнению с С++? Очень простое — решения на нем выглядят изящнее, нежели монстроидальные малопонятные шаблоны. И не сказывается на скорости компиляции и всяких интеллисенсов.
A>>>>>В обсуждении да, а на практике? Много ли кода пишется не с std::auto_ptr, а с boost::shared_ptr? AVK>>>>И кто в этом виноват? Неужели опять всемирный заговор? A>>>Нет, способы разработки софта. AVK>>Т.е. в случае С++ виноваты эти способы, а в случае C# уже нет? Ну так тогда это тоже плюс, что C# от этих способов не страдает
A>Он не успел пока от них пострадать
То есть со временем ситуация становится хуже? Ну тогда ждать что на С++ ситуация улучшится тоже не стоит.
AVK>>Во, теперь добрались до сути. Осталось понять что в язык нужно добавлять нормальные средства программирования, а не извращаться с шаблонами и все встанет на свои места.
A>Что есть тем и пользуюсь. Извратом это не считаю — просто на 100% использую возможности шаблонов.
Я бы сказал на 110, поскольку шаблоны разрабатывались для дженерик-программирования, а не для метапрограммирования.
A>>>Ну то есть проект выходит смешанным... AVK>>Да. А что в этом страшного?
A>Поганое качество какой-то из частей.
Здравствуйте, McSeem2, Вы писали:
MS>Во-вторых, использование умных указателей для объектов, создающихся динамически через фабрики классов — это лишь один из способов. Есть и другие, например специализированные контейнеты, подчищающие объекты по указателям, объекты "суициидного" типа и т.д.
А можно по подробнее про объекты "суициидного" типа и т.д.?
Здравствуйте, AndrewVK, Вы писали:
A>>Я просто хочу сказать что написание многопоточных программ для конкретной платформы на любом не многопоточном языке (не поддерживающем многопоточность синтаксически) AVK>Что значит "поддерживать многопоточность синтаксически"?
Это значит, что не делаешь CreateThread(...) или что-то в этом роде, а описываешь создание нового потока, его удаление и межпотоковую синхронизацию исключительно пользуясь ключевыми словами языка.
A>>>>механика деплоймента — автоматизировання установка программы? AVK>>>Это автоматическая инсталляция пакетов с бизнес-логикой, а не программы.
AVK>Причем здесь удобство/неудобство дотнета?
Удобство в данном случае это более удобное решение описываемых задач.
AVK>>>Т.е. в случае С++ виноваты эти способы, а в случае C# уже нет? Ну так тогда это тоже плюс, что C# от этих способов не страдает A>>Он не успел пока от них пострадать AVK>То есть со временем ситуация становится хуже? Ну тогда ждать что на С++ ситуация улучшится тоже не стоит.
Нет, не станет. Ситуация на C# станет хуже.
AVK>>>Во, теперь добрались до сути. Осталось понять что в язык нужно добавлять нормальные средства программирования, а не извращаться с шаблонами и все встанет на свои места. A>>Что есть тем и пользуюсь. Извратом это не считаю — просто на 100% использую возможности шаблонов. AVK>Я бы сказал на 110, поскольку шаблоны разрабатывались для дженерик-программирования, а не для метапрограммирования.
Здравствуйте, adontz, Вы писали:
A>>>Я просто хочу сказать что написание многопоточных программ для конкретной платформы на любом не многопоточном языке (не поддерживающем многопоточность синтаксически) AVK>>Что значит "поддерживать многопоточность синтаксически"?
A>Это значит, что не делаешь CreateThread(...) или что-то в этом роде, а описываешь создание нового потока, его удаление и межпотоковую синхронизацию исключительно пользуясь ключевыми словами языка.
Для синхронизации в шарпе есть ключевое слово, а для создания используется тот самый RAII, о котором Паша говорил. Зачем нужно для этого ключевое слово я не знаю.
AVK>>Причем здесь удобство/неудобство дотнета? A>Удобство в данном случае это более удобное решение описываемых задач.
Ты зря поскипал цитату. Помнишь о чем речь была, когда я стал рассказывать о серверах приложений?
AVK>>Я бы сказал на 110, поскольку шаблоны разрабатывались для дженерик-программирования, а не для метапрограммирования.
A>А что в C# есть для подобных задач?
Довольно мало. В основном это атрибуты, рефлекшен, заметно более простая кодогенерация.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, adontz, Вы писали:
AVK>>>Я бы сказал на 110, поскольку шаблоны разрабатывались для дженерик-программирования, а не для метапрограммирования.
A>>А что в C# есть для подобных задач?
AVK>Довольно мало. В основном это атрибуты, рефлекшен, заметно более простая кодогенерация.
А есть какие-либо тенденции к развитию подобного рода "фишек"? Кроме R# ес-но
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
К>>А есть какие-либо тенденции к развитию подобного рода "фишек"? Кроме R# ес-но
AVK>Ты имеешь ввиду МСные или сторонние. Если сторонние то есть. Например XC#. От МС пока ничего не слышно.
Конечно лучше мсное , а то ...
А вот это с шарпом, не можешь дать ссылку, а то что-то гуглевание плохо помогает...
Заранее спасибо.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, AndrewVK, Вы писали:
A>Это значит, что не делаешь CreateThread(...) или что-то в этом роде, а описываешь создание нового потока, его удаление и межпотоковую синхронизацию исключительно пользуясь ключевыми словами языка.
Мы на любом языке всё так или иначе всё описываем, ограничены только ключевыми словами языка...
Чем Вас не устраивает synchronized в java:? Тем, что не бъёт по рукам, когда вызываешь "циклическую заклинивающую синхронизацию", во время компиляции?
A>>>Что есть тем и пользуюсь. Извратом это не считаю — просто на 100% использую возможности шаблонов. AVK>>Я бы сказал на 110, поскольку шаблоны разрабатывались для дженерик-программирования, а не для метапрограммирования.
Ну так памятник поставьте — за создание из ничего 10% возможностей
Изврат — это очень имхоистый критерий.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Волк-Призрак, Вы писали:
ВП>>Отсюда следует, что такая система не сожет быть создана человеком и не может быть созданна в даной Вселенной.
VD>Не только может, но и не однократно создавались. Почти все серьезные серверные продукты имют ту или иную систему контроля ресурсов (причем неважно на чем они пишутся). Управляемые среды обеспечивают автоматическое управление памятью и простые средства контроля за ней. Поэтому являются идеальной основой для подобных решений.
Не и деальной, а самой близкой к требуемому уровню безошибочности. Единственный девелопер, который никогда не ошибается, это Бог.
ВП>> Т. к. если система защиты от шибок, созданная человеком, априори содержит ошибки.
VD>Неверно. Всегда возможно создать проверяемую систему. Это вопрос технологии, который как раз должны решать люди.
...способные к ошибкам. "Ружьё, если оно есть дома, обязязательно выстрелит".
ВП>> Даже (И особенно) если это компилятор компиляторов генераторов компиляторов [infinity_loop/] систем защиты от ошибок/средств разработки/иных систем. ВП>>Просто делаем что можем и пытаемся придумать что бы ещё заморочить на тему борьбы против ошибок, а не борьбы вместе с ошибками против программ/людей
VD>Ну, видимо ты так и действуешь. Но это не значит, что остальные делают тоже самое.
Я так не делаю. Я просто не идиеализирую рукотворное, протоколитрую ошмбки, и смотрю по логам, что происходит, чтобы это не повторялось, то что в логах указывает на ошибку, посредством определения и устронения ошибки. Отладка не всегда мне поможет, т. к. использование отладчика на моём компе часто вызывает коматозные тормоза (даже на винамп 2-4% нет возможности выделить, а иногда и полное повисание винды происходит).
Здравствуйте, Курилка, Вы писали: AVK>>Ты имеешь ввиду МСные или сторонние. Если сторонние то есть. Например XC#. От МС пока ничего не слышно. К>А вот это с шарпом, не можешь дать ссылку, а то что-то гуглевание плохо помогает... http://www.resolvecorp.com/default.aspx
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, EvilChild, Вы писали:
EC>А можно по подробнее про объекты "суициидного" типа и т.д.?
Ну это типа:
void DecrementRefCounter()
{
if (--m_RefCounter == 0) delete this;
}
Но лично мне это сильно не нравится, поскольку предполагает де-локализацию времени жизни объекта. Плюс существенные ограничения, типа объект может быть создан только в куче.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Но лично мне это сильно не нравится, поскольку предполагает де-локализацию времени жизни объекта. Плюс существенные ограничения, типа объект может быть создан только в куче.
Не редко, когда объект должен удалять по событию (WM_DESTROY например ) это наилучшее решение.
Здравствуйте, adontz, Вы писали:
A>Не редко, когда объект должен удалять по событию (WM_DESTROY например ) это наилучшее решение.
Согласен, это — вынужденная мера. Решается написанием простой оболочки вокруг обычного класса, обладающего некой прикладной функциональностью, независимой от WM_DESTROY.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Оригинал надо читать.
