Здравствуйте, gandjustas, Вы писали:
__>>Здравствуйте, gandjustas, Вы писали:
G>>>Тогда приведи минимальный код, который падает по этой причине. На .NET.
__>>да просто открытие файлов в цикле должно падать
G>Проверь
G>

G>static void Main(string[] args)
G>{
G>    for (int i = 0; i < 1000000; i++)
G>    {
G>        new FileStream("test.txt", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite);
G>    }
G>}
G>

G>Не падает
ну, в общем-то интересная задачка наверное. я бы чтобы добиться падения попробовал бы рандомное имя файла давать и еще что-нить читать оттуда, чтобы гарантировать открытие. а то вдруг оно там ленивое? или в оптимизаторе дотнетовском стоит каколй-нить if — типа в цикле если файлы открываем, но не читаем, то не открывать их

__>>если хотите просимулировать то, о чем я говорю — вставьте в начала частоиспользуемых ф-ий вашего приложение по открытию файла и оно у вас начнет непрдесказуемым способом падать в разных местах по out of resources
G>Не будет.
я сам сталкивался недавно с этим. создаешь просто пару сотен потоков и начинаешь в них что-то делать. у тебя то там, то там out of resources

G>Ты только что расписался, что не знаешь как работает GC и .NET вообще.
а он что, может отловить когда handle закончились? он смотрит на оставшуюся память. откуда он знает, что у нас еще и лимит по хэндлам или там, потокам?
раньше был лимит по файловым хэндлам вроде около 5000, сейчас по-моему его тысяч до 100 увеличили как раз по причине что падает вся Явовское-дотнетовское. ну да, решение в духе этих языков. есть же другие лимиты — на потоки, на графические примитивы, на, там, кто его знает что еще. не только в обьеме памяти дело.

__>>понимаете, что вы просто вручную уничтожаете обьект? не бывает никаких init и dispose. бывает создание и уничтожение обьекта. а то, что оно разбито на два этапа это извращения, на которые приходится идти ради совместимости с другими нерабочими великими идеями. в этом плане вызов Dispose в C# или delete в С++ ничем не отличается. разве что в первом случае вы получаете говнообьект, а в С++ вы д-но его диспозите
G>Это ты пытаешься на любом языке писать как на C++.
G>А в реальности не бывает никаких объектов, бывает вызов метода closehandle, который "закрывает" файл. То есть дает доступ другим приложениями в случае эксклюзивного доступа, а также сбрасывает буфер на диск. Если того и другого не треубется в данный момент, то в .NET можно dispose не звать.
что значит не требуется в данных момент? у вас будет расти и расти занятость системы, а вы будете бороться с этим увеличением лимитов вместо того, чтобы искать где там что не дисплозится и переписывать код на using. одна малюсенькакая дотнетовская какашечка чисто теоретически может зажрать сколько угодно памяти и сколько угодно ресурсов. поэтому и приходится писать using

G>Это в C++ важна работа с объектами, ибо она эквивалентна работе с памятью. А в других (нормальных) яызках ты не с объектами работаешь, а с результатом, который нужно получить. Если нужно чтобы после выполнения функции данные гарантированно записались в файл, то ты вызываешь dispose.
G>dispose и delete кстати отличается очень сильно. Но я уж понял, что все что ты пишешь основано на незнании .NET. Ранее ты умудрился using приравнять к auto_ptr
ха-ха-ха как смищьно

G>Чувак, нет никакого destruction в .NET, он только в C++ есть и еще в паре говноязыков, есть только side-эффект, который тебе нужно получить "сейчас", для таких сайд-эффектов часто используется idisposable.
G>Причем если ты привязывает сайд-эффект к деструктору (RAII), то появляется другая проблема, ты не можешь объект передать куда-либо, ибо вызовется конструктор копии, для которого вызовется деструктор, который вызовет эффект раньше времени. Можно, конечно, передать голый указатель , но тогда проблема со временем жизни появляется, можно передать защищенный указатель (ссылку)?
перефразируя поговорку микрософтовскую "ты просто слишком долго пишешь на .NET". обьект создается и уничтожается. всё. больше с ним ничего не может происходить. наличие промежуточных шагов — лисапеды и бесконечное болото для ошибок.

__>>мы хотим контролировать время его жизни. но средствами языка это делать нельзя и мы добавляем велосипед — договариваемся, что код деструктора помещаем в Dispose и вручную будем вызывать его.
G>Мы не хотим время жизни объектов контролировать, это желание C++ника. Мы хотим получить сайд-эффект в точно определенное время. Для этого даже dispose не нужен, просто вызвать метод close или типа того. Но этот метод можно забыть вызвать, а dispose имеет много средств, чтобы избежать таких ситуаций — using, подсказки среды\FxCop.
у нас дело может до close не дойти из-за возникшего по дороге исключения. именно поэтому я и писал про auto_ptr капк гарантия уничтожения обьектов на куче при любом выходе из области видимости, если до тебя еще не дошло

G>Ты наверное все еще не понял, что в 99% случаев если не вызвать dispose, то ничего страшного не случится. Поэтому глупо приравнивать dispose к разрушению объекта. Но я уж понял, что все что ты пишешь основано на незнании .NET
конечно это не разрушение. это лисапед — полуразрушение

G>Чувак, я знаю C++ (и судя по твоему комменту ниже — знаю лучше тебя), это ты не знаешь .NET
а смысл знать .NET ?
он не годится для серверной стороны, так там там линукс везде
он не годится для гуя — так как он сейчас весь вебовский и нужно копать что-то в сторону типизованного жабоскрипта
он не годится для каких-то вычислений из-за корявой модели памяти.

он был просто создан как замена С++ для внутренних проектов Микрософта. Никто другой в здавом уме его использовать не будет С++ый проект внутри MS контролировать невозможно в принципе никаким образом. C# ый — да, он тормозит и еле работает, ну по крайней мере он не так часто падает. Всё остальное уже вторично

__>>а теперь, внимание, обьяснение по поводу auto_ptr — если нас не устраивает стек, хотим на куче, то
__>>void f()
__>>{
__>> x = 10
__>> { <- это типа начало scope using
__>> auto_ptr<ifstream> f = make_unique_ptr() // я уже не помню, тут его как-то инициализируем, открываем
__>> } <- вот тут вот он уничтожится

__>> x = 20
__>>}
G>
G>Убило.
G>Во-первых просто не скомпилируется.
ну ясен пень

G>Во-вторых ты походу не знаешь разницу между auto_ptr и unique_ptr.
G>В-третьих попробуй передать куда-либо auto_ptr.
auto_ptr был создан как раз с целью using — гарантированное уничтожение обьекта при выходе из scope при возникновении исключения. он был создан миллион лет назад и давно уже obsolete.

__>>вот это повредение и пытается симулировать C# со своим Dispose
G>Пойди учебник почитай, не пиши глупостей.
учебник по C#? да я лучше на шиномонтаж работать пойду, чем снова на C# писать