А я и не знал...

← →
Игорь Шевченко © (2010-03-05 16:57) [80]

Alkid © (05.03.10 16:55) [79]

> Вот потому-то и нельзя вызывать виртуальные методы из базовых
> классов

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

> То, что дельфи позволяет вызывать конструктор базового класса
> произвольным образом, или даже вообще его не вызывать -
> это глюк.

Это не глюк, а свойство языка. Точно также можно сказать, что слово friend в C++ это глюк, потому что в Delphi его нет (и близкого понятия - тоже).

← →
Anatoly Podgoretsky © (2010-03-05 16:59) [81]

> Alkid (05.03.2010 16:55:19) [79]

Суровые вы приплюснутые ребята, чуть что не по вашему, так глюк

← →
Alkid © (2010-03-05 17:03) [82]

> Игорь Шевченко © (05.03.10 16:57) [80]
> Вот потому и в стандарте приняли, что нельзя управлять порядком
> вызова.

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

Если позволить менять порядок вызовов конструкторов (т.е. сначала наследника, потом базового), то можно будет обращаться к методам подобъекта базового ДО того, как у него отработает конструктор.

> Это не глюк, а свойство языка. Точно также можно сказать,
> что слово friend в C++ это глюк, потому что в Delphi его
> нет (и близкого понятия - тоже).

В Дельфи все классы пределах юнита френды по умолчанию, так что близкое понятие таки есть :)

Что касается определения "глюк".
Выражусь иначе - я считаю, что это недостаток дизайна языка.

← →
Alkid © (2010-03-05 17:04) [83]

> Anatoly Podgoretsky © (05.03.10 16:59) [81]

Вай, зачем ярлыки вешать, дарагой!

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

← →
GrayFace © (2010-03-05 17:05) [84]

oxffff © (05.03.10 14:57) [48]
Берем перекрываем аллокатор newinstance без очистки на 0 для неуправляемых объектов. Получаем исключение на free. Гарантий нет!!!
Это проблема того, кто перекрыл. Если кто-то хочет вызвать ошибку, то он найдет миллион способов это сделать.

@!!ex © (05.03.10 15:29) [54]
Неудачный пример.
В первую очередь потому, что отличается от общего стиля остальной бибилиотеки, что плохо.
Если делать в общем стиле, нужно делать через LoadFromFile.
Я бы сделал через LoadFromFile,SaveToFile.
Неудачный для тебя :)
То, что такой конструктор есть - это правильно, т.к позволяет писать
with TMemIniFile.Create("options.ini") do try ... finally Free; end;
Более гибко было бы добавить конструктор без параметров и сделать изменяемым FileName, но конструктор с параметром оставить - от него только польза.

Alkid © (05.03.10 16:14) [68]
Согласно стандарту в A::A() будет вызван метод A::F(), что сохраняет озвученный выше инвариант. Если бы в A::A() вызывалась самая перегруженная реализация, т.е. B::F(), то мы бы имели вызов метода класса B до вызова конструктора класса. В приведенном примере это будет означать стрельбу по нулевому указателю, т.е. AV.

Так что этот пункт в Стандарте появился неслучайно, и очень продумано.

В Дельфи:
constructor B.Create(); begin message:= "Hello, World!"; inherited Create(); end;
Вот это - действительно продуманно.

← →
Alkid © (2010-03-05 17:08) [85]

> GrayFace © (05.03.10 17:05) [84]
> Вот это - действительно продуманно.

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

← →
GrayFace © (2010-03-05 17:14) [86]

При создании наследника в любом случае надо знать, что допустимо делать с базовым классом.

← →
Alkid © (2010-03-05 17:16) [87]

> GrayFace © (05.03.10 17:14) [86]

Когда вообще допустимо пользоваться экземпляром ДО его конструирования?

← →
Игорь Шевченко © (2010-03-05 17:18) [88]

Alkid © (05.03.10 17:03) [82]

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

В Delphi другой инвариант. На этом инварианте, как и на виртуальных конструкторах, довольно много построено. Другой язык, другие танцы - ну так вышло :)

> Если позволить менять порядок вызовов конструкторов (т.е.
> сначала наследника, потом базового), то можно будет обращаться
> к методам подобъекта базового ДО того, как у него отработает
> конструктор.

Насколько мне память не изменяет, это связано еще и с множественным наследованием - то есть, на каком-то этапе неизвестно кого вызывать. В языках, где нет множественного наследования реализации, такой проблемы не существует.

> В Дельфи все классы пределах юнита френды по умолчанию,
> так что близкое понятие таки есть :)

Смешно.

← →
Alkid © (2010-03-05 17:27) [89]

> Игорь Шевченко © (05.03.10 17:18) [88]
> В Delphi другой инвариант. На этом инварианте, как и на
> виртуальных конструкторах, довольно много построено. Другой
> язык, другие танцы - ну так вышло :)

Какой инвариант?

> Насколько мне память не изменяет, это связано еще и с множественным
> наследованием - то есть, на каком-то этапе неизвестно кого
> вызывать. В языках, где нет множественного наследования
> реализации, такой проблемы не существует.

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

> Смешно.

Поясни. Разве я не прав, что классы в одном юните видят приватные/защищенные члены другого? Если да, то чем это принципиально отличается от концепции дружественных классов в С++?

← →
Владислав © (2010-03-05 17:28) [90]

> Alkid © (05.03.10 17:08) [85]

По этому поводу уже написано здесь:

> Anatoly Podgoretsky © (05.03.10 15:05) [49]

← →
Alkid © (2010-03-05 17:38) [91]

> Владислав © (05.03.10 17:28) [90]

Не аргумент :) Его можно под любое ограничение, заложенное в язык, подвести. Например, под инкапсуляцию данных. Зачем нам защищенные и приватные члены? Даешь полный доступ ко всему!

← →
Игорь Шевченко © (2010-03-05 17:39) [92]

Alkid © (05.03.10 17:27) [89]

> Какой инвариант?

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

> Поясни. Разве я не прав, что классы в одном юните видят
> приватные/защищенные члены другого?

Видят. Без слова strict. В пределах одного модуля. Friend в C++ несколько иначе работает, не находишь ? Там правда и модулей нету :)

> Не совсем. Множественное наследование порождает свои проблемы,
> но среди них нет проблемы с порядком вызова конструкторов.
>

Я имел в виду не с порядком вызова конструкторов, а с возможностью вызова виртутальных методов в конструкторах.

Кстати, насчет порядка вызовов, вот такой пример (на Delphi):

type TFooForm = class(TForm) .... procedure OnCreate (Sender: TObject); private FBar: TFooBar; public constructor Create (AOwner: TComponent; ABar: TFooBar); reintroduce; end; procedure TFooForm.OnCreate (Sender: TObject); begin with FBar do begin Bazz; Boom; Bang; end; .... end; constructor TFooForm.Create (AOwner: TComponent; ABar: TFooBar); begin FBar := ABar; inherited Create (AOwner); end;

Так как OnCreate вызывается конструктором базового класса (при OldCreateOrder, начиная с какой-то версии Delphi), каким образом можно передать параметр классу для того, чтобы он имел смысл в обработчике OnCreate ?

← →
GrayFace © (2010-03-05 18:14) [93]

Alkid © (05.03.10 17:16) [87]
Когда вообще допустимо пользоваться экземпляром ДО его конструирования?
Когда вызывается код конструктора объект уже инициализирован нулями и проставлены все указатели на таблицы виртуальных функций. Конструкторы выполняют только последующую инициализацию. Что недопустимого?

А инварианты не такие уж инвариантные:
class A { public: int val; A() { val = 5; } A(int v) { val = 5; } int ShowVal() { if(val == 5) MessageBoxA(0, "5", "", 0); else MessageBoxA(0, "not 5", "", 0); return 0; } }; class B : public A { public: B() : TA(ShowVal()) {} };
В VC++ запускается и показывает "not 5".

← →
GrayFace © (2010-03-05 18:16) [94]

B() : TA(ShowVal()) {}
имеется в виду
B() : A(ShowVal()) {}

← →
Alkid © (2010-03-05 18:23) [95]

> Игорь Шевченко © (05.03.10 17:39) [92]
> Ручное управление порядком вызова конструкторов, вызовом
> методов предков.

Это не инвариант. Это как раз его отсутствие.

> Видят. Без слова strict. В пределах одного модуля. Friend
> в C++ несколько иначе работает, не находишь ? Там правда
> и модулей нету :)

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

> Я имел в виду не с порядком вызова конструкторов, а с возможностью
> вызова виртутальных методов в конструкторах.

Все правильно - возможность контролировать порядок вызовов конструкторов и возможность вызывать виртуальные методы в конструкторе - вещи комплементарные. Второе не имеет смысла без первого (вызовы всегда будут в не созданный объект, что небезопасно по определению. Разработчики сказали "А" и вполне обоснованно сказали "Б".

Но я критикую именно "А". Да, это фитча дельфи, но я считаю, что это фитча плохая.

> Так как OnCreate вызывается конструктором базового класса
> (при OldCreateOrder, начиная с какой-то версии Delphi),
> каким образом можно передать параметр классу для того, чтобы
> он имел смысл в обработчике OnCreate ?

Только поменяв порядок вызова конструкторов :)
Но надо понимать, что в таком случае по всей цепочке наследования до того класса, где вызывается OnCreate, конструкторы должны быть устроены так: "сначала свой код, потом вызов предка".

Но у меня есть вопрос - а зачем вызывать OnCreate из базового класса? Что мешает вызвать его в конструкторе TFooForm?

← →
Игорь Шевченко © (2010-03-05 18:29) [96]

Alkid © (05.03.10 18:23) [95]

> Разница косметическая

Фигасе косметическая. friend объявленный в классе дает возможность доступа к своим потрохам из любого места, лишь бы домогающийся был правильного типа. А в Delphi доступайся кто хочет, но только в пределах модуля. Это хорошо, когда модуль есть, не правда ли ? А когда его нету - и варенья тоже нету.

> Да, это фитча дельфи, но я считаю, что это фитча плохая

А я не вижу ничего плохого. Свойство языка, какое есть, такое есть.

> Но у меня есть вопрос - а зачем вызывать OnCreate из базового
> класса? Что мешает вызвать его в конструкторе TFooForm?

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

← →
Alkid © (2010-03-05 18:31) [97]

> GrayFace © (05.03.10 18:14) [93]
> А инварианты не такие уж инвариантные:

В С++ тоже дыр хватает, кто же спорит-то? ;)

> Когда вызывается код конструктора объект уже инициализирован
> нулями и проставлены все указатели на таблицы виртуальных
> функций. Конструкторы выполняют только последующую инициализацию.
> Что недопустимого?

Очень просто - не всегда можно и удобно написать класс, у которого инициализированные нулями поля представляет собой валидное состояние экземпляра. Представь, что одно из полей - ссылка на другой объект и при вызове метода класса вызывается метод по этой ссылке. Если в ссылке будет ноль, то ты получаешь AV/NRE.

Проверять каждый раз каждое поле на то, что оно было проинициализировано? Заставлять каждого потребителя твоего класса знать тонкости реализации? Смотри мой пример в [68], он являет собой похожий пример. В С++ там, конечно, в message будет мусор, а не ноль, но это не принципиально различие, будет AV не по нулевому адресу, а по случайному. Подобный пример можно написать для C# и там будет NRE.

← →
GrayFace © (2010-03-05 18:38) [98]

Alkid © (05.03.10 18:31) [97]
Заставлять каждого потребителя твоего класса знать тонкости реализации?
Заставить их не вызывать функции класса до вызова его конструктора.

← →
Alkid © (2010-03-05 18:50) [99]

> Игорь Шевченко © (05.03.10 18:29) [96]
> Фигасе косметическая. friend объявленный в классе дает возможность
> доступа к своим потрохам из любого места, лишь бы домогающийся
> был правильного типа. А в Delphi доступайся кто хочет, но
> только в пределах модуля. Это хорошо, когда модуль есть,
> не правда ли ? А когда его нету - и варенья тоже нету.

Отсутствие модулей в С++ - это его большой недостаток, не спорю :)
Что касается friend/strict - то да, я таки считаю, что это разные реализации одной идеи со своими плюсами и минусами. Просто ты сформулировал, что в Дельфи нет "близкого понятия". Я не согласен.

> А я не вижу ничего плохого. Свойство языка, какое есть, такое есть.

Бывают удачные свойства, и неудачные. Это я отношу к неудачным.
Так же как, например, отсутствие модульности в С++.

Почему я считаю это свойство неудачным? Потому что автор класса должен иметь в виду возможность вызова метода у его класса до того, как будет вызван конструктор. Если автор этого не сделает, то он создает потенциально небезопасный класс. Если он делает, то ему придется нагружать код параноидальными проверками на то, что метод вызван после отработки конструктора. Можно, конечно, говорить о стеклянном члене, о том, что умные программисты не будут нарушать правил, но это действует только до тех пор, пока аудитория, использующая код, ограничена.

← →
Alkid © (2010-03-05 18:52) [100]

> GrayFace © (05.03.10 18:38) [98]

А зачем тогда вообще давать программисту в руки такую возможность?

← →
Игорь Шевченко © (2010-03-05 19:08) [101]

Alkid © (05.03.10 18:50) [99]

> Просто ты сформулировал, что в Дельфи нет "близкого понятия".
> Я не согласен.

Ну так его же нету. Можно быть несогласным, от этого понятие не появится :)

В С++ доступ к телу дается для доверенных типов отовсюду. Ну нету там возможности выделить модули. Но только для доверенных типов. В Delphi наоборот, доступ открыт любому типу, но только внутри модуля и если не указано слово strict.

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

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

← →
GrayFace © (2010-03-05 19:30) [102]

Alkid © (05.03.10 18:52) [100]
А зачем тогда вообще давать программисту в руки такую возможность?
Чтобы он сам решал, когда ей пользоваться. Конкретно эта возможность (существующая и в VC++) если и нужна, то очень редко.

А возможность вызова виртуальных функций нужна, например, для такого:
TA = class public procedure Open(const FileName: string); virtual; constructor Create; constructor Create(const FileName: string); // вызывает Open end; TB = class public procedure Open(const FileName: string); override; end;
В C++ в такой ситуации, перекрывая Open (или любую функцию, которую вызывает Open!), надо имплементить в наследнике и Create(const FileName: string). Это вопиющая неочевидость, да еще мы должны точно знать, что делает Create(const FileName: string) базового класса и это должно оставаться неизменным.

← →
Piter © (2010-03-05 20:16) [103]

по-моему, вы сейчас спорите, что зеленый цвет лучше красного. И приплетаете сюда дифракцию...

← →
Kerk © (2010-03-05 20:38) [104]

> @!!ex © (05.03.10 15:48) [60]
>
> Delphi без VCL имеет мало ценности.
> Писать в разных стилях в пределах одного проекта - плохо.

1) В больших проектах собственный код и VCL пересекаются только краешком;
2) Подход к разработке, где в конструкторе выполняется вся необходимая инициализация, позволяет писать более читаемый код. Т.к. программист сразу видит какие данные нужны для инициализации и после вызова конструктора сразу имеет пригодный к работе объект;
3) Структура VCL обусловлена поддержкой визуальной настройки в design time, непонятно зачем копировать такой подход в классах для того не предназначенных.

← →
Kerk © (2010-03-05 20:42) [105]

В частности, из-за того, что ты отстаиваешь, VCL не будет никогда полноценно поддерживать многопоточность.

← →
Alkid © (2010-03-05 20:45) [106]

> Игорь Шевченко © (05.03.10 19:08) [101]
> Ну так его же нету. Можно быть несогласным, от этого понятие
> не появится :)

Давай сойдемся на том, что понятие "близость понятий" - субъективное и закончим эту часть спора? :)

> Ну вот VCL как-то обходится без паранойи. На самом деле
> конечно никто параноей не страдает, вызовут не вовремя -
> получат по морде (ну или иной побочный эффект), так что
> слухи о навороченных способах проверки вызовов до конструктора
> сильно преувеличены.

Я знаю, что без паранойи. Что касается "по морде" - оно, конечно, да, но лучше, что бы этот класс ошибок был вообще исключен. Это как со статической типизацией. В принципе можно и без нее, она накладывает свои ограничения, но она дает определенные ништяки, позволяя устранять целые классы ошибок в программе.

> GrayFace © (05.03.10 19:30) [102]

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

← →
Alkid © (2010-03-05 20:47) [107]

> Piter © (05.03.10 20:16) [103]

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

← →
vuk © (2010-03-05 21:03) [108]

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

Alkid © (05.03.10 20:45) [106]

> Давай сойдемся на том, что понятие "близость понятий" -
> субъективное и закончим эту часть спора? :)

Давай сойдемся и закончим.

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

С этим тоже не буду спорить. При огульном использовании типа variant, например, ошибки времени компиляции переносятся на время выполнения.

Kerk © (05.03.10 20:38) [104]

> 3) Структура VCL обусловлена поддержкой визуальной настройки
> в design time, непонятно зачем копировать такой подход в
> классах для того не предназначенных.

С этого момента подробнее. Даже будучи созданными с конструкторами без параметров классы VCL успешно инициализируются значениями по умолчанию. Еще существуют классы RTL, которым визуальные настройки вообще безразличны.

> 1) В больших проектах собственный код и VCL пересекаются
> только краешком;

С этого момента опять же, подробнее - код исполняемой системы любой среды, будь то .Net, Java и прочие VBRUN и не должен "пересекаться". С учетом его должен быть свой код спроектирован, только и всего.

> Игорь Шевченко © (05.03.10 21:08) [109]
> С этого момента подробнее. Даже будучи созданными с конструкторами
> без параметров классы VCL успешно инициализируются значениями
> по умолчанию. Еще существуют классы RTL, которым визуальные
> настройки вообще безразличны.

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

Про остальной RTL хотелось бы конкретных примеров. Тут уже вспоминали TIniFile и TThread, которые принимают параметры инициализации в конструктор. TStringList, который вспоминался как контрпример, дополнительно инициализировать не нужно, создал и сразу работай.

> С этого момента опять же, подробнее - код исполняемой системы
> любой среды, будь то .Net, Java и прочие VBRUN и не должен
> "пересекаться". С учетом его должен быть свой код спроектирован,
> только и всего.

Под пересечением я имел ввиду связность кода. Как правило какое-то взаимодействие с VCL осуществляет относительно небольшой слой кода программы.

Kerk © (05.03.10 21:22) [110]

> TStringList, который вспоминался как контрпример, дополнительно
> инициализировать не нужно, создал и сразу работай.

Да его и нечем особенно инициализовать.

> Про остальной RTL хотелось бы конкретных примеров

если примеры классов, имеющих конструкторы с параметрами, то в Db их много.

> Как правило какое-то взаимодействие с VCL осуществляет относительно
> небольшой слой кода программы

Это смотря какая программа. Всяческие обработчики событий, работа с наборами данных и т.п. таки подразумевает взаимодействие с VCL

> Игорь Шевченко © (05.03.10 21:30) [111]
> если примеры классов, имеющих конструкторы с параметрами,
> то в Db их много.

Ну дык я как раз и отстаиваю такой подход, что вся необходимая инициализация должна производится в конструкторе :)

> Это смотря какая программа. Всяческие обработчики событий,
> работа с наборами данных и т.п. таки подразумевает взаимодействие
> с VCL

Тут я не буду спорить. Просто в общем случае нет причин полностью копировать подход к разработке из VCL (конструкторы без параметров). Тем более, что эти два подхода не конфликтуют.

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

Значит, не зря все же, а?
:o)

> Kerk © (05.03.10 21:47) [114]

К счастью, он довольно большой.
:o)

Да и нет нужды - каждый про себя и сам знает.
:o)

Kerk © (05.03.10 21:37) [112]

> Ну дык я как раз и отстаиваю такой подход, что вся необходимая
> инициализация должна производится в конструкторе :)

Так для инициализации не всегда нужны параметризованные конструкторы.

> Игорь Шевченко © (05.03.10 21:56) [116]
> Так для инициализации не всегда нужны параметризованные
> конструкторы.

В случае TStringList, да. Потому там конструктор без параметров.
Или ты о другом?

Kerk © (05.03.10 21:57) [117]

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

> Игорь Шевченко © (05.03.10 22:11) [118]

Ну значит не нужны им эти параметры.

Я напомню, с чего начался разговор:

> @!!ex © (05.03.10 10:00) [5]
>
> И вообще, конструктор не должен делать ничего такого, что
> может вызвать исключение.
> Для этого есть другие методы, например Init и LoadFromFile.
> ..
> По хорошему конструктор должен только инициализировать объект
> значениями по умолчению.
> А настраиватся объект должен отдельно.

Я с этим не согласен. Если инициализация есть, то она должна быть произведена в конструкторе. Если нет, то и проблемы нет :)

Kerk © (05.03.10 22:14) [119]

> > И вообще, конструктор не должен делать ничего такого,
> что
> > может вызвать исключение.
> > Для этого есть другие методы, например Init и LoadFromFile.
>

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

А я и не знал... Найти похожие ветки