Взгляд на С++ с другой стороны.

← →
vlad-mal © (2007-01-16 12:15) [80]

> Вообще-то не класс, а пространство имен. Но модульности
> это не добавляет.

А что нужно-то, от модульности такого особенного, что там есть?
Доступ к закрытым членам другого класса в переделах модуля? :)

← →
Игорь Шевченко © (2007-01-16 12:16) [81]

Ega23 © (16.01.07 11:54) [63]

> А группа классов, конечно же, по наследованию в разных ветках
> сидит, да?

Чаще всего да.

Странные люди, ей-богу. Для того, чтобы сравнивать два языка, их надо хотя бы знать.

← →
GRAND25 © (2007-01-16 12:17) [82]

> Тем не менее, мне понравилось. К примеру, нет нужды переменную
> цикла где-то далеко описывать.

Это разврат!

← →
clickmaker © (2007-01-16 12:18) [83]

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

← →
vlad-mal © (2007-01-16 12:18) [84]

> GRAND25 © (16.01.07 12:17) [82]

:)

← →
Бурундук © (2007-01-16 12:21) [85]

2 clickmaker © (16.01.07 12:00) [66]
>меня, например, несколько напрягают все эти initialization/finalization

В плюсах ты можешь получить ровным счётом то же самое
с помощью глобальных объектов.

Потом, честно говоря, сам я как-то никогда не ощущал, что VCLные
initialization/finalization мешают мне в понимании логики.

← →
GRAND25 © (2007-01-16 12:22) [86]

Удалено модератором

← →
vlad-mal © (2007-01-16 12:22) [87]

> Странные люди, ей-богу. Для того, чтобы сравнивать два языка,
> их надо хотя бы знать.

Ну нафик. Так не интересно. Если знаешь - о чем разговаривать?

← →
vuk © (2007-01-16 12:24) [88]

to clickmaker © (16.01.07 12:15) [79]:
>каким образом?
.c/.h и их аналоги в cpp. При этом в заголовочных файлах применяются меры (при помощи директив условной компиляции) для того, чтобы текст не был при компиляции включен более одного раза.

← →
Игорь Шевченко © (2007-01-16 12:27) [89]

vuk © (16.01.07 12:24) [88]

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

Модульность туда же.

Церковь святого Вирта :)

← →
vlad-mal © (2007-01-16 12:30) [90]

А что, большая разница, указать используемый модуль в секции uses или использовать заголовочный файл?

← →
GRAND25 © (2007-01-16 12:30) [91]

Удалено модератором
Примечание: Флудить завязываем

← →
clickmaker © (2007-01-16 12:32) [92]

> [88] vuk © (16.01.07 12:24)
> to clickmaker © (16.01.07 12:15) [79]:
> >каким образом?
> .c/.h и их аналоги в cpp.

да? для меня это как раз не было никогда аналогом модульности... именно эта связка c/h.
ну пространства имен - еще куда ни шло

← →
xayam © (2007-01-16 12:37) [93]

> GRAND25 © (16.01.07 10:43) [20]
> Очень хорошая и правильная ветка для дельфийского форума!
> Идеологически выдержанная. Респект!

Переходим на паскаль!

← →
@!!ex © (2007-01-16 12:43) [94]

Статься отстонойная.
Да... С++ позволяет ТАКОЙ огород городить... Жуть просто...
Однако это не мешает писать на нем эффективно и понятно.
А то что основная масса не знает его на достаточном уровне... Разве это вина языка??
Лично убедился, что код на нем может быть понятен не хуже дельфи. Зависит от того кто и что писал.

← →
TohaNik © (2007-01-16 12:48) [95]

> @!!ex © (16.01.07 12:43) [94]
> Статься отстонойная.Да... С++ позволяет ТАКОЙ огород городить.
> .. Жуть просто...

Угу, место для разврата и падения нравов:)

← →
vuk © (2007-01-16 13:03) [96]

to Игорь Шевченко © (16.01.07 12:27) [89]:
>делается все, чтобы не дай Аллах, они не мучились, забыв включить
>заголовочный файл и.т.д
При наличии модульности такой проблемы нет вообще.

>Церковь святого Вирта :)
Ну... Вирт здесь, скажем так, ни при чем.

← →
Игорь Шевченко © (2007-01-16 13:18) [97]

vuk © (16.01.07 13:03) [96]

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

← →
Reindeer Moss Eater © (2007-01-16 13:55) [98]

> Тем не менее, мне понравилось. К примеру, нет нужды переменную
> цикла где-то далеко описывать.

Это разврат!

Да нет. Это как раз удобно - раз. И читабельность кода не снижает а повышает. особенно если процедура в один экран не влезает.

← →
vlad-mal © (2007-01-16 14:08) [99]

> Да нет. Это как раз удобно - раз. И читабельность кода не
> снижает а повышает. особенно если процедура в один экран
> не влезает.

А еще бывает, что вроде метод короткий, а в нем локальные методы, куча целая (я про Delphi). От главного begin-end до объявления переменных - глаза вылупишь. Какая уж там читабельность. Тут тоже как раз пригодилось бы.

← →
iZEN © (2007-01-16 14:44) [100]

Лекарство от C++ создано более пятнадцати лет назад.
Правда немного жаль, что оно само отчасти написано на С++. :)))

← →
oxffff © (2007-01-16 15:00) [101]

> Бурундук © (16.01.07 11:08) [24]
> Ega23 © (16.01.07 10:53) [22]
> Можно, если известен базовый класс с виртуальным конструктором.
>

Для динамического инстанцирования метакласса не обязательно наличие виртуального конструктора.

См. реализацию ClassCreate.

C++
-Плавающий VTB. Реально в современной жизни, где в большинстве классов присутствуют виртуальные функции, наличие плавающего VTB ограничивает гибкость программ.

Классы в С++ представляют собой лес классов, в delphi это дерево классов.

Конечно можно в С++ определить базовый класс и пусть все классы проекта наследуют от него. Все вроде бы гладко.

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

Можно предположить пусть все проекты наследуют от одного класса.
Но реально ли это.

В Delphi все это учтено.

А как все просто.

Offset Type Description
-76 Pointer pointer to virtual method table (or nil)
-72 Pointer pointer to interface table (or nil)
-68 Pointer pointer to Automation information table (or nil)
-64 Pointer pointer to instance initialization table (or nil)
-60 Pointer pointer to type information table (or nil)
-56 Pointer pointer to field definition table (or nil)
-52 Pointer pointer to method definition table (or nil)
-48 Pointer pointer to dynamic method table (or nil)
-44 Pointer pointer to short string containing class name
-40 Cardinal instance size in bytes
-36 Pointer pointer to a pointer to ancestor class (or nil)
-32 Pointer pointer to entry point of SafecallException method (or nil)
-28 Pointer entry point of AfterConstruction method
-24 Pointer entry point of BeforeDestruction method
-20 Pointer entry point of Dispatch method
-16 Pointer entry point of DefaultHandler method
-12 Pointer entry point of NewInstance method
-8 Pointer entry point of FreeInstance method
-4 Pointer entry point of Destroy destructor
0 Pointer entry point of first user-defined virtual method
4 Pointer entry point of second user-defined virtual method

Разве не это гибкость, какой нет и не может быть в С++.
Далее простые два метода. Но насколько они мощны и востребованы.

AfterConstruction method
BeforeDestruction method

Попробуй сделать на С++.

Будешь в каждом конструкторе дописивать в конце, и декструторе в начале.
А здесь delphi все сделает за тебя.

Разве не это гибкость.

Далее делегирование реализации классу или интерфейсу.
Разве это не облегчает жизнь.

← →
Игорь Шевченко © (2007-01-16 15:35) [102]

> Попробуй сделать на С++.

Ты не представляешь, что можно сделать на С++.

← →
oxffff © (2007-01-16 15:44) [103]

> Игорь Шевченко © (16.01.07 15:35) [102]
>
> > Попробуй сделать на С++.
>
>
> Ты не представляешь, что можно сделать на С++.

Чтобы вы много не говорили :)

Реализуйте на С++ автоматический вызов методов
AfterContruction, BeforeDestruction.

← →
Игорь Шевченко © (2007-01-16 15:48) [104]

oxffff © (16.01.07 15:44) [103]

Без проблем. Наследуй все классы от одного (как в Delphi), в нем установи соответствующую логику.

← →
clickmaker © (2007-01-16 16:05) [105]

> [103] oxffff © (16.01.07 15:44)

вот ведь... любая тема про языки программизма рано или поздно выливается в меренье пиписьками )

← →
oxffff © (2007-01-16 16:10) [106]

> Без проблем. Наследуй все классы от одного (как в Delphi),
> в нем установи соответствующую логику.

Продемонстрируйте как это сделать

← →
Игорь Шевченко © (2007-01-16 16:12) [107]

oxffff © (16.01.07 16:10) [106]

Посмотри, как это сделано в System.pas

← →
Бурундук © (2007-01-16 16:15) [108]

oxffff © (16.01.07 15:00) [101]
>См. реализацию ClassCreate.

_ClassCreate - это внутренняя ф-я, подготавливающая объект к конструированию.
Ответственна за вызов NewInstance и за разрушение объекта
в случае возникновения эксепшна в конструкторе.
Компилятор неявно встраивает её в конструктор.
Сама она сконструировать объект не может.

Игорь Шевченко © (16.01.07 15:48) [104]
>Без проблем. Наследуй все классы от одного (как в Delphi),
>в нем установи соответствующую логику.

Трудность в том, что ни из конструктора, ни из
деструктора нельзя вызвать виртуальную функцию.

Придётся городить что-нибудь типа

template<class T>
T* Create(аргументы)
{
// Check T is BaseClass
T * t = new T(аргументы);
t->AfterCreate();
}
Или есть пути проще? Я не очень хорошо знаю плюсы...

>Игорь Шевченко
>Посмотри, как это сделано в System.pas

Так вот незадача в delphi компилятор подставляет в код конструктора вначале вызов ClassCreate, в конце вызов АfterConstruction.

АfterConstruction вызается после вызова всех конструкторов!!!
"Есть там регистр такой dl". Не мне вам рассказывать про это.

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

Даже несмотря на такой изврат. Работать не будет. Почему?

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

Вот выдержка из MSDN

Calling Member Functions and Virtual Functions from Within Constructors
It is usually safe to call any member function from within a constructor because the object has been completely set up (virtual tables have been initialized and so on) prior to the execution of the first line of user code. However, it is potentially unsafe for a member function to call a virtual member function for an abstract base class during construction or destruction.

Constructors can call virtual functions. When virtual functions are called, the function invoked is the function defined for the constructor"s own class (or inherited from its bases). The following example shows what happens when a virtual function is called from within a constructor:

Copy Code
// specl_calling_virtual_functions.cpp
// compile with: /EHsc
#include <iostream>

using namespace std;
class Base
{
public:
Base(); // Default constructor.
virtual void f(); // Virtual member function.
};

Base::Base()
{
cout << "Constructing Base sub-object\n";
f(); // Call virtual member function
} // from inside constructor.

void Base::f()
{
cout << "Called Base::f()\n";
}

class Derived : public Base
{
public:
Derived(); // Default constructor.
void f(); // Implementation of virtual
}; // function f for this class.

Derived::Derived()
{
cout << "Constructing Derived object\n";
}

void Derived::f()
{
cout << "Called Derived::f()\n";
}

int main()
{
Derived d;
}

When the preceding program is run, the declaration Derived d causes the following sequence of events:

The constructor for class Derived (Derived::Derived) is called.

Prior to entering the body of the Derived class"s constructor, the constructor for class Base (Base::Base) is called.

Base::Base calls the function f, which is a virtual function. Ordinarily, Derived::f would be called because the object d is of type Derived. Because the Base::Base function is a constructor, the object is not yet of the Derived type, and Base::f is called.

Игорь Шевченко ждем от вас вашу реализацию.

> clickmaker © (16.01.07 16:05) [105]
>
> > [103] oxffff © (16.01.07 15:44)
>
> вот ведь... любая тема про языки программизма рано или поздно
> выливается в меренье пиписьками )

Как ни жаль.
Здесь вы безусловно правы.

Если и обращать внимание на языки, то наверно не на C++,C#.

Возможно стоит обратить внимание на языки D,smalltalk

oxffff © (16.01.07 16:35) [109]

Я же говорю, наследуйся от базового класса, конструируй его через helper, в helper"е вызывай виртуальный метод AfterConstruction. В Delphi разработчики комилятора это за тебя уже сделали - ну и что ?

процитирую сам себя:

> > oxffff © (15.01.07 23:12) [11]
>
> > Есть такой паттерн class factory, так вот его придумали
> > для С++ поскольку нет динамического инстанцирования.
>
> там еще много чего нет... и ничего, живут люди...
> да и дельфи тоже МНОГО ЧЕГО нет, но если я об этом заикнусь,
> то налетит куча борцунов, которые мне быстро докажут, что
> и БЕЗ ЭТОГО жить можно...
> так что это вопрос скорее философии и личных предпочтений/трудолюбия/лени

если человек и через 100 постингов долбится туда же, то кто ему доктор?... :-/

> В Delphi разработчики комилятора это за тебя уже сделали
> - ну и что ?

А то, что придется постоянно вызывать AfterConstruction в каждом классе.
Плюс придется ввести параметр, аналог использования регистра dl.
Только вот незадача конструктор по умолчанию не принимает параметров (ну или с параметрами но только по умолчанию). Что делать придется ввести в класс поле(аналог регистра Dl). Во как.

Это удобно?

> Если и обращать внимание на языки, то наверно не на C++,C#.

ну шарп - это отдельная история. Его рассматривать в отрыве от дотнета вообще бессмысленно

> [37] GRAND25 © (16.01.07 11:29)

Вообще-то, это требование. Он должен не только быть виртуальным, но и перекрывать унаследованный.

> [24] Бурундук © (16.01.07 11:08)

Э, кстати. Конструктор - метод класса, он по определению статический AFAIK. Сама Delphi отыскивает нужный класс и его конструктор по RTTI AFAIK.
> [90] vlad-mal © (16.01.07 12:30)

Разница есть. Иногда довольно заметная.

oxffff © (16.01.07 17:00) [113]

Если через helper создавать экземпляры классов, то каждый раз вызывать не придется (все в точности как в Delphi).

Насчет удобно/неудобно - скажи это миллионам мух, программирующим на С/C++

Я повторю еще раз - С/C++ являются де-факто стандартом языка разработки.

2 Vga © (16.01.07 17:06) [115]
>Конструктор - метод класса, он по определению статический AFAIK

Во-первых, конструктор - не метод класса, хотя
синтаксис вызова и похож. Конструктор - это конструктор.

Во-вторых, метод класса тоже может быть виртуальным.

← →
Kirr. (2007-01-16 18:06) [118]

> oxffff © (16.01.07 17:00) [113]
>
>
> > В Delphi разработчики комилятора это за тебя уже сделали
> > - ну и что ?
>
>
> А то, что придется постоянно вызывать AfterConstruction
> в каждом классе.

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

> Будешь в каждом конструкторе дописивать в конце, и декструторе
> в начале.

А тут прямо написанно, что это такие мучения постоянно дописывать! Кошмар! А чего стоит постоянно писать: constructor и destructor? А procedure и function ? Вообще! И ниче никто не жалуется. А тут, понимаешь, дополнительный вызов написать проблема.

Меня больше напрягает отсутвие автоматических объектов в Delphi. Даже какой-нибудь маленький объект с парой полей приходиться создавать динамически. И ниче, пишу и сильно не напрягаюсь.

А уж чего в Java есть или нет... Это вообще отдельный разговор. И опять же, пишу используя то, что есть - напрягаться не надо.

> Э, кстати. Конструктор - метод класса, он по определению
> статический AFAIK. Сама Delphi отыскивает нужный класс и
> его конструктор по RTTI AFAIK.

> Во-вторых, метод класса тоже может быть виртуальным.

Конструктор может быть и виртуальным.

> Zeqfreed (16.01.2007 10:39:19) [19]

> Хороший дизайн на народе будет смотреться нелепо.

Хороший дизайн на народе - это антинародно

Взгляд на С++ с другой стороны. Найти похожие ветки