C++ vs C# and C++/CLI :) Dynamic Type
От: Pavel Chikulaev Россия  
Дата: 15.12.05 11:15
Оценка: :)
Я в шоке Читаю стандарт С# и С++/CLI.

Первые две программы выводят Derived::foo, третья выводит Base::foo.

Глубоко обежден, что поведение C++ (третья) правильное, однако интересно услышать мнение почему так сделано в CLI.
Программа C#
class Base
{
    ~Base()
    {
         foo();
    }

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

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

class Program
{
    public static void Main()
    {
        Base b = new Derived;
        b = null;
        GC.Collect();
    }
}


Программа на C++/CLI:
ref struct Base
{
    ~Base()
    {
        foo(); 
    }

    virtual void foo()
    {
        Console::WriteLine("Base::foo");
    }
};

ref struct Derived : Base
{
    virtual void foo() override
    {
        Console::WriteLine("Derived::foo");
    }
};

int main()
{
    Base ^ b = gcnew Derived;
    delete b;
}


Программа на C++:
struct Base
{
    ~Base()
    {
        foo(); 
    }

    virtual void foo()
    {
        
    }
};

struct Derived : Base
{
    virtual void foo()
    {
        std::cout << "Derived::foo" << std::endl;
    }
};

int main()
{
    Base * b = new Derived;
    delete b;
}


А если Derived::foo обращается к каким-то ресурсам которые уже удалены.... А говорят verifiable....
class Base
{
    ~Base()
    {
         foo();
    }

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

class Derived : Base
{
    Derived () { ... }

    ~Derived ()
    {
        o.Dispose();
    }
    public overide void foo()
    {
        o.HelloWorld();
        Console.WriteLine("Derived::foo");
    }

    DisposableObject o;
}

class Program
{
    public static void Main()
    {
        Base b = new Derived;
        b = null;
        GC.Collect(); //тыдыж!!!! :(
    }
}


ЗЫ Я знаю разницу между Finalizerом и деструктором Так меньше писать.
Re: C++ vs C# and C++/CLI :) Dynamic Type
От: BitField Украина http://lazy-bitfield.blogspot.com
Дата: 15.12.05 11:54
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Я в шоке Читаю стандарт С# и С++/CLI.


PC>Программа на C++:

PC>
PC>struct Base
PC>{
PC>    virtual ~Base()
PC>    {
PC>        foo(); 
PC>    }

PC>    virtual void foo()
PC>    {
        
PC>    }
PC>};

PC>struct Derived : Base
PC>{
PC>    virtual void foo()
PC>    {
PC>        std::cout << "Derived::foo" << std::endl;
PC>    }
PC>};

PC>int main()
PC>{
PC>    Base * b = new Derived;
PC>    delete b;
PC>}
PC>



Стандартные хорошо описанные грабли С++. Правило KISS -- если структуре не нужен виртуальный деструктор -- зачем компилятору его самостоятельно прикручивать?
Re[2]: C++ vs C# and C++/CLI :) Dynamic Type
От: Pavel Chikulaev Россия  
Дата: 15.12.05 11:57
Оценка:
Здравствуйте, BitField, Вы писали:

BF>Стандартные хорошо описанные грабли С++. Правило KISS -- если структуре не нужен виртуальный деструктор -- зачем компилятору его самостоятельно прикручивать?


Сорри безусловно дтор virtual.

copy & paste
Re: C++ vs C# and C++/CLI :) Dynamic Type
От: Oyster Украина https://github.com/devoyster
Дата: 15.12.05 12:19
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

[... skipped ...]

PC>А если Derived::foo обращается к каким-то ресурсам которые уже удалены.... А говорят verifiable....


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

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

[... skipped ...]
Re: Offtopic
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 15.12.05 14:04
Оценка: :)
Здравствуйте, Pavel Chikulaev, Вы писали:

Ужос!
Отныне настаиваю на изгнании обсуждений C++/CLI со страниц славного форума по C++!
Re[2]: Offtopic
От: Pavel Chikulaev Россия  
Дата: 15.12.05 14:12
Оценка: :)
Здравствуйте, Alxndr, Вы писали:

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


A>Ужос!

Для native типов в С++/CLI все остается по прежнему

Там еще очень много подстав... Статью что-ли написать?

Например:
struct Base
{
    void foo(float) { cout << "float"; }
};

struct Derived : Base
{
    void foo(int)    { cout << "int"; }
};

void bar()
{
    Derived d;

    d.foo(4.35); //ок :)) выведет int
}

ref struct Base2
{
    void foo(float) { cout << "float"; }
};

ref struct Derived2 : Base2
{
    void foo(int)    { cout << "int"; }
};

void bar2()
{
    Derived2 d;

    d.foo(4.35); //не ок :)) выведет float
}


Hidebysig in action.

A>Отныне настаиваю на изгнании обсуждений C++/CLI со страниц славного форума по C++!

И куда его, ***** ?
Re[3]: Offtopic
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 15.12.05 14:15
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Там еще очень много подстав...


Ну да, багосовместимость с CLS

A>>Отныне настаиваю на изгнании обсуждений C++/CLI со страниц славного форума по C++!


PC>И куда его, ***** ?


Пожалуй, там ему самое место
Re: C++ vs C# and C++/CLI :) Dynamic Type
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.12.05 06:55
Оценка: +3 -1
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Я в шоке Читаю стандарт С# и С++/CLI.


PC>Первые две программы выводят Derived::foo, третья выводит Base::foo.


PC>Глубоко обежден, что поведение C++ (третья) правильное, однако интересно услышать мнение почему так сделано в CLI.

Базовый принцип — тип у объекта всегда один. Было принято волевое решение, что так — логичнее.
Вся виртуальная таблица инициализируется сразу же, еще до вызова конструктора. Кроме того, все поля автоматически инициализируются значениями по умолчанию.
Таким образом, в конструкторе мы имеем полностью рабочий объект. Точно так же и в финалайзере мы всегда работаем с полностью рабочим объектом.
Такое поведение было признано более логичным — нет разницы, откуда ты вызываешь виртуальный метод.
Кроме того, плюсовая стратегия приводила бы к многим другим неочевидным вещам — вот например, GetType(), хоть и невиртуальный, должен был бы в конструкторе возвращать не финальный тип, а тот, до которого мы "доконструировались". Иначе были бы возможны спецэффекты — вроде обнаружения через Reflection методов, которых еще нет.
Ну и много других побочных эффектов. Причем их существование ничем не оправдано — никакого риска типа "а вдруг у нас объект еще не до конца сконструирован или частично разрушен" нет.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: C++ vs C# and C++/CLI :) Dynamic Type
От: Pavel Chikulaev Россия  
Дата: 16.12.05 12:19
Оценка: -1 :)
Здравствуйте, Sinclair, Вы писали:

PC>>Глубоко обежден, что поведение C++ (третья) правильное, однако интересно услышать мнение почему так сделано в CLI.

S>Базовый принцип — тип у объекта всегда один. Было принято волевое решение, что так — логичнее.
S>Вся виртуальная таблица инициализируется сразу же, еще до вызова конструктора. Кроме того, все поля автоматически инициализируются значениями по умолчанию.
S>Таким образом, в конструкторе мы имеем полностью рабочий объект. Точно так же и в финалайзере мы всегда работаем с полностью рабочим объектом.
S>Такое поведение было признано более логичным — нет разницы, откуда ты вызываешь виртуальный метод.
S>Кроме того, плюсовая стратегия приводила бы к многим другим неочевидным вещам — вот например, GetType(), хоть и невиртуальный, должен был бы в конструкторе возвращать не финальный тип, а тот, до которого мы "доконструировались". Иначе были бы возможны спецэффекты — вроде обнаружения через Reflection методов, которых еще нет.
S>Ну и много других побочных эффектов. Причем их существование ничем не оправдано — никакого риска типа "а вдруг у нас объект еще не до конца сконструирован или частично разрушен" нет.

Все логично, но в С++ нет таких проблем как в CLI в четвертом примере.

ИМХО правильный подход конструирования (он даже не как в С++ )

И соответсвенно разрушение/файнализинг


Что повлияло на разработчиков .NET, что не позволило им использовать этот более правильный в теоретическом и практическом ООП-смыслах.
В C++ тоже не идеал — конструирование немного не так... по понятным соображениям производительность — как никак низкий уровень, дважды нулями нехочется. Но CLI... и так все тормозит... почему бы нет?

А GetType это вообще идиотизм... ООП блин... typeid без какого-либо членства в С++ умудряется делать все то же самое... (ну или почти ... но эт на самом деле не важно...)

Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.
Re[2]: C++ vs C# and C++/CLI :) Dynamic Type
От: Шахтер Интернет  
Дата: 16.12.05 12:33
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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


PC>>Я в шоке Читаю стандарт С# и С++/CLI.


PC>>Первые две программы выводят Derived::foo, третья выводит Base::foo.


PC>>Глубоко обежден, что поведение C++ (третья) правильное, однако интересно услышать мнение почему так сделано в CLI.

S>Базовый принцип — тип у объекта всегда один. Было принято волевое решение, что так — логичнее.

Он и в C++ всегда один. Просто в С++ объекты конструируются, а в .Net инициализируются после конструирования по-умолчанию. В этом разница. В .Net нет конструкторов класса, а есть инициализаторы класса. Эквивалент в C++ -- двухфазная инициализация.

class C
 {
  public:

   C();

   void init(int a,int b,int c);
 };

C c;

c.init(1,2,3);


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

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

S>Таким образом, в конструкторе мы имеем полностью рабочий объект. Точно так же и в финалайзере мы всегда работаем с полностью рабочим объектом.
S>Такое поведение было признано более логичным — нет разницы, откуда ты вызываешь виртуальный метод.

Есть. Она есть объективно и устранить эту разницу нельзя. Просто разработчики .Net скрыли проблему за счет отказа от возможностей.

Впрочем, для облегчённого языка подобные подходы вполне оправданы.

S>Кроме того, плюсовая стратегия приводила бы к многим другим неочевидным вещам — вот например, GetType(), хоть и невиртуальный, должен был бы в конструкторе возвращать не финальный тип, а тот, до которого мы "доконструировались". Иначе были бы возможны спецэффекты — вроде обнаружения через Reflection методов, которых еще нет.


+

S>Ну и много других побочных эффектов. Причем их существование ничем не оправдано — никакого риска типа "а вдруг у нас объект еще не до конца сконструирован или частично разрушен" нет.


Неверно. Корректность состояния объекта не сводится к тому -- проинициализированы его поля или нет.

class Base
 {
  public Base() { doIt(); }

  public virtual void doIt() {}
 }

class Derived : Base
 {
   SomeClass obj;

  public Derived()
   {
    obj=new SomeClass();
   }

  public override void doIt() { obj.method(); }
 }
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[3]: C++ vs C# and C++/CLI :) Dynamic Type
От: Oyster Украина https://github.com/devoyster
Дата: 16.12.05 12:35
Оценка: +1 -1
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Что повлияло на разработчиков .NET, что не позволило им использовать этот более правильный в теоретическом и практическом ООП-смыслах.


"Моё кунг-фу лучше, чем твоё кунт-фу"? Что такое "правильное ООП", вообще? Например, CLOS (Common Lisp Object System) тоже ООП, хотя там нет методов (есть generic functions) и все слоты (aka поля) public.

PC>В C++ тоже не идеал — конструирование немного не так... по понятным соображениям производительность — как никак низкий уровень, дважды нулями нехочется. Но CLI... и так все тормозит... почему бы нет?


Вот это "и так всё тормозит", наверное, не совсем корректно без ссылок на тесты. Или тормозит по определению?

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

PC>А GetType это вообще идиотизм... ООП блин... typeid без какого-либо членства в С++ умудряется делать все то же самое... (ну или почти ... но эт на самом деле не важно...)


"Почти" не считается. Я бы сказал — typeid сотоварищи и рядом не валялись с reflection.

Кстати, почему это GetType() идиотизм? Почему плохо всегда знать тип объекта? Или, если бы этот метод был статическим, тебе было бы легче?

PC>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.


Вот с этим совершенно не согласен. Во-первых, наверняка читали Во-вторых, им удалось избежать многих проблем C++ (довольно сложный синтаксис, обязательная перекомпиляция всего в процессе билда, отсутствие чего-то вроде сборки в .NET FW, пресловутые memory leaks).

Дизайн CLI отнюдь не случаен. Поверь — товарищи разработчики долго взвешивали все "за" и "против". И, я думаю, получилось у них очень неплохо.
Re[3]: C++ vs C# and C++/CLI :) Dynamic Type
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.12.05 13:00
Оценка: +2 -1
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Все логично, но в С++ нет таких проблем как в CLI в четвертом примере.


Есть. Просто ты их не замечаешь. Ты искусственно придумал пример, при котором финалайзер базового типа начинает заниматься фигней. Финалайзер вообще стоит писать с большой осторожностью, т.к. порядок финализации не определен. Независимо от того, вызывается ли виртуальный метод, и был ли вызван финалайзер потомка.
Для начала рекомендую несколько освоиться с индетерминистической финализацией как таковой. Она сводится не только к отсутствию возможности вызвать деструктор напрямую. Есть и другие ограничения. В аналогичном случае ты бы рисковал получить то же самое, т.к. вместо вызова деструктора у тебя был бы вызов классического виртуального метода Dispose. И он точно так же позвал бы Derived::Foo, который бы успешно обратился к уже отдиспозенному Derived::o. И получил бы исключение ObjectDisposed.

PC>ИМХО правильный подход конструирования (он даже не как в С++ )

PC> И чего он позволит достичь? Зачем, собственно, этот геморрой?
PC>И соответсвенно разрушение/файнализинг
PC>

PC>Что повлияло на разработчиков .NET, что не позволило им использовать этот более правильный в теоретическом и практическом ООП-смыслах.

Здравый смысл и огромный опыт.
PC>В C++ тоже не идеал — конструирование немного не так... по понятным соображениям производительность — как никак низкий уровень, дважды нулями нехочется. Но CLI... и так все тормозит... почему бы нет?

PC>А GetType это вообще идиотизм... ООП блин... typeid без какого-либо членства в С++ умудряется делать все то же самое... (ну или почти ... но эт на самом деле не важно...)

А, вот теперь мне все понятно. Я рекомендую тебе воздержаться от критики дотнета до тех пор, пока ты не получишь достаточный опыт. Нельзя слепо переносить опыт из одной среды в другую. GetType() настолько круче, чем typeid, что это даже обсуждать бессмысленно. На нем построено очень много чего в дотнете. Но ты пока что не видишь всей этой мощи, потому как смотришь на дотнет сквозь танковую смотровую щель С++.

PC>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.

Уверяю тебя — читали. И изучили не только С++, а еще много языков.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Offtopic
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 01:06
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Там еще очень много подстав... Статью что-ли написать?


PC>Например:

PC>
PC>    d.foo(4.35); //не ок :)) выведет float
PC>


PC>Hidebysig in action.


Да, уж. Подставища еще та. Я бы даже сказал клинический случай.
Однако как плюсы менталитет плющат.

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

Что странного с того, что методы не скрываются если они имеют разные сигнатуры? Ну, напиши:
d.foo((int)4.35);

и вызовется нужный метод.

Кстати, Шарп на твой код пошлет далеко и на долго, так как 4.35 в нем квалифицируется как double, а автоматическое понижающее приведение типов в нем запрещено. Но так:
d.foo(4.35F);

все пройдет на ура.

ЗЫ

Кстати, это баян. Вопрос обсуждался сто лет назад.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++ vs C# and C++/CLI :) Dynamic Type
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 01:06
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

Попробуй заняться статистикой... подсчитать количество обратившихся в форумы со случаями подобными описаным тобой на Шарпе, и со случаями вроде "почему не вызвалась моя виртуальная функция в С++?" и "почему виртуальный конструктор не виртуальный?".

А потом за одно подсчитай сколько обратилось с вопросом "почему в С++ не вызвался деструктор класса наследника?". Ведь ты не указал, что у Base деструктор виртуальный, но тем не менее вызывашь его у типа приведенного к базовому.

Когда подвидешь результаты статистического исследования подумай "почему оно оказалось не в пользу С++?".

ЗЫ

Почти уверен отевет на все вопросы будет "да они все ламеры..."
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++ vs C# and C++/CLI :) Dynamic Type
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 02:17
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

О! Еще одна попытка объяснить почему на С++ программировать безопаснее, быстрее и удобнее чем на C#. Радует только то, что появилось хоть каое-то разнообразие. С++ vs. C++/CLI это все же свежо!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C++ vs C# and C++/CLI :) Dynamic Type
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 02:40
Оценка: +3
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.


Не, ну, все можно понять, в конце концов объяснить складом характера. Но чтобы вот так посоветовать почитать книг человеку создавшему не один популярнийший ООЯ — это ж какой самоуверенностью нужно обладать?!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C++ vs C# and C++/CLI :) Dynamic Type
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.05 02:40
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>Он и в C++ всегда один. Просто в С++ объекты конструируются, а в .Net инициализируются после конструирования по-умолчанию. В этом разница.


Нет в дотнете кострукторов по-умолчанию. Есть инициализация экземпляра системой которая заключается в обнулении памяти (и то реально обнуляется область кучи) и засовывании ссылки на информацию о типе в начало объекта.

Ш>В .Net нет конструкторов класса, а есть инициализаторы класса.


Как раз "конструкторов классов" в дотнете есть. Только делают они не то о чем ты думашь. Они вызываются при первом обращении к классу.

А ты говоришь о конструкторах экземпляров. И они тоже есть. Ну, а то что для С++-ника странно выглядит проинициализированные vtbl и т.п. (кстати, ее как раз в дотнете в общем-то нет ), так это просто проблемы стереотипов.

Ш>Эквивалент в C++ -- двухфазная инициализация.


Ш>
Ш>class C
Ш> {
Ш>  public:

Ш>   C();

Ш>   void init(int a,int b,int c);
Ш> };

Ш>C c;

Ш>c.init(1,2,3);
Ш>


Это не совсем эквивалент. Отличий два:
1. "C();" физически нет.
2. При исключении в "init" в дотнете невозможно будет получить ссылку н объект.

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


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

Ш>Есть. Она есть объективно и устранить эту разницу нельзя. Просто разработчики .Net скрыли проблему за счет отказа от возможностей.


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

Ш>Впрочем, для облегчённого языка подобные подходы вполне оправданы.


Это какй из них облегченный? С++/CLI, что ли? Или MSIL?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Offtopic
От: Pavel Chikulaev Россия  
Дата: 17.12.05 07:11
Оценка:
Здравствуйте, VladD2, Вы писали:

PC>>Hidebysig in action.

VD>Да, уж. Подставища еще та. Я бы даже сказал клинический случай.
Для С++/CLI да.

VD>Однако как плюсы менталитет плющат.

П. 5 !!!

VD>Ведь даже в голову не прийдет, что решения в дизайне языков бывают разные? И уж темболее не задумываться же на счет того, что дизайн любимого языка может оказаться кривым?

Очень даже придет... млин см. п. 5!!!

VD>Кстати, Шарп на твой код пошлет далеко и на долго, так как 4.35 в нем квалифицируется как double, а автоматическое понижающее приведение типов в нем запрещено. Но так:

Очепятка, я стандарт С# прочитал, и пишу на нем тоже, и кое-что понимаю...
Re[4]: C++ vs C# and C++/CLI :) Dynamic Type
От: Pavel Chikulaev Россия  
Дата: 17.12.05 07:17
Оценка:
Здравствуйте, Oyster, Вы писали:

PC>>Что повлияло на разработчиков .NET, что не позволило им использовать этот более правильный в теоретическом и практическом ООП-смыслах.

O>"Моё кунг-фу лучше, чем твоё кунт-фу"? Что такое "правильное ООП", вообще? Например, CLOS (Common Lisp Object System) тоже ООП, хотя там нет методов (есть generic functions) и все слоты (aka поля) public.
Наследование сделано не правильно...

PC>>В C++ тоже не идеал — конструирование немного не так... по понятным соображениям производительность — как никак низкий уровень, дважды нулями нехочется. Но CLI... и так все тормозит... почему бы нет?


O>Вот это "и так всё тормозит", наверное, не совсем корректно без ссылок на тесты. Или тормозит по определению?

Ок из-за безопасности... будем считать, что не тормозит...

PC>>А GetType это вообще идиотизм... ООП блин... typeid без какого-либо членства в С++ умудряется делать все то же самое... (ну или почти ... но эт на самом деле не важно...)


O>"Почти" не считается. Я бы сказал — typeid сотоварищи и рядом не валялись с reflection.

млин зачем делать членом, то что могло им не быть... Например в C++3x элементарно можно добавиь reflection в std::type_info...

O>Кстати, почему это GetType() идиотизм? Почему плохо всегда знать тип объекта? Или, если бы этот метод был статическим, тебе было бы легче?

Я и из typeid знаю... не так хорошо, но знаю
Ладно про это проехали, С++ и без reflection хорошо живет...

PC>>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.

O>Вот с этим совершенно не согласен. Во-первых, наверняка читали Во-вторых, им удалось избежать многих проблем C++ (довольно сложный синтаксис, обязательная перекомпиляция всего в процессе билда, отсутствие чего-то вроде сборки в .NET FW, пресловутые memory leaks).
Я про CLI, а не про шарп. Наследние С и только. Memory leaks у некоторых и без GC нет...

O>Дизайн CLI отнюдь не случаен. Поверь — товарищи разработчики долго взвешивали все "за" и "против".

Так вот эти "за" и "против" о которых я спрашивал никто говорит не собирается.

O>И, я думаю, получилось у них очень неплохо.

Кое-что да, кое-что нет...
Re[4]: C++ vs C# and C++/CLI :) Dynamic Type
От: Pavel Chikulaev Россия  
Дата: 17.12.05 07:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PC>>Все логично, но в С++ нет таких проблем как в CLI в четвертом примере.


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

Ок придумай искусственный пример где С++ с его семантикой смены динамического типа в дторе подведет. Жду.

S>Финалайзер вообще стоит писать с большой осторожностью, т.к. порядок финализации не определен. Независимо от того, вызывается ли виртуальный метод, и был ли вызван финалайзер потомка.

Да я понимаю это. Это безусловно лишь теоретический вопрос.

S>Для начала рекомендую несколько освоиться с индетерминистической финализацией как таковой. Она сводится не только к отсутствию возможности вызвать деструктор напрямую. Есть и другие ограничения. В аналогичном случае ты бы рисковал получить то же самое, т.к. вместо вызова деструктора у тебя был бы вызов классического виртуального метода Dispose. И он точно так же позвал бы Derived::Foo, который бы успешно обратился к уже отдиспозенному Derived::o. И получил бы исключение ObjectDisposed.

Почему ты так уверен, что я это не понимаю?

PC>>ИМХО правильный подход конструирования (он даже не как в С++ )

PC>> S>И чего он позволит достичь? Зачем, собственно, этот геморрой?
Потому что это самый правильный вариант, но в чистом виде он нигде не используется (ни в С++ ни CLS)

PC>>И соответсвенно разрушение/файнализинг

PC>>
PC>>Что повлияло на разработчиков .NET, что не позволило им использовать этот более правильный в теоретическом и практическом ООП-смыслах.
S>Здравый смысл и огромный опыт.
Сомневаюсь...

PC>>В C++ тоже не идеал — конструирование немного не так... по понятным соображениям производительность — как никак низкий уровень, дважды нулями нехочется. Но CLI... и так все тормозит... почему бы нет?


PC>>А GetType это вообще идиотизм... ООП блин... typeid без какого-либо членства в С++ умудряется делать все то же самое... (ну или почти ... но эт на самом деле не важно...)

S>А, вот теперь мне все понятно. Я рекомендую тебе воздержаться от критики дотнета до тех пор, пока ты не получишь достаточный опыт. Нельзя слепо переносить опыт из одной среды в другую. GetType() настолько круче, чем typeid, что это даже обсуждать бессмысленно. На нем построено очень много чего в дотнете.
П. 5. Я ЭТО МЛИН ЗНАЮ! В скобках написано, что reflection не учитывается...
S>Но ты пока что не видишь всей этой мощи, потому как смотришь на дотнет сквозь танковую смотровую щель С++.
А ты уверен, что щель с моей стороны? Я нет.

PC>>Очень жаль, что разрботчики .NET не читали Design & Evolution of C++ — много бы проблем избежали типа не совмещять понятия access и overload.

S>Уверяю тебя — читали. И изучили не только С++, а еще много языков.
И все в .NET замечательно да? фанатизм какой-то...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.