допустим упрощенно есть

struct A
{
 virtual void Test()=0;
};

struct B: A
{
 void Test() {/*...*/}
};

struct C //не наследуется ни от чего, важно!
{
 virtual void Test()=0;
};

struct D: B, C
{
 //КАК ПРАВИЛЬНО определить метод от C?
 void C::Test() {/*...*/}
};

вот за это я и не люблю с++ )

(0) Поставь Java или C# и не парься.

зачем структуры использовать ?

(2) в том и дело, хочу без промежуточной платформо-машины
(3) это пример, но и вообще в плюсах без разницы

(4) Без промежуточной не обойдёшься. Слоёв 5-6 будет точно

(0)разыменовав явно, ромбовидное наследование же.

(6) нет его же!
(5) ладно тебе придираться

(7)а, у тебя же struct C //не наследуется ни от чего

сработает?

void class C::Test() {/*...*/}

(9) в том и дело, что нет

Вроде бы порешал разной сигнатурой методов (ввел фиктивный параметр)

ООП устаревшая технология, где то была статья на (sql.ru) про новую парадигму!

(12)зря ты. Сейчас начнется срач на 3 ветки в 1000 постов

(13) Может найду ссылку на статью...

(10)А че ты хочешь получить-то?

да уже получил, но расскажу таки, тут шаблоны
есть абстрактный класс Enumerable<T>, от него
1. есть вполне реальный класс List<T>: public Enumerable<T>
2. опять таки абстрактный класс CompositeEnumerable<T>: public Enumerable<T>
3. и от последнего уже опять вполне реальный класс CompositeList<T>: public Enumerable<T>, public List<Enumerable<T> >

то есть CompositeList<T> одновременно является и списком списков и просто списком (в этом случае проход по всем спискам как по одному делается)

struct [1C++]:,[C++]
{
   virtual void Zdelat_Vse_Zaebato()=0;
}

(13) Ну, вот на 100 постов даже нет :)
Устал народ от программирования :)

весны народ хочет

как обещал в (14)
http://blogerator.ru/page/oop_why-objects-have-failed

комментарий с форума:

К ООП тоже отношусь спокойно, отрицательно.

Так вот, написание кода - это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять куда-то намыливается... И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение!

Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. И вот тут, в объектно-ориентированных языках типа Java, С# начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, монстроидальным шаблонным метапрограммированием, полиморфизмом, исключительными ситуациями... Увидев вызов простой функции, как правило сразу понятно что происходит, можно сходить и посмотреть, что она делает. В объектно ориентированных языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, не поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.

(21) однако новые языки (после плюс+плюс): шарп, ява, руби все же стали объектными

(22) Это одно из направлений. Есть Haskell, F# - это другое, не объектно-ориентированное направление. Есть Scala, Nemerle - это "гибридные" языки. И т.д.

(23) F# тоже поддерживает ООП, а вообще что-то они не менее известны широкой публике

в шарпе тоже есть и элементы функционального и обобщенного, это не противоречит ООП

(24) Поддерживает - как вспомогательный механизм и для интероперабельности.
Что касается известности - тут ведь дело не в качестве языка. Бренд + наличие инструментальных средств. Ну и "возраст" (в том числе "возраст" эффективной реализации - _компиляторы_ для функциональных языков появились позже, чем для императивных; да и современные функциональные языки начались в 1980-х, то есть, на полтора-два десятка лет позже того же ООП).

(25) "Чистые" языки на практике малопригодны. Любой язык так или иначе реализует несколько парадигм. Но в большинстве языков - имеется основная парадигма + практически удобные довести.

вот еще с форума:

Например, когда-то одному разработчику был дан проект очень незатейливой игры. Предполагалось, что эта игра займет около месяца разработки. Но месяца не хватило. Спустя шесть недель выяснилась причина. Программист попался очень педантичный и вместо того чтобы взять чистый СИ и написать игру, он 80% времени занимался тусовкой классов в сложнейшей иерархии. Когда посчитали – оказалось порядка 210 классов. Движок получился, была написана чудовищная гора текста. В объекты было завернуто все, начиная от объектов межпоточной синхронизации и кончая экранными виджетами со своей собственной системой сообщений. Да только вот беда — сама игра была в совершенно зачаточном состоянии и не работала.

и ещё, но in english

http://www.softpanorama.org/SE/anti_oo.shtml

(27) Ну, это больше напоминает историю о дураке и стеклянном половом члене, нежели характеризует ООП :-)

все таки устроили холивар )) льете на вентилятор?

Почему бы не использовать has-a отношение?

(30) можно, но там и так вложенных объектов много

оказывается нельзя так писать:

class A{};
class B: protected A{};
A* a1 = new B();

не знал