>Множественное наследование в С++ связано с RTTI

дебил ?

>Компиляторы в нативный код под любой платформой

Под 16-битовые платформы С++ так и не написали, хотя хотели. Хотя можно представить себе std::vector<int>::near_iterator, std::vector<int>::far_iterator, std::vector<int>::const_near_iterator и std::vector<int>::const_far_iterator

>>Множественное наследование в С++ связано с RTTI

>дебил ?

Характерная для зубрилки-плюсойоба манера излагать мысли.

> Под 16-битовые платформы С++ так и не написали, хотя хотели.

То есть, Turbo C++ под DOS мне приснился? :-O

>Будто бы под С++ не надо писать обертки и биндинги под системное API. Вообще, С++ - безусловный чемпион по написанию boilerplate-кода который ничего не делает.

Вообще-то речь шла про библиотеки, мой красноглазый товарищ.

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

А не надо читать быдлокниги. Есть стандрат, а остальное всё - половые трудности разработчиков компилятроров.

ЗЫЖ, интересно посмотреть, что будет с тем же D через 10-12 лет, если он, конечно, получит хоть какое-то распространения.

>> Под 16-битовые платформы С++ так и не написали, хотя хотели.

>То есть, Turbo C++ под DOS мне приснился? :-O

А что, там есть __near и __far ссылки (&)?

>Под 16-битовые платформы С++ так и не написали, хотя хотели. Хотя можно представить себе std::vector<int>::near_iterator, std::vector<int>::far_iterator, std::vector<int>::const_near_iterator и std::vector<int>::const_far_iterator

Недоплатформы не нужны, а borland c++ под dos - ошибка в матрице ::))

>А что, там есть __near и __far ссылки (&)?

акстись, товарищ - это 91-й год. Тебя ещё не было ::))

>>Будто бы под С++ не надо писать обертки и биндинги под системное API. Вообще, С++ - безусловный чемпион по написанию boilerplate-кода который ничего не делает.

>Вообще-то речь шла про библиотеки, мой красноглазый товарищ.

Какие библиотеки? Неужели плюсойобы уже избавились от привычки оборачивать системные Си-библиотеки тоннами уродских врапперов? Как же Божественный RAII в конце то концов?

>Есть стандрат, а остальное всё - половые трудности разработчиков компилятроров.

Есть конкретный компилятор который используется для работы. А т.н Стандарт - половая трудность Строуструпа и прочих темлейтохедов из комитета по стандартизации.

>>Под 16-битовые платформы С++ так и не написали, хотя хотели. Хотя можно представить себе std::vector<int>::near_iterator, std::vector<int>::far_iterator, std::vector<int>::const_near_iterator и std::vector<int>::const_far_iterator

>Недоплатформы не нужны, а borland c++ под dos - ошибка в матрице ::))

А вот ненавистный майкрософт как то умудрился большую часть своего 16-битного кода перенести с минимальными правками. Объявлили только NEAR и FAR как #define NEAR и #define FAR и все.

>>>Множественное наследование в С++ связано с RTTI

>>дебил ?

>Характерная для зубрилки-плюсойоба манера излагать мысли.

а посуществу ?

я утверждаю что человек говорящий "Множественное наследование в С++ связано с RTTI" дебил, не знающий ни что такое множественное наследование, ни что такое RTTI, ни что такое с++.

возразить есть что ?

>>>>Множественное наследование в С++ связано с RTTI

>>>дебил ?

>>Характерная для зубрилки-плюсойоба манера излагать мысли.

>я утверждаю что человек говорящий "Множественное наследование в С++ связано с RTTI" дебил, не знающий ни что такое множественное наследование, ни что такое RTTI, ни что такое с++.

Ты собираешься работать с множественным наследованием без dynamic_cast ?

> Ты собираешься работать с множественным наследованием без dynamic_cast ?

И не только он.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Multiple_Inher...

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Run-Time_Type_..._

> Ты собираешься работать с множественным наследованием без dynamic_cast ?

так, полное не знание с++, слив и пердение в лужу
при этом просто __ЧУДЕСНОЕ__ не знание с++,
такое еще поискать надо

попробуй откомпилировать
class A {}; class B {}; class C: public A, public B {};
dynamic_cast<A&>(b);

и немедленно подотри за собой свою блевотину

excuse me
быстро писал

class A {}; class B {}; class C: public A, public B {};
C c;
dynamic_cast<A&>(c);

>> Ты собираешься работать с множественным наследованием без dynamic_cast ?

>И не только он.

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

Плохой пример. Ты скорее будешь приводить A или B к C. А то что ты делаешь и без каста работает.

>>> Ты собираешься работать с множественным наследованием без dynamic_cast ?

>>И не только он.

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

Ты C++ные вложенные классы с Java-вскими вложенными классами не путаешь?

>быстро писал

Ручки трясуццо?

>class A {}; class B {}; class C: public A, public B {}; >C c; >dynamic_cast<A&>(c);

Какбе намекаешь на отсутствие виртуального деструктора? А нахрена тогда множественное наследование? В гугле вон только для pure abstract классов, т.е интерфейсов его применяют.

>>>> Ты собираешься работать с множественным наследованием без dynamic_cast ?

>>>И не только он.

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

>Ты C++ные вложенные классы с Java-вскими вложенными классами не путаешь?

Не путаю. Поскольку в гугле все равно инициализируют поля не в конструкторе а в отдельной функции можно в этой отдельной функции вложенным классам this передать. Очень вероятно, их friend придется сделать.

>Плохой пример. Ты скорее будешь приводить A или B к C. А то что ты делаешь и без каста работает.

Зря ты раскрыл карты раньше времени

Полное описание требуемого:

C c;
std::cout << (&dynamic_cast<A&>(c) == &static_cast<A&>(c)) << std::endl;

A& a = static_cast<A&>(c);
std::cout << (&static_cast<C&>(a) == &c) << std::endl;

убедительно показывающего что у того кто потребовал RTTI для множественного наследования не все порядке с головой

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

У того кто использует iostream не все в порядке с головой. И кто блюет прямо в треде.

>>class A {}; class B {}; class C: public A, public B {}; >C c; >>dynamic_cast<A&>(c);

>Какбе намекаешь на отсутствие виртуального деструктора? А нахрена тогда множественное наследование? В гугле вон только для pure abstract классов, т.е интерфейсов его применяют.

Деточка, я ладно, бухал
но тебе же еще рано, головка то может и не отрелаксится ...
это не в порядке эмоций, а в порядке коментария на тот бред что ты написал

>>Ты C++ные вложенные классы с Java-вскими вложенными классами не путаешь?

>Не путаю. Поскольку в гугле все равно инициализируют поля не в конструкторе а в отдельной функции можно в этой отдельной функции вложенным классам this передать. Очень вероятно, их friend придется сделать.

Да, это явно проще, чем множественное наследование. А еще, после такой декомпозиции можно сразу же заявить, что ОО в C++ -- полная фигня.

ты сейчас зло тупишь) во первых, путаешь анонимусов, во вторых, ты уже было начал остаивать мнение что dynamic_cast таки без RTTI возможен, сам же используешь только восходящее преобразование, для которого dynamic_cast в нормальной жизни не нужен (виртуальное наследование мы ведь отмели?))).

в порядке итога

Absurd яркий пример воинствующего невежества
самое интересное что плюсы хают в основном такой тип людей

мне лично лень учить глупых

за сим, откланиваюсь

> У того кто использует iostream не все в порядке с головой. И кто блюет прямо в треде.

У тех кто сидит на ЛОР с головой уже давно не все в порядке. Только сопли не распускай :)

>>>Ты C++ные вложенные классы с Java-вскими вложенными классами не путаешь?

>>Не путаю. Поскольку в гугле все равно инициализируют поля не в конструкторе а в отдельной функции можно в этой отдельной функции вложенным классам this передать. Очень вероятно, их friend придется сделать.

>Да, это явно проще, чем множественное наследование. А еще, после такой декомпозиции можно сразу же заявить, что ОО в C++ -- полная фигня.

А использовать его только для того чтобы красиво передавать инстанс пользуясь неявным апкастингом - это Ъ ? Какая разница - externalProcess(obj) или externalProcess(obj.getInterface()) ?

ошибаешься

A& a = static_cast<A&>(c);
std::cout << (&static_cast<C&>(a) == &c) << std::endl;

&static_cast<C&>(a) - восходящее преобразование
и пример показывает что при наличии множественного наследования как для восходящего так и для нисходящего преобразования динамика (RTTI) не нужны

в данном случае:
C c;
std::cout << (&dynamic_cast<A&>(c) == &static_cast<A&>(c)) << std::endl;

показано, что при множественном наследовании статическое пробразование может использоваться вместо динамического

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

+
виртуальное наследование - это __виртуальное__ наследование
оно интерферирует с множественным, но множественное наследование само по себе не требует виртуального
пример:

class X {};
class A : public X {}; class B : public X {}; class C: public A, public B {};

абсолютно корректная формулировка
и даже практичная :)

class X {};
class A : public virtual X {}; class B : public virtual X {}; class C: public A, public B {};

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

в общем, мне лень (продолжаем пить)
откланиваюсь

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

Про статическое преобразование я лично с тобой и не спорил (не мог спорить, потому что у самого не одном проекте это используется).

Про виртуальное наследование: в таких языках как Java или C# есть интерфейсы и ромбовидное наследование проблем не доставляет.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> Про виртуальное наследование: в таких языках как Java или C# есть интерфейсы и ромбовидное наследование проблем не доставляет.

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

>А использовать его только для того чтобы красиво передавать инстанс пользуясь неявным апкастингом - это Ъ ? Какая разница - externalProcess(obj) или externalProcess(obj.getInterface()) ?

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

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

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

>> Про виртуальное наследование: в таких языках как Java или C# есть интерфейсы и ромбовидное наследование проблем не доставляет.

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

Отвечал на следующий вопрос:

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

>>А использовать его только для того чтобы красиво передавать инстанс пользуясь неявным апкастингом - это Ъ ? Какая разница - externalProcess(obj) или externalProcess(obj.getInterface()) ?

>Разница в количестве классов, которые нужно создать и задокументировать.

Можно в .h файле только предварительную декларацию внутреннего класса дать. Типо как еще один pimpl. Сколько вспомогательных классов в .cpp файле написано клиента кода не касается.

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

А это уже косяк плюсов что внутренние классы доступа к закрытой секции не имеют.

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

Время жизни - как у хостящего объекта.

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

>А это уже косяк плюсов что внутренние классы доступа к закрытой секции не имеют.

так, еще раз пернул в лужу .....

>Какие библиотеки? Неужели плюсойобы уже избавились от привычки оборачивать системные Си-библиотеки тоннами уродских врапперов? Как же Божественный RAII в конце то концов?

Ну если

#ifdef __cplusplus
extern "C" {
#endif

"уродский враппер", то у тебя явные проблемы.

>Ну если

>#ifdef __cplusplus
>extern "C" {
>#endif

>"уродский враппер", то у тебя явные проблемы.


Речь шла вообще-то об оборачивании Си-кода для С++ а не об оборачивании С++ кода для Си.

>>Ну если

>>#ifdef __cplusplus
>>extern "C" {
>>#endif

>>"уродский враппер", то у тебя явные проблемы.


>Речь шла вообще-то об оборачивании Си-кода для С++ а не об >оборачивании С++ кода для Си.


Клоун !!!
ты вообще понял что тебе сказали , а что ты в ответ ?

>ты вообще понял что тебе сказали , а что ты в ответ ?

1) extern "C" {} нужен чтобы вызывать С++-функции из Си (отключает манглинг)

2) Врапперы нужны чтобы приделать к гадскому, нестроуструпоугодному C API Божественное С++ ОО и RAII.

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

>А что, там есть __near и __far ссылки (&)? Absurd * (*) (16.09.2008 15:56:48)

Мой юный трук, сцылки там в формате [смещение] или [сегмент]:[смещение] компилятор выбирает автоматически, в зависимости от заданной модели памяти и надобности указывать near, far для сцылок нет никакой. Кароче, учите матчасть.

>>А что, там есть __near и __far ссылки (&)

>Мой юный трук, сцылки там в формате [смещение] или [сегмент]:[смещение] компилятор выбирает автоматически, в зависимости от заданной модели памяти и надобности указывать near, far для сцылок нет никакой.

А для указателей стало быть надобность есть?

СИКП - это "структура и интерпретация компьютерных программ" , я правильно понимаю ? А что такое АОКП ? что-то ничего в голову не приходит ....

> А что такое АОКП ?

Кнут, очевидно.

АОКП - Ассортиментная часть Общесоюзного классификатора промышленной и сельскохозяйственной продукции

>1) extern "C" {} нужен чтобы вызывать С++-функции из Си (отключает манглинг)

Бугага, а не наоборот?

ЗЫЖ, Теперь понятно, почему ты с++ не осилил

>>1) extern "C" {} нужен чтобы вызывать С++-функции из Си (отключает манглинг)

>Бугага, а не наоборот?

В Си-хедерах extern "C" делать не стоит: кому собственно нужны плюсовые дауны?

>В Си-хедерах extern "C" делать не стоит: кому собственно нужны плюсовые дауны?

Т.е. ты считаешь, что разработчики cups, flac, mpcdec, zlib и т.д. - дауны. Отлично!! Продолжай играть со своей попкой в гордом одиночестве, товарищ.

>В Си-хедерах extern "C" делать не стоит: кому собственно нужны плюсовые дауны?

Т.е. ты считаешь, что разработчики cups, flac, mpcdec, zlib и т.д. - дауны. Отлично!! Продолжай играть со своей попкой в гордом одиночестве, товарищ.

_И_ наоборот