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

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

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

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

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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++ точно все нормально. Другие проблемы безусловно есть, как и в других языках.

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>можно обойти систему безопасности типов при желании.



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

Здравствуйте, 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 соеденений будут задействованы по делу. Но и тут не трудно выкрутиться ожидая возврата соеденения в пул если их количество привысило предельно допустимое.

Здравствуйте, 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>паттерны, кстати.

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

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

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

+1

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

-1