WH>Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.
Одновременно? Попахивает извращением. Хотя, возможно, какое-то зерно в этом есть.
Здравствуйте, mihailik, Вы писали:
M>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.
Слово "например" видел?
M>В том то и дело, что нестрогие определения как раз и приводят к таким вот доопределениям "на ходу". Чтобы объяснить, что такое "детерменированное освобождение" тебе пришлось и от умных указателей отталкиваться, и от GC, и от цены. Как будто этот детерминизм — не реальное понятие, а что-то из области гуманитарных наук. Что нельзя понять, только сердцем почувствовать
Ну, если подходить совсем формально, в случае с GC он бесспорно тоже определен в каком-то смысле. Можно ведь после каждого присваивания ссылки делать GC.Collect(), только ведь это абсурд.
Попробуем определить так: детерминированность — это когда событие не зависит от внешних к системе факторов.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
WH>>>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.
То оче ты говоришь называется MarshalByRefObject и для него существуют определенные интерфейсы для определения его времени жизни. Хотя и пользоваться им не стоит часто. Очень сомнительно, использовать объект с подключенным к нему кучей других из одного потока , вместо того чтобы прямо его использовать. Значит, что то с логикой программы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
WH>>Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой. S>Ну у нас софтина под java работала как часы под очень жесткой нагрузкой. Ну, это не так важно. Хотя я вообще не очень понимаю, как Java или .NET может вообще положить систему. Надо бы изучить эту тему.
Ну на счет операционки это я скорей всего погорячился (хотя если в callback'е поставить открытие файла то система будет чувствовать себя очень хреново) но сама себя программа может свалить легко
using System;
using System.Threading;
namespace SystemCrush
{
class Class1
{
static object sync=new object();
static void callback()
{
lock(sync)
Thread.Sleep(0);
}
[STAThread]
static void Main(string[] args)
{
while(true)
new Thread(new ThreadStart(callback)).Start();
}
}
}
В место Thread.Sleep может быть любая операция прерывающая поток.
В реальной жизни на сервак который обрабатывает пользователей в отдельных потоках пришла бешеная нагрузка.
S>Ну, вообще представить себе такой случай особой фантазии не надо. Практически любое отношение в бизнес-системе позволяет двустороннюю навигацию. Его можно, конечно, искусственно разорвать, но это не всегда удобно. Ну там накладная->клиент->список накладных->накладная. пипец.
И кто из них работает с системными ресурсами?
S>А! вот одновременно — неплохая идея. Поверх GC можно реализовать подсчет ссылок. Очень даже вполне.
Для этого надо хоть какието средства со стороны среды. Хотя и сейчас можно но на это смотреть будет страшно. Нужны смартпоинтеры.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mihailik, Вы писали:
M>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.
Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже.
Что не понятно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Именно. Всё должно быть как можно проще.
WH>Вот именно все должно быть проще. Вот скажи мне какого черта я должен прописать создание десятка объектов (конструктор по умолчению которых мне прекрасно подходит) в конструкторе и удаление всех в деструкторе если я могу их лишь одан раз описать?
В конечном счёте для того, чтобы не нужно было заботится о циклических ссылках.
WH>А слабо integer by ref сделать? M>>Именно, что слабо. Никому не нужная экзотика. WH>Ну ладно не int а класс написаный неизвесно кем не извесно когда и менять его ты не можешь. Ы?
Тут и делать ничего не надо. Все классы в Дельфи byref.
AK> делфи язык бизнес-апликаций, с++ язык системного уровня — но при этом он совершенно свободно может быть использован для наисания все-чего угодно...
Это "чего угодно" меня просто веселит. Вы, товарищи крутые программисты, bat-файлы тоже на C++ пишете? Или зашоренность до таких размеров ещё не разрослась?
WF>>Судя по тому компилятору, который они сейчас попробовать дают, в Java будут на редкость отстойные шаблоны .
M>>Хе-хе. Мелочь, а приятно.
WH>Ну и нахрена нужны отмазки в место инструментов?
Ты не понял. Это я радуюсь, что злопакостным явщикам неприятности сыпятся. Микрософт, как это говорят, форева!
WF>>> И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом.
M>>Вот он, булыжник в огород сишников!
WH>Ага ты посмотри посты Serginio1 где он пытается реализовать элементарные вещи.
Ну, ты не путай. Одно дело — коренная убогость капиталистов, а другое дело социалистические перегибы на местах.
M>>Я не знаю, насколько STL зависит от платформы. WH>STL от платформы не зависит вобще.
Это хорошо, если так. Видимо, ребята из Микрософта не были так в этом уверены.
WH>>>Слова человека не знающего о существовании такого понятия в STL как allocator. M>>Для профессионального программиста на C++ ты делаешь удивительно тривиальные выводы. Да, я не знаю, что такое STL allocator. И именно поэтому, я не понимаю твоего аргумента WH>Это такая дурь скармливается последним аргументом шаблона(обычно используется аллокатор по умолчанию) Короче можно заставить контейнер использовать тот распределитель памяти который тебе нужен.
Ага. Удобно.
WH>>>Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов. M>>Думаю, без хороших библиотек шаблоны среднеполезны. WH>Думаю без шаблонов хороших библиотек не напишешь.
Напоминаю, вопрос в том, стоит ли в драйверах использовать C++.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Serginio1, Вы писали:
WH>У мнея такое ощущение что кто-то чего-то сильно не понимает. WH>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок. А вот как его реализовать в .НЕТ чтобы не было мучительно больно при использовании это уже придется хорошо подумать. WH>Хотя некоторые объекты (строки,...) лучше на GC.
Для этого существуют Синглетоны, Синглкалы и активированные клиентом объекты. Правда через MarshalByRefObject. При этом подсчет ссылок совершенно не нужен, особенно когда клиент отвалился. То, что следить за системными ресурсам стало сложнее это накладывает более продуманный подход к программированию. А выбор есть, только не тот к чему ты привык.
и солнце б утром не вставало, когда бы не было меня
M>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.
WH>Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже. WH>Что не понятно?
M>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.
WF>Слово "например" видел?
Через примеры можно только описать, но нельзя определить.
WF>Попробуем определить так: детерминированность — это когда событие не зависит от внешних к системе факторов.
Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".
WH>В место Thread.Sleep может быть любая операция прерывающая поток. WH>В реальной жизни на сервак который обрабатывает пользователей в отдельных потоках пришла бешеная нагрузка.
Ого, ты попробуй там while(true), тоже экстремальные ощущения.
Здравствуйте, mihailik, Вы писали:
M>>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.
WH>>Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже. WH>>Что не понятно?
M>Непонятно слово "необходимость".
Ссылок не осталось. Необходимость есть, пока существуют ссылки. Ну хорошо, если тебе так нравится, пускай будет так: пока существуют сильные ссылки (strong references), которыми определяется семантика владения объектом.
Если ссылок на объект не осталось (ушли из поля видимости исполняемого в данный момент кода), он СРАЗУ ЖЕ будет прибит.
Пример:
0. Начало функции.
1. Создаем на куче объект0.
2. Заворачиваем его в смарт-поинтер.
3. Передаем смарт-поинтер объекту1,
4. передаем смарт-поинтер объекту2.
5. некие действия
6. конец функции.
Объект0 умрет в случае когда оба объекта 1 и 2 наиграются им, и выбросят.
В случае, если они наигрались им до завершения нашей функции, то он будет прибит при ее завершении.
Здравствуйте, Serginio1, Вы писали:
S> Были еще Модула и (уже забыл Обтерон вроде) тоже ООП. Главное идеи и их преемственность. А так как я вырос еще из Виртовского Паскаля, то эти переходы для меня очень просты.
Оберон2. Жаль ты не видел это "объектной-ориентированнсоти".
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FWP, Вы писали:
FWP>Вирт создал не только Pascal. Были еще Modula, Modula-2, Modula-3. TurboPascal и Delphi много чего почерпнули из них.
Врд ли можно что-то почерпнуть из продуктов вышедших позже. Да и слава богу что не почепрнули. Уж очень своеобразное видение ОО у Вирта.
FWP> Создатели Delphi привнесли в язык много модных, но потенциально опасных вещей. Поэтому он и "плевался". И если Modula-2 и TurboPascal — близняшки, то Oberon-2 и Delphi7 — троюродные братья
Да как две капили воды и пластмассы.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
M>Через примеры можно только описать, но нельзя определить.
Вообще-то примеры нужны для лучшего понимания... Чтобы разговор не превратился в совершенно оторванный флейм (правда, он уже превратился ). Собственно, для этого я их и пытался дать. Т.е на вопрос я давал конкретный пример и попытку определения.
M>Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".
Хорошо, давай определимся, что я считаю системой и внешними факторами.
Весь программный комплекс — внутренняя система. Все библиотеки, все классы, объекты с которыми программа работает. Поэтому возможность смерти объекта не зависит от внешних факторов. GC — это внешний фактор, программа про него ничего не знает. И про память она ничего не знает.
Грубо говоря: Живут себе объекты, рождаются как-то, посылают сообщения друг другу. Иногда, когда про объект забывают, он через некоторое время загадочным образом умирает. Повлиять, когда он реально умрет другие объекты не могут. А вот в C++ жизнь объекта не зависит от внешних факторов, объекты как-то общаются друг с другом, и когда они договариваются о ненужности какого-либо объекта, они его убивают. Вот детерминированность в моем определении.
.
