Здравствуйте, s.ts, Вы писали:
ST>Код, приведенный выше на любом ОО языке можно написать и не показывает ЧЕМ КОНСТРУКТОР С++ ОТЛИЧАЕТСЯ ОТ ТРИГГЕРА НА СОЗДАНИЕ ОБЪЕКТА.
Ну, ни в одном ООЯП я не видел такого понятия, как "триггер на создание объекта". Поэтому не могу сказать,чем они отличаются.
ST>1.КАК В С++ ИЗ КОНСТРУКТОРВА МОЖНО УПРАВЛЯТЬ КОНСТРУИРОВАНИЕМ ОБЪЕКТА, КРОМЕ ИНИЦИАЛИЗАЦИИ ПОЛЕЙ И ВЫЗОВОВ КОНСТРУКТОРОВ БАЗОВЫХ КЛАССОВ ????????????
Не кричи. Ответ — никак.
ST>2.ЧЕМ ИМЕННО МОЖНО УПРАВЛЯТЬ В КОНСТРУКТОРЕ ????????????????
Состоянием объекта после окончания конструирования.

З.Ы. Ты неправильно понимаешь, что такое конструктор. С точки зрения ООП, задачи размещения и инициализации объекта ортогональны. Конструктор в С++ гарантирует, что нельзя получить доступ к объекту в нецелостном сотоянии. Все ограничения конструктора связаны именно с этим. Именно поэтому виртуальные методы из конструктора вызываются статически — чтобы не произвести вызов метода на недоконструированном объекте.
Гибкость при размещении дает оператор выделения памяти new. Поэтому в создающем коде принимается сразу два решения:
1. Стратегия размещения (стек/статика/одна из версий new)
2. Стратегия инициализации (один из конструкторов).
При желании эти решения можно инкапсулировать в фабрику, которая будет размещать и инициализировать объект по своему усмотрению. Но внутри метода, реализующего выбранную стратегию, уже никакого выбора не происходит.

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 13:20:05 GMT:

s> В делфе нужно указывать вызов конструктора/деструктора базового класса,
s> но в любом месте, а можно и не указывать.

Т.е., если не указать вызов конструктора базового класса, то базовый объект останется неинициализированным?

s> Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи -
s> более сильная часть чем в С++. А чего не хватает относительно С++ —
s> это краткости кода (begin, end etc.), перегрузки операторов и шаблонов.
s> Впрочем, это, видимо, общая тенденция.

А множественное наследование есть?

Best regards,
Sergey.

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

H_D>Так и с Дельфи — то, что вы не знаете профессионалов, которые великолепно владеют Delphi и умеют совмещать код Delphi с кодом на других ЯП (иногда — и в одном проекте) не значит, что таковых нет, а Дельфи — отстой... просто Борланд чуть лучше заботится о своих юзверях

Ага, особенно когда прекратила поддержку OWL и сказала "юзайте VCL или идите нах.".

best regards..
in hack we trust.

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

s>> В делфе нужно указывать вызов конструктора/деструктора базового класса,
s>> но в любом месте, а можно и не указывать.

S>Т.е., если не указать вызов конструктора базового класса, то базовый объект останется неинициализированным?

Инициализировано нулем или чем ты там укажешь в InitInstance — этот всегда вызывается — в некотором смысле аналог оператора new из С++.

Я помнится поначалу иногда забывал вызывать базовый конструктор Но теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни перепутал 2 раза и нашел за 2 минуты).

s>> Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи -
s>> более сильная часть чем в С++. А чего не хватает относительно С++ —
s>> это краткости кода (begin, end etc.), перегрузки операторов и шаблонов.
s>> Впрочем, это, видимо, общая тенденция.

S>А множественное наследование есть?

Есть "множественное наследование" интерфейсов (кстати, COM-совместимых), что просто отражает общую тенденцию (java C# и иже с ними).

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

S>Здравствуйте, s.ts, Вы писали:
ST>>Код, приведенный выше на любом ОО языке можно написать и не показывает ЧЕМ КОНСТРУКТОР С++ ОТЛИЧАЕТСЯ ОТ ТРИГГЕРА НА СОЗДАНИЕ ОБЪЕКТА.
S>Ну, ни в одном ООЯП я не видел такого понятия, как "триггер на создание объекта". Поэтому не могу сказать,чем они отличаются.

Понятие триггер из области СУБД, но более точно отражает природу конструкторов. Конструирует объект скорее оператор new.

Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
В общем, смотрите шире: используите не "ООЯП", а ООА&D .

А вообще-то интуитивно понятно что я имел ввиду и не нужно цепляться к словам

ST>>1.КАК В С++ ИЗ КОНСТРУКТОРВА МОЖНО УПРАВЛЯТЬ КОНСТРУИРОВАНИЕМ ОБЪЕКТА, КРОМЕ ИНИЦИАЛИЗАЦИИ ПОЛЕЙ И ВЫЗОВОВ КОНСТРУКТОРОВ БАЗОВЫХ КЛАССОВ ????????????
S>Не кричи. Ответ — никак.
ST>>2.ЧЕМ ИМЕННО МОЖНО УПРАВЛЯТЬ В КОНСТРУКТОРЕ ????????????????
S>Состоянием объекта после окончания конструирования.

S>З.Ы. Ты неправильно понимаешь, что такое конструктор. С точки зрения ООП, задачи размещения и инициализации объекта ортогональны. Конструктор в С++ гарантирует, что нельзя получить доступ к объекту в нецелостном сотоянии. Все ограничения конструктора связаны именно с этим. Именно поэтому виртуальные методы из конструктора вызываются статически — чтобы не произвести вызов метода на недоконструированном объекте.
S>Гибкость при размещении дает оператор выделения памяти new. Поэтому в создающем коде принимается сразу два решения:
S>1. Стратегия размещения (стек/статика/одна из версий new)
S>2. Стратегия инициализации (один из конструкторов).
S>При желании эти решения можно инкапсулировать в фабрику, которая будет размещать и инициализировать объект по своему усмотрению. Но внутри метода, реализующего выбранную стратегию, уже никакого выбора не происходит.

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

Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).

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

S>Здравствуйте, WolfHound, Вы писали:
S>Ну, теперь еще сделай так, чтобы я мог построить функцию, принимающую указатель на класс и вызывающую вот этот твой сreate с заданными параметрами.
S>В дельфи это будет вот так:
S>

S>type
S>  TBaseClass = class of base;
S>function CreateMyBaseDescendant(BaseClass: TBaseClass): base;
S>begin
S>  Result:= BaseClass.create(2, 4);
S>end;
S>var
S>  K: base;
S>begin
S>  K:= CreateMyBaseDescendent(some);
S>end;
S>

Нету в С++ "указателей на класс".
TClass в дельфи — это в своем роде фабрика классов, но встроенная в компилятор. На С++ делается все то же самое, но с дополнительными усилиями.

Для удовлетворения же твоего желания на С++ нужно передавать указатель на фабрику класса. RTTI (читай фабрики) там реализуются при помощи шаблонов, ибо другого универсального пути (кроме как встраивание в компилятор, что сделал Борланд) ИМХО нет.

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 14:11:55 GMT:

s>>> В делфе нужно указывать вызов конструктора/деструктора базового
s>>> класса, но в любом месте, а можно и не указывать.

S>> Т.е., если не указать вызов конструктора базового класса, то базовый
S>> объект останется неинициализированным?

s> Инициализировано нулем или чем ты там укажешь в InitInstance — этот
s> всегда вызывается — в некотором смысле аналог оператора new из С++.

В некотором смысле, это аналог конструктора в С++ Оператор new занимается выделением памяти под объекты и вызовом конструкторов, а не их собственно созданием объектов.

Кстати, вот тебе и причина, по которой С++'ный конструктор сложного объекта будет быстрее — там дефолт инициализация базовых объектов и мемберов не обязательна, можно сразу вызвать нужный конструктор с параметром.

s> Я помнится поначалу иногда забывал вызывать базовый конструктор Но
s> теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни
s> перепутал 2 раза и нашел за 2 минуты).

Значит, просто мало программировал на С

S>> А множественное наследование есть?

s> Есть "множественное наследование" интерфейсов (кстати, COM-совместимых),
s> что просто отражает общую тенденцию (java C# и иже с ними).

Это не просто тенденция, а следствие наличия общего для всех объектов предка.

Best regards,
Sergey.

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

S>Hello, s.ts!
S>You wrote on Thu, 16 Oct 2003 14:11:55 GMT:

s>>>> В делфе нужно указывать вызов конструктора/деструктора базового
s>>>> класса, но в любом месте, а можно и не указывать.

S>>> Т.е., если не указать вызов конструктора базового класса, то базовый
S>>> объект останется неинициализированным?

s>> Инициализировано нулем или чем ты там укажешь в InitInstance — этот
s>> всегда вызывается — в некотором смысле аналог оператора new из С++.

S>В некотором смысле, это аналог конструктора в С++ Оператор new занимается выделением памяти под объекты и вызовом конструкторов, а не их собственно созданием объектов.

Согласен . Моя аналогия не правильна.

S>Кстати, вот тебе и причина, по которой С++'ный конструктор сложного объекта будет быстрее — там дефолт инициализация базовых объектов и мемберов не обязательна, можно сразу вызвать нужный конструктор с параметром.

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

s>> Я помнится поначалу иногда забывал вызывать базовый конструктор Но
s>> теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни
s>> перепутал 2 раза и нашел за 2 минуты).

S>Значит, просто мало программировал на С

Померяемся, у кого длиннее ?

Далее серьезно:
М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только изучал С++ — это было давно и к моменту начала реальной работы уже были изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне хоть какие-то неудобства.

S>>> А множественное наследование есть?

s>> Есть "множественное наследование" интерфейсов (кстати, COM-совместимых),
s>> что просто отражает общую тенденцию (java C# и иже с ними).

S>Это не просто тенденция, а следствие наличия общего для всех объектов предка.

В С++ ни кто не мешает делать множественное наследование от классов с общим предком (просто он должен быть виртуальным базовым классом). Так что следствия тут нет. Интерфейсы в дельфи скорее частный случай множественного наследования в C++.

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

S>> Кстати, вот тебе и причина, по которой С++'ный конструктор сложного
S>> объекта будет быстрее — там дефолт инициализация базовых объектов и
S>> мемберов не обязательна, можно сразу вызвать нужный конструктор с
S>> параметром.

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

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

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

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

s>>> Я помнится поначалу иногда забывал вызывать базовый конструктор Но
s>>> теперь все хорошо. Это из области перепутать в С = и == (я в своей
s>>> жизни перепутал 2 раза и нашел за 2 минуты).

S>> Значит, просто мало программировал на С

s> Померяемся, у кого длиннее ?

Зачем? Мне и так понятно, что ты либо приврал, либо гений внимательности (не верю ), либо действительно мало программировал на С/С++.

s> Далее серьезно:
s> М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только
s> изучал С++ — это было давно и к моменту начала реальной работы уже были
s> изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне
s> хоть какие-то неудобства.

Ну, отсутствие неудобств — это одно, 2 ошибки с = и == за всю практику программирования — совсем другое


s>>> Есть "множественное наследование" интерфейсов (кстати,
s>>> COM-совместимых), что просто отражает общую тенденцию (java C# и иже с
s>>> ними).

S>> Это не просто тенденция, а следствие наличия общего для всех объектов
S>> предка.

s> В С++ ни кто не мешает делать множественное наследование от классов с
s> общим предком (просто он должен быть виртуальным базовым классом).

Во-первых, не должен, а может быть виртуальным базовым классом. Во-вторых, виртуальное aka "бриллиантовое" множественное наследование реализуется на порядок сложнее обычного, да и прикладному программисту с ним тоже не просто обращаться. А нужно оно очень редко.

s> Так что следствия тут нет.

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

s> Интерфейсы в дельфи скорее частный случай множественного наследования в C++.
Да.


Best regards,
Sergey.

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

S>Hello, s.ts!
S>You wrote on Thu, 16 Oct 2003 15:14:38 GMT:

S>>> Кстати, вот тебе и причина, по которой С++'ный конструктор сложного
S>>> объекта будет быстрее — там дефолт инициализация базовых объектов и
S>>> мемберов не обязательна, можно сразу вызвать нужный конструктор с
S>>> параметром.

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

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

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

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

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

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

S>Зачем? Мне и так понятно, что ты либо приврал, либо гений внимательности (не верю ), либо действительно мало программировал на С/С++.

Эту несодержательную тему мы оставим.

s>> Далее серьезно:
s>> М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только
s>> изучал С++ — это было давно и к моменту начала реальной работы уже были
s>> изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне
s>> хоть какие-то неудобства.

S>Ну, отсутствие неудобств — это одно, 2 ошибки с = и == за всю практику программирования — совсем другое

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

s>>>> Есть "множественное наследование" интерфейсов (кстати,
s>>>> COM-совместимых), что просто отражает общую тенденцию (java C# и иже с
s>>>> ними).

S>>> Это не просто тенденция, а следствие наличия общего для всех объектов
S>>> предка.

s>> В С++ ни кто не мешает делать множественное наследование от классов с
s>> общим предком (просто он должен быть виртуальным базовым классом).

S>Во-первых, не должен, а может быть виртуальным базовым классом. Во-вторых, виртуальное aka "бриллиантовое" множественное наследование реализуется на порядок сложнее обычного, да и прикладному программисту с ним тоже не просто обращаться. А нужно оно очень редко.

s>> Так что следствия тут нет.

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

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

Здравствуйте, s.ts, Вы писали:
ST>Нету в С++ "указателей на класс".
ST>TClass в дельфи — это в своем роде фабрика классов, но встроенная в компилятор. На С++ делается все то же самое, но с дополнительными усилиями.
Вот как раз это-то я очень неплохо знаю. Мне и интересно, какие дополнительные усилия надо предпринять. Wolfhound написал :

О уже почти дельфя. Вернее логически один в один.

А я ему намекаю, что нифига это не один в один. Пусть покажет один в один.
S>Для удовлетворения же твоего желания на С++ нужно передавать указатель на фабрику класса. RTTI (читай фабрики) там реализуются при помощи шаблонов, ибо другого универсального пути (кроме как встраивание в компилятор, что сделал Борланд) ИМХО нет.

Здравствуйте, s.ts, Вы писали:
ST>Понятие триггер из области СУБД,
да
ST>но более точно отражает природу конструкторов.
нет
ST>Конструирует объект скорее оператор new.
Ну конечно же нет
ST>Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
В БД НЕТ объектов. Триггер на создание записи — совсем другая фишка.
ST>В общем, смотрите шире: используите не "ООЯП", а ООА&D .
Да я с удовольствием. В ООА&D тоже нету триггеров.
ST>А вообще-то интуитивно понятно что я имел ввиду и не нужно цепляться к словам
Ок, не будем
ST>Я то, видать (см. всю ветку), все правильно понимаю.
Смотрю. Не уверен
ST>Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).
Я в курсе. Это как раз очень плохо. Фактически, отсутствие способа размещать объекты на стеке мешает повысить эффективность операция распределения памяти для объектов со scope lifetime, т.е. порядок удаления которых в точности обратен порядку их создания. В Дельфи вообще другое понимание термина "конструктор". Половина войн с ++ программерами именно из-за этого. В плюсах конструкторы строже. Нужно понимать, что в плюсах создание объекта — двухстадийное, а в Дельфи — четырехстадийное (NewInstance/InitInstance/Create/AfterConstruction). В плюсах InitInstance отсутствует, поэтому нельзя трактовать конструктор, как обычную функцию. А в Дельфи можно вызывать конструктор сколько угодно раз на уже готовом объекте.
Зато дельфи реализует паттерн "абстрактная фабрика" натуральным образом. Мне до сих пор интересно, можно ли в точности воспроизвести семантику Delphi средствами плюсов, не влезая в компилятор.

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

ST>В делфе нужно указывать вызов конструктора/деструктора базового класса, но в любом месте, а можно и не указывать.
Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.

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

ST>Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи — более сильная часть чем в С++.
Как можно получить тотже эффект на С++ я уже говорил.
ST>А чего не хватает относительно С++ — это краткости кода (begin, end etc.),
Фигня
ST>перегрузки операторов и шаблонов.
О а вот это на столько круто что даже не все С++ники представляют.

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

ST>Память то надо все равно освободить
А в С++ ни кто delete не пишет.

struct some_t{};
struct some_else_t
{
    std::auto_ptr<some_t> some;
    some_else_t()
        :some(new some_t)
    {
        throw 1;
    }
};

Утечек не будет.

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

H_D>Так и с Дельфи — то, что вы не знаете профессионалов, которые великолепно владеют Delphi и умеют совмещать код Delphi с кодом на других ЯП (иногда — и в одном проекте) не значит, что таковых нет, а Дельфи — отстой... просто Борланд чуть лучше заботится о своих юзверях
Я знаю одного уже несколько лет. Дык вот некоторое время назад он решил что пора переходить на С++ и собирается сделать это при первой возможности. Интересно почему?

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

S>А я ему намекаю, что нифига это не один в один. Пусть покажет один в один.
Вот я и думаю как это сделать красиво.
Как вариант можно так

/*****************************************************/
template<class class_t>
struct get_delphi_ctor
{
    class_t* operator()()
    {
        return class_t::create();
    }
    template<class param1_t>
    class_t* operator()(param1_t param1)
    {
        return class_t::create(param1);
    }
    template<class param1_t, class param2_t>
    class_t* operator()(param1_t param1, param2_t param2)
    {
        return class_t::create(param1, param2);
    }
    //Продолжить по вкусу
};
/*****************************************************/

Остальное как тут

Автор: WolfHound
Дата: 14.10.03

(только надо исправить virtual delphi_dtor())

base* CreateMyBaseDescendant(boost::function<base*(float,float)> fn)
{
    return fn(2, 4);
}
int main()
{
    base* ptr=CreateMyBaseDescendant(get_delphi_ctor<some>());
    ptr->destroy();
    return 0;
}

Хотя boost::function в данном случае как из пушки по воробьям ну да ладно.

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

WH>>>В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция
FWP>>Если вы думаете, что программирование заканчивается на Windows и OLE, то вы несколько заблуждаетесь.
WH> Ты вобще о чем?
Это я о фабричной функции.

WH>>>Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
FWP>>Принимается! Замечательный ответ. Только когда вам отвечают таким же образом реакция почему-то другая
WH>И для чего кроме ГУИ это полезно? Вот толко не надо про сериализацию я на С++ и круче могу.

FWP>>Потом стало лениво писать на С — придумали С++
FWP>>Потом стало лениво писать на С++ — придумали ... Что придумали?
WH>.NET
А вот и нет. Сначала они придумали VB и Delphi. Потом Java. Потом почитали вот такие форумы и решили сделать .NET

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

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

ST>>В делфе нужно указывать вызов конструктора/деструктора базового класса, но в любом месте, а можно и не указывать.
WH>Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.
Это все было не то

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

Это поведение по умолчанию, которое можно изменить.

WH>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...

Почему ?

WH>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.

Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.

ST>>Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи — более сильная часть чем в С++.
WH>Как можно получить тотже эффект на С++ я уже говорил.
ST>>А чего не хватает относительно С++ — это краткости кода (begin, end etc.),
WH>Фигня
ST>>перегрузки операторов и шаблонов.
WH>О а вот это на столько круто что даже не все С++ники представляют.

В смысле ? Если не представляют, то .... зачем они делают ЭТО (в смысле, пишут на С++)

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

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

ST>>Память то надо все равно освободить
WH>А в С++ ни кто delete не пишет.
WH>

WH>struct some_t{};
WH>struct some_else_t
WH>{
WH>    std::auto_ptr<some_t> some;
WH>    some_else_t()
WH>        :some(new some_t)
WH>    {
WH>        throw 1;
WH>    }
WH>};
WH>

WH>Утечек не будет.

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

М.б. будет понятно из кода:

MyClass *c=NULL; 
try
{
  c = new MyClass();
} 
catch(...)
{
  delete c;
}

Если переменную с не инициализировать, то будет AV на вызове delete.

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

S>Здравствуйте, s.ts, Вы писали:
ST>>Понятие триггер из области СУБД,
S>да
ST>>но более точно отражает природу конструкторов.
S>нет
ST>>Конструирует объект скорее оператор new.
S>Ну конечно же нет

^- это мы оставим. Просто в дельфе и в С++ конструкторами называются немного разные вещи.

ST>>Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
S>В БД НЕТ объектов. Триггер на создание записи — совсем другая фишка.
Есть. Еще и какие — с полиморфизмом и прочими атрибутами ООП (см. для примера Oracle Types : http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_82a.htm).

ST>>Я то, видать (см. всю ветку), все правильно понимаю.
S>Смотрю. Не уверен
Предлагаю воздержаться от взаимных оценок.
ST>>Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).
S>Я в курсе. Это как раз очень плохо. Фактически, отсутствие способа размещать объекты на стеке мешает повысить эффективность операция распределения памяти для объектов со scope lifetime, т.е. порядок удаления которых в точности обратен порядку их создания. В Дельфи вообще другое понимание термина "конструктор". Половина войн с ++ программерами именно из-за этого. В плюсах конструкторы строже. Нужно понимать, что в плюсах создание объекта — двухстадийное, а в Дельфи — четырехстадийное (NewInstance/InitInstance/Create/AfterConstruction). В плюсах InitInstance отсутствует, поэтому нельзя трактовать конструктор, как обычную функцию. А в Дельфи можно вызывать конструктор сколько угодно раз на уже готовом объекте.

Конструктор С++ == InitInstance. В С++ отсутствует конструктор в том смысле, который вкладывается в дельфи, но его можно создать.

S>Зато дельфи реализует паттерн "абстрактная фабрика" натуральным образом. Мне до сих пор интересно, можно ли в точности воспроизвести семантику Delphi средствами плюсов, не влезая в компилятор.

Можно. Благо есть шаблоны и макросы. Но дополнительная работа Да и не нужно это. Просто разные стили написания программ на С++ и дельфи. А стиль порождается возможностями языка. Например, в дельфе очень широко используется 'паттерн "абстрактная фабрика"'