Освобождение памяти от экземпляра класса

[Mixim]

Реализовываю задачу по дисциплине "Структуры и алгоритмы". Как понимаете, данная дисциплина накладывает жесткие ограничения на работу с памятью - ни один бит не должен уйти в пустую, скорость выполнения алгоритма должна быть высокой и т.д.
Стояла задача реализовать свой собственный двусвязный список(LinkedList использовать нельзя), в котором необходимы методы: Push() - вставить экземпляр в список; Pop() - изъять(перенаправить связи) экземпляра списка; Get_First() - получить первый экземпляр в списке; само собой конструкторы и деструктор и прочее. Все это успешно реализовано, но встал вопрос про экономию памяти: если текущий размер списка больше чем тот, который ввел пользователь, то нужно удалить несколько последних элементов. Не долго думая, пишу банальный код:

delete MyElement.Get_Last().Pop()

Но вся проблема заключается в том, что метод delete почему-то недоступен(находится за пределами области видимости компилятора VS2010). Подскажите, какой модуль нужно подключить, чтобы данный код нормально работал, чтобы была возможность вызывать метод delete?

[m0nax]

Разделом не ошиблись?

В .net нету delete, нельзя ничего удалить - все лишнее автоматически освобождается

[Пепел Феникса]

какой нахрен delete в dotNET?
там обьекты сами уничтожаются как только теряются все ссылки на них.

(да я и вообще считаю что dotNET и экономия памяти вещи не совместимые, VM всетаки)

или я отстал от жизни?(это вопрос к шарпистам)

[Hollander]

Единственный ход быстрой очистки памяти в .NET, насколько я знаю, это - убить объект(= null и вручную вызвать сборщик мусора.

[dampirik]

Вот почитай...

[Mixim]

Сообщение от Hollander

вручную вызвать сборщик мусора.

Сообщение от dampirik

Вот почитай...

Спасибо за советы вручную вызвать сборщик мусора, работая на "не автоматизированном" языке C++ - совсем о нем забыл.
По предоставленным ссылкам MSDN, нашел методику вызова сборщика мусора:

 GC.Collect(n);//первая перегрузка

или

GC.Collect();//вторая перегрузка

, только немного не ясно, что означает аргумент функции Collect в первой перегрузке - он освобождает потомков до поколения n, а вторая перегрузка освобождает всю занятую но неиспользуемую память? Если это так, то зачем нужна первая перегрузка, ведь "если на объект потеряны все ссылки", то с ним больше ни как не поработаешь или я немного не понимаю принципы C#?

[Никки]

У object есть метод Dispose(), который его уничтожает и очищает память.

[veniside]

Сообщение от Mixim

или я немного не понимаю принципы C#?

На самом деле там всё просто, ггг.

Basically, the GC divides the managed heap into three generations. Objects that have just been allocated are in Gen0 and objects that have survived one collection cycle are in Gen1; all other objects are in Gen2.

The CLR keeps the Gen0 section relatively small (a maximum of 16 MB on the 32-bit workstation CLR, with a typical size of a few hundred KB to a few MB). When the Gen0 section fills up, the GC instigates a Gen0 collection—which happens relatively often. The GC applies a similar memory threshold to Gen1 (which acts as a buffer to Gen2), and so Gen1 collections are relatively quick and frequent too. Full collections that include Gen2, however, take much longer and so happen infrequently.



Figure 12-2 shows the effect of a full collection.

To give some very rough ballpark figures, a Gen0 collection might take less than 1 ms, which is not enough to be noticed in a typical application. A full collection, however, might take as long as 100 ms on a program with large object graphs. These figures depend on numerous factors and so may vary considerably—particularly in the case of Gen2 whose size is unbounded (unlike Gen0 and Gen1).

Есть такая пословица, "не мала баба хлопоту, купила порося". Вызывать GC.Collect(), пытаясь сэкономить ничтожные биты памяти, это примерно как вызывать дефрагментацию диска после каждой записи в файл.

[Hollander]

Сообщение от veniside

Вызывать GC.Collect(), пытаясь сэкономить ничтожные биты памяти, это примерно как вызывать дефрагментацию диска после каждой записи в файл.

Отчасти согласен. Для Mixim - это действительно так. Но когда объекты занимают сотни mb (у меня такие на практике есть), то такой вызов единственное спасение.