В Visual С++ автоматическая сборка мусора?

← →
Artem (2012-08-31 02:02) [0]

Здравствуйте. А то мне тут сказали что нет, а мне казалось, что да...

← →
Германн © (2012-08-31 02:42) [1]

> Здравствуйте. А то мне тут сказали что нет, а мне казалось,
> что да...

Что не не смог найти форумы для Си-шников?

← →
Artem (2012-08-31 02:55) [2]

> Что не не смог найти форумы для Си-шников?

Ой. Вообще по ошибке сюда задал сорри

← →
Inovet © (2012-08-31 09:22) [3]

Как ты се6бе представляешь автоматическую сборку мусора в Си++?

← →
Студент (2012-08-31 09:35) [4]

Inovet © (31.08.12 09:22) [3]

>>Как ты се6бе представляешь автоматическую сборку мусора в Си++?

Сторонними библиотеками.

← →
KSergey © (2012-08-31 10:04) [5]

> Inovet © (31.08.12 09:22) [3]
> Как ты се6бе представляешь автоматическую сборку мусора в Си++?

Smart pointer - наше все! )

← →
han_malign (2012-08-31 10:18) [6]

> Сторонними библиотеками.

- угу - .NET называется...
И делать надо управляемый код (/clr, #pragma managed) - но это проще сразу на C#, чтобы не заморачиваться со всякими gcnew, ^, %(вместо: new, *, &)

← →
han_malign (2012-08-31 10:21) [7]

> Smart pointer

- RAII
http://ru.wikipedia.org/wiki/Получение_ресурса_есть_инициализация

← →
Inovet © (2012-08-31 10:28) [8]

> [4] Студент (31.08.12 09:35)
> Сторонними библиотеками.

Мало ли что там в библитех.

← →
Inovet © (2012-08-31 10:31) [9]

> [5] KSergey © (31.08.12 10:04)
> Smart pointer - наше все! )

Это не сборка мусора. Мусора собственно и нет при таком подходе.

← →
Inovet © (2012-08-31 10:44) [10]

> [6] han_malign (31.08.12 10:18)
> - угу - .NET называется...
> И делать надо управляемый код (/clr, #pragma managed) -
> но это проще сразу на C#, чтобы не заморачиваться со всякими
> gcnew, ^, %(вместо: new, *, &)

А, ну и в Делфи тогда есть сборка мусора, в версии .NET.

← →
Кукарямба (2012-08-31 18:41) [11]

> han_malign (31.08.12 10:21) [7]
> - RAII

Ну, такой "сборщик" и в Delphi есть)

← →
jack128_ (2012-09-01 20:58) [12]

> Ну, такой "сборщик" и в Delphi есть)

он не такой удобный в использовании и время жизни объектов не так четко определено, как в с++

← →
Алибабай (2012-09-02 00:01) [13]

> он не такой удобный в использовании и время жизни объектов
> не так четко определено, как в с++

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

И что там не так насчет "удобства"?

← →
Inovet © (2012-09-02 08:41) [14]

> [13] Алибабай (02.09.12 00:01)
> И что там не так насчет "удобства"?

То, что только целиком в функции. Какой-нить массив 10 раз не создать без освобождения предыдущего.

← →
Кукарямба (2012-09-02 09:19) [15]

> То, что только целиком в функции. Какой-нить массив 10 раз
> не создать без освобождения предыдущего.

Я говорю вот об этом:

var A: IInterface; begin A := TInterfacedObjectDescendant.Create; A := nil; // уничтожили явно A := TInterfacedObjectDescendant.Create; A := TInterfacedObjectDescendant.Create; // создали новый, старый уничтожен автоматически неявно end; // уничтожен автоматически

А вы о чем?

← →
Алибабай (2012-09-02 09:20) [16]

> Кукарямба (02.09.12 09:19) [15]

Это я.

← →
Inovet © (2012-09-02 09:45) [17]

> [15] Кукарямба (02.09.12 09:19)
> А вы о чем?

Область видимость меньше функции.
{ ... { // объявили // используем } // само уничтожилось ... }

> Область видимость меньше функции.
мнимое удобство, объявлять в месте использования. (кучу ошибок делают именно из-за этого, к примеру, простая опечатка и уже новая переменная, глюк логики, а не ошибка которую покажет)
уничтожение при выходе из блока объявления это следствие, блок как бы маленькая функция.

и кстати в чем тут удобство? уничтожается само... а по выходу их блока оно тебе нужно... значит отчитываешь блоки "вверх" переносишь туда (если заметишь, т.к. если просто напишешь переменную это будет объявление и как следствие ошибка), т.е. необходимо следить постоянно.
где удобство?

как в [15] очевиднее, и значит удобнее. ИМХО.

> [18] sniknik © (02.09.12 12:54)
> и кстати в чем тут удобство? уничтожается само... а по выходу
> их блока оно тебе нужно...

Объявлять там где нужно, где не нужно не будет память расходоваться, мод массивы, например vector.

> А тип указать?
а типа зачастую и не нужно в таких языках... возьмем к примеру PHP.

> где не нужно не будет память расходоваться
вообще то, настоящий сборщик мусора не освобождает память прям в тот момент как стала не нужна. т.что...
com объекты некоторые (ADO например) делают также, ради оптимизации скорости выполнения.
ну и т.д. перераспределение памяти - "тяжёлая" операция, ее пытаются минимизировать обыйно.

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

← →
Алибабай (2012-09-02 13:45) [23]

> Inovet © (02.09.12 09:45) [17]
>
> Область видимость меньше функции.

RAII к этому не имеет никакого отношения.
Это особенность языка программирования.
Или вы хотите поговорить про, например, вложенные подпрограммы?

> [3] Inovet © (31.08.12 09:22)
> Как ты се6бе представляешь автоматическую сборку мусора в Си++?

> [9] Inovet © (31.08.12 10:31)
> Это не сборка мусора. Мусора собственно и нет при таком подходе.

В Visual С++ автоматическая сборка мусора? Найти похожие ветки