Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата IL_Agent @ 29.12.11, 19:18

Т.е. при закрытии приложения/выгрузке сборки оно таки будет вызвано.

У меня даже опера месяцами не закрывается на работе

Цитата D_KEY @ 29.12.11, 19:32

Как это? RAII успешно справляется. Я же уже неоднократно писал об этом. Питоновские менеджеры контекста, шарповые using'и, новый явовский "try с ресурсами". И зачем в таком случае finally?

Синтаксический сахар над try-finally. Для удобства. Но сути это не меняет.

Добавлено 29.12.11, 19:37

Цитата IL_Agent @ 29.12.11, 19:18

http://msdn.microsoft.com/ru-ru/library/system.object.finalize.aspx

Цитата

Во время завершения работы домена приложения Finalize вызывается автоматически для объектов, которые не исключены из финализации, даже для тех, которые остаются доступными.

Т.е. при закрытии приложения/выгрузке сборки оно таки будет вызвано.

Майкрософтовский GC дергает каждый объект? О ужас...

Добавлено 29.12.11, 19:41
D_KEY, т.е. ты придираешься к конкретному синтаксису try-finally, я же говорю о его назначении -- явным образом инициировать высвобождение конкретных ресурсов (в противовес автоматическому их высвобождению при уничтожении объекта).

Цитата korvin @ 29.12.11, 19:35

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

А как тогда расценивать мой код? Это явное инициирование высвобождения, суть сахароза, или всё же автоматическое высвобождение при уничтожении, суть опора на детерминированный вызов деструкторов?
Этот вопрос стал бы ещё важнее, будь в плюсах макросы по типу Nemerle - тогда было бы полное ощущение сахара.

Цитата MyNameIsIgor @ 29.12.11, 19:45

А как тогда расценивать мой код? Это явное инициирование высвобождения, суть сахароза, или всё же автоматическое высвобождение при уничтожении, суть опора на детерминированный вызов деструкторов?

Так а почему ты не написал подобие locker'а, который уничтожался бы автоматически и освобождал ресурс?

Цитата korvin @ 29.12.11, 19:50

Так а почему ты не написал подобие locker'а, который уничтожался бы автоматически и освобождал ресурс?

Чтобы показать аналог кода на Go.

Цитата MyNameIsIgor @ 29.12.11, 19:52

Чтобы показать аналог кода на Go.

И только? Тогда это просто пример, что "так можно", не более. А так да, это ручная инициализация освобождения ресурсов и в C++ видимо не нужно. Или есть случаи, когда иначе никак?

Цитата korvin @ 29.12.11, 20:00

И только? Тогда это просто пример, что "так можно", не более.

Это пример того, что так писать на плюсах можно - без написания локеров.

Цитата korvin @ 29.12.11, 20:00

Или есть случаи, когда иначе никак?

Да вроде всегда можно написать владельца ресурса...

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

Цитата korvin @ 29.12.11, 20:11

Не думаю, что реализация классов-владельцев будет занимать больше места, чем Defer'ов

Как раз наоборот. Такой defer пишется один раз на все случаи жизни...

Цитата korvin @ 29.12.11, 19:35

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

Так это ты зациклился на синтаксисе. Вышеперечисленные средства не просто синтаксический сахар, это как раз смена "парадигмы" с "явного делания чего-то при выходе" на "захват ресурса и автоматическое его освобождение". И костыль в виде finally можно выпиливать.
А что он делает в Delphi без GC - вообще не понятно

Цитата Flex Ferrum @ 29.12.11, 11:30

А ещё лучше - &str[0], и не надо никаких кастов.

Во-во-во. Чё-то меня в спешке взгючило.

Цитата Flex Ferrum @ 29.12.11, 12:16

Ага. В несознанке, видимо, писали. Потому что дальше операция [] также определяется через итераторы.

Та не. Это всё std::vector<bool> виноват. Скорее для вектора надо было бы через итераторы.

Добавлено 29.12.11, 22:40

Цитата D_KEY @ 29.12.11, 19:35

У меня даже опера месяцами не закрывается на работе

На предмет "пары недель", а не "месяцев" у меня тоже есть опыт. Каждая активизация окна Оперы - минутные тормоза из-за свопа, а её в конце-концов завершение - ещё более длительные тормоза на очистку ресурсов и завершение процесса, хотя да, окошко пропадает сразу.

Цитата D_KEY @ 29.12.11, 20:38

Так это ты зациклился на синтаксисе. Вышеперечисленные средства не просто синтаксический сахар, это как раз смена "парадигмы" с "явного делания чего-то при выходе" на "захват ресурса и автоматическое его освобождение". И костыль в виде finally можно выпиливать.
А что он делает в Delphi без GC - вообще не понятно

О! Синтаксический сахар у нас теперь называется парадигмой? Я тут на ЛОРе задал вопрос про переопределение методов, вот товарищ привел пример на Питоне:

 from contextlib import contextmanager
 
@contextmanager
def override(obj, **kwargs):
    oldvalues = dict((attr, getattr(obj, attr)) for attr in kwargs)
 
    for attr, value in kwargs.iteritems():
        setattr(obj, attr, value)from contextlib import contextmanager
 
@contextmanager
def override(obj, **kwargs):
    oldvalues = dict((attr, getattr(obj, attr)) for attr in kwargs)
 
    for attr, value in kwargs.iteritems():
        setattr(obj, attr, value)
 
    try:
        yield
    finally:
        for attr, value in oldvalues.iteritems():
            setattr(obj, attr, value)
 
 
class A(object):
    def id(self):
        return 0
 
 
a1 = A()
a2 = A()
 
with override(A, id=lambda self: 1):
    assert (a1.id(), a2.id()) == (1, 1)
 
assert (a1.id(), a2.id()) == (0, 0)
 
 
with override(a1, id=lambda: 2):
    assert a1.id() == 2
 
assert a1.id() == 0
 
    try:
        yield
    finally:
        for attr, value in oldvalues.iteritems():
            setattr(obj, attr, value)
 
 
class A(object):
    def id(self):
        return 0
 
 
a1 = A()
a2 = A()
 
with override(A, id=lambda self: 1):
    assert (a1.id(), a2.id()) == (1, 1)
 
assert (a1.id(), a2.id()) == (0, 0)
 
 
with override(a1, id=lambda: 2):
    assert a1.id() == 2
 
assert a1.id() == 0

И что же мы видим? Оказывается, что Менеджер Контекста всего-навсего обычная обертка над try-finally, прям как в CL с 80-х годов...

Цитата korvin @ 30.12.11, 04:11

Менеджер Контекста всего-навсего обычная обертка над try-finally

Потому что был введён в язык, где уже был finally. А если бы finally не было?

Цитата korvin @ 30.12.11, 04:11

О! Синтаксический сахар у нас теперь называется парадигмой?

Синтаксический сахар - это один из способов обеспечения удобного использования парадигмы. То, что with в питоне сейчас реализован именно так, не является его семантическим свойством. Выпили finally из python 4, реализуй with иначе, но с сохранением той же семантики, и он перестанет быть синтаксическаим сахаром.

Цитата D_KEY @ 29.12.11, 20:38

Так это ты зациклился на синтаксисе. Вышеперечисленные средства не просто синтаксический сахар, это как раз смена "парадигмы" с "явного делания чего-то при выходе" на "захват ресурса и автоматическое его освобождение". И костыль в виде finally можно выпиливать.

Да?
А для нетривиальных ситуаций разве не нужно расставлять локальные блоки { ... } (а-ля try ... finally)?
А на нетривиальную деинициализацию не нужно ничего биндить (а-ля finally ... end)?
Те же уши только в профиль, ну и о каких костылях ты говоришь?

Добавлено 30.12.11, 06:21
Если я правильно понял, то идиома Scope Guard из C++ - как раз тот костыль try-finally из Delphi.