Здравствуйте, __kot2, Вы писали:
__>>>да просто открытие файлов в цикле должно падать 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 — типа в цикле если файлы открываем, но не читаем, то не открывать их
Ага, магия прям.
Но ты не стесняйся, глянь исходники http://referencesource.microsoft.com/mscorlib/system/io/filestream.cs.html
Никакой магии, честно зовется Win32Native.SafeCreateFile, который по сути CreateFile из WinAPI
Естественно оптимизатор ничего не знает о то, что такое FileStream, да и запускал под дебагом.
__>>>если хотите просимулировать то, о чем я говорю — вставьте в начала частоиспользуемых ф-ий вашего приложение по открытию файла и оно у вас начнет непрдесказуемым способом падать в разных местах по out of resources G>>Не будет. __>я сам сталкивался недавно с этим. создаешь просто пару сотен потоков и начинаешь в них что-то делать. у тебя то там, то там out of resources
Да ладно?
static void Main(string[] args)
{
for (int i = 0; i < 300; i++)
{
new Thread(() =>
{
for (int j = 0; j < 1000000; j++)
{
new FileStream("test.txt", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite);
}
}).Start();
}
}
Не падает.
Готов спорить что ты сталкивался с тем, что у тебя кривые руки и ты не знаешь .NET.
G>>Ты только что расписался, что не знаешь как работает GC и .NET вообще. __>а он что, может отловить когда handle закончились? он смотрит на оставшуюся память. откуда он знает, что у нас еще и лимит по хэндлам или там, потокам?
А зачем ему это знать? Сборшик мусора срабатывает на 256к памяти, старые хендлы в этот момент закроются. Лимит в винде около миллиона, посчитаешь сам почему ГЦ не должен знать сколько там лимит?
__>раньше был лимит по файловым хэндлам вроде около 5000 сейчас по-моему его тысяч до 100 увеличили как раз по причине что падает вся Явовское-дотнетовское. ну да, решение в духе этих языков. есть же другие лимиты — на потоки, на графические примитивы, на, там, кто его знает что еще. не только в обьеме памяти дело.
16 тысяч был еще до w95, и то только потому что внтури хранилось в духбайтном слове, а хендл был кратным 4. Начиная с W2000 стало двойное слово и убрали кратность 4, стало 2М хнедлов. Так практически везде — потоки, сокеты итп. В последних версиях МСДН даже убрали эти значения, ибо практически их достичь невозможно, память раньше кончится. (если не в курсе, то за каждым хендлом стоит структура в ядре, которая занимает сильно больше 4 байт).
Но это не имеет никакого значения, так как .NET не допускает утечек и надо что-то специально делать, чтобы лимитов достичь.
Это в C++ является проблемой, а в .NET — нет.
__>>>понимаете, что вы просто вручную уничтожаете обьект? не бывает никаких init и dispose. бывает создание и уничтожение обьекта. а то, что оно разбито на два этапа это извращения, на которые приходится идти ради совместимости с другими нерабочими великими идеями. в этом плане вызов Dispose в C# или delete в С++ ничем не отличается. разве что в первом случае вы получаете говнообьект, а в С++ вы д-но его диспозите G>>Это ты пытаешься на любом языке писать как на C++. G>>А в реальности не бывает никаких объектов, бывает вызов метода closehandle, который "закрывает" файл. То есть дает доступ другим приложениями в случае эксклюзивного доступа, а также сбрасывает буфер на диск. Если того и другого не треубется в данный момент, то в .NET можно dispose не звать. __>что значит не требуется в данных момент? у вас будет расти и расти занятость системы, а вы будете бороться с этим увеличением лимитов вместо того, чтобы искать где там что не дисплозится и переписывать код на using.
С чего это "занятость системы" будет расти? Если нет ссылок на объект, то за один проход GC он удалится, и ничего расти не будет. Сборка мусора в поколении 0 выполняется порядка 100 раз в секунду, так что ты даже не увидишь чтобы что-то росло. Ты походу вообще не понимаешь как работает ОС и .NET.
__>одна малюсенькакая дотнетовская какашечка чисто теоретически может зажрать сколько угодно памяти и сколько угодно ресурсов. поэтому и приходится писать using
Ну ты уже расписался в непонимании, можешь не продолжать. Я тебе пример кода без using привел, запусти и посмотри как он расходует ресурсы.
Ты до сих пор не понимаешь, что даже если не писать using никаких утечек не будет.
G>>Это в C++ важна работа с объектами, ибо она эквивалентна работе с памятью. А в других (нормальных) яызках ты не с объектами работаешь, а с результатом, который нужно получить. Если нужно чтобы после выполнения функции данные гарантированно записались в файл, то ты вызываешь dispose. G>>dispose и delete кстати отличается очень сильно. Но я уж понял, что все что ты пишешь основано на незнании .NET. Ранее ты умудрился using приравнять к auto_ptr __>ха-ха-ха как смищьно
Тебе смешно, что ты не знаешь что такое auto_ptr и using?
__>перефразируя поговорку микрософтовскую "ты просто слишком долго пишешь на .NET". обьект создается и уничтожается. всё. больше с ним ничего не может происходить. наличие промежуточных шагов — лисапеды и бесконечное болото для ошибок.
Какой объект? CloseHandle надо вызвать. Это в C++ модно (потому что более безопасно чем любой другой подход) всеподряд привязывать к уничтожению объекта. Но это не значит, что в любом языке так стоит делать. Ты же ничего кроме C++ не знаешь (да и его плохо судя по всему), поэтому и пишешь фигню. Бросай, лучше учебники читай.
__>у нас дело может до close не дойти из-за возникшего по дороге исключения.
Ну да, не придумали try\finally конструкцию в C++, поэтому все в деструкторах. В других языка есть другие средства (к счастью).
__>именно поэтому я и писал про auto_ptr капк гарантия уничтожения обьектов на куче при любом выходе из области видимости, если до тебя еще не дошло
Да и до сих пор не дошло что ты хочешь сказать...
Что using дает гарантию уничтожения объекта при выходе из области? Так не дает, можно за пределами using обратиться к объекту, IDisposable это не уничтожение объекта.
Ты какую то фигню сморозил, тем более ты не знаешь как работает auto_ptr, я же говорю попробуй его в метод передать.
G>>Ты наверное все еще не понял, что в 99% случаев если не вызвать dispose, то ничего страшного не случится. Поэтому глупо приравнивать dispose к разрушению объекта. Но я уж понял, что все что ты пишешь основано на незнании .NET __>конечно это не разрушение. это лисапед — полуразрушение
Что значит "полуразрушение" ? Ты о чем вообще? Лисапед для чего?
G>>Чувак, я знаю C++ (и судя по твоему комменту ниже — знаю лучше тебя), это ты не знаешь .NET __>а смысл знать .NET ?
Чтобы моз работал, а не раскисал.
Кстати а зачем тебе знать C++?
__>он не годится для серверной стороны, так там там линукс везде
Странно, более 10 лет пишу исключительно серверные приложения на .NET. Так что "везде" это только в твоем воображаемом мире. Вот например этот форум вовсе не на линуксе.
Там где не .NET, там Java, а C++ днем с огнем не сыщешь.
__>он не годится для гуя — так как он сейчас весь вебовский и нужно копать что-то в сторону типизованного жабоскрипта
То есть C++ тоже не годится.
__>он не годится для каких-то вычислений из-за корявой модели памяти.
Как связаны модель памяти и вычисления? Массив в .NET отличается от массива в C? Или ты о чем? Опять какой-то воображаемый мир у тебя.
Да и зачем тут С++, когда все вычисления пишутся на голом C?
__>он был просто создан как замена С++ для внутренних проектов Микрософта.
Опять воображаемый мир? Историю почитай чтоли. .NET создали когда Sun не допустил лицензирование виртуальной машины Java с расширениями MS.
__>Никто другой в здавом уме его использовать не будет
Чувак, ты пишешь на форуме, который на .NET, ты считаешь его создателей ненормальными?
__>С++ый проект внутри MS контролировать невозможно в принципе никаким образом.
Странно, как же Office Team уже 20 лет офис делает?
__>C# ый — да, он тормозит и еле работает, ну по крайней мере он не так часто падает. Всё остальное уже вторично
Вот тебе и ответ, изучай .NET — научишься делать программы, которые не падают.
G>>Во-первых просто не скомпилируется. __>ну ясен пень
А зачем постить такой код, в котором ты даже сам не разбираешься?
G>>Во-вторых ты походу не знаешь разницу между auto_ptr и unique_ptr. G>>В-третьих попробуй передать куда-либо auto_ptr. __>auto_ptr был создан как раз с целью using — гарантированное уничтожение обьекта при выходе из scope при возникновении исключения. он был создан миллион лет назад и давно уже obsolete.
Ты упоротый чтоли? Цель using — не "гарантированное уничтожение", а только лишь гарантированный вызов dispose. Dispose может делать что угодно, даже не связанное с уничтожением.
Кстати для справки — IDisposable в .NET может реализовывать даже структура для которой нет никакого "уничтожения".
Читай учебник и не пиши глупости.
__>>>вот это повредение и пытается симулировать C# со своим Dispose G>>Пойди учебник почитай, не пиши глупостей. __>учебник по C#? да я лучше на шиномонтаж работать пойду, чем снова на C# писать
Ну судя по твоим знаниям — на шиномонтаже тебе самое место
Re[11]: Garbage collection vs manual memory management
Здравствуйте, AlexRK, Вы писали: __>>а смысл знать .NET ? __>>он не годится для серверной стороны, так там там линукс везде __>>он не годится для гуя — так как он сейчас весь вебовский и нужно копать что-то в сторону типизованного жабоскрипта __>>он не годится для каких-то вычислений из-за корявой модели памяти. ARK>Есть и другие места применения, помимо перечисленных. Я, помимо прочего, участвую в разработке ГИС на C#.
отличная идея. и как это собираются портировать на iphone/ipad/web? — самые быстрорастущие и денежные рынки? хотя, наверное это советский продукт, раз mac os в пролете? но даже совесткие смартфоны андроидовские
__>>он был просто создан как замена С++ для внутренних проектов Микрософта. Никто другой в здавом уме его использовать не будет С++ый проект внутри MS контролировать невозможно в принципе никаким образом. C# ый — да, он тормозит и еле работает, ну по крайней мере он не так часто падает. Всё остальное уже вторично ARK>Тупой бред.
я там работал
Re[12]: Garbage collection vs manual memory management
Здравствуйте, __kot2, Вы писали:
ARK>>Есть и другие места применения, помимо перечисленных. Я, помимо прочего, участвую в разработке ГИС на C#. __>отличная идея. и как это собираются портировать на iphone/ipad/web? — самые быстрорастущие и денежные рынки? хотя, наверное это советский продукт, раз mac os в пролете? но даже совесткие смартфоны андроидовские
Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core?
Re[13]: Garbage collection vs manual memory management
Здравствуйте, gandjustas, Вы писали: G>Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core?
это как в Советском Союзе? Сначала создать проблему, а потом героически ее преодолевать?
Re[14]: Garbage collection vs manual memory management
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, gandjustas, Вы писали: G>>Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core? __>это как в Советском Союзе? Сначала создать проблему, а потом героически ее преодолевать?
Ты не в курсе, что .net был создан сильно до того, как появились все эти платформы?
Re[15]: Garbage collection vs manual memory management
Здравствуйте, gandjustas, Вы писали: G>Здравствуйте, __kot2, Вы писали: __>>Здравствуйте, gandjustas, Вы писали: G>>>Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core? __>>это как в Советском Союзе? Сначала создать проблему, а потом героически ее преодолевать? G>Ты не в курсе, что .net был создан сильно до того, как появились все эти платформы?
а С++ когда был создан?
есть очень простой критерий удачности решений/технологий
хорошие решения имеют приятные неожиданные побочные эффекты
плохие решения имеют неприятные неожиданные побочные эффекты
это самый лучший в мире и 100% рабочий критерий грамотности какой-то разработки — попробовать применить ее в области для которой она не создавалась.
Re[16]: Garbage collection vs manual memory management
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, gandjustas, Вы писали: G>>Здравствуйте, __kot2, Вы писали: __>>>Здравствуйте, gandjustas, Вы писали: G>>>>Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core? __>>>это как в Советском Союзе? Сначала создать проблему, а потом героически ее преодолевать? G>>Ты не в курсе, что .net был создан сильно до того, как появились все эти платформы? __>а С++ когда был создан?
В 2011 году, все предыдущие версии безнадежно больны и практически неизлечимы (неприятные побочные эффекты, ага).
Но и это не играет никакой роли, ибо никакого универсального фреймворка, работающего более чем на одной платформе в принципе нет для C++.
Про Qt даже не вспоминай, выглядит как говно, в приличном обществе сразу по лицу за такое бьют.
В итоге вместо универсальности ты получишь N разных codebase для N разных платформ. Желаю удачи в поддержке.
Re[17]: Garbage collection vs manual memory management
Здравствуйте, gandjustas, Вы писали: G>>>>>Ты совсем от жизни отстал? Про Xamarin и Unity вообще не слышал? А про .NET Core? __>>>>это как в Советском Союзе? Сначала создать проблему, а потом героически ее преодолевать? G>>>Ты не в курсе, что .net был создан сильно до того, как появились все эти платформы? __>>а С++ когда был создан? G>В 2011 году, все предыдущие версии безнадежно больны и практически неизлечимы (неприятные побочные эффекты, ага).
я вообще понять не могу о чем разговор даже. С++ всегда был рабочим и всегда подходил для разработки. С++ 11 это обычные мелкие доработочки, чтобы каждые свой велосипед не городили посредствами языка, стандартные решения были стандартизованы.
G>Но и это не играет никакой роли, ибо никакого универсального фреймворка, работающего более чем на одной платформе в принципе нет для C++. G>Про Qt даже не вспоминай, выглядит как говно, в приличном обществе сразу по лицу за такое бьют.
Qt лучший фреймворк среди всех существующих.
G>В итоге вместо универсальности ты получишь N разных codebase для N разных платформ. Желаю удачи в поддержке.
я портировал С++ десктопные приложения на iphone. Раз плюнусть.
ты реально какой-то наркоман. засим прекращаю нашу тут дискуссию. не вижу смысла вообще ее вести
Re[18]: Garbage collection vs manual memory management
Здравствуйте, johny5, Вы писали:
J>Общались с Джавистом пересевшим на С++. Мол висящие указатели, явная чистка памяти, и т.д. Всё это плохо и известно. Он предлагает универсальное решение — shared_ptr на всё. Я задал контрольный вопрос: есть кнопка, к ней привязан звук из менеджера звуков. Мы решили перегрузить менеджер звуков. Нам для этого старый нужно удалить а в новом все звуки загрузить заново. И что я слышу от него, оказывается это нормально в данном случае что кнопка на UI не даст старому звуковому менеджеру умереть!! А если там нужно драйвер переиниализировать, старый обязательно должен выгрузить своё.
Стандартный паттерн для таких сценариев — это приведение отношения использования из oo:1 к 1:1 и нам достаточно будет затем сделать подмену указателя только в одном месте. Делается опять же стандартно через ровно +1 к уровню косвенности...
J>Я до сих пор в шоке. Это ужос для С++ профессионала, вдруг оказаться в языке где ты не можешь контролировать жизнь объектов вокруг тебя. J>Я сам С++ник и безуспешно пытался пересесть на С#. Я поимел реальных проблем с тем что я впринципе не имею никакого контроля над временем жизни объектов мной созданных.
Disposable паттерн тебе в помощь. Прекрасно точно так же все работает. Для особо клинических случаев, например, когда мы "что-то отдаем наружу", и "там" ожидается клиническое поведение, есть даже GCHandle, создаваемый как weak. Либо опять же предыдущий способ.
J>К примеру загрузил я файл в модель, отобразил модель на форму и всё, хочу удалить и загрузить новую модель, но я не могу потому что в языке просто нет таких средств. Всё что тут можно сделать это подчистить везде везде везде ссылки на эту форму, на модель и скрестить пальцы что скоро всё само удалится. И всё равно не срабатывает в 50% случаях.
Если нет статических ссылок и прочего лишнего кеширования, то в 99.99% случаев и пальцы скрещивать не надо. А если есть, то опять же способ борьбы уже был дан.
Re[9]: Garbage collection vs manual memory management
Здравствуйте, gandjustas, Вы писали:
G>Причем если ты привязывает сайд-эффект к деструктору (RAII), то появляется другая проблема, ты не можешь объект передать куда-либо, ибо вызовется конструктор копии, для которого вызовется деструктор, который вызовет эффект раньше времени. Можно, конечно, передать голый указатель , но тогда проблема со временем жизни появляется, можно передать защищенный указатель (ссылку)?
Эта рассуждение устарело после выхода C++11. Move-only типы решают вопрос передачи владения. В стандартной библиотеке пример move-only типа std::unique_ptr. Обёртка над файлом отличный кандидат на move-only:
File create_file(const string& path);
Re[10]: Garbage collection vs manual memory management
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Причем если ты привязывает сайд-эффект к деструктору (RAII), то появляется другая проблема, ты не можешь объект передать куда-либо, ибо вызовется конструктор копии, для которого вызовется деструктор, который вызовет эффект раньше времени. Можно, конечно, передать голый указатель , но тогда проблема со временем жизни появляется, можно передать защищенный указатель (ссылку)?
К>Эта рассуждение устарело после выхода C++11. Move-only типы решают вопрос передачи владения.
Это тоже костыль для небезопасных указателй и автоматических деструкторов.
Re[18]: Garbage collection vs manual memory management
Здравствуйте, __kot2, Вы писали:
__>С++ 11 это обычные мелкие доработочки, чтобы каждые свой велосипед не городили посредствами языка, стандартные решения были стандартизованы.
-1
Ни фига себе мелкие доработки:
— move семантика
— возможность по-человечески использовать алгоритмы STL (лямбды)
— нормальный способ итерироваться по коллекциям без ужасов типа BOOST_FOREACH
— std::unique_ptr (нормальных аналогов до выхода C++11 не было)
— избавление от необходимости писать километровые имена типов (auto)
+ по мелочи variadic templates, constexpr, upgrade STL ...
Скажу больше,
— если человек когда-то писал на C++, но не делает это сейчас
— если человек пишет на C++, но не интересуется, не изучал С++11
то он не знает современный C++
Re[11]: Garbage collection vs manual memory management
Здравствуйте, gandjustas, Вы писали:
К>>Эта рассуждение устарело после выхода C++11. Move-only типы решают вопрос передачи владения.
G>Это тоже костыль для небезопасных указателй и автоматических деструкторов.
Почему костыль? Вполне себе идиома объекта с единственным владельцем.
Аналогия: сорвал яблоко, отдал другому. Для этого не нужно считать число владельцев и создавать/убивать клоны яблок.
Re[12]: Garbage collection vs manual memory management
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
К>>>Эта рассуждение устарело после выхода C++11. Move-only типы решают вопрос передачи владения.
G>>Это тоже костыль для небезопасных указателй и автоматических деструкторов.
К>Почему костыль? Вполне себе идиома объекта с единственным владельцем.
А зачем оно нужно? Единственность владельца важна в двух случаях — автоматическое удаление объекта, передача между потоками. Второе в С++ не реализовано, а первое является костылем для атоматических деструкторов, которые в свою очередь костыли для небезопасных указателей.
Re[19]: Garbage collection vs manual memory management
Здравствуйте, Константин, Вы писали: К>Ни фига себе мелкие доработки: К>- move семантика
оптимизация — чтобы вместо по референсу по значению передавать. ну да, удобно, но ничего фундаментально нового
К>- возможность по-человечески использовать алгоритмы STL (лямбды)
не понял. шаблоны и раньше допускали ф-ии произвольные вставлять. синтаксис более удобный стал. может быть читаемость чуток повысилось. я вот без лямбд живу и ниче.
инлайнить функцию или отдельно ее выносить это неоднозначный вопрос.
К>- нормальный способ итерироваться по коллекциям без ужасов типа BOOST_FOREACH
я и говорю, мелкие доработки вместо своих велосипедов.
К>- std::unique_ptr (нормальных аналогов до выхода C++11 не было)
auto_ptr то же самое кроме move semantics. или я в чем-то неправ? смартпойнтеры были хорошо разжеваны еще Александреску и я использовал его локивские еще году в 2006ом. стандартизовали — молодцы. сделаи чтото новое? да нет кгнечно
К>- избавление от необходимости писать километровые имена типов (auto)
да, согласен. единсвтенная сильная доработка. впрочем, ничего фундаментально не меняющая. просто typedef писать не нужно. я лично auto ипользую в основном только для итераторов.
К>+ по мелочи variadic templates, constexpr, upgrade STL ...
ну да, мелкая хрень всякая
К>Скажу больше, К>- если человек когда-то писал на C++, но не делает это сейчас К>- если человек пишет на C++, но не интересуется, не изучал С++11 К>то он не знает современный C++
конечно, не знает. современный С++ такой сложный, что его никто не знает
Здравствуйте, gandjustas, Вы писали:
К>>Почему костыль? Вполне себе идиома объекта с единственным владельцем. G>А зачем оно нужно? Единственность владельца важна в двух случаях — автоматическое удаление объекта, передача между потоками. Второе в С++ не реализовано, а первое является костылем для атоматических деструкторов, которые в свою очередь костыли для небезопасных указателей.
IMHO, единственность владельца облегчает понимание кода. Владение и side эффекты связанные с этим локализованы.
<offtopic>
С точки зрения .NET некоторые идиомы C++ могут казаться костылями. Обратное тоже верно. Не вижу смысла особо флеймить по этому поводу.
</offtopic>
Re[14]: Garbage collection vs manual memory management
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
К>>>Почему костыль? Вполне себе идиома объекта с единственным владельцем. G>>А зачем оно нужно? Единственность владельца важна в двух случаях — автоматическое удаление объекта, передача между потоками. Второе в С++ не реализовано, а первое является костылем для атоматических деструкторов, которые в свою очередь костыли для небезопасных указателей.
К>IMHO, единственность владельца облегчает понимание кода.
Это облегчает понимание C++ кода, мбо в нем владелец отвечает за овобождение памяти. В языках с GC владение нужно нечасто, только в запутанных графах объектов.
К>Владение и side эффекты связанные с этим локализованы.
Владение в C++ это вовсе не гарантия, можно из unique_ptr получить голый указатель и предать куда угодно.
Фактически единственная суть "владения" в C++ — ответственность за уничтожение.
К><offtopic> К>С точки зрения .NET некоторые идиомы C++ могут казаться костылями. Обратное тоже верно. Не вижу смысла особо флеймить по этому поводу. К></offtopic>
Если кажется костылями, то это и есть костыли. Но нужно отдать должное новым версиям C++, там ручное выписывание copy и move ctor почти не нужно если пользуешься правильными средствами. Все костыли надежно спрятаны внутри stl.
В ранних версиях конечно все костыли торчали наружу, что изрядно доставляло.
Re[2]: Garbage collection vs manual memory management
Здравствуйте, vdimas, Вы писали:
V>Стандартный паттерн для таких сценариев — это приведение отношения использования из oo:1 к 1:1 и нам достаточно будет затем сделать подмену указателя только в одном месте. Делается опять же стандартно через ровно +1 к уровню косвенности...
