EG>А разве у .NET процессов IRQL выше PASSIVE_LEVEL ? EG>Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
Просто у сборщика мусора довольно хитрый и сложный алгоритм определения момента когда нужно включаться.
EG>и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0 EG>Это помоему былобы разумно.
Вобщето в .NET нет никаких счетчиков ссылок. Там мусор по другому собирают. Есть объекты которые крепятся, скажем, к аппаратным ресурсам-их удалять нельзя, они ссылаются на другие объекты. Таким образом обходится все дерево из них растущее . Все что в дерево не вошло — все это мусор подлежащий удалению — но неизвестно когда, когда жареный петух клюнет.
Внутри одного .NET процесса управление памятью довольно эффективное, но каждый такой процесс думает только о себе.
А несколько десятков таких процессов, если не будут как то согласовывать распределение памяти, будут использовать память очень не эффективно. Нужен какой то профсоюз мусоршиков из всех процессов.
S_>> Еще память расходуется из-за того что процессы держат многие десятки мегабайт одинаковых стандартных библиотек в памяти.
EG>Это да однозначно mscoree не грузится статически EG>И поэтому кажный процесс получает по екземпляру mscoree и нетолько EG>Что вобщемто как бы меня не убеждали ресурсо-неэффективно
mscoree.dll это еще цветочки — 150 килобайт всего,а там еще мегабайтов 40, стандартных библиотек. Большая часть которых запросто может быть использована мелкой утилиткой.
Может это технически и нереально разделять общую память для кода стандартных библиотек на все процессы. Но тогда проблемы будут серьезные. Раньше то таких проблем не было до .NET — так как такого количества стандартных библиотек просто не было. И с каждой новой версией их количество быстро увеличивается.
Если запускать только 1-3 .NET процесса то никаких проблем. А если больше то кривовато пока.
ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители... SAV>два года ( + год-два на распространение ОС) у регионов есть что бы SAV>приобрести /что-то вроде P-IV. Так что все нормально
У регионов еще 80286 несписанные стоят и пашут
Срок списания и амортизации техники у регионов несколько иной.
Регионы потому и стремяться перейти на OpenSource(Linux,FreeBSD и т.д.)
я в частности был вынужден все коммуникационные серваки на работе,
как впрочем и почтовые перенести на FreeBSD, в связи с тем что
мелкомягкие всечаще интересуются лицензионностью софта.
А техническая поддержка мелкомягких как и всех остальных в регионах не более чем красивая сказка.
Потому и стремяться все купить если приложение бизнес-логики банковской то
RS-BANK, потому как rsl потому как все перекопать можно под себя
Потому и OpenSource что все проблемы и так на конечном пользователе висят,
дык проще с OpenSource разобраться чем с уже откомилированным кодом от Мелкомягких
Тут речь даже не о том как перейти на .NET а о том как нанего неперейти с наиболее
низкими затратами и прочими издержками.
Хороше что мне тут сообщили о том что есть mono. Теперь буду еще и его искать.
Незнаю есть ли версии под FreeBSD.
К примеру Celeron 800 -считается нормальной даже высокопроизводительной тачкой для регионов сейчас
И списаны Celeron 800 будут лет эдак через 10-15
Просто я понимаю что .NET это неотвратимое будующейй для России,а для Москвы уже настоящее
Поэтому изза этой неотвратимости я должен все взвесить и принять решение, не стоит ли пользоваться Linux + mono. Так как линь всетаки является более экономным и расчетливым нежели Winь .
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Edvard Grieg, Вы писали:
EG>>А разве у .NET процессов IRQL выше PASSIVE_LEVEL ? EG>>Многозадачность вроде никто не отменял мне кажется в таком случае как раз Runtime
S_>Просто у сборщика мусора довольно хитрый и сложный алгоритм определения момента когда нужно включаться.
EG>>и должен проявить свою мощь Объект без указателя (хендла какойлибо ссылки как хотите вобщем) должен быть уничтожен если счетчик ссылок на объект достигнет 0 EG>>Это помоему былобы разумно.
S_>Вобщето в .NET нет никаких счетчиков ссылок. Там мусор по другому собирают. Есть объекты которые крепятся, S_>скажем, к аппаратным ресурсам-их удалять нельзя, они ссылаются на другие объекты. Таким образом обходится все S_>дерево из них растущее . Все что в дерево не вошло — все это мусор подлежащий удалению — но неизвестно когда, S_>когда жареный петух клюнет.
Спасибо за информацию но мне кажется что какраз так и происходит в у диспетчера NT,
есть дерево Lookaside List и время от времени диспетчеры всякие пробегают по всему дереву.
Но мне всеже кажется что щетчики должны быть, иначе откуда известно сколько веток отходит от уза дерева???
Здравствуйте, Edvard Grieg, Вы писали:
EG>ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители... SAV>>два года ( + год-два на распространение ОС) у регионов есть что бы SAV>приобрести /что-то вроде P-IV. Так что все нормально EG>У регионов еще 80286 несписанные стоят и пашут
Можешь мне не рассказывать, у меня в профайле значится Архангельск. Так вот, это правда Мой продукт (.NET) несмотря на минимальные требования, успешно используют на P-133 64Mb. И ничего, радуются жизни (только вот грузится долго, прихошлось приписать к обновлялке опциональнцю функцию обработки сборок ngen`ом, стало лучше). Так что не все так плохо.
Здравствуйте, Nuald, Вы писали:
N>Автоген тут не причем. Мне приходится часто писать кросс-платформенные приложения, и если на данный момент слой чистого win-кода не особо большой, то после перехода на управляемый код все кардинально изменится — даже не уверен, удастся ли писать такие приложения...
Все универсальное убого. Так что тут заморчиваться не нужно. Все равно ты не сможешь обеспечить подержки всех фич всех ОС. Так что или выбирай Яву (возможно дотнет с Моно) или С/С++ и забивай на фичи ОС. Опять таки сможешь привинчивать ОС-специфичные фичи вручную.
N>И еще — что же получается — сам длинный рог дофига будет жрать ресурсов, но если под ним будут крутится только приложения под .NET, то это вообще будет полный абзац — это же какие ресурсы нужны будут тачке...
Каждая новая ОС будет жрать все больше и бльше ресурсов. По крайней мере до глобального рефакторинга или до переписывания с нуля. Это закон. Тут ничего не поделаешь. Только дотнет тут совершенно не причем. В том же ЛХ основную память сжирает MSSQL.
N> Что-то у меня сомнения приживется ли он в России, если конечно, к выпуску рога все регионы не станут такими же богатыми как москва, чтобы можно было во всех офисах ставить пни 4 >3ггц, >=1 гб озу, 3д-ускорители...
Такие сомнения я слышал по поводу всех без исключения версий ОС. Никогда в жизни они еще не подтверждались на практике. Приживание новой ОС — это вопрос времени. Как минимум компьютеры стареют и выходят из строя. Так что рано или поздно все перейдут на новые версии.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Edvard Grieg, Вы писали:
EG>У регионов еще 80286 несписанные стоят и пашут
Вот эти сказки лучше петь где-то в другом месте.
Двушки вымерли как диназавры. Отдельные экспонаты конечно можно найти, но к мэйнстриму это отношение не имеет. По официальной статистике Интел Россия обгоняет еврому по продажам процессоров.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, woto, Вы писали:
W>Так в смысле как раз и нету возможности его скачать .
Физической что ли?
W>Он бесплатный же?
Да.
W> Я точно не уверен состоите ли вы в команде RSDN Team,
Если красный значе есть, значит состою пока.
W> и не нарушает ли это какие-то правила microsoft'a, но все таки спрошу. Можно ли надеяться что он будет идти в комлпекте с журналом RSDN, а то ролики эти уже запарили .
Вряд ли. У МС есть жесткая и дурацкая политика на этот счет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
[QUOTE]
Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться
[/QUOTE]
Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора.
Это принцип. Так устроено все!
Там где зеканчивается это:
void Test()
{
TextWriter tw = new StreamWriter("test.txt",true);
tw.Write("123");
}
Так или иначе начинается вот это:
CreateFile
NtCreateFile();
Потом вот это:
int 2E;
Потом вот это:
ZwCreateFile
и т.д.
А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д.
Ради интереса стоит узнать что -такое PEB.
ObjectManager в дальнейшем следит за объектом процесса и хэндлами.
Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Здравствуйте, Serginio1, Вы писали:
EG>[QUOTE] EG>Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться EG>[/QUOTE]
EG>Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора. EG>Это принцип. Так устроено все! EG>Там где зеканчивается это: EG>[CODE] EG>void Test() EG>{ EG> TextWriter tw = new StreamWriter("test.txt",true); EG> tw.Write("123"); EG>}
Здесь говорится о том, что файл не закроется по выходе из видимости, т.к. GC не сработает.
Поэтому
Для пренудительного закрытия файла (но не уничтожения объекта) EG>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>Ради интереса стоит узнать что -такое PEB. EG>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
"Первое, что делает GC во время сборки мусора – это принимает решение о том, что все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они вам больше не нужны К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все. Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в этом. Легче заного этот граф построить в при достижении порога памяти.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, woto, Вы писали:
W>>Так в смысле как раз и нету возможности его скачать .
VD>Физической что ли?
В смысле, а какой еще не бывает?
В смысле нету канала.
... << RSDN@Home 1.1.4 beta 1 >>
Re[10]: И что дальше будет с .NET?
От:
Аноним
Дата:
12.07.04 17:13
Оценка:
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Здравствуйте, Serginio1, Вы писали:
EG>>[QUOTE] EG>>Думаю, исключение System.IO.IOException вам обеспечено по причине «The process cannot access the file "test.txt" because it is being used by another process.» (Процесс не может достучаться EG>>[/QUOTE]
EG>>Оно будет обеспечено _НЕ_ПО_ПРИЧИНЕ_ неправильной сборки мусора. EG>>Это принцип. Так устроено все! EG>>Там где зеканчивается это: EG>>[CODE] EG>>void Test() EG>>{ EG>> TextWriter tw = new StreamWriter("test.txt",true); EG>> tw.Write("123"); EG>>}
S> Здесь говорится о том, что файл не закроется по выходе из видимости, т.к. GC не сработает. S> Поэтому S>
S> Для пренудительного закрытия файла (но не уничтожения объекта)
В этом и ловушка, может для .NET файл и не объект вовсе, ноколь скоро файл существует он самый настоящий объект ядра управляемый ObjectManager -ом
и находящийся тут ://..//c:\*
И далее применяются все законы работы с объектами ОС. Вот вчем все дело
Мне кажется не стоит забывать о том что .NET всеголишь верхний слой пока,
а вот законы определяет то что ниже
Как только ты закрываешь файл ты уменьшаешь счетчик объекта файл на единицу,
если никто другой объек открытым а именно этот-же хендл файла не держит объект-файл будет уничтожнен.
Если ты файл не закрыл (явно) счетчик объектов не уменьшился , деструктор по умолчанию закрывать файл не станет, кто его знает где этот хендл еще использоваться будет?
EG>>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>>Ради интереса стоит узнать что -такое PEB. EG>>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
S> "Первое, что делает GC во время сборки мусора – это принимает решение о том, что S>все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они S>вам больше не нужны
Угу одна проблема есть разница между объекто -"файл" и блоком памяти
объект файл это какбы выразиться некая ссылка на объект.
Хендл это чтото похожее на расшаренную секцию , которая шарится для пользовательского режима менеджером объектов.
Не все так просто
К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все.
Неужели :ds,cs, и прочие селекторы тож сканирует??
Или он надеется что .NET приложение нулевое кольцо захватит?
Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
S> Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект
Иными словами он действительно содержит индексы и счетчики объектов:
Чтото похожее на.
struct Uncknown_Struct
{
DWORD CounterConnections;
OBJECT_TYPE Type;
OBJECT Obj;
PNODE Node;
PNEXT_BLOCK NextBlocks[CounterConnections];
}
Любая база данных представляет собой граф, а любой графф должен быть проиндексирован.
Для возможности нахождения кратчайшего пути к примеру методом рельефов.
>пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в >этом. Легче заного этот граф построить в при достижении порога памяти.
Ага ну конечно заново отстроить всю структуру памяти, а где в это время данные временно хранить?
S>> Для пренудительного закрытия файла (но не уничтожения объекта) А>В этом и ловушка, может для .NET файл и не объект вовсе, ноколь скоро файл существует он самый настоящий объект ядра управляемый ObjectManager -ом А>и находящийся тут ://..//c:\* А>И далее применяются все законы работы с объектами ОС. Вот вчем все дело А>Мне кажется не стоит забывать о том что .NET всеголишь верхний слой пока, А>а вот законы определяет то что ниже А>Как только ты закрываешь файл ты уменьшаешь счетчик объекта файл на единицу, А>если никто другой объек открытым а именно этот-же хендл файла не держит объект-файл будет уничтожнен. А>Если ты файл не закрыл (явно) счетчик объектов не уменьшился , деструктор по умолчанию закрывать файл не станет, кто его знает где этот хендл еще использоваться будет?
FileStream это объект, содержащий в себе унманагед дескриптор файла. Поэтому он реализует интерфейс IDisposable для закрытия файла при финализации. Почитай статью там это все указано. EG>>>А теперь о счетчиках, любой объект процесса считает память , хэндлы и т.д. EG>>>Ради интереса стоит узнать что -такое PEB. EG>>>ObjectManager в дальнейшем следит за объектом процесса и хэндлами. EG>>>Пока на хендл файла есть хоть одна ссылка _НИКТО_ небудет его уничтожать.
S>> "Первое, что делает GC во время сборки мусора – это принимает решение о том, что S>все выделенные блоки памяти в вашей программе — это как раз и есть мусор, и они S>вам больше не нужны А>Угу одна проблема есть разница между объекто -"файл" и блоком памяти А>объект файл это какбы выразиться некая ссылка на объект. А>Хендл это чтото похожее на расшаренную секцию , которая шарится для пользовательского режима менеджером объектов. А>Не все так просто
Все достаточно просто. Достаточно взглянуть на коеструктор и финализатор
Нативный хэндл содержиться в поле объекта. А>К счастью, на этом GC не прекращает свою работу. Далее начинается утомительный поиск «живых» указателей на объекты по всем закоулкам приложения. Microsoft называет эти указатели «roots». В процессе поиска GC сканирует глобальную память программы (на рисунках обозначено как Global), стек (Stack – локальные переменные) и даже регистры процессора (CPU). Как мы знаем, каждый поток в программе имеет свой собственный стек, и CLR приходится сканировать их все. А>Неужели :ds,cs, и прочие селекторы тож сканирует?? А>Или он надеется что .NET приложение нулевое кольцо захватит?
GC работает только с объектами. Работу с хэндлами ведут объекты реализующие IDisposable
А>Кроме того, интересен тот факт, что CLR умеет работать даже с потоками, которые создавались в неуправляемом коде с использованием функций WinAPI."
S>> Но когда объектов много начинается write barier. По сути такое впечатление, что GC держит впостроенный граф достижимых объектов, и при изменении сылок на объект А>Иными словами он действительно содержит индексы и счетчики объектов: А>Чтото похожее на. А>struct Uncknown_Struct А>{ А>DWORD CounterConnections; // не нужно т.к. смотрятся только он достижимые объекты. А>OBJECT_TYPE Type;// не нужен т.к. из объекта есть выход на Type А>OBJECT Obj; А>PNODE Node; А>PNEXT_BLOCK NextBlocks[CounterConnections]; А>} А>Любая база данных представляет собой граф, а любой графф должен быть проиндексирован. А>Для возможности нахождения кратчайшего пути к примеру методом рельефов.
>>пересчитывает этот граф. При этом память не выделяется и нет никакого смысла в >этом. Легче заного этот граф построить в при достижении порога памяти. А>Ага ну конечно заново отстроить всю структуру памяти, а где в это время данные временно хранить?
Дело в том, что сбор мусора нужен когда памяти не достаточно. Кроме того после выполнение каких либо действий живых объектов останется мало, и затраты по слежением за графом просто не нужны. При этом выполняется огромная ненужная работа.
Поэтому хранить ничего не нужно. А отстроить заного граф по доступным объектам.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
А>>struct Uncknown_Struct А>>{ А>>DWORD CounterConnections; // не нужно т.к. смотрятся только он достижимые объекты. А>>OBJECT_TYPE Type;// не нужен т.к. из объекта есть выход на Type А>>OBJECT Obj; А>>PNODE Node; А>>PNEXT_BLOCK NextBlocks[CounterConnections]; А>>}
Вернее не совсем так. Сначала строится граф доступных переменных и ссылки в объектах на которые ссылаются эти переменные, которые могут находится в статических полях, стеке, и регистрах. При сборке мусора (дефрагментации памяти) все ссыли корректируются.
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
if (FileStream._canUseAsync && useAsync) //Проверка асинхронный ли вызов?
//Есть ли нужда в WaitForSingleObject в дальныйшем?
{
this._handle = Win32Native.SafeCreateFile(text2, num1, share, security_attributes1, mode, 1073741824, Win32Native.NULL);
this._isAsync = true; // да это асинхронный вызов
}
else
{ this._handle = Win32Native.SafeCreateFile(text2, num1, share, security_attributes1, mode, 128, Win32Native.NULL);
this._isAsync = false; //нет вызов не асинхронный.
}
protected virtual void Dispose(bool disposing)
{ if (this._handle != null) //Хендл не зомби?
{
try
{
if (!this._handle.IsClosed) //Если хендл не закрыт
{
base.Flush(); //Выбросить буфферы на диск.
}
}
finally
{
this._handle.Close(); // Нихрена выбросить не получилось. Поэтому закрываем.
}
}
his._canRead = false; // Так как хэндла больше не существует,this._canWrite = false; // запрещаем всяческие обращения к нему .this._canSeek = false; // эти аттрибуты поидее сигнализируют о том что хэндла больше нет,this._buffer = null; // и его нужно как минимум создать заново.
}
Честно говоря непонял в чем проблема. Все по идее должно коректно отрабатывать.
Ну получается что после диспозанья, хендла больше нет,
тогда невижу причины по которой файл должен быть залочен.
Re[13]: И что дальше будет с .NET?
От:
Аноним
Дата:
13.07.04 09:38
Оценка:
Здравствуйте, Edvard Grieg, Вы писали:
Меня здесь забанили. Так что под анонимом. Большой разницы нет.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Честно говоря непонял в чем проблема. Все по идее должно коректно отрабатывать. EG>Ну получается что после диспозанья, хендла больше нет, EG>тогда невижу причины по которой файл должен быть залочен.
Если ты внимательно прочитаешь ту статью то в коде
void Test()
{
TextWriter tw = new StreamWriter("test.txt",true);
tw.Write("123");
}
После выхода из процедуры не будет вызван финализатор. При такой схеме финализатор буде т вызван только при сборе мусора и то не сразу, т.к.
объекты с финализатором отслеживаютс дополнительно и финализация происходит после сборки мусора
поэтому обычно принудительно вызывают
GC.Collect();
void WaitForPendingFinalizers();
WaitForPendingFinalizers
Останавливает текущий поток до завершения выполнения методов Finalize для всех объектов из F-reachable Queue (рис. 9).
Для того, чтобы вызвать финализатор из кода нужно вызвать Dispose метода IDisposable
void Test()
{
using (TextWriter tw = new StreamWriter("test.txt",true))
{
tw.Write("123");
}
}
Это уже гораздо лучше. Конструкция using генерирует код, аналогичный нашему примеру с try/finally, за тем исключением, что вместо метода Close она вызывает Dispose. Вполне логично предположить, что объект должен иметь в своём составе такой метод. Так и есть, мы можем использовать с этой конструкцией только те объекты, которые реализуют интерфейс IDisposable, содержащий в своём составе один единственный метод:
void Dispose();
Интерфейс IDisposable призван формализовать освобождение ресурсов в CLR. Он реализуется многими классами .NET Framework, в том числе и для уведомления клиентов об уничтожении объекта (Component, Container, Control).
Соответственно, если вы создаёте класс, использующий какие-либо ресурсы, вы также должны реализовать этот интерфейс и метод Dispose в соответствии со следующими требованиями (эти правила никак не обозначены в MSDN и взяты мной из комментариев к исходным текстам CLI):
Метод Dispose должен иметь возможность быть безопасно вызванным несколько раз.
Освобождать любые ресурсы, ассоциированные с экземпляром объекта.
Вызывать метод Dispose базового класса при необходимости.
Подавлять вызов метода Finalize путём удаления ссылки на объект из Finalization Queue.
Не должен генерировать исключения, кроме очень серьёзных случаев наподобие OutOfMemoryException. В идеале с вашим объектом не должно происходить ничего особенного в процессе вызова Dispose.
Давайте напишем класс, который бы соответствовал данным требованиям, и который можно было бы использовать в дальнейшем как базовый.
Спасибо большое за объяснения
Мне кажется класс мог бы выглядеть похожим на это:
template <class InputClass> class FileWorker
{
typedef struct _ERROR_COMMENT
{
bool IC_NOT_CREATED;
bool IC_ERROR_WRITE;
bool IC_ERROR_READ;
bool IC_ERROR_FLUSH;
bool IC_ERROR_CLOSE;
}ERROR_COMMENT,*PERROR_COMMENT;
InputClass *IC;
PERROR_COMMENT EC;
FileWorker(char *FileName)
{
ZeroMemory(EC,sizeof(ERROR_COMMENT));
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC = new StreamWriter(FileName,true);
}
finally
{
IC_NOT_CREATED = TRUE;
}
}
};
Write (char *InputBuffer)
{
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC->Write(InputBuffer);
}
finally
{
IC_ERROR_WRITE = TRUE;
}
}
}
char *Read ()
{
char OutputBuffer[MAX_LENGTH];
if (typeid(InputClass)==typeid(TextWriter))
{
try
{
IC->Read(OutputBuffer);
}
finally
{
IC_ERROR_READ = TRUE;
}
}
}
и т.д. потом должен быть такойже член класса для seek, для close, и т.д.
и блок статистики ошибок.
Блок статистики ошибок нужен бля того чтобы время от времени в зависимости от количества ошибок мажоритарная система контроля моглабы удалять класс и создавать заново.Или есть более удобные способы?:-)
И вообще чтото такое возможно на шарпе ? Если да то как:-)
я был бы очень благодарен за какой-нибудь такой примерчик:-)
}
Re[15]: И что дальше будет с .NET?
От:
Аноним
Дата:
13.07.04 11:36
Оценка:
Здравствуйте, Edvard Grieg, Вы писали:
EG> и т.д. потом должен быть такойже член класса для seek, для close, и т.д. EG> и блок статистики ошибок. EG> Блок статистики ошибок нужен бля того чтобы время от времени в зависимости от количества ошибок мажоритарная система контроля моглабы удалять класс и создавать заново.Или есть более удобные способы? EG>И вообще чтото такое возможно на шарпе ? Если да то как EG>я был бы очень благодарен за какой-нибудь такой примерчик
Ты можешь создать класс оболочку над FileStream наследника от Stream и реализовать все его абстрактные методы через экземпляр класса FileStream который будет полем этого класса или свой класс.
И соответствнно в нем ты можешь реализовать все что писал. При этом с экземпляр класса FileStream ты можешь делать что угодно. Обычнвя практика.
А> Ты можешь создать класс оболочку над FileStream наследника от Stream и реализовать все его абстрактные методы через экземпляр класса FileStream который будет полем этого класса или свой класс. А> И соответствнно в нем ты можешь реализовать все что писал. При этом с экземпляр класса FileStream ты можешь делать что угодно. Обычнвя практика.
Сегодня после работы попробую
Кстати тут статья про дженерики какаянибудь русскоязычная не пробегала нигде?
Мой продукт (.NET) несмотря на минимальные требования, успешно используют на P-133 64Mb. И ничего, радуются жизни (только вот грузится долго, прихошлось приписать к обновлялке опциональнцю функцию обработки сборок ngen`ом, стало лучше). Так что не все так плохо. 
.
