Garbage collection vs manual memory management - Философия программирования

Здравствуйте, chaotic-good, Вы писали:

G>>На практике это не так.
G>>Основные тормоза создаются при генерации мусора. Меньше мусора == реже сборки == выше производительность даже при более дорогих сборках мусора.

CG>И при этом лучше, когда мусор короткоживущий. Ну и не только мусор, нужно в целом о структурах данных думать с позиции GC (в том числе), стараться делать из более gc-friendly, чтобы создавать меньше работы для сборщика мусора, pointer chasing в стиле С/С++ тут до добра не доведет.
Меньше мусора лучше чем короткоживущий мусор.

G>>Пулы объектов в языках с GC работают прекрасно.

CG>У меня был случай, когда я на практике наблюдал обратное — после выпиливания пулла и замены его на обычный new, все стало работать быстрее и приложение стало проводить меньше времени за сборкой мусора. В принципе, это становится очевидно и если просто почитать про устройство gc в .net, в msdn есть очень хорошая статья на эту тему, ты должно быть ее читал. Пулл объектов может работать хорошо, если ссылки внутри этих объектов не меняются, только данные, соответственно не дергается сборка в gen 2, но в общем случае, пуллы рекомендовать нельзя, особенно для короткоживущих объектов.

Любой код можно написать плохо. Можно считать это аксиомой. Но даже тысячи плохо написанных пулов объектов не делают пулинг с gc неэффективным.
Если посмотреть внтуренности .NET и Roslyn, то можно заметить, что очень часто используется thread-local пул объектов StringBuilder, который очень даже изменяемый. На Channel9 даже есть запись с teched где объясняют почему так.

Но тут есть особенность. По умолчанию хорошо работает пул размером 1. Я проводил замеры с пулами больших размеров — они зачастую приводят к падению производительности.

Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.

Здравствуйте, Nuseraro, Вы писали:

N>Невозможность контролировать результирующий машинный код — неприемлемо для меня, поэтому пишу только на кошерном асме.

На асме тоже не все всегда контролируешь. По-моему, tasm не давал написать что-то типа xchg dx, ax, сразу заменяя на xchg ax, dx, потому что второй вариант на байт короче. А мне обязательно нужен был первый вариант.

G>Любой код можно написать плохо. Можно считать это аксиомой. Но даже тысячи плохо написанных пулов объектов не делают пулинг с gc неэффективным.
G>Если посмотреть внтуренности .NET и Roslyn, то можно заметить, что очень часто используется thread-local пул объектов StringBuilder, который очень даже изменяемый. На Channel9 даже есть запись с teched где объясняют почему так.

И почему же так? Я запись нашел, но смотреть времени нет.

G>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.

Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.

Здравствуйте, chaotic-good, Вы писали:

G>>Любой код можно написать плохо. Можно считать это аксиомой. Но даже тысячи плохо написанных пулов объектов не делают пулинг с gc неэффективным.
G>>Если посмотреть внтуренности .NET и Roslyn, то можно заметить, что очень часто используется thread-local пул объектов StringBuilder, который очень даже изменяемый. На Channel9 даже есть запись с teched где объясняют почему так.

CG>И почему же так? Я запись нашел, но смотреть времени нет.

Truth #3

Allocations are king
Time spent in the garbage collector harms responsiveness
Average delays ≈ (Collection rate) × (Collection cost)
Average delays ≈ (Allocation rate) × (Heap size)

Corollary: Allocate less
Less often (reduce collection rate)
Smaller, fewer long-lived objects (reduce heap size)

G>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.

CG>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.

Здравствуйте, gandjustas, Вы писали:

G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.

Ага, вот только Скит сам писал, что не считает себя гуру дотнета.
№1 на SO — ну дык Билл Гейтс был номер в MS, а Джобс номер один в Apple.
Написать книгу по языку — вовсе не значит быть профи в разработке на этом языке.

G>
Truth #3

G>
Allocations are king
G>Time spent in the garbage collector harms responsiveness
G>Average delays ≈ (Collection rate) × (Collection cost)
G>Average delays ≈ (Allocation rate) × (Heap size)

G>
Corollary: Allocate less
G>Less often (reduce collection rate)
G>Smaller, fewer long-lived objects (reduce heap size)

Я бы не сказал что это противоречит тому, о чем я говорил, впрочем ладно, думаю из нашей дискуссии и так уже можно сделать достаточно полезных выводов

G>>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.

CG>>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.

Я знаю кто это такой, читал его книгу и статьи. Суть в том, что тем не менее, дядя не публикует свои бенчмарки для этой статьи, следовательно, все что он в ней пишет — не имеет никакого значения. У него там долгоживущий string builder, который, насколько я понмю, содержит внутри себя ссылку на буфер, которая может меняться при использовании builder-а. Можно написать benchmark так, что эта ссылка не будет меняться никогда (буфер не будет ресайзиться, так как форматируется все время строка одной и той же длины), collection cost в тесте может быть очень низким, так как кроме самого теста никто не создает нагрузку на GC, поэтому полная сборка не будет отражаться на производительности. В реальном же коде все может быть совсем не как в бенчмарке. В реальном коде можно дернуть эту функцию, сформатировать что-нибудь объемное, что вызовет аллокацию и изменение ссылок в долгоживущем string builder-е, что в свою очередь вызовет полную сборку мусора, которая будет дорогой, а не дешевой как в benchmark-е. Может моя интуиция относительно этого и не верна и Скит правильно все делает, но я этому не поверю все равно пока сам не пощупаю или не увижу код теста. Вот такая вот у меня политика относительно бенчмарков

По поводу влияния остального кода на сложность и стоимость сборки мусора — это IMO главный недостаток языков с GC. Тут мы тестим фунцию и все ок, а там мы используем ее в приложении, которое имеет совсем другой характер нагрузки на сборщик мусора и получается совсем другой результат. Получается что кусок кода нельзя рассматривать отдельно performance wise и это не что иное как отсутствие модульности.

Здравствуйте, chaotic-good, Вы писали:

CG>По поводу влияния остального кода на сложность и стоимость сборки мусора — это IMO главный недостаток языков с GC. Тут мы тестим фунцию и все ок, а там мы используем ее в приложении, которое имеет совсем другой характер нагрузки на сборщик мусора и получается совсем другой результат. Получается что кусок кода нельзя рассматривать отдельно performance wise и это не что иное как отсутствие модульности.

Бред мягко говоря. Неэффективный код будет плохо работать независимо от места использования.
Просто в языках с GC надо считать не только циклы процессора, но и аллокации.
При ручном управлении памятью аллокации напрямую отражаются в CPU usage, а с GC получаются отложенные затраты.

Из той же презентации:

Truth #1

Profiles don’t lie
You can speculate and hypothesize all you want…
If you’re not measuring, you’re just guessing.

Truth #2

Good tools make all the difference
For managed code, the profiler of choice is PerfView
LMBTFY: http://www.bing.com/search?q=PerfView+download
http://www.microsoft.com/en-us/download/details.aspx?id=28567

Здравствуйте, johny5, Вы писали:

J>Как то не возникает с этим проблемы в C++, не все мусорные указатели на самом деле используются. Кроме того, в С++ есть возможность передаваемую структуру данных скопировать by value. В С# это не подрузамевается но если сильно надо то конечно можно, только какой смысл тогда кодить на C# если там так всё сложно и ты должен думать над передачей каждого указателя и каждой лямбдой. Ничего GC тогда не облегчает а даже наоборот. Кроме того мемори лики оочень сложно искать, я потратил неделю. В случае с С++ висячий указатель выстрелил бы почти сразу.

В .NET утечки ищутся элементарно. Для этого даже никакой app verifier с gflags не нужен, достаточно просто дампа процесса, прямо от клиента или с продакшена. Даже символьные файлы не нужны. Вот в С++ — это секс, да.

Здравствуйте, __kot2, Вы писали:

__>да, есть такой прикол — вместо delete приходится вызывать dispose. поэтому грамотная работа с памятью в C#, Java становится ничем не проще С++

Интересно, какое отношение Dispose имеет к работе с памятью?

Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, __kot2, Вы писали:
__>>да, есть такой прикол — вместо delete приходится вызывать dispose. поэтому грамотная работа с памятью в C#, Java становится ничем не проще С++
T>Интересно, какое отношение Dispose имеет к работе с памятью?
ну вы же сталкивались с тем, что у нас некоторые обьекты держат указатели на системные ресурсы как файлы, хэндлы, потоки. если вы не будете их руками освобождать в dispose у вас приложение будет нестабильно падать по out of resources

в случае с reference counting такой проблемы нет — как только обьект вам не нужен, ресурс будет высвобожден

в C#-Java вы начинаете писать код в стиле
using (...)
симулирую auto_ptr. а вот reference couring ptr вам не удастся никаикм образом добиться и придется мучаться технологиями многолетней давности

потом вдруг вы столнетесь, что с большими кусками памяти та же история — дефрагментации памяти слишком тяжелая и по уму хорошо бы иметь заранее выделенные буферы или какое-то ручное более низкоуровневое управление памятью — когда большие буферы не перемешаны с мелкими временными обьектами

в итоге у вас получится полностью ручной memory management. хрень полнейшая.

Здравствуйте, __kot2, Вы писали:
__>ну вы же сталкивались с тем, что у нас некоторые обьекты держат указатели на системные ресурсы как файлы, хэндлы, потоки. если вы не будете их руками освобождать в dispose у вас приложение будет нестабильно падать по out of resources
И причем тут память?
И зачем хранить в поле класса ссылку на файл?
И в чем проблема если файл закроется не сразу, а после срабатывания ГЦ?
Хоть раз в жизни видел падение от того что хендлы кончались? Я нет, хотя есть подозрение что побольше тебя .Net приложений видел.
В курсе что code analysis в студии показывает все места с незадиспозенным idisposable?

__>в C#-Java вы начинаете писать код в стиле
__>using (...)
__>симулирую auto_ptr. а вот reference couring ptr вам не удастся никаикм образом добиться и придется мучаться технологиями многолетней давности
Курил? Каким образом auto_ptr похож на using?

__>потом вдруг вы столнетесь, что с большими кусками памяти та же история — дефрагментации памяти слишком тяжелая и по уму хорошо бы иметь заранее выделенные буферы или какое-то ручное более низкоуровневое управление памятью — когда большие буферы не перемешаны с мелкими временными обьектами
Это в с++ оно лучше, а с gc долгоживущие и короткоживущие объекты и так вместе не живут буквально после пары сборок мусора.

__>в итоге у вас получится полностью ручной memory management. хрень полнейшая.
Ты представляешь такой класс программистов, который на любом языке может писать как на с++. Я тебя расстрою, описанных тобой проблем просто не существует. Они есть только в с++, а в языках с ГЦ ты в микроскоп не увидишь эти проблемы, даже если тщательно воспроизведешь все условия.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, __kot2, Вы писали:
__>>ну вы же сталкивались с тем, что у нас некоторые обьекты держат указатели на системные ресурсы как файлы, хэндлы, потоки. если вы не будете их руками освобождать в dispose у вас приложение будет нестабильно падать по out of resources
G>И причем тут память?
G>И зачем хранить в поле класса ссылку на файл?
G>И в чем проблема если файл закроется не сразу, а после срабатывания ГЦ?
G>Хоть раз в жизни видел падение от того что хендлы кончались? Я нет, хотя есть подозрение что побольше тебя .Net приложений видел.
да, конечно, много раз

G>В курсе что code analysis в студии показывает все места с незадиспозенным idisposable?
ну да, показывает лики. и что с ними делать?

__>>в C#-Java вы начинаете писать код в стиле
__>>using (...)
__>>симулирую auto_ptr. а вот reference couring ptr вам не удастся никаикм образом добиться и придется мучаться технологиями многолетней давности
G>Курил? Каким образом auto_ptr похож на using?
ну, это не мой ник похож на "ганджубас". а зачем по-вашему вообще нужен using если в C# все так хорошо с захватом и освобождением ресурсов системы?

Здравствуйте, __kot2, Вы писали:

__>ну, это не мой ник похож на "ганджубас". а зачем по-вашему вообще нужен using если в C# все так хорошо с захватом и освобождением ресурсов системы?

Не стоит в это втягиваться. Просто поставь ему минус за хамство и всё.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, gandjustas, Вы писали:

G>>Хоть раз в жизни видел падение от того что хендлы кончались? Я нет, хотя есть подозрение что побольше тебя .Net приложений видел.
__>да, конечно, много раз
Тогда приведи минимальный код, который падает по этой причине. На .NET.

G>>В курсе что code analysis в студии показывает все места с незадиспозенным idisposable?
__>ну да, показывает лики. и что с ними делать?
Вызвать dispose.

__>>>в C#-Java вы начинаете писать код в стиле
__>>>using (...)
__>>>симулирую auto_ptr. а вот reference couring ptr вам не удастся никаикм образом добиться и придется мучаться технологиями многолетней давности
G>>Курил? Каким образом auto_ptr похож на using?
__>ну, это не мой ник похож на "ганджубас". а зачем по-вашему вообще нужен using если в C# все так хорошо с захватом и освобождением ресурсов системы?
Он нужен для детерминированного освобождения. Так как часто при "закрытии" хендла выполняется много действий Например при закрытии файла сбрасывается буфер на диск, при закрытии сокета — отправка данных из буфера, закрытие соединения с БД — возвращение в пул, чтобы другой поток мог его взять, а не плодить еще одно соединение.

Тем не менее если не использовать idisposable никакой утечки не случится, просто файл\сокет\соединение закроется после сборки мусора. В десктопном приложении никаких проблем от этого не будет вообще.

А еще часто используют disposable как некоторый scope Например в razor шаблоне с помощью using указывается где форма начинается и закачивается.

Здравствуйте, __kot2, Вы писали:

G>>Курил? Каким образом auto_ptr похож на using?
__>ну, это не мой ник похож на "ганджубас". а зачем по-вашему вообще нужен using если в C# все так хорошо с захватом и освобождением ресурсов системы?

Кстати ты так и не ответил каким образом auto_ptr похож на using?

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

G>>>В курсе что code analysis в студии показывает все места с незадиспозенным idisposable?
__>>ну да, показывает лики. и что с ними делать?
G>Вызвать dispose.
понимаете, что вы просто вручную уничтожаете обьект? не бывает никаких init и dispose. бывает создание и уничтожение обьекта. а то, что оно разбито на два этапа это извращения, на которые приходится идти ради совместимости с другими нерабочими великими идеями. в этом плане вызов Dispose в C# или delete в С++ ничем не отличается. разве что в первом случае вы получаете говнообьект, а в С++ вы д-но его диспозите

G>Он нужен для детерминированного освобождения. Так как часто при "закрытии" хендла выполняется много действий Например при закрытии файла сбрасывается буфер на диск, при закрытии сокета — отправка данных из буфера, закрытие соединения с БД — возвращение в пул, чтобы другой поток мог его взять, а не плодить еще одно соединение.
правильно, это должно делаться при разрушении обьекта. разрушение в смысле destruction. мы хотим контролировать время его жизни. но средствами языка это делать нельзя и мы добавляем велосипед — договариваемся, что код деструктора помещаем в Dispose и вручную будем вызывать его.

G>Тем не менее если не использовать idisposable никакой утечки не случится, просто файл\сокет\соединение закроется после сборки мусора. В десктопном приложении никаких проблем от этого не будет вообще.
G>А еще часто используют disposable как некоторый scope Например в razor шаблоне с помощью using указывается где форма начинается и закачивается.
правильно, в С++ это как создавать обьекта на стеке. будет вызыван деструктор при выходе из фрейма. если еще в танке, то можно писать так
void f()
{
x = 10
{ <- это типа начало scope using
ifstream f("filename")
} <- вот тут вот он уничтожится

x = 20
}
а теперь, внимание, обьяснение по поводу auto_ptr — если нас не устраивает стек, хотим на куче, то

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

x = 20
}

вот это повредение и пытается симулировать C# со своим Dispose

Здравствуйте, __kot2, Вы писали:

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

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

Не падает

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

Ты только что расписался, что не знаешь как работает GC и .NET вообще.

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

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

dispose и delete кстати отличается очень сильно. Но я уж понял, что все что ты пишешь основано на незнании .NET. Ранее ты умудрился using приравнять к auto_ptr

G>>Он нужен для детерминированного освобождения. Так как часто при "закрытии" хендла выполняется много действий Например при закрытии файла сбрасывается буфер на диск, при закрытии сокета — отправка данных из буфера, закрытие соединения с БД — возвращение в пул, чтобы другой поток мог его взять, а не плодить еще одно соединение.
__>правильно, это должно делаться при разрушении обьекта.

Ага, см выше про разрушение объекта.

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

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

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

G>>Тем не менее если не использовать idisposable никакой утечки не случится, просто файл\сокет\соединение закроется после сборки мусора. В десктопном приложении никаких проблем от этого не будет вообще.
G>>А еще часто используют disposable как некоторый scope Например в razor шаблоне с помощью using указывается где форма начинается и закачивается.
__>правильно, в С++ это как создавать обьекта на стеке. будет вызыван деструктор при выходе из фрейма. если еще в танке, то можно писать так
__>void f()
__>{
__> x = 10
__> { <- это типа начало scope using
__> ifstream f("filename")
__> } <- вот тут вот он уничтожится

__> x = 20
__>}
Чувак, я знаю C++ (и судя по твоему комменту ниже — знаю лучше тебя), это ты не знаешь .NET

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

__> x = 20
__>}

Убило.
Во-первых просто не скомпилируется.
Во-вторых ты походу не знаешь разницу между auto_ptr и unique_ptr.
В-третьих попробуй передать куда-либо auto_ptr.
В-четвертых ты вообще не понимаешь как работает .NET вообще и IDisposable в частности.

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

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

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	13.01.15 21:38
Оценка:	+1

	От:	Privalov
	Дата:	14.01.15 07:37
	Оценка:

	От:	chaotic-good
	Дата:	14.01.15 09:34
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	14.01.15 10:18
Оценка:

	От:	koodeer
	Дата:	14.01.15 10:37
	Оценка:

От:	johny5	https://www.facebook.com/TachyonWars/
Дата:	17.01.15 23:06
Оценка:	-1

	От:	mrTwister
	Дата:	16.01.15 15:09
	Оценка:

	От:	mrTwister
	Дата:	16.01.15 15:11
	Оценка:

	От:	__kot2
	Дата:	18.01.15 16:12
	Оценка:	-2

	От:	__kot2
	Дата:	18.01.15 19:01
	Оценка:	-5