Re: Косяк во всем CLI (Common Language Infrastructure)! - Философия программирования

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

C>Замените в примере Finalize на Dispose и подумайте как нормально
C>организовать иерархию Dispose'ов.

C>Hint: у Dispose семантика фактически такая же, как у С++ного деструктора.

Совершенно не такая же — Dispose не удаляет объект (вот оно — главное отличие), он освобождает (или не освобождает) ресурсы, и никаких гарантий нам вызов Dispose в общем случае не даёт.

C>Это бред. В С++ объекты (даже со сложным деревом множественного
C>наследования) выделяются одним куском. Лишней косвенности тоже непонятно
C>откуда взяться.

А вот и не бред

На данный момент в CLI объекты reference-типа хранятся в куче. Каждый объект хранится в куче отдельно. Предложенная модификация повлечёт за собой изменение способа конструирования/хранения/сбора объектов — оно надо?

Насчёт лишней косвенности:

// "Обычное" наследование
class Base
{
    virtual void M()
    {
    }
}

class Derived : Base
{
    virtual void N()
    {
    }
}

// Агрегация
class Base
{
    virtual void M()
    {
    }
}

class Derived
{
    Base b;
    
    // Интерфейс Base как бы надо сохранить
    virtual void M()
    {
        // Насчёт дополнительных косвенных вызовов
        b.M();
    }
    virtual void N()
    {
    }
}

Да, есть JIT, который может заинлайнить вызов. А может и не заинлайнить.

В общем, такую штуку можно использовать при реализации mix-ins в C# (тогда код будет явно декларировать свои намерения по агрегации), например, но не для реализации обычного наследования — это точно.

C>Потому как сложные вещи тогда будет делать очень сложно.

Точно — чего-то мне smart pointers в C# не хватает

Дело в том, что в C# сложные вещи можно делать проще и чего-то совершенно не тянет делать их очень сложно

PS: ты забыл предложить перенести BOOST на C#

А то как же тут без него?

VladD2 wrote:
> Ой, а можно список несерьезных программ?

> Вот наш сайт серьезная программа?
Простите, но нет. От падения RSDN на пару часов никто не пострадает и не
потеряет кучу бабок.

> Я вот сейчас глянул, а там по статистики постянно появляются
> выжившие в результате финализации объекты. Прикино, что было
> бы если они все привращались в потери неуправляемых ресурсов?
А что прикидывать-то? RSDN у меня с завидной переодичностью глючит.

Кроме того, веб сайт — это как раз пример того, где не так уж и важно
нормальное обращение с неуправляемыми ресурсами.

> C> Единственное назначение Finalize — чтобы написаные
> C>левой пяткой программы хоть как-то работали.
> Это у кого как. У кого как ты говоришь, а у кого для облегчения слежения
> за ресурсами и чтобы пара мелких ошибок не приводила к остановке работы
> критически важных приложений.
Ну да, пара мелких ошибок тут, пара мелких ошибок там....

Я достаточно долго занимался одной программой на Java, где
использовались мои JNI-обертки. Финализаторы тоже использовались — в них
стоял такой код:

void finalize()
{
    if (objectHandle!=0)
    {
        System.err.println("UNFINALIZED OBJECT! Created at:");
        creationStackTrace.printStackTrace();
    }
}

creationStackTrace создавался в конструкторе оьъекта. Сначала наши
Java-программисты пищали, что это типа неудобно и GC — наше все, но
потом (после того, как отловили кучу ошибок) стали применять такой трюк
в своих объектах.

> C>Семантический аналог деструктора — это именно Dispose.
> Диспоз — это паттерн. И в его полную версию входит использования
> финализатора. Так что симантических аналогов деструкторов в дотнете *нет*.
Финализатор — это кривая подпорка. А деструкторы в С++ — это тоже
паттерны, кстати.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

Попробуй подумать над вот такой штукой:

using System;

class A
{
    ~A() { GC.ReRegisterForFinalize(this); }
}

class B : A
{
    ~B()
    {
        Console.WriteLine("Я объект класса 'A'. "
            + "Кажется я помираю... :( Но я пока жив! :)");
    }
}

class Program
{
    static void Main()
    {
        new B();
    }
}

Забавно? Правда?

Так что вызовы из "деструкторов" виртуальных методов — это еще цветочки. Вот воскресающие объекты — это куда прикольнее. Как тебе необязательность деструкторов?

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>[snipped]
PC>Очевиднее?

Я полагаю, аргументы исчерпались?

Для меня очевиднее потому, что ... (см. ниже) Для тебя неочевиднее потому, что ты просто не привык к этому.

PC>Ок. Почему только не ясно. Сообственно это и был исходный вопрос.

Ну я же уже объяснял, почему. Сейчас постараюсь сформулировать более сжато:

В CLI у типов нет понятия деструктора. Объекты уничтожает GC и только GC. Метод Finalize() предназначен только для освобождения unmanaged ресурсов, поэтому мы не можем утверждать, что к моменту вызова Base.Finalize() всё состояние, добавленное типом Derived, будет освобождено.
Наследование всегда реализовано не через ... удержание ссылки на объект базового типа, поэтому семантика удаления объекта совершенно иная (только всем куском).
Виртуальный метод всегда вызывается через vtbl, откуда бы он ни был вызван (иначе имела бы место путаница, т.к. Finalize — самый что ни на есть обычный метод).

Я не гуру CLI, поэтому объяснил как смог.

PC>И чем агрегация базового в наследнике плоха?

А чем она хороша, особенно в managed environment? Иметь 10 объектов в куче вместо одного — просто замечательная идея

Ещё и косвенные вызовы появляются — тоже супер. И я просто не знаю, как бы в таком случае работал reflection или сериализация...

В общем, зачем усложнять там, где можно сделать просто?

Oyster wrote:
> 1. В CLI у типов нет понятия деструктора. Объекты уничтожает GC и
> только GC. Метод Finalize() предназначен только для освобождения
> unmanaged ресурсов, поэтому мы не можем утверждать, что к моменту
> вызова Base.Finalize() всё состояние, добавленное типом Derived,
> будет освобождено.
Замените в примере Finalize на Dispose и подумайте как нормально
организовать иерархию Dispose'ов.

Hint: у Dispose семантика фактически такая же, как у С++ного деструктора.

> PC>И чем агрегация базового в наследнике плоха?
> А чем она хороша, особенно в managed environment? Иметь 10 объектов в
> куче вместо одного — просто замечательная идея Ещё и косвенные вызовы
> появляются — тоже супер.
Это бред. В С++ объекты (даже со сложным деревом множественного
наследования) выделяются одним куском. Лишней косвенности тоже непонятно
откуда взяться.

> В общем, зачем усложнять там, где можно сделать просто?
Потому как сложные вещи тогда будет делать очень сложно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

Oyster wrote:
> Ты предлагаешь избавиться от него вообще?
Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
можно было поставить большой матюгальник, если ресурсы не будут закрыты
вовремя.

> Просто я не вижу лучшей альтернативы в CLI, которая среда с GC (Dispose
> не предлагать — я могу его и не вызвать).
Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
И это даже не потребует никак изменений в самом CLI — достаточно чтобы
компилятор сам оборачивал их в try..finally.

> C>Семантический аналог деструктора — это именно Dispose.
> Скажем так — в CLI сейчас нет аналога деструктора *вообще* Называть
> Dispose аналогом деструктора в его текущем виде у меня рука не поднимается.
Именно поэтому и нужно их нормально вводить. Идеально было бы ввести
автоматические типы с семантикой как в С++ (в том числе и для
деструкторов), а остальное можно было бы и не трогать.

> C>Но есть интерфейсы — с ними те же проблемы, на самом деле.
> Нет, не те же, т.к. у интерфейсов нету состояния. В итоге вопрос с
> реализацией нескольких интерфейсов достаточно просто разруливается в CLR.
Я про то, что вызов метода по интерфейсу происходит дольше прямого вызова.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

C>Замените в примере Finalize на Dispose и подумайте как нормально
C>организовать иерархию Dispose'ов.

C>Hint: у Dispose семантика фактически такая же, как у С++ного деструктора.
Dispose не часть CLI, и из-за него динамическую смену типа засовывать не будут...

>> В общем, зачем усложнять там, где можно сделать просто?
C>Потому как сложные вещи тогда будет делать очень сложно.
Мне тоже не нравится, но похоже в CLI лучше так... Там и vtbl инициализируются до входа в ктор

class Base
{
    Base() { foo(); }
    public virtual void foo () { Console.WriteLine("Base.foo"); }
}

class Derived : Base
{
    public void overide foo() { Console.WriteLine("Derived.foo"); }
}

void bar()
{
    Derived d = new Derived; //выведет Derived.foo :no:
}

Да исключения дурацкие

Кол-во заморочек C++ < кол-во заморочек C# + CLI следовательно С++ проще

(ерунда это конечно)

Oyster wrote:
> C>Hint: у Dispose семантика фактически такая же, как у С++ного деструктора.
> Совершенно не такая же — Dispose *не удаляет объект* (вот оно — главное
> отличие) он освобождает (или не освобождает) ресурсы, и никаких
> гарантий нам вызов Dispose в общем случае не даёт.
В С++ деструктор тоже не удаляет объект (этим занимается operator
delete), а освобождает связанные с объектом ресурсы. Именно этим же и
занимается Dispose.

> На данный момент в CLI объекты reference-типа хранятся в куче. Каждый
> объект хранится в куче отдельно. Предложенная модификация повлечёт за
> собой изменение способа конструирования/хранения/сбора объектов — оно надо?
Может быть. Хотя может и стоит изменить семантику хранения.

> class Derived
> {
> Base b;
>
> // Интерфейс Base как бы надо сохранить
> virtual void M()
> {
> // Насчёт дополнительных косвенных вызовов
> b.M();
Ничего особенного не будет. vtbl'и в случае одинарного наследования
будут расположены "вплотную", а значит и вызов будет обычным вызовом по
указателю.

Это легче всего описать на чистом С:

struct base
{
    void (*func1)();
    void (*func2)();
};
struct derived
{
    struct base base_struct;
    void (*func3)();
    void (*func4)();
};

Структуры будт расположены "вплотную", так что никаких затрат не будет.

Вот с множественным наследованием (и интерфейсам) все сложнее.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

Oyster wrote:
> C>В С++ деструктор тоже не удаляет объект (этим занимается operator
> C>delete), а освобождает связанные с объектом ресурсы. Именно этим же и
> C>занимается Dispose.
> Не совсем. Как раз этим занимается Finalize (гарантия вызова Finalize
> есть, гарантии вызова Dispose нет).
Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
серьезных программах. Единственное назначение Finalize — чтобы написаные
левой пяткой программы хоть как-то работали.

Семантический аналог деструктора — это именно Dispose.

> C>Может быть. Хотя может и стоит изменить семантику хранения.
> Да, это прийдётся сделать, если в CLI захочется эффективно хранить N
> объектов "подряд" (грубо говоря).
Да, было бы неплохо.

> C>Вот с множественным наследованием (и интерфейсам) все сложнее.
> Может, поэтому множественное наследование и отсутствует в C#, что не
> захотели усложнять?
Но есть интерфейсы — с ними те же проблемы, на самом деле.

> Мне в смысле множественного наследования больше
> нравится идея с миксинами — мы *явно* указываем, что реализация
> интерфейса второго (третьего и т.д.) класса, который мы как бы
> "наследуем", будет вынесена в отдельный объект, агрегированный нашим
> классом.
Тогда начнутся сложности с иерархией миксинов.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

struct Base
{
    virtual void Finalize()
    {
        printf("Base::Finalize();\n");
    }
};

struct Derived : public Base
{
    virtual void Finalize()
    {
        printf("Derived::Finalize();\n");

        Base::Finalize();
    }
};

void main()
{
    Base* a = new Derived();
    a->Finalize();
}

Почему не не происходит смена динамического типа после вызова Derived::Finalize?
Только не надо говорить, что Finalize вызывается не из деструктора. ОК? Ведь в дотнете и C# вообще нет деструкторов.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>Finalize не простая виртуальная функция — у нее другая семантика и переписывать на С++ ее нет смысла... Не убедил.

Ты будишь смеяться, но Finalize это простая виртуальная функция. Как по спецификации, так и по реализации. А то что ты видишь в C# — это эдакая дебильная маскировка под деструктор. Именно она и смущает тебя и многих других.

В VB финалайзер и есть просто виртуальный метод. В дельфи тоже.

VD>>Почему не не происходит смена динамического типа после вызова Derived::Finalize?
VD>>Только не надо говорить, что Finalize вызывается не из деструктора. ОК? Ведь в дотнете и C# вообще нет деструкторов.
PC>П. 5. Я знаю!!

Слушай, ты уже малось надоел про п. 5 говорить. Ты что под ним имешь в виду?

PC> Млин я не второй день про дотнет читаю... Я два года на нем пишу... Но вашего фанатизма пока не разделяю...

Не заметно, если чесно. А если, так то давно было бы пора разобраться с тем, что используешь. А то говоришь черти что "финалайзер не простой метод" и при этом заявляшь о том что знашь все что нужно.

... << RSDN@Home 1.2.0 alpha rev. 620>>

VladD2 wrote:
> C>Dispose Pattern не помогает, если ресурс кладется в поле объекта.
> Это с чего же? Может просто понять, что ресурс лежащий в поле уже
> является обернутым финалайзером?
Представьте себе, я прекрасно понимаю, что GC абсолютно и глубоко пофиг
где лежал объект до своей смерти.

Я говорю о том, что надеятся на GC для удаления внешних ресурсов —
ненадежно.

> Иначе бы любой массив обязан был бы реализовывать разные диспозы и
> вызывать их у всех вложенных объектов. А вдруг у них есть диспоз?
И это правильно.

> Да? Можно примеры? А то вот у меня на работу с неуправляемыми ресурсами
> в программах тратится где-то 0.1% уселий и кода.
В основном потому, что на C# как раз и пишутся в основном программы, где
управление ресурсами некритично (а часто и вообще ненужно). Типа
веб-серверов, серверов приложений и простых десктопных приложений.

> О. Вот тут и начинается дизайн приложения. И то что ты привык к кривому
> дизайну удерживающему ресурсы очень долго еще не значит, что нельзя по
> другому.
Где тут плохой дизайн? Можно объяснить?

> В дотнете есть прицип. Держи ресурсы только если они тебе нужны и пока
> они тебе нужны. Тот же файл можно и повтоно открыть. Или считать все что
> нужно из файла и забыть про него.
Это из-за кривости системы. Зря открывать/закрывать файлы — зря тратить
время.

> Ведь невооруженным взглядом видно, что развитие идет в сторону
> надежности и безопасности.
С# надежен не более, чем С++ когда дело заходит о работе с внешними
ресурсами.

> Думаю, что С++ — это псоледний не типобезопасный язык завоявавший популрность.
С++ — типобезопасен, причем намного больше, чем C#. Только вот в С++
можно обойти систему безопасности типов при желании.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

O>Ошибаешься. Поскольку на сам родительский класс ссылок нету, то и на someClass их уже неду (из объектов, на которые никто не ссылается, ссылки не считаются). Почитал бы про GC.

Есть, есть. Наличие финалайзера заставляет положить ссылку на объект сначала в очередь финализации, а потом в freachable-очередь (как раз ее читает поток финализации чтобы вызвать финалайз для объектов). Вот как раз freachable и является корнем ЖЦ.

PC>>Почему не меняют адрес виртуальной функции?

Эт не правильно

Derived части ж нет....

O>Опять ошибаешься — она есть, т.к. объект собирается не по частям, а целиком.

Ага. Я бы даже ответил проще. Как же можно поменять адрес виртуальной функции у объекта? Ведь она же виртуальная!

У объекта этого класса других в общем-то и нет.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>Это все вершина айсберга... копни по глубже... ИМХО косяк во всем CLI...

Нет уж, извольте. Если метод виртуальный, то логично, что он всегда вызывается через vtbl. Иначе дизайн C# стал бы более ... неочевидным, что ли.

Кстати, причём тут CLI? В данном случае именно компилятор вполне может вставить call вместо callvirt, если вызов происходит из "деструктора" (из Finalize). Только вот ихмо это было бы неправильно.

Если ты об этом, конечно.

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

O>Здравствуйте, Pavel Chikulaev, Вы писали:

PC>>Это все вершина айсберга... копни по глубже... ИМХО косяк во всем CLI...

O>Нет уж, извольте. Если метод виртуальный, то логично, что он всегда вызывается через vtbl. Иначе дизайн C# стал бы более ... неочевидным, что ли.

O>Кстати, причём тут CLI? В данном случае именно компилятор вполне может вставить call вместо callvirt, если вызов происходит из "деструктора" (из Finalize). Только вот ихмо это было бы неправильно.

O>Если ты об этом, конечно.

ИМХО

В CLI нет ООП. А именно:
Пусть у нас есть Base и Derived : Base. В CLI отношения "is-a" в момент разрушения/удаления/собирания объектов, т.к. подобъект Base не является Base, Derived части уже нет, а объект все еще является Derived, и соответственно виртуальные функции могут обращаться к данным которых уже нет.

Вопрос:
Зачем так сделали? Я просто не понимаю...

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

PC>gcroot на someclass есть, пока не вызван finalizer (или ошибаюсь?)

Ошибаешься. Поскольку на сам родительский класс ссылок нету, то и на someClass их уже неду (из объектов, на которые никто не ссылается, ссылки не считаются). Почитал бы про GC.

PC>Почему не меняют адрес виртуальной функции?

Эт не правильно

Derived части ж нет....

Опять ошибаешься — она есть, т.к. объект собирается не по частям, а целиком.

В общем, дьявол в дизайне

Например, я могу написать так:

class Base
{
    public string X = "Hello!";
    
    ~Base()
    {
        int y = X.Length;
    }
}

class Derived : Base
{
    ~Derived()
    {
        X = null;
    }
}

Что дальше?

PC>Да я знаю

Давай в Derived::~Derived() напишу someClass.Dispose()... тогда как?

Ну так писать нельзя — я уже говорил, по-моему, т.к. в этот момент Finalize() уже мог быть вызван для someClass и неизвестно, что у него там с состоянием. Повторюсь — хорошенько почитай про Dispose Pattern и пойми, что чужой Dispose из Finalize вызывать нехорошо, т.к. из Finalize освобождаются только unmanaged ресурсы.

PC>Эт реализация, мне надо общее, стандартное.

(Я из форума С++, а там любят стандарт и ссылки).

Тут я промолчу, т.к. не читал стандарт.

PC>Implementation-defined

Ужас

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

C>>Hint: у Dispose семантика фактически такая же, как у С++ного деструктора.
O>Совершенно не такая же — Dispose не удаляет объект (вот оно — главное отличие), он освобождает (или не освобождает) ресурсы, и никаких гарантий нам вызов Dispose в общем случае не даёт.
+1

C>>Это бред. В С++ объекты (даже со сложным деревом множественного
C>>наследования) выделяются одним куском. Лишней косвенности тоже непонятно
C>>откуда взяться.
O>А вот и не бред

O>На данный момент в CLI объекты reference-типа хранятся в куче. Каждый объект хранится в куче отдельно. Предложенная модификация повлечёт за собой изменение способа конструирования/хранения/сбора объектов — оно надо?
Чуть изменить GCHandle и все будет легко...

O>Насчёт лишней косвенности:
O>

O>class Derived
O>{
O>    Base b;
    
O>    // Интерфейс Base как бы надо сохранить
O>    virtual void M()
O>    {
O>        // Насчёт дополнительных косвенных вызовов
O>        b.M();
O>    }
O>    virtual void N()
O>    {
O>    }
O>}
O>

Ужас... А и не знал, что у меня в С++ такая косвенность....

O>Точно — чего-то мне smart pointers в C# не хватает

RAII, smart_ptr лишь способ

O>Дело в том, что в C# сложные вещи можно делать проще и чего-то совершенно не тянет делать их очень сложно

Ага std::set как?

O>PS: ты забыл предложить перенести BOOST на C#

А то как же тут без него?

язык простой слишком

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

PC>Ага std::set как?

PowerCollections. В FCL, как и в C++ Standard Library, не всё имеется изначально.

PC>язык простой слишком

Oyster wrote:
> Ну не нравится мне твоё решение Не вижу я, каким образом "автоматические
> объекты" помогут делу освобождения ресурсов. Уже сейчас можно делать
> детерминированную сборку ресурсов, юзая Dispose Pattern.
Dispose Pattern не помогает, если ресурс кладется в поле объекта.

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

> Кроме того, сейчас я не вижу, как именно предлагается реализовать эти
> самые "автообъекты". Детали какие-то есть в обсуждении, а общей картинки
> уловить не могу. Может, подробно опишешь? Типа как это будет работать +
> примеры кода.
Берем С++, пример обертки для файла:

class FileHandle
{
    HANDLE nativeHandle;
public:
    //Конструируем по имени
    FileHandle(string filename)
    {
        nativeHandle=OpenFile(filename);
    }
    //Копирующий конструктор (пока забудем про
    //оператор присваивания)
    FileHandle(const FileHandle &_other)
    {
        nativeHandle=DuplicateHandle(_other.nativeHandle);
    }
    //Деструктор
    ~FileHandle()
    {
        CloseHandle(nativeHandle);
    }

    void ReadFile(...);
    void WriteFile(...);
};

Использовать очень просто:

void someFunc()
{
    FileHandle blah("c:\\...");
    blah.Read(...);
//Деструктор выполнится автоматически при выходе из блока,
//в том числе и при броске исключений. По сути, это Dispose-паттерн.
}

FileHandle getLogFile()
{
    string logName=...;
    FileHandle res(logName);
    return res;
//В 'return res' происходит создание ЕЩЕ одного объекта FileHandle
//и вызова у него копирующего конструктора. При это создается _копия_
//объекта 'res'. Затем исходный объект 'res' уничтожается - вызывающий
//получает временный объект FileHandle.
}

//Структура с двумя файлами, деструктор генерируется автоматически,
//в нем происходит вызов деструкторов членов.
struct TwoFiles
{
    FileHanlde one, two;
};
TwoFiles someFunc5()
{
    TwoFiles res;
    res.one=getLogFile();
    res.two=FileHandle("c:\\...");
    return res;
}

//Используем
FileHandle some;
{
    TwoFile fl=someFunc5();
    some=fl.one;
}

Можно еще более сложные примеры приводить. Первый случай использования —
по сути тот же Dispose-паттерн, но вот остальные не имеют аналогов в C#.

Лучше всего это сейчас сделано в D:
http://www.digitalmars.com/d/memory.html (см. секцию про RAII)

> А ещё меня пугает то, что вместо свободы действий ты предлагаешь
> наложить дополнительное ограничение.
Да, именно дополнительное ограничение, чтобы можно было отлавливать
болье ошибок еще на этапе компиляции.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

PC>В CLI нет ООП.

ЕэсссЪ! Это же разоблачение века!!!

Кстати, под CLI ты что понимашь? Может лучше применять или термин C++/CLI (от же МС++2) или CLR, а то CLI очень уж свободный термин.

PC> А именно:
PC>Пусть у нас есть Base и Derived : Base. В CLI отношения "is-a" в момент разрушения/удаления/собирания объектов, т.к. подобъект Base не является Base, Derived части уже нет, а объект все еще является Derived, и соответственно виртуальные функции могут обращаться к данным которых уже нет.

Знашь, я не знаю кто такой "подобъект Base", но я точно знаю, что в CLR нет понятия деструктора и детерминированной финализации. CLR просто позволяет вызвать метод объекта с сигнатурой

virtual void Finalize();

А то что в Шарпе синтаксис похож на конструктор и производится неявный вызов финализатора базового класса — это всего лишь реализация встроенная в Шарп. Видимо не хотели напугать С++-ников радикальным отличием идеологии. Вот только она все равно радикально другая. Так что попытка явно неудачная.

Финализатор всегда вызвается у неразрушенного объетка. Более того. В CLR вообще нет понятия разрушения объекта! Темболее в нем нет понятия последовательного разрушения. Объект или есть, или нет. Объект есть если на него есть хотя бы одна ссылка. И объекта нет если на него нет ссылок. Других приципов нет. И это нужно просто понять. Ну, другая идеология. С глаз долой — из сердца вон.

Кстати, совершенно бессмысленно вызвать Dispose-ы вложенных объектов из финалайзера. Все равно финалайзер вызывается истемой. Так что как тут правильно сказали рядом "курите паттерн диспоз". Ну, для тех кто вкурить неможет придумали исключение. При неправильной логике ты просто получишь исключение, проанализируешь колстэк и поймешь в чем был неправ. Это моло чем отличается от банального повторного вызова деструктора.

PC>Вопрос:
PC>Зачем так сделали? Я просто не понимаю...

Причины две. Первая — хотели уйти от той прорвы граблей которое С++ подарил миру. Вторая — за каким-то лешим все же хотели чтобы синтаксис финилизаторов походил на С++-ный. Мне кажется, правильно было бы не косить под С++-ные деструкторы и не "помогать народу". Нужно было сделать как в Васике — позволить реализовывать финалайзеры и переопределять их с помощью банального ovveride. Тогда и вопроса бы не возникло. Ведь просто вызывается виртуальный метод.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

C>Dispose Pattern не помогает, если ресурс кладется в поле объекта.

Это с чего же? Может просто понять, что ресурс лежащий в поле уже является обернутым финалайзером? Знаешь, что это значит? Это значит, что даже если ты не сделашь финалайзер у внешнего объекта или сделашь, но забудеш в нем дернуть некий диспоз, то все равно в момент когда умрет этот внешиний объект умрет и вложенный объект. А это значит, что у вложенного объекта вызовится финалайзер.

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

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

Да? Можно примеры? А то вот у меня на работу с неуправляемыми ресурсами в программах тратится где-то 0.1% уселий и кода.

C>//Структура с двумя файлами, деструктор генерируется автоматически,
C>//в нем происходит вызов деструкторов членов.
C>struct TwoFiles
C>{
C> FileHanlde one, two;
C>};
C>TwoFiles someFunc5()
C>{
C> TwoFiles res;
C> res.one=getLogFile();
C> res.two=FileHandle("c:\\...");
C> return res;
C>}

О. Вот тут и начинается дизайн приложения. И то что ты привык к кривому дизайну удерживающему ресурсы очень долго еще не значит, что нельзя по другому.

В дотнете есть прицип. Держи ресурсы только если они тебе нужны и пока они тебе нужны. Тот же файл можно и повтоно открыть. Или считать все что нужно из файла и забыть про него.

C>Лучше всего это сейчас сделано в D:
C>http://www.digitalmars.com/d/memory.html (см. секцию про RAII)

D — это тупиковая ветвь эволюции. Будь в нем RAII или еще что в сто раз лучше чем где-бы то нибыло, но язык этот проиграл еще будучи в проекте. Ведь невооруженным взглядом видно, что развитие идет в сторону надежности и безопасности. Думаю, что С++ — это псоледний не типобезопасный язык завоявавший популрность. Единственно почему люди отказыаются от безопасности — это скорость. Так вот этот аргумент все эфемернее и эфемернее. Ведь уже сейчкас текущие реализации безопасных языков показывают очень нехилые результаты. А учитывая количество ислледований посвященных устранению оверхэда вызваемого безопасностью с уверенностью можно сказать, что в будущем эта проблема исчезент вовсе.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

VD>Здравствуйте, Pavel Chikulaev, Вы писали:

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

PC>>[snipped]
PC>>Ок. Тогда попробуй объяснить почему не происходит смена динамического типа после вызова Derived::Finalize и/или Derived::IDisposable::Dispose ? Где логика. Некоторые Derived части могут быть измененены\удалены...

VD>Прикольно. Давай ты сам попробушь ответить на этот вопрос. Только я тебе его перепишу на С++:
Finalize не простая виртуальная функция — у нее другая семантика и переписывать на С++ ее нет смысла... Не убедил.

VD>Почему не не происходит смена динамического типа после вызова Derived::Finalize?
VD>Только не надо говорить, что Finalize вызывается не из деструктора. ОК? Ведь в дотнете и C# вообще нет деструкторов.
П. 5. Я знаю!! Млин я не второй день про дотнет читаю... Я два года на нем пишу... Но вашего фанатизма пока не разделяю...

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

PC>П. 5. Я знаю!! Млин я не второй день про дотнет читаю... Я два года на нем пишу... Но вашего фанатизма пока не разделяю...

Никакого фанатизма — просто попытки объяснить.

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

O>А нефиг в Finalize обращаться к таким ресурсам — он для освобождения чего-то, что ещё не освобождено, предназначен. И вообще — Dispose лучше вызывать из родительского Dispose, т.к. из Finalize имхо уже немного поздно это делать (курим Dispose pattern).
Это только пример. Я все прекрасно понимаю.

O>В общем, если проектировать правильно, то никаких гвоздей

Это все вершина айсберга... копни по глубже... ИМХО косяк во всем CLI...

17.12.05 05:17: Ветка выделена из темы C++ vs C# and C++/CLI :) Dynamic Type — VladD2

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

PC>ИМХО

Это точно

PC>В CLI нет ООП. А именно:
PC>Пусть у нас есть Base и Derived : Base. В CLI отношения "is-a" в момент разрушения/удаления/собирания объектов, т.к. подобъект Base не является Base, Derived части уже нет, а объект все еще является Derived, и соответственно виртуальные функции могут обращаться к данным которых уже нет.

В CLI нет понятия "подобъект", а есть понятие "подкласс". Объект физически один (а не два — типа Base и типа Derived) и в нём находятся все поля — и базового класса, и производного. Соответственно, часть объекта удалить не получится (да и неправильно это будет — к примеру, не забываем про public/protected поля, доступные наследникам). И я, например, не считаю это "нарушением" ООП.

PC>Вопрос:
PC>Зачем так сделали? Я просто не понимаю...

Потому что в C# (и CLI вообще) наследование реализовано не через аггрегацию объекта базового типа

Главное — следить за дизайном своего кода. Тогда проблем не будет.

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

O>В CLI нет понятия "подобъект", а есть понятие "подкласс". Объект физически один (а не два — типа Base и типа Derived) и в нём находятся все поля — и базового класса, и производного. Соответственно, часть объекта удалить не получится (да и неправильно это будет — к примеру, не забываем про public/protected поля, доступные наследникам). И я, например, не считаю это "нарушением" ООП.

Но ведь:

class Base
{
    ~Base { ... }
    public virtual void foo() { ... };
}

class Derived : Base
{
    ~Derived() { ... }
    public void overide foo() { ... };
    
    SomeClass someClass;
}

Пусть у нас есть

Base b = new Derived;

И в какой-то момент происходит зачистка объекта (Псевдокод):

вызов b.Finalize() который вызвает
    Derived::~Derived()
    gcrootов на someClass нету (или есть?), и он возможно тоже зачищается.
    Base::~Base() который вызывает виртуальную функцию foo. Но почему-то она не меняется на Base::foo.

Я совсем не прав?

O>Потому что в C# (и CLI вообще) наследование реализовано не через аггрегацию объекта базового типа

Ссылку можна в ecma 335? А как?

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

PC>... Я совсем не прав?

Ты перепутал местами строчки. Скорее, так:

gcrootов на someClass нету, и он возможно тоже зачищается.
вызов b.Finalize() который вызвает
  код внутри Derived::~Derived() ("деструктор" на самом деле компилируется в Finalize)
  Base::Finalize() который вызывает виртуальную функцию foo. Но она не меняется на Base::foo, потому что вызов виртуальный

Вызов Finalize означает, что объект (и, соответственно, объекты, которые достижимы только из него) уже никем не держатся и могут очищаться. И никто тебе не гарантирует, что b.Finalize() вызовется раньше, чем someClass.Finalize().

PC>Ссылку можна в ecma 335? А как?

Зачем ссылку? Открой Derived рефлектором и увидишь, что наследник просто содержит все поля базового класса. Кстати, а в C++ разве иначе?

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

PC>... Я совсем не прав?

Ещё одно замечание — в CLI нет деструкторов, есть только метод Finalize(), предназначенный для освобождения ресурсов. Этот метод вызывается GC; соответственно, момент удаления объекта не определён (как в C++, например), равно как и порядок вызова Finalize для объектов.

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

O>Здравствуйте, Pavel Chikulaev, Вы писали:

PC>>... Я совсем не прав?

O>Ты перепутал местами строчки. Скорее, так:
gcroot на someclass есть, пока не вызван finalizer (или ошибаюсь?)

O>

O>gcrootов на someClass нету, и он возможно тоже зачищается.
O>вызов b.Finalize() который вызвает
O>  код внутри Derived::~Derived() ("деструктор" на самом деле компилируется в Finalize) 
знаю
O>  Base::Finalize() который вызывает виртуальную функцию foo. Но она не меняется на Base::foo, потому что вызов виртуальный
O>

Почему не меняют адрес виртуальной функции?

Эт не правильно

Derived части ж нет....

O>Вызов Finalize означает, что объект (и, соответственно, объекты, которые достижимы только из него) уже никем не держатся и могут очищаться. И никто тебе не гарантирует, что b.Finalize() вызовется раньше, чем someClass.Finalize().
Да я знаю

Давай в Derived::~Derived() напишу someClass.Dispose()... тогда как?

PC>>Ссылку можна в ecma 335? А как?

O>Зачем ссылку? Открой Derived рефлектором и увидишь, что наследник просто содержит все поля базового класса.
Эт реализация, мне надо общее, стандартное.

(Я из форума С++, а там любят стандарт и ссылки).

O>Кстати, а в C++ разве иначе?
Implementation-defined

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

O>Здравствуйте, Pavel Chikulaev, Вы писали:

PC>>... Я совсем не прав?

O>Ещё одно замечание — в CLI нет деструкторов, есть только метод Finalize(), предназначенный для освобождения ресурсов. Этот метод вызывается GC; соответственно, момент удаления объекта не определён (как в C++, например), равно как и порядок вызова Finalize для объектов.
Я нигде не сказал слово дтор, да и знаю я это!

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

[snipped]
Ок. Тогда попробуй объяснить почему не происходит смена динамического типа после вызова Derived::Finalize и/или Derived::IDisposable::Dispose ? Где логика. Некоторые Derived части могут быть измененены\удалены...

PC>>Да я знаю

Давай в Derived::~Derived() напишу someClass.Dispose()... тогда как?

O>Ну так писать нельзя — я уже говорил, по-моему, т.к. в этот момент Finalize() уже мог быть вызван для someClass и неизвестно, что у него там с состоянием. Повторюсь — хорошенько почитай про Dispose Pattern и пойми, что чужой Dispose из Finalize вызывать нехорошо, т.к. из Finalize освобождаются только unmanaged ресурсы.
Только для примера!!!

PC>>Эт реализация, мне надо общее, стандартное.

(Я из форума С++, а там любят стандарт и ссылки).
O>Тут я промолчу, т.к. не читал стандарт.
http://www.ecma-international.org/publications/standards/Ecma-335.htm CLI
http://www.ecma-international.org/publications/standards/Ecma-334.htm C#
http://www.ecma-international.org/publications/standards/Ecma-372.htm C++/CLI

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

PC>Ок. Тогда попробуй объяснить почему не происходит смена динамического типа после вызова Derived::Finalize и/или Derived::IDisposable::Dispose ? Где логика. Некоторые Derived части могут быть измененены\удалены...

Ну IDisposable тут вообще ни при чём, т.к. этот интерфейс не является частью рантайма и никоим образом не используется GC (только дёргается из кода напрямую), так что его не трогаем. Note: C++-ник может рассматривать IDisposable как некую замену RAII (грубо говоря) — мы используем IDisposable, когда нам надо обязательно отпустить ресурс по выходу из некоторого блока, а не ждать GC.

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

PC>Только для примера!!!

У меня тоже был пример плохого дизайна, но ведь CLI не виноват в том, что программист педалит плохой дизайн, правда?

PC>http://www.ecma-international.org/publications/standards/Ecma-335.htm CLI

Цитата оттуда специально для тебя (Chapter 8.9.8, p. 41):

The derived class type shall support all of the supported interfaces contracts, class contracts, event contracts, method contracts, and property contracts of its base type. In addition, all of the locations defined by the base type are also defined in the derived type.

И вот ещё цитата (Chapter 8.3, p. 22), чтобы было понятно, что в данном случае location == field:

Values are stored in locations.

Это по поводу "в C# (и CLI вообще) наследование реализовано не через аггрегацию объекта базового типа". Повторюсь — в CLI производный тип просто включает все поля базового.

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

[snipped]
Очевиднее?

Ок. Почему только не ясно. Сообственно это и был исходный вопрос. И чем агрегация базового в наследнике плоха?

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

C>В С++ деструктор тоже не удаляет объект (этим занимается operator
C>delete), а освобождает связанные с объектом ресурсы. Именно этим же и
C>занимается Dispose.

Не совсем. Как раз этим занимается Finalize (гарантия вызова Finalize есть, гарантии вызова Dispose нет).

C>Может быть. Хотя может и стоит изменить семантику хранения.

Да, это прийдётся сделать, если в CLI захочется эффективно хранить N объектов "подряд" (грубо говоря).

C>Вот с множественным наследованием (и интерфейсам) все сложнее.

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

Собственно, именно так сейчас "множественное наследование" и делается в C# — класс наследуется от интерфейса, реализация интерфейса в классе переадресует вызовы внутреннему объекту, содержащему стандартную реализацию интерфейса.

В общем, рассуждать на эту тему можно долго и плодотворно (или неплодотворно). Возвращаясь к теме топика, меня вполне устраивает то, как CLI работает сейчас в случае вызова фиртуальных методов из Finalize — при правильном дизайне проблем с этим не бывает.

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

C>Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
C>серьезных программах. Единственное назначение Finalize — чтобы написаные
C>левой пяткой программы хоть как-то работали.

Ты предлагаешь избавиться от него вообще? Просто я не вижу лучшей альтернативы в CLI, которая среда с GC (Dispose не предлагать — я могу его и не вызвать).

C>Семантический аналог деструктора — это именно Dispose.

Скажем так — в CLI сейчас нет аналога деструктора вообще

Называть Dispose аналогом деструктора в его текущем виде у меня рука не поднимается.

C>Да, было бы неплохо.

Да ну — нафиг надо, на самом деле. Имхо и сейчас всё очень даже хорошо.

C>Но есть интерфейсы — с ними те же проблемы, на самом деле.

Нет, не те же, т.к. у интерфейсов нету состояния. В итоге вопрос с реализацией нескольких интерфейсов достаточно просто разруливается в CLR.

C>Тогда начнутся сложности с иерархией миксинов.

Вот тут я промолчу — сказывается недостаток знаний.

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

C>Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
C>можно было поставить большой матюгальник, если ресурсы не будут закрыты
C>вовремя.

Спорное утверждение. А ежели никто не озаботился вызовом Dispose? А ежели у нас объект долгоживущий, и RAII не получается использовать?

Получаемся, меняем шило на мыло (одно соглашение на другое).

C>Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
C>И это даже не потребует никак изменений в самом CLI — достаточно чтобы
C>компилятор сам оборачивал их в try..finally.

Хочется RAII? Кстати, разве такого в C++/CLI нету?

C>Именно поэтому и нужно их нормально вводить. Идеально было бы ввести
C>автоматические типы с семантикой как в С++ (в том числе и для
C>деструкторов), а остальное можно было бы и не трогать.

См. выше.

C>Я про то, что вызов метода по интерфейсу происходит дольше прямого вызова.

А. Ну да. Я серьёзной проблемой считал проблему поддержания состояний всех наследуемых классов в случае множественного наследования.

Oyster wrote:
> C>Да. Точнее, оставить в качестве отладочного средства — чтобы в Finalize
> C>можно было поставить большой матюгальник, если ресурсы не будут закрыты
> C>вовремя.
> Спорное утверждение. А ежели никто не озаботился вызовом Dispose?
Сразу получит в лоб ассертом (или чем нибудь еще) из финализатора после
первого же запуска.

Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
ресурсы (типа файлов на запись), а потом не закрываются. В результате
ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
на Марсе объект не прибивается GC в первый проход.

> А ежели у нас объект долгоживущий, и RAII не получается использовать?
RAII замечательно используется для долгоживущих объектов — просто надо
ввести понятие конструктора копирования и перемещения.

> C>Вот. Именно поэтмоу нужны автоматические объекты с семантикой как в С++.
> C>И это даже не потребует никак изменений в самом CLI — достаточно чтобы
> C>компилятор сам оборачивал их в try..finally.
> Хочется RAII? Кстати, разве такого в C++/CLI нету?
Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
из всех, что я видел — это язык D.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

C>Сразу получит в лоб ассертом (или чем нибудь еще) из финализатора после
C>первого же запуска.

C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
C>на Марсе объект не прибивается GC в первый проход.

Т.е. если объект реализует IDisposable, для него автоматически генерируется некий код в Finalize? Или он для всех классов автоматически генерируется? Какое огромное поле для неочевидных багов

C>RAII замечательно используется для долгоживущих объектов — просто надо
C>ввести понятие конструктора копирования и перемещения.

Считать ссылки, что ли?

Отличное решение — очень в духе C++

Всё-таки Finalize и Dispose Pattern мне нравятся больше. Или ты полагаешь, что с предложенным тобой решением совершенно не будет геморроя?

C>Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
C>из всех, что я видел — это язык D.

Ты бы тогда и на C# не перешёл, если б там a-la-RAII появилось... и ради кого тогда делать такое изменение?

Oyster wrote:
> C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
> C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
> C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
> C>на Марсе объект не прибивается GC в первый проход.
> Т.е. если объект реализует IDisposable, для него автоматически
> генерируется некий код в Finalize?
НЕТ. Вообще забудьте слово Finalize.

> Или он для всех классов автоматически генерируется? Какое огромное
> поле для неочевидных багов
Все просто — если в классе есть автоматические поля, то они должны быть
освобождены в момент финализации. В автосгенерированом финализаторе это
можно проверять и орать в лог о нарушениях.

> C>RAII замечательно используется для долгоживущих объектов — просто надо
> C>ввести понятие конструктора копирования и перемещения.
> Считать ссылки, что ли? Отличное решение — очень в духе C++
Не обязательно — нужно вспомнить про политики владения: монопольную,
эстафетную, разделяемую и т.п.

> Всё-таки Finalize и Dispose Pattern мне нравятся больше. Или ты
> полагаешь, что с предложенным тобой решением совершенно не будет геморроя?
Оно, по крайней мере, будет детерминированым. В отличие от
финализаторов, которые могут срабатывать в зависимости от погоды на Марсе.

> C>Есть. Но сам C++/CLI пока как-то не очень привлекает. Лучшая реализация
> C>из всех, что я видел — это язык D.
> Ты бы тогда и на C# не перешёл, если б там a-la-RAII появилось... и ради
> кого тогда делать такое изменение?
К сожалению, проекты на C#/Java я тоже пишу.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

[... skipped ...]

Ну не нравится мне твоё решение

Не вижу я, каким образом "автоматические объекты" помогут делу освобождения ресурсов. Уже сейчас можно делать детерминированную сборку ресурсов, юзая Dispose Pattern. Ты же хочешь, чтобы компилятор обязательно следил за тем, чтобы такая сборка происходила, в то время как будет достаточно просто нормального дизайна.

Кроме того, сейчас я не вижу, как именно предлагается реализовать эти самые "автообъекты". Детали какие-то есть в обсуждении, а общей картинки уловить не могу. Может, подробно опишешь? Типа как это будет работать + примеры кода.

А ещё меня пугает то, что вместо свободы действий ты предлагаешь наложить дополнительное ограничение. Боюсь, твоё предложение только сделает дизайн менее гибким, чем сейчас (впрочем, могу ошибаться, т.к. самого решения целиком не уловил).

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

PC>gcroot на someclass есть, пока не вызван finalizer (или ошибаюсь?)

Он есть до тех пор пока объект жив. То есть все время пока вызвается финалайзер. И не факт, что не останется после него. Так что любые предположения о жизни объектов на основании того вызван финалайзер или нет не верны.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

O>А чем она хороша, особенно в managed environment? Иметь 10 объектов в куче вместо одного — просто замечательная идея

Ещё и косвенные вызовы появляются — тоже супер. И я просто не знаю, как бы в таком случае работал reflection или сериализация...

Кстати, С++-компиляторы тоже никаких левых объектов не создают, а "изменение адресов" просто эмулируется. И вообще, уж где ООП точно пока нет, так это в x86-ассемблере.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

O>>На данный момент в CLI объекты reference-типа хранятся в куче. Каждый объект хранится в куче отдельно. Предложенная модификация повлечёт за собой изменение способа конструирования/хранения/сбора объектов — оно надо?
PC>Чуть изменить GCHandle и все будет легко...

Ого! Ну, ты дал. Ты уверен что четко понимашь, что такое GCHandle?

O>>Точно — чего-то мне smart pointers в C# не хватает

PC>RAII, smart_ptr лишь способ

Для RAII как раз и придуманы IDisposable и using.

O>>Дело в том, что в C# сложные вещи можно делать проще и чего-то совершенно не тянет делать их очень сложно

PC>Ага std::set как?

И в чем с ним проблема?

O>>PS: ты забыл предложить перенести BOOST на C#

А то как же тут без него?

PC>язык простой слишком

Ага. Ошибок почти нет. Приходится сильно напрягаться чтобы жизнь не стала скучной.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

C>Finalize вообще надо в морг отправить. Абсолютно неюзабельная вещь в
C>серьезных программах.

Ой, а можно список несерьезных программ?
Вот наш сайт серьезная программа? Я вот сейчас глянул, а там по статистики постянно появляются выжившие в результате финализации объекты. Прикино, что было бы если они все привращались в потери неуправляемых ресурсов?

C> Единственное назначение Finalize — чтобы написаные
C>левой пяткой программы хоть как-то работали.

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

C>Семантический аналог деструктора — это именно Dispose.

Диспоз — это паттерн. И в его полную версию входит использования финализатора. Так что симантических аналогов деструкторов в дотнете нет.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
C>на Марсе объект не прибивается GC в первый проход.

Примеры подобных проблем в реальной жизни можно привести?

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

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

VD>Здравствуйте, Pavel Chikulaev, Вы писали:

PC>>В CLI нет ООП.

VD>ЕэсссЪ! Это же разоблачение века!!!

VD>Кстати, под CLI ты что понимашь?
As described in ECMA 335
VD>Может лучше применять или термин C++/CLI (от же МС++2) или CLR, а то CLI очень уж свободный термин.
Нет именно так. А С++/CLI == MC++2 это ерунда полная/

PC>> А именно:
PC>>Пусть у нас есть Base и Derived : Base. В CLI отношения "is-a" в момент разрушения/удаления/собирания объектов, т.к. подобъект Base не является Base, Derived части уже нет, а объект все еще является Derived, и соответственно виртуальные функции могут обращаться к данным которых уже нет.

VD>Знашь, я не знаю кто такой "подобъект Base", но я точно знаю, что в CLR нет понятия деструктора и детерминированной финализации. CLR просто позволяет вызвать метод объекта с сигнатурой
VD>

VD>virtual void Finalize();
VD>

VD>А то что в Шарпе синтаксис похож на конструктор и производится неявный вызов финализатора базового класса — это всего лишь реализация встроенная в Шарп. Видимо не хотели напугать С++-ников радикальным отличием идеологии. Вот только она все равно радикально другая. Так что попытка явно неудачная.
Читай мои посты внимательно. Я знаю! П. 5

VD>Финализатор всегда вызвается у неразрушенного объетка. Более того. В CLR вообще нет понятия разрушения объекта! Темболее в нем нет понятия последовательного разрушения. Объект или есть, или нет. Объект есть если на него есть хотя бы одна ссылка. И объекта нет если на него нет ссылок. Других приципов нет. И это нужно просто понять. Ну, другая идеология. С глаз долой — из сердца вон.
Т.е. дыра есть и ты ее не отрицаешь?

VD>Кстати, совершенно бессмысленно вызвать Dispose-ы вложенных объектов из финалайзера. Все равно финалайзер вызывается истемой. Так что как тут правильно сказали рядом "курите паттерн диспоз". Ну, для тех кто вкурить неможет придумали исключение. При неправильной логике ты просто получишь исключение, проанализируешь колстэк и поймешь в чем был неправ. Это моло чем отличается от банального повторного вызова деструктора.
Syntetic example. Я мог вызвать любой другой метод, делающий какие-то не обратимые последствия.

VD>Причины две. Первая — хотели уйти от той прорвы граблей которое С++ подарил миру.
Перечисли а...? С этим в C++ точно все нормально. Другие проблемы безусловно есть, как и в других языках.

VD>Вторая — за каким-то лешим все же хотели чтобы синтаксис финилизаторов походил на С++-ный. Мне кажется, правильно было бы не косить под С++-ные деструкторы и не "помогать народу". Нужно было сделать как в Васике — позволить реализовывать финалайзеры и переопределять их с помощью банального ovveride. Тогда и вопроса бы не возникло. Ведь просто вызывается виртуальный метод.
+1 или !T()

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

VD>>Кстати, под CLI ты что понимашь?
PC>As described in ECMA 335

А. Ну, учти, что CLR не полностью с этим стандартом совместим.

PC>Нет именно так. А С++/CLI == MC++2 это ерунда полная

Во оно как?

PC>Читай мои посты внимательно. Я знаю! П. 5

Тогда зачем сравнивать несравнимые сущьности? Зачем говоришь о неком мифическом разрушении объекта в финализаторе?

VD>>Финализатор всегда вызвается у неразрушенного объетка. Более того. В CLR вообще нет понятия разрушения объекта! Темболее в нем нет понятия последовательного разрушения. Объект или есть, или нет. Объект есть если на него есть хотя бы одна ссылка. И объекта нет если на него нет ссылок. Других приципов нет. И это нужно просто понять. Ну, другая идеология. С глаз долой — из сердца вон.
PC>Т.е. дыра есть и ты ее не отрицаешь?

Какая дыра? Где дыра? Фуууххх...

PC>Syntetic example. Я мог вызвать любой другой метод, делающий какие-то не обратимые последствия.

Ты вообще можешь исключения направо и налево кидать. Или деление на ноль делать. Вот только что это доказывает?

VD>>Причины две. Первая — хотели уйти от той прорвы граблей которое С++ подарил миру.
PC>Перечисли а...?

А поиском слабо воспользоваться? Здеь эта тема уже двадцатая наверно. Попробуй вот так http://rsdn.ru/search/?q=%E3%F0%E0%E1%EB%E8+C%2B%2B&mode=rank&group=N

PC> С этим в C++ точно все нормально. Другие проблемы безусловно есть, как и в других языках.

С чем? Зайди в форум по С++ и погляди сколько там вопросв и непонимания в этих вопросах.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>>П. 5. Я знаю!! Млин я не второй день про дотнет читаю... Я два года на нем пишу... Но вашего фанатизма пока не разделяю...

O>Никакого фанатизма — просто попытки объяснить.

Скорее небольшое раздражение от тщетности сего занятия. Позиция ведь уже выбрана. Человек все знает. Общая идея:
1. Все должно быть как в С++.
2. Если это не так, то это не верно.
3. Если с чем-то не согласны см. п. 1.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PC>Я конечно понмаю, что модераторские права развязывают руку, но тема тут одна...
PC>Я лишь очень не согласен с тем как это реализовано в дотнете...

Вопросы модерирования обсуждаются на moderatoe@rsdn.ru

От себя замечу, что обсуждение CLI, а точнее GC и CLR никак не вписывается в рамки заявленной темы "C++ vs C# and C++/CLI".

... << RSDN@Home 1.2.0 alpha rev. 620>>

VladD2 wrote:
> C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
> C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
> C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
> C>на Марсе объект не прибивается GC в первый проход.
> Примеры подобных проблем в реальной жизни можно привести?
Вот примерчик:

MANAGED_PUBLIC class RSIDLLPP_API CRsiComBase : public CRsiWaitObject
{
    public:
        CRsiComBase();
        virtual ~CRsiComBase();
#ifdef DOT_NET
        !CRsiComBase();
        BOOL SetName(String* name);    // Associates a name with the service 
represented by this object.
        String* GetName() { return m_sName; }    // Obtains the name of the 
service represented by this object.
#else
        BOOL SetName (char*);    // argument is copied to new storage
#ifndef WIN_CE
        LPCTSTR GetName() { return m_szName; }
#else
        char* GetName() { return m_szName; }

Библиотека для работы со сканерами геометрии руки HandPunch.

Все бы ничего, да только драйвера не держат более 256 соединений
одновременно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 2.0

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

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

PC>[snipped]
PC>Ок. Тогда попробуй объяснить почему не происходит смена динамического типа после вызова Derived::Finalize и/или Derived::IDisposable::Dispose ? Где логика. Некоторые Derived части могут быть измененены\удалены...

Физическое размещение объекта в памяти выбирается имплементацией. Ничего нельзя никуда подменить в общем случае. Да, кстати, ссылка на класс в каждом объекте полностью и однозначно описывает все, даже количество памяти, занимаемое объектом. Т.е. они таким образом избывились от оверхеда операций по выделению освобождению памяти

O>>Ну так писать нельзя — я уже говорил, по-моему, т.к. в этот момент Finalize() уже мог быть вызван для someClass и неизвестно, что у него там с состоянием. Повторюсь — хорошенько почитай про Dispose Pattern и пойми, что чужой Dispose из Finalize вызывать нехорошо, т.к. из Finalize освобождаются только unmanaged ресурсы.
PC>Только для примера!!!

Да ничего не будет. Ексепшены глотаются при GC, хотя и притормаживают его.

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

C>Представьте себе, я прекрасно понимаю, что GC абсолютно и глубоко пофиг
C>где лежал объект до своей смерти.

Речь шала не о том.

C>Я говорю о том, что надеятся на GC для удаления внешних ресурсов —
C>ненадежно.

Надеяться на него никто и не заставляет. Реализуй диспоз и пользуйся юсингом. Тебе говорят о том, что это отличная подстраховка в большинстве случаев устраняющая фатальные в ином случае ошибки.

>> Иначе бы любой массив обязан был бы реализовывать разные диспозы и
>> вызывать их у всех вложенных объектов. А вдруг у них есть диспоз?
C>И это правильно.

С твоей, навазанной плюсами, точки зрения.

>> Да? Можно примеры? А то вот у меня на работу с неуправляемыми ресурсами
>> в программах тратится где-то 0.1% уселий и кода.
C>В основном потому, что на C# как раз и пишутся в основном программы, где
C>управление ресурсами некритично (а часто и вообще ненужно). Типа
C>веб-серверов, серверов приложений и простых десктопных приложений.

Конечно, конечно. Важны только те приложения которые пишешь ты. Остальные занимаются фигней. Ну, подумашь там глючная бухгалтерия. Главное, чтобы она не глючила у твоего оператора сотовой связи.

C>Где тут плохой дизайн? Можно объяснить?

Дизайн в котором производится долгое удержание разделяемых ресурсов принципиально плохой дизайн. А дизайн в котором надежность зависит от внимательности программиста в двойне плохой дизайн. По этому ресурсами лучше поручать управлять автоматике. Или хотя бы подстраховываться автоматикой когда рушишь ресурсами вручную.

>> В дотнете есть прицип. Держи ресурсы только если они тебе нужны и пока
>> они тебе нужны. Тот же файл можно и повтоно открыть. Или считать все что
>> нужно из файла и забыть про него.
C>Это из-за кривости системы. Зря открывать/закрывать файлы — зря тратить
C>время.

Это из-за разумности архитекторов.

>> Ведь невооруженным взглядом видно, что развитие идет в сторону
>> надежности и безопасности.
C>С# надежен не более, чем С++ когда дело заходит о работе с внешними
C>ресурсами.

Держите меня семеро.

В С++ не нужно говорить о работе с внешними ресурсами. Память для этого языка первеший ресусрс. И весь контроль за этим ресурсом целиком и полностю лежит на программисте. Все смарт-указатели и прочая лабуда не более чем костыли то и дело вылетающие из рук.

Понимаш ли. В средней программе используется 2-50 ресурсов ОС и моря объектов. Управиться с пятьюдесятью респсами можно и без костылей. Ну, или с простенькими костылями вроде юсингов (и то лучше подстраховаться теми же финалайзерами), а вот управляя миллионами ресурсов ошибиться настолько просто, что серьезная система на С++ просто не мыслима без автоматизированного тестирования и серьезных заморочек на проработке политики владения. А это геморрой и ошибки.

C>С++ — типобезопасен, причем намного больше, чем C#. Только вот в С++
C>можно обойти систему безопасности типов при желании.

К спору на таком уровне я не готов. Извини, но спорить с теми кто спорит с очевидными вещами я не намерен. Это пустая трата времени. Разберись сначало что такое типобезопасность и какие языки отвечают ее требованиям, а какие нет.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

C>VladD2 wrote:
>> C>Просто сейчас УЖЕ есть куча программ, в которых открываются критичные
>> C>ресурсы (типа файлов на запись), а потом не закрываются. В результате
>> C>ошибки вылавливаются в production'е, когда из-за какой-то смены погоды
>> C>на Марсе объект не прибивается GC в первый проход.
>> Примеры подобных проблем в реальной жизни можно привести?
C>Вот примерчик:
C>

C>MANAGED_PUBLIC class RSIDLLPP_API CRsiComBase : public CRsiWaitObject
C>{
C>    public:
C>        CRsiComBase();
C>        virtual ~CRsiComBase();
C>#ifdef DOT_NET
C>        !CRsiComBase();
C>        BOOL SetName(String* name);    // Associates a name with the service 
C>represented by this object.
C>        String* GetName() { return m_sName; }    // Obtains the name of the 
C>service represented by this object.
C>#else
C>        BOOL SetName (char*);    // argument is copied to new storage
C>#ifndef WIN_CE
C>        LPCTSTR GetName() { return m_szName; }
C>#else
C>        char* GetName() { return m_szName; }
C>

C>Библиотека для работы со сканерами геометрии руки HandPunch.

C>Все бы ничего, да только драйвера не держат более 256 соединений
C>одновременно.

1. Это твоя личная проблема возникшая при программировании на С++ Ты же тут пел песни кро ЖЦ и дотнет. Так вот я тебе и просил привести пример таких проблем. И не где попало, а в том, на что ты катишь бочку.
2. В упро не вижу тут проблемы. 256 соеденений это огромное количество. Сделай пул соеденений и вызов ЖЦ если их не хватет. Это полностью застрахует от нехватки соеденений. Конечно при условии, что у тебя не окажется случая когда все 256 соеденений будут задействованы по делу. Но и тут не трудно выкрутиться ожидая возврата соеденения в пул если их количество привысило предельно допустимое.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

C>VladD2 wrote:
>> Ой, а можно список несерьезных программ?

>> Вот наш сайт серьезная программа?
C>Простите, но нет. От падения RSDN на пару часов никто не пострадает и не
C>потеряет кучу бабок.

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

>> Я вот сейчас глянул, а там по статистики постянно появляются
>> выжившие в результате финализации объекты. Прикино, что было
>> бы если они все привращались в потери неуправляемых ресурсов?
C>А что прикидывать-то? RSDN у меня с завидной переодичностью глючит.

Видмо ты особенный.

Ну, да если даже так. Глючит не висит. Да и глюки не обязательно связаны с потерей ресурсов. Вернее даже почти наверняка не связаны.

C>Кроме того, веб сайт — это как раз пример того, где не так уж и важно
C>нормальное обращение с неуправляемыми ресурсами.

Да? Ну, ну. Если у тебя вылитит какой-нибудь десктоп, то ты его презапустишь. А если ляжет сервер, то люди могут ждать его поднятия сутки. Финалайзеры позволяет сайту работать без каких либо проблем. Если бы их небыло, то сайт просто лег бы. И делал бы это с завидной переодичноитью.

>> C> Единственное назначение Finalize — чтобы написаные
>> C>левой пяткой программы хоть как-то работали.
>> Это у кого как. У кого как ты говоришь, а у кого для облегчения слежения
>> за ресурсами и чтобы пара мелких ошибок не приводила к остановке работы
>> критически важных приложений.
C>Ну да, пара мелких ошибок тут, пара мелких ошибок там....

Во-во. И твоя программа ляжет. Причем до тех пор пока ты не вычистишь эти мелкие ошибки она будет преодически ложиться. Хорошо если без потери данных.

C>Я достаточно долго занимался одной программой на Java, где
C>использовались мои JNI-обертки. Финализаторы тоже использовались — в них
C>стоял такой код:
C>

C>void finalize()
C>{
C>    if (objectHandle!=0)
C>    {
C>        System.err.println("UNFINALIZED OBJECT! Created at:");
C>        creationStackTrace.printStackTrace();
C>    }
C>}
C>

C>creationStackTrace создавался в конструкторе оьъекта. Сначала наши
C>Java-программисты пищали, что это типа неудобно и GC — наше все, но
C>потом (после того, как отловили кучу ошибок) стали применять такой трюк
C>в своих объектах.

Не спорю. В неоторых случаях такой подход оправдан. В большинстве же — нет. Тут еще отдельный вопрос, что за ошбики у вас там были? Может чем ловить ошибки на юзверях лучше было подрихтвать твоей JNI? Или вообще выкинут его?

C>Финализатор — это кривая подпорка. А деструкторы в С++ — это тоже
C>паттерны, кстати.

Интересная оговорка. Финалазеры — подпорка. А деструкторы — паттерн.

Я не спорю. Финалайзеры действительно подпорка. Но подпорка автоматическая. Ее сломать не так то просто. А вот деструкторы это никакой не паттерн. Это функциональность языка. Паттерн вмонтированный в язык — уже его часть. Но это тут не причем. Проблем у деструкторов две а) они нужны не только для управления ресурсами но и для контроля памяти, б) у них нет автоматической подпорки вроде финалайзеров.

... << RSDN@Home 1.2.0 alpha rev. 620>>

От:	Oyster	https://github.com/devoyster
Дата:	15.12.05 14:58
Оценка:	23 (1) +1

	От:	Cyberax
	Дата:	17.12.05 12:58
	Оценка:	+2 -1

От:	VladD2	www.nemerle.org
Дата:	17.12.05 01:43
Оценка:	7 (2)

От:	Oyster	https://github.com/devoyster
Дата:	15.12.05 14:29
Оценка:	6 (1) -1

	От:	Cyberax
	Дата:	15.12.05 14:42
	Оценка:	3 (1) -1

	От:	Pavel Chikulaev
	Дата:	15.12.05 14:53
	Оценка:	+1