[ivank]

vasketsov
Спор продолжать не хочу, но только одну вещь добавлю -- C++ есть везде, где есть C, т.к. существуют C++-frontend'ы -- компиляторы из C++ в C. Первые компилеры C++ (cfront в частности) компилировали всё в C, т.к. "это портабельный ассемблер". Сейчас наиболее популярный фронтенд это *Comeu. Его можно у них в onlin'е пощупать -- http://www.comeaucomputing.com .

[Daiv]

[rus]
Ne pomnyu - gde to sprashival... no zabyl gde ...
PO kakoi mukulature del'fei s samogo - 0 uchit' ?

[/rus]

[ivank]

Daiv
а тему новую создать не судьба?

[Daiv]

ivank
dumaesh stoit? nu sozdam, sozdam...

[Guest]

Какая на... Делфи. С++ быстрее, компактнее, мощнее. Билдер - вот то, что нужно.

[Crew]

...Почему-то я себя почувствовал маленьким и *несчастным

ivank
Можно пример какого-нибудь применения множественного наследования, не код я имею ввиду, а просто идею.. кроме кнопочек с картинками и кроме потокового ввода-вывода, который соединяет в себе наследование от класса вывода и класса ввода (или может соединять)
И еще очень интересует вопрос переопределения имен при множественном наследовании. При достаточно больших классах не будут ли затраты.....слишком большими.


[s]Исправлено: Crew, 0:05 11-02-2003[/s]

[vasketsov]

ivank

C++ есть везде, где есть C

Пока еще нет.
Ну вот не сделали еще компилятор, и все, руки, видать, не дошли руки. Даже компилятора с языка ассемблера там еще нет, на парситеках.

[Vaulter]

mj
смотря как писать. если руки кривые то хоть делфи суй в них, хоть си++

[ivank]

vasketsov
Не понял... Фронт-енды C++ -> C есть? Есть, соответственно для всего, для чего есть компилятор C можно откомпилять плюсовую программу (если ресурсов хватит). Где я не прав?

Crew
Множественное наследование можно применять где угодно, где приходится совмещать "два в одном".

И еще очень интересует вопрос переопределения имен при множественном наследовании. При достаточно больших классах не будут ли затраты.....слишком большими.

Какие затраты, в смысле на что?

[Crew]

ivank

Какие затраты, в смысле на что?

Проблема неоднозначности
Например: оба родителя используют метод add(int)
И предположим, что получившийся класс использует оба метода и ему они нужны для разных целей. После некоторго размышления оставляем оба метода например так
void CC::add(int n)
{
* *CA::add(n);
}
И вводим второй метод
void CC::add2(int n)
{
* CB::add(n);
}
Ура, проблема решена

А если двусмысленность более сложна?
Сейчас это было необходимо из-за пересечения понятий наследования и параметрической перегрузки. Когда в С++ используется перегруженное имя, то сперва вызывается механизм наследования для поиска контекста, в котором определена функция. Затем типы параметров анализируются для снятия двусмысленности в пределах данного контекста. Предположим, что есть два класса А и В, для каждого из которых определен метод display. но у методов разные аргументы (int и double). Мы считаем, что так как эти два метода различаются по списку параметров, дочерний класс может наследовать от двух родителей и иметь доступ к обоим методам. Счазззз. Когда мы вызываем метод display с целочисленным аргументом, компилятор не может приянять решение, использовать ли функцию из класса A(которая соответствует типу аргумента) или же из класса В (которая встречается первой при заложенном в С++ алгоритме поиска; для ее вызова аргумент будет приведен от типа int к типу double). Копмилятор ругнется, но ругнется только в точке вызова метода, а не при описании класса.
Звучит может угрожающе, но на самом деле это лечится, но только переопределением родительских классов, где методы необходимо объявить виртуальными (не чисто виртуальными), и компилятору станет ясно, что мы сделали это специально
Проблема на уровне дочерних классов, а решение на уровне родительских. Кде тут ООП?
Вот эти вот расходы на переопределение больших классов и кажутся мне слишком большими.

[s]Исправлено: Crew, 0:15 12-02-2003[/s]