Hello, s.ts!
You wrote on Thu, 16 Oct 2003 15:59:30 GMT:

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

S>> А в случае возникновения исключения в конструкторе деструктор просто не
S>> вызывается, только и всего.

s> Память то надо все равно освободить

Ага. Если не делать ошибок, она будет освобождена — деструктор для базового класса вызовется, деструкторы для членов вызовутся.

s>>> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s>>> сомнительная плата за быстродействие.

S>> Это не плата за быстродействие, а желание Страуструпа отучить
S>> программистов от процедурного стиля программирования

s> Какая тут связь ?

Ну, например, использование более одного "голого" указателя как членов класса сильно затрудняет написание exception-safe кода, что побуждает использовать разнообразные смарт-пойнтеры. Каждый ресурс заворачивается в отдельный класс, утечек нет. Да и finally в С++ отсутствует из тех же соображений.

S>> Если разрешить любое множественное наследование от классов с
S>> данными (не-интерфейсов) в языках типа C#, то любое наследование
S>> в них придется делать виртуальным. Проще оказалось вообще забить на
S>> множественное наследование .

s> То, что сложнее — это точно. А все виртульным делать не надо. Достаточно
s> только от базового aka Object aka TObject aka CObject чтобы RTTI было,
s> для чего все и затевалось.

Вот именно — у каждого объекта будет виртуальный базовый класс — который в отсутствие множественного наследования был бы просто базовым. Дороговато.

Best regards,
Sergey.

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

S>Ага. Если не делать ошибок, она будет освобождена — деструктор для базового класса вызовется, деструкторы для членов вызовутся.

Ну а как в деструкторе понять, что ресурс не бы выделен ?

Как вариант :

class My
{
  Handle h[100];
  My()
  {
    for(int i=0; i<100; i++)
    {
      h[i] = 0;
      h[i] = CreateHandle();
    }
  };
  ~My()
  {
    for(int i=0; i<100; i++)
    {
      if(handle!=0)
        ReleaseHandle(h);
    }
  };
}

Где начальную инициализацию лучше делать автоматически по умолчанию. И не говори, что там можно использовать Vector или любой другой класс вместо голого массива. Ведь может быть еще хуже — все h оазных типов.


s>>>> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s>>>> сомнительная плата за быстродействие.

S>>> Это не плата за быстродействие, а желание Страуструпа отучить
S>>> программистов от процедурного стиля программирования

s>> Какая тут связь ?

S>Ну, например, использование более одного "голого" указателя как членов класса сильно затрудняет написание exception-safe кода, что побуждает использовать разнообразные смарт-пойнтеры. Каждый ресурс заворачивается в отдельный класс, утечек нет. Да и finally в С++ отсутствует из тех же соображений.

Это оставим на совести Страуструпа.

S>>> Если разрешить любое множественное наследование от классов с
S>>> данными (не-интерфейсов) в языках типа C#, то любое наследование
S>>> в них придется делать виртуальным. Проще оказалось вообще забить на
S>>> множественное наследование .

s>> То, что сложнее — это точно. А все виртульным делать не надо. Достаточно
s>> только от базового aka Object aka TObject aka CObject чтобы RTTI было,
s>> для чего все и затевалось.

S>Вот именно — у каждого объекта будет виртуальный базовый класс — который в отсутствие множественного наследования был бы просто базовым. Дороговато.

Но не вся иерархия наследования будет виртуальной, а только на самом верхнем уровне (у корня)
Насчет дороговато :
1 лишний указатель в VMT ???

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

WH>>Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.
ST>Это все было не то
Что не то? Ты хочешь сказать что в дельфе конструктор устроен иначе чем я показал?

WH>>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...
ST>Почему ?
А там все контейнеры это классы, а все классы создаются в хипе...

WH>>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.
ST>Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.
Ну мне попадались перци которые утверждали что на делфе они это могут сделать легко

WH>>О а вот это на столько круто что даже не все С++ники представляют.
ST>В смысле ? Если не представляют, то .... зачем они делают ЭТО (в смысле, пишут на С++)
Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++

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

ST>Так ведь автоуказатель-неавтоуказатель все равно вызывается деструктор (или что другое) чтобы освободить ресурсы.
Деструктор автоуказателя.
ST>А ты даже не знаешь выделены ли они.
Знаю выделены иначе автоуказатель не будет создан.

ST>М.б. будет понятно из кода:
хъ
ST>Если переменную с не инициализировать, то будет AV на вызове delete.
С автоуказателями такой проблемы нет ибо они имеют конструктор по умолчанию который инициализирует внутренный указатель нулем.

Вобще грамотная С++ программа это куча шаблонных кирпичиков каждый из которых выполняет ту и только ту маленькую часть работы кторую должен. std::auto_ptr реализует смартпоинтер со стратегией эксклюзивного владения, boost::shared_ptr раздельное владение(реализовано через внешний подсчет ссылок)...
Из них собирают кирпичи по крупнее которые надеятся на то что заданные свойства маленьких кирпичиков в точности соблюдены. И так далие.

ИМХО в идеальной программе нет двух кусков кода которые далают одно и тоже. С++ программы очень близки к идеальным. Гораздо ближе чем дельфийские ибо например встретить delete в программе на С++ (а не С с классами) кроме как в нутри смартпоинтера нельзя. В тоже время на дельфе free обычное дело. И тд и тп.

Hello, s.ts!
You wrote on Fri, 17 Oct 2003 08:12:20 GMT:

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

S>> Ага. Если не делать ошибок, она будет освобождена — деструктор для
S>> базового класса вызовется, деструкторы для членов вызовутся.

s> Ну а как в деструкторе понять, что ресурс не бы выделен ?

Еще раз — деструкторы для недоконструированных объектов не вызываются.

s> Как вариант :

s>

 s> class My
 s> {
 s>   Handle h[100];
 s>   My()
 s>   {
 s>     for(int i=0; i<100; i++)
 s>     {
 s>       h[i] = 0;
 s>       h[i] = CreateHandle();
 s>     }
 s>   };
 s>   ~My()
 s>   {
 s>     for(int i=0; i<100; i++)
 s>     {
 s>       if(handle!=0)
 s>         ReleaseHandle(h);
 s>     }
 s>   };
 s> }
 s>

Куда лучше будет так:

class My
{
class sHandle
{
Handle _h;
sHandle()
{ _h = CreateHandle(); }
~sHandle()
{ ReleaseHandle(_h); }
};
sHandle _h[100];
};

И никаких проблем с исключениями в CreateHandle.

Best regards,
Sergey.

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

WH>Что не то? Ты хочешь сказать что в дельфе конструктор устроен иначе чем я показал?
Все гораздо проще и примерно так:
delphi.NewInstance = C++::operator new, delphi.InitInstance = C++::constructor,
delphi.constructor = фабричная функция в C++.

WH>>>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...
ST>>Почему ?
WH>А там все контейнеры это классы, а все классы создаются в хипе...
А есть языки где все суть есть класс и дельфя ближе к ним.

WH>>>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.
ST>>Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.
WH>Ну мне попадались перци которые утверждали что на делфе они это могут сделать легко

WH>>>О а вот это на столько круто что даже не все С++ники представляют.
ST>>В смысле ? Если не представляют, то .... зачем они делают ЭТО (в смысле, пишут на С++)
WH>Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++

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

А вообше, народ, кончайте на эту тему копья ломать (я про автопойнтеры). В этой ветке ведь поначалу обсуждалось, "как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает". О наличии и отсутствии шаблонов речь не шла (и не могла идти — смысла нет, это однозначно недостаток Delphi). А ваша полемика упорно сбивается в этом направлении.

WH, представь себе, что шаблонов НЕТУ

Slicer

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

S>Hello, s.ts!
S>You wrote on Fri, 17 Oct 2003 08:12:20 GMT:

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


S>Куда лучше будет так:

S>class My
S>{
S> class sHandle
S> {
S> Handle _h;
S> sHandle()
S> { _h = CreateHandle(); }
S> ~sHandle()
S> { ReleaseHandle(_h); }
S> };
S> sHandle _h[100];
S>};

S>И никаких проблем с исключениями в CreateHandle.

Согласен, но одно большое "НО":
Изначально разговор был о производительности. А тут мы экономим операцию записи в память за счет операции вызова функции (и не дай бог виртуальной — если через фабрику создавать).
Да, и не говорите мне пожалуйста об инлайн-расширении.

Hello, s.ts!
You wrote on Fri, 17 Oct 2003 08:55:45 GMT:

s> Согласен, но одно большое "НО":
s> Изначально разговор был о производительности.

Да, но перестал быть разговором о производительности, как только речь зашла об исключениях в конструкторах Потому что исключения вообще штука достаточно медленная. Разговор пошел о том, что в дельфи мы делаем дефолтную инициализацию всегда, а в С++ — только когда надо (компилятор все равно какие-то невидимые флаги выставляет, чтобы обеспечить правильную работу с недоконструированными объектами).

s> А тут мы экономим операцию
s> записи в память за счет операции вызова функции (и не дай бог
s> виртуальной — если через фабрику создавать).

Нифига. Операция записи в память здесь лишняя — она ничего не дает. Если хочется делать закат солнца вручную — изволь обложить свой цикл try/catch и освобождать ресурсы в catch.

s> Да, и не говорите мне пожалуйста об инлайн-расширении.

Почему? Очень полезная фича.

Best regards,
Sergey.

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

...

WH>Вобще грамотная С++ программа это куча шаблонных кирпичиков каждый из которых выполняет ту и только ту маленькую часть работы кторую должен. std::auto_ptr реализует смартпоинтер со стратегией эксклюзивного владения, boost::shared_ptr раздельное владение(реализовано через внешний подсчет ссылок)...
WH>Из них собирают кирпичи по крупнее которые надеятся на то что заданные свойства маленьких кирпичиков в точности соблюдены. И так далие.



WH>ИМХО в идеальной программе нет двух кусков кода которые далают одно и тоже. С++ программы очень близки к идеальным. Гораздо ближе чем дельфийские ибо например встретить delete в программе на С++ (а не С с классами) кроме как в нутри смартпоинтера нельзя. В тоже время на дельфе free обычное дело. И тд и тп.

Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).

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

...

WH>>>>О а вот это на столько круто что даже не все С++ники представляют.
ST>>>В смысле ? Если не представляют, то .... зачем они делают ЭТО (в смысле, пишут на С++)
WH>>Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++
ST>

Если я правильно ошибаюсь, в С с классами — сами классы тоже были объектами. Жаль что в С++ они не попали.

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

WH>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>А есть языки где все суть есть класс и дельфя ближе к ним.

И какое это имеет отношение к обращениям к хипу которых могло и не быть?

Здравствуйте, Slicer [Wirkwood], Вы писали:

>> С++ программы очень близки к идеальным
SW>WH, камрад, расскажи мне пожалуйста, что такое идеальная программа?
Ды эта... зачем поскипал?

SW>А вообше, народ, кончайте на эту тему копья ломать (я про автопойнтеры). В этой ветке ведь поначалу обсуждалось, "как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает". О наличии и отсутствии шаблонов речь не шла (и не могла идти — смысла нет, это однозначно недостаток Delphi). А ваша полемика упорно сбивается в этом направлении.
Ну считайте что мой поинт в том что в С++ за всем следит компилятор, а в дельфе ручками...

SW>WH, представь себе, что шаблонов НЕТУ
Ага и метаклассов в С++ нету. И о чем тогда спорить?

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

ST>Согласен, но одно большое "НО":
ST>Изначально разговор был о производительности. А тут мы экономим операцию записи в память за счет операции вызова функции (и не дай бог виртуальной — если через фабрику создавать).
ST>Да, и не говорите мне пожалуйста об инлайн-расширении.
Почему? В данном случае все очень хорошо инлайнится.

WH>И о чем тогда спорить?

Ну так и я не понимаю — чего вам всем времени не жалко?
Поспорьте лучше о сравнительных характеристиках C++ и C# — хотя бы актуально

Slicer

P.S. Это тактический маневр был — перессорить Цников

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

M>Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).
А какой ценой? Таскать объекты исключительно через интерфейсы? Создавать еще один объект смартпоинтер +1 обращение к хипу и работа через виртуальные функции в место стека и инлайна в С++? А как это все выглядит...

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

M>Если я правильно ошибаюсь, в С с классами — сами классы тоже были объектами. Жаль что в С++ они не попали.
Имелся в виду стиль программирования "С с классами" те программа фактически написана на С но с использованием классов.
Это далеко не тоже самой что программа на С++. На С++ получается в несколько раз короче и надежней. Просто к сожалению не все умеют.

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>Ну так и я не понимаю — чего вам всем времени не жалко?
Ну развлекаться тоже иногда надо.
SW>Поспорьте лучше о сравнительных характеристиках C++ и C# — хотя бы актуально
Где ты был летом? Тут такая война шла...

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

M>>Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).

WH>А какой ценой? Таскать объекты исключительно через интерфейсы? Создавать еще один объект смартпоинтер +1 обращение к хипу и работа через виртуальные функции в место стека и инлайна в С++? А как это все выглядит...

Через интерфейсы.

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

Во-вторых, это заставляет тщательнЕе задумываться о времени жизни сложных/составных объектов — проблема циклических ссылок, и как следствие зачастую пересматривать общий каркас программы. А так же упрощает возможность переноса программ на другие ( ) языки, тот же Delphi.Net.

Во-третьих, с точки зрения самого программирования, оперирование интерфейсами вместо оперирования реализациями — гибче, мощнее и в конечном счёте правильнее. Это подтверждают и последние (и даже не очень последние) тенценции в язаках — типа Java, C# (да и .Net в целом).

Кроме того, очень многи паттерны программирования хорошо реализуются только с помощью абстрактных классов (С++) и интерфейсов. В частности, в Delphi очень, имхо, удачно сделана возможность реализации интерфейса через агрегатирование.


Собственно говоря, большое имхо, возможность управления жизнью объектов через интерфейсы — это побочный, а не основной эффект их использования.

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

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

M>Во-вторых, это заставляет тщательнЕе задумываться о времени жизни сложных/составных объектов — проблема циклических ссылок, и как следствие зачастую пересматривать общий каркас программы.
В С++ таже фигня
M>А так же упрощает возможность переноса программ на другие ( ) языки, тот же Delphi.Net.
Спорноное преймущество.

M>Во-третьих, с точки зрения самого программирования, оперирование интерфейсами вместо оперирования реализациями — гибче, мощнее и в конечном счёте правильнее. Это подтверждают и последние (и даже не очень последние) тенценции в язаках — типа Java, C# (да и .Net в целом).
Это мне обьяснять не надо. Но сам подумай Зачем мне на каждый чих заводить интерфейс если можно положить в стек и не париться.

M>Кроме того, очень многи паттерны программирования хорошо реализуются только с помощью абстрактных классов (С++) и интерфейсов. В частности, в Delphi очень, имхо, удачно сделана возможность реализации интерфейса через агрегатирование.
В С++ подключение реализации сделано куда круче. Особенно если применить фантазию и шаблоны.

M>Собственно говоря, большое имхо, возможность управления жизнью объектов через интерфейсы — это побочный, а не основной эффект их использования.
Вот и я о томже.