> А это не тупо указывать к какому интерфейсу относится метод?Может
> проще спроектировать нормально, чтоб не было такой шняги?
С первого взгляда, конечно, выглядит диковато, да и действительно, не
всегда это нужно. Пример случая, когда это полезно (не утверждаю, что
данная ситуация не решается более лучшими способами, написал первое,
что в голову пришло):

interface Filter {
boolean accept (Object);
}

interface TreeViewFilter extends Filter {
// some methods specific for tree view
}

interface ListViewFilter extends Filter {
// some methods specific for list view
}

class FilterImpl imlements TreeViewFilter, ListViewFilter {
// захотелось по каким-то причинам реализовать оба фильтра одним
// классом и сделать разные реализации accept() для разных
// интерфейсов. Скажем, в дереве отфильтровывать не-директории и
// все, что начинается на ".", а в list view -- только ".*"
}

2Casus: да мне плевать как расценивают мой ответ, те про кого я говорил в нем, Ы? Мы с rivares уточнили точку зрения друг-друга и разобрались с непоняткой и это имхо важней чем то, как поймут мой постинг всякие R00Tоподбные линуксоиды...
Я прекрасно знаю что и среди линуксоидов иногда попадаются умные люди, но имхо это именно те исключения, которые толко подтверждают правило.

2Irsi: "Я прекрасно знаю что и среди линуксоидов иногда попадаются умные люди, но имхо это именно те исключения, которые толко подтверждают правило."

Слово "линуксоидов" лишнее.

И где все-таки этого Анти опустили

Дайте урл, пожалуйста. Выпендривается слишком. А он случайно не Виталий Луговский ? Набор слов - типичный.

BarD слушай а не я вот пока не очень в этом разбираюсь, но может эти твои два интерфейса сделать не интерфесами а классами и включить просто их в окончательный рассширенный?

> может эти твои два интерфейса сделать не интерфесами а классами и
> включить просто их в окончательный рассширенный?
Мнээ... тут есть две проблемы, если я правильно все понял. Во-первых,
интерфейс для подобных вещей всегда лучше, чем класс. Лучше потому, что
у класса есть некая реализация, и в связи с этим появляются всякого рода
заморочки (например, в Java отсутствует множественное наследование,
и потому сделать класс, который будет как TreeViewFilter'ом, так и
ListViewFilter'ом просто невозможно, если оные фильтры будут тоже
классами).
Во-вторых, разве это решит проблему? Если не ошибаюсь, в C++, где
множественное разрешено, все равно нельзя в классе-наследнике сделать
разные реализации методов с одинаковой сигнатурой, но доставшиеся из
разных классов-предков? Если ошибаюсь, то поправьте. Но первая причина
важнее.

Я вообше-то имел в виду не наследование а просто внутри класса создать 2 объекта через new.

Зачем так извращатся то? В Java GUI development принято использовать принцип Model-View-Controller. Читай доки, они Rulezz! :)

> Зачем так извращатся то? В Java GUI development принято использовать
> принцип Model-View-Controller. Читай доки, они Rulezz! :)
Теперь расшифруй, пожалуйста, это выражение в применении хотя бы к
данному примеру (который, как было сказано, взят от балды). Сказать
красивые слова про MVC и про доки я и сам могу. Хотя лично мне спорить
на тему "как лучше сделать этот пример" очень не хочется. Не нравится
этот пример -- придумай свой, и не говори, что тебе НИКОГДА не захочется
сделать в одном классе реализацию методов с одной сигнатурой, пришедшие
из разных интерфейсов. В проекте, использующем только тобой написанный
код ты может и сможешь сделать такой дизайн, в котором не возникнет
подобной неприятности, но, к сожалению, иногда и чужие интерфейсы
использовать приходится.

> Я вообше-то имел в виду не наследование а просто внутри класса создать
> 2 объекта через new.
Да я более чем уверен, что существуют тыщи разных способов решить эту
конкретную задачу, тем более, что она даже до конца-то и поставлена не
была. Но из этого не следует, что никогда в жизни вам не придет в
голову бредовое желание воспользоваться приятной фичей и реализовать
в одном классе два метода с одинаковой сигнатурой. Никто не говорит, что
только так и надо делать, но парашют тоже не каждый раз применяют,
однако ж в полет с собой почему-то берут.

2 BarD:
>Но из этого не следует, что никогда в жизни вам не придет в
голову бредовое желание воспользоваться приятной фичей и реализовать
в одном классе два метода с одинаковой сигнатурой.

Интересно, и каким таким шоколадным образом клиент такого класса будет различать, какой конкретно из методов с одинаковой сигнатурой ему нужен? Явной квалификацией имени типа p->Interface1::method, как в плюсах? Красотишша, блин....

> Интересно, и каким таким шоколадным образом клиент такого класса будет > различать, какой конкретно из методов с одинаковой сигнатурой ему > нужен? В C# для этого сделали хитрый механизм. Реализации этих самых методов имеют модификатор не-public (не помню точно, private или protected), и сменить его нельзя. Таким образом, если класс A реализует интерфейсы B и C, и у обоих есть метод foo(), то нельзя написать ничего типа a->B::foo(). Можно привести экземпляр A к интерфейсу и вызвать метод интерфейса: A a; B b = (B)a; b.foo(); Это такое ООП, доведенное до абсурда :)

2 BarD:
Nu tak v C++ tochno tak legko mozhno sdelat' -- i bez vsyakih "hitryh" mechanisms C#. Vot ono, preimushchestvo multiple inheritance ot classes, a ne ot interfaces :).

> Nu tak v C++ tochno tak legko mozhno sdelat' -- i bez vsyakih "hitryh"
> mechanisms C#.

ну я потому и просил меня поправить :). Таким макаром:
p->Interface1::foo()
мне пользоваться, на моей памяти, не приходилось. Как, кстати,
записывается определение такого метода? MyClass::Interface1::foo(){} ?

Впрочем, исходное-то сообщение относилось к тому, что C# взял и что не
взял от Java, а не от Це++ ...

> Vot ono, preimushchestvo multiple inheritance ot classes, a ne ot
> interfaces :).

ну у множественного наследования от классов есть свои известные
недостатки. Хотя, если сравнить его с тем же парашютом ... :)

>Как, кстати,
записывается определение такого метода? MyClass::Interface1::foo(){} ?

Net. Imeetsya v vidu, chto esli class nasleduet dvum classam, v kotoryh suchestvuut methods s odinakovoi signaturoi, to vyzyvat' sootvetstvuushie methods mozhno opisannym vyshe obrazom. Opredelit' v _odnom_ klasse dva methods s odinakovoi signaturoi, estestvenno, nel'zya. Odnako pereopredelit' dva unasledovannih methods _odnim_ s toi zhe signaturoi mozhno, a iz pereopredelennogo method'a mozhno vyzyvat', naprimer, sootvetstvyushie methods bazovyh classov s pomoshch'u yavnoi kvalifikazii imen. V C++, kak izvestno, net interfaces -- ih mozhno emulirovat' s pomoshch'u abstract classes -- s kotorymi privedennii vame primer velikolepno reshaetsya.

>ну у множественного наследования от классов есть свои известные
недостатки.

Kstati, hotelos' by uslyshat', kakie imenno. Krome, konechno, "psevdo-nedostatkov" -- nekotoryh slozhnostei v ponimanii i realizacii. Hotya, effectivno realizovat' mnozhestvennoe nasledovanie ot classov mozhno.

>class FilterImpl imlements TreeViewFilter, ListViewFilter {
// захотелось по каким-то причинам реализовать оба фильтра одним
// классом и сделать разные реализации accept() для разных
// интерфейсов. Скажем, в дереве отфильтровывать не-директории и
// все, что начинается на ".", а в list view -- только ".*"
}


Kstati govorya, posmotrev na Vash primer, chto ne sovsem yasno -- a zachem _voobsche_ sovmeshchat' dve suchestvenno raznyh implementazii v odnom classe? Ne mozhet zhe _odin_i_tot_zhe_ component byt' to derevom, to spiskom? Ili vse taki implementazii sovmeshautsya v odnom classe tol'ko potomu, chto implementiruetsya Filter? Nu tak, v takom sluchae nado logiku imenno filtra vynosit' v FilterImpl, a ot nee nasledovat TreeFilterView i ListFilterView, i imet' taki dva sootvetstvuushih object'a. Tak chto, vryad li predlagaemyi Vami primer budet horoshei illustraziei poleznosti predlagaemoi Vami vozmozhnosti.

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

2 anonymous (*) (2001-08-31 16:10:25.0): Множественное наследование с темплетами - термоядерная смесь. ATL тому пример. Хотя да, слишком сложно в разработке и отладке. Не слишком очевидно при изучении к тому же. Multiple inheritance must die, кроме наследования интерфейсов.

Bluezman тогда как ты относишься к тому что сказал BarD по поводу интерфейсов в С#?Слишком уж похоже на множественное наследование.Не будет ли и здесь таких же проблемм?

To Bluezman:
>Множественное наследование с темплетами - термоядерная смесь. ATL тому пример.

Ну типа, как и все от MS -- ATL, конечно же, верх крутости C++-ных библиотек. Особенно, если учесть, что MSVC и темплейты, считай, не поддерживает.

>Хотя да, слишком сложно в разработке и отладке.

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

>Multiple inheritance must die, кроме наследования интерфейсов.

Так в итоге, почему же множественное наследование классов must die?
Какие-нибудь этому есть _рациональные_ причины? Кроме иррациональной "сложности" при разработке и отладке? Которая исчезает, если таки потрудиться прочитать и немного подумать над соответствующим разделом стандарта?
На рояле вон тоже, сложно играть -- но это же не значит, что рояли must die..:)

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

Здравствуйте всем!

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

Про сообщение и про споры (то бишь в топик): При использовании языков высокого уровня существуют ограничения накладываемые этими языками. Конечно все хорошо пока вы используете язык для решения задач под которые он заточен и не натыкаетесь на ограничения. Но если вам нужно написать что-то еще то траблы и возникают казалось бы из ниоткуда. Лично мне не нравится Жаба, Паскаль и С# за лишние слова (ну лень мне писать function каждый раз) и за ограничения в наследовании. Про интерфейсы - не знаю, не разобрался пока еще в них. А в С/С++ лишних слов нет, наследование возможно какое угодно... И вообще я хочу вам напомнить слова Кернигана, Ритчи и Страуструпа - "Мы создали язык, то что мы не заложили в языке ВЫ можете сделать сами". И это действительно так - на С/С++ реализовать можно что угодно (другой вопрос сколько времени потратишь на написание классов функций и т.д. для этой реализации а на всем готовеньком - за 5 минут в легкую) именно за это я и люблю С++. А на счет распространения Жабы я скажу следующее: в мире появляется все больше юзверей, которые клепают свои паги используя стандартные решения на Жаба-скрипте (описанные в любой книге по веб-дезигну) и после этого кричат на каждом углу, что круто программят на Жабе - вот и все...

З.Ы.: Может подскажете какой дистрибутив Линуха для начинающий больше всего подходит. Заранее спасибо. DSS

Мальчик, иди поиграй в другом месте.

Девочка, ты тоже иди.

2 DSS
>> А на счет распространения Жабы я скажу следующее: в мире
>> появляется все больше юзверей, которые клепают свои паги используя
>> стандартные решения на Жаба-скрипте (описанные в любой книге по веб-
>> дезигну) и после этого кричат на каждом углу, что круто программят на
>> Жабе - вот и все...

"Жабы" и "Жаба-скрипт" - это разные вещи.

>> Может подскажете какой дистрибутив Линуха для начинающий больше всего подходит
Лучше всего тот, который стоит у твоих знакомых.
Чтобы можно было вопрос задать, если возникнут проблемы.

Да вот еще.
Тут на днях знакомый рассказывал,
что поставил RH 7.0 для вылазки в интернет с разных компов
через один модем.
Под Win NT/2000 не смог это сделать, в Linux'e - без проблем.
Когда я у него спросил какую версию ядра он поставил,
сказал что не знает. Также он не знал: запущен proxy-сервер или
нет, есть ли маскарад или нет.

Анализатор логов сквида лучше все таки писать на перле могу поделиться кодом мыль на bsod@gs7.saminfo.ru

> Odnako pereopredelit' dva unasledovannih methods _odnim_ s toi zhe
> signaturoi mozhno
Ах вот вы о чем...
> abstract classes -- s kotorymi privedennii vame primer velikolepno
> reshaetsya.
Я и не говорил, что он не решается никаким иным способом, кроме
приведенного

> Kstati, hotelos' by uslyshat', kakie imenno. Krome, konechno,
> "psevdo-nedostatkov" -- nekotoryh slozhnostei v ponimanii i
> realizacii.
Мне не нравится перспектива иметь при ромбовидном наследовании два
instance базового класса в runtime'е. Причем еще более не нравится
то, что до поры до времени меня это может быть и будет устраивать, но
однажды в базовом классе произойдет невинное добавление какого-нибудь
атрибута и как следствие я буду вынужден перекраивать архитектуру
унаследованных классов. С этой проблемой можно бороться, если вы автор
базового класса и вольны делать и не делать с ним все, что
заблагорассудится: делать виртуальное наследование, не делать пакостей
типа добавлений злостных атрибутов, etc. Но если его автор не вы, а
Вася Пупкин, то тут уже стоит не раз подумать, прежде чем использовать
множественное наследование, IMHO.

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

> по поводу интерфейсов в С#?Слишком уж похоже на множественное
> наследование.Не будет ли и здесь таких же проблемм?

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

> a zachem _voobsche_ sovmeshchat' dve suchestvenno raznyh
> implementazii odnom classe?
Две существенно разных -- совершенно незачем. Обидно, когда две
существенно схожих имплементации приходится делать в разных классах
только из-за того, что различается поведение (или хотя бы возвращаемое
значение) какого-нибудь вшивого метода... Скажем, в интерфейсе
javax.swing.tree.TreeNode есть метод TreeNode getParent(), а в
интерфейсе org.w3c.dom.Node есть метод, который, к счастью, обозван
все же Node getParentNode(). Мне хочется реализовать обе деревянные
модели одним классом, разве это не естественно? Как свинговые так и
DOM интерфейсы представляют дерево, поведение у него одно (скажем, это
XML), зачем мне создавать в runtime две реальные модели -- одну для
свинга и одну для DOM'а и мучительно их синхронизировать? Сейчас
методы, возвращаюшие родительский узел, имеют разные сигнатуры, но
работая с другими API я не всегда могу рассчитывать на такую удачу.

> Tak chto, vryad li predlagaemyi Vami primer budet horoshei
> illustraziei poleznosti predlagaemoi Vami vozmozhnosti.
Ну во-первых, возможность предлагаю не я, а це шарп и мелкософт :)
Во-вторых, на любой пример можно найти workaround. И я сам могу их
написать, и не в одном экземпляре.

> Так в итоге, почему же множественное наследование классов must die?
Да пусть живет множественное наследование. И применяется себе на
здоровье там, где ну никак без него. Думаю, оно вполне оправдывает
себя на некоторых задачах, и если его применяют с толком и получают
существенный выигрыш, то счастья ему и здоровья :)

>Мне не нравится перспектива иметь при ромбовидном наследовании два
instance базового класса в runtime'е.

Для этого и существует виртуальное наследование.

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

Виртуальное наследование -- это, если можно так выразиться, "характеристика" производного класса, а не базового.
Конечно, если два авторских класса унаследованы от базового невиртуально, и вы хотите наследовать их оба -- тогда да, вилы:(
Кстати говоря, я точно не знаю, в Java возможно ромбовидное наследование от классов и интерфейсов, типа:
interface IBase {
}
interface I1 extends IBase {
}
interface I2 extends IBase {
}
class C implements I2 {
}
class CC extends C implements I1 {
}
Или компайлер это словит?

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

Так вроде proxy и adapter для этого придуманы?

>Мне хочется реализовать обе деревянные модели одним классом, разве это не естественно?

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

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

Если для всех классов примеров, показывающих необходимость такой-то возможности, можно легко найти удобный workaround, то соответствующая возможность не нужна:) Спросите у Строуструпа...:)

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

Так зачем же в яве и до-диезе оно порезано? Generic types отрезали, перегрузку операторов отрезали, явный инлайнинг отрезали -- да разве ж это жизнь?:)

Мона мона наследовать от кучи интерфейсов а вот от класса только от одного...
типа продолжение твоего:
class B extends Vector{
// ну че то типа этого:))
}
class CC extends B implements I1 , I2 {
// сорри точно не помню синтаксиса имплемента:))
}

To eugenes.

>> "Жабы" и "Жаба-скрипт" - это разные вещи Да я то это знаю, но от фактов никуда не денешься - познакомился на прошлой неделе с двумя челами. Оба сказали, что занимаются веб-дезигном и даже программят. Спросил на чем - ответили ВБ и Java (заметь не Java-script, а именно Java). Попросил показать что на Java наваяли - показывают сайт со скриптами. После этого долго понять не мог - я тормоз или они.

>> Лучше всего тот, который стоит у твоих знакомых. >> Чтобы можно было вопрос задать, если возникнут проблемы. Вот в том то и дело, что среди своих знакомых я первый, кто решил Линукс ставить - поэтому спросить не у кого. А вообще я уже кое-что надыбал. Можно почитать здесь -> http://www.linuxoid.ru/how_to/choice.htm И еще где-то было написано, что для новичков - Mandrake, а для профи - Slackware.

То speer.

About Project D. Интересно получается: D = компилируемый C#, выполняемый без виртуальной машины?

Забыл подписаться - DSS. Извините, больше не буду.

>>>About Project D. Интересно получается: D = компилируемый C#, выполняемый без виртуальной машины?

Project D старше C#, да, виртуальной машины в нем не предполагается, хотя семантика не противоречит созданию интерпретирующей виртуальной машины

Ориентирован на прикладное программирование (как и Java/C#), поддерживает модули подобно пакетам в Java, плюс контрактное программирование.

Если иметь к нему хороший gc, то можно и ядро ОС на нем написать, использую для HAL С/Asm, так как доступ с Cишным либам обеспечивается.

IMHO, написать OS с лучшими чертами существующих и без тех принципиальных проблем, которые тянутся родовым проклятьем от применения C можно только взяв за основу другой язык.

Блин speer ты скжи чем круче твой Д чем джава?Вроде компилятор джавы есть гсдж?И нету вроде у этого Д компилятора а тока задумки...

>Мона мона наследовать от кучи интерфейсов а вот от класса только от одного... ипа продолжение твоего:

Eto ya kak by v kurse... Ty pochitai, chto sprashivau, a potom uzh otvechai:(

Ну и чем отличается твое ромбовидное наследование от обычного.Должно быть все нормально...

To speer. Согласен С/С++ НУЖНО изменять, но не таким образом, как это делается в С# или в D. Я не буду сильно против убийства препроцессора (хотя иногда именно с его помощью задачи решаются легко и изящно). Но лучшие черты С/С++ должны перейти в новый язык (в том числе множественное наследование и "умные" указатели, которые отсутствуют в D). Не забывай, что почти каждая задача в С++ решается каким-нибудь легким и изящным языковым финтом, а в Д это убивается на корню. На счет garbage collect - в С++ это решается элементарной перегрузкой операторов new и delete.

>>>Блин speer ты скжи чем круче твой Д чем джава?

ФАК для кого по ссылке написан, или ты блин читать не умеешь!

D seriously departs from Java. Here are some of the ways, in no particular order:

1.D has out and inout function parameters, i.e. functions can return multiple values. 2.D has enums. 3.D's floating point is the best available on the target machine. 4.D has design by contract. 5.D has a direct interface to C and operating system APIs. 6.D has lightweight structs. 7.D has strings implemented as arrays, not objects. 8.D has broad basic type support. 9.D has imaginary and complex floating point types. 10.D has typedefs. 11.D does not do dynamic class loading. 12.D has turn-offable array bounds checking. 13.D has support for assert()s and debug statements. 14.D works with your other existing dev tools (make, linkers, debuggers, etc.)

Java is designed to be write once, run everywhere. D is designed for writing efficient native system apps. Although D and Java share the notion that garbage collection is good and multiple inheritance is bad , their different design goals mean the languages have very different feels.

2AC > Особенно, если учесть, что MSVC и темплейты, считай, не поддерживает.

положи компресс на голову и пересчитай получше...

_GSH_

>положи компресс на голову и пересчитай получше...

Posmotri snachala na standart C++, a ne knigu "C++ dlya polnyh idiotov", a potom lechi drugih. Doktor, mlya:(

>>>Согласен С/С++ НУЖНО изменять, но не таким образом, как это делается в С# или в D

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

>>>Я не буду сильно против убийства препроцессора (хотя иногда именно с его помощью задачи решаются легко и изящно)

Не гона ради и не для очернения повседневного инструмента (своего в том числе, увы) замечу про препроцессор:

Какого фига совершенно независимое языковое средство оказалось как бы частью компилируемого языка?! Да так, что (а) практическое использование его без него невозможно,(b) многие его еще и к достоинствам подхода причисляют! ИМХО - это следствие наследственной близости С к Асм'у, где без макросов языка вообще бы не состоялось...

Дальше про С++:

И вот, на КОДЕРСКИЙ Си с МакроАсм корнями прикручивается взятый из совершено другой области (ПРОЕКТИРОВАНИЯ, а не КОДИРОВАНИЯ!) Объектный подход. Получается гибридизация разноуровневых "организмов" и в результате надутый монстр на машинных ножках! Его долго и трудно доводили/подгоняли и вот - те решения, которые "легкие и изящные" - это симпатичные кусочки лоскутного одеяла. А остальные - совсем как-бы нет и непонятно какие!

Совершенно верно: "каждая задача в С++ решается каким-нибудь легким и изящным языковым финтом" - и что, это достоинство?! А как финты комбинировать, если одним вся задача не покрывается? И какие дальше финты надо в язык ввести, чтобы уж всем хорошо стало их проблемы решать? Что в результате - универсальный С++ или (не хочу никого обидеть) Perl?!

Сколько времени надо эти финты осмыслять, а самое главное, как в рамках проекта проследить за правильным, целесообразным, ПОНЯТНЫМ применением языковых средств... Это ведь надо специальный еще этапы вводить - Отбор средств языка и Контроль их использования! ИМХО, если средства языка не дают ясно-понятного описания программируемого алгоритма - этот язык не лучший для решаемой задачи. На bash'e некоторые умудрились Ассемблер реализовать, так что, выберем это путь за основной?

Квалификациия отдельных одаренных и дисциплинированных личностей (если их больше треx) погоды не делает и геммороя в проектах не убавляет. Благодаря препроцессору, перегрузке операторов, множественному наследованию и т.д. получается шифрованная запись алгоритма, когда приходится разбираться не в том, ЧТО (это в комментариях должно быть) и КАК (это конструкции языка должны ясно выражать), а сначала определить что ОЗНАЧАЮТ используемые идентификаторы и знаки операций!

Кстати, чего-то мне сдается, что распространненость и значении C++ либо сильно преувеличена, либо обусловлена массовым прогаменьем под GUI конкретного семейства ОС, не будем поминать всуе какое. Вот C++ м используется там, где мог-бы быть почти любой ДРУГОЙ ЯЗЫК, поддержанный библиотеками-обертками для доступа к ОС и IDE.

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

PS. А Страуструп - это голова! И Wall - голова. Антихрист - тоже голова, раз я с ним согласен :))

>Какого фига совершенно независимое языковое средство оказалось как бы частью компилируемого языка?!

Так исторически сложилось... Как всегда, следование подлому принципу обратной совместимости ни к чему хорошему не приводит:(

>И вот, на КОДЕРСКИЙ Си с МакроАсм корнями прикручивается взятый из совершено другой области (ПРОЕКТИРОВАНИЯ, а не КОДИРОВАНИЯ!) Объектный подход.

Стоп-стоп... Что значит КОДЕРСКИЙ? А Smalltalk кодерский или как?
Или под "кодерскостью" подразумевается поддержка адресной арифметики, и так далее? Так лучше иметь возможность и использовать разумно или не исользовать вовсе, тем более она ничего не стоит -- чем не иметь её вообще и иметь проблемы в нужный момент.

>Сколько времени надо эти финты осмыслять, а самое главное, как в рамках проекта проследить за правильным, целесообразным, ПОНЯТНЫМ применением языковых средств... Это ведь надо специальный еще этапы вводить - Отбор средств языка и Контроль их использования!

А что, для других языков этого делать не надо???

>ИМХО, если средства языка не дают ясно-понятного описания программируемого алгоритма

Ясно-понятного для кого?? Для меня например, сложный код на ML выглядит китайской грамотой, а тот же Antichrist прочитает его "с листа".

>этот язык не лучший для решаемой задачи

Какой язык лучший для решаемой задачи, все равно решают конкретно те, кто её решает. Объективных критериев не существует.

>а сначала определить что ОЗНАЧАЮТ используемые идентификаторы и знаки операций!

А Вас не смущает, что значок * для чисел означает одно, для векторов другое, а для матриц совсем третье?
И по поводу перегрузки операторов: неужели Вы считаете, что:
matrix<real> D;
matrix<real> A;
matrix<rational> C;
//....
//....
matrix<real> res = transpose(D) * A * D + C;

хуже чем:
real_matrix res;
real_matrix_mul(transpose(D),A,res);
real_matrix_mul(res,A,res);
real_rational_matrix_add(res,C,res);

>Кстати, чего-то мне сдается, что распространненость и значении C++ либо сильно преувеличена, либо обусловлена массовым прогаменьем под GUI конкретного семейства ОС, не будем поминать всуе какое.

Распространенность С++ обусловлена поддержкой различных парадигм программирования, и наличием возможностей, не реализованных пока в других _широко_ распространенных языках.
А GUI не будем поминать какого семейства ОС по умолчанию программируется, если Вы помните, на С:)
Блин, ну что опять за подчеркивание элитарности?:(

>Вот C++ м используется там, где мог-бы быть почти любой ДРУГОЙ ЯЗЫК, поддержанный библиотеками-обертками для доступа к ОС и IDE.

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

>считаю его универсальное применение тупой и малоэффективной деятельностью, т.е. ламерством.

Что значит _универсальное_ применение?

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

2AC:

Я высказал совсем общие сетования по поводу "родимых пятен" наиболее употребимых сейчас средств осуществления кодерами-программистами-дизайнерами своей профессиональной деятельности. Очень всерьез просьба не воспринимать...

Правда на днях подумал: "А вот пристали бы ко мне люди с предложением, мол давай там для того-сего, но в общем, универсально, разработаем ядро новой ОСы". Прям мешок денег к ногам положили, но пожелали бы, чтобы все было красиво-надежно, портабельно и не слишком долго. Чтобы я выбрал в качестве инструментария? Огледелся вокруг - мля, тридцать лет прошло почти, как Сишка под это дело замутилась - и что, так от той печки и танцевать опять? Неужели кроме forth'а ничего больше близко железного не мелькнуло? Вот откуда и грусть, да и пятница же, достало все!

>>>Что значит КОДЕРСКИЙ?

Это значит близкий к тому, как в машинных кодах алгоритм отрабатывается, и типы данных соотв. и адресная арифметика, куда ж без нее. Глядя на сишный текст, прям себя CPU чувствуешь, регистры мысленно распределяешь, стек двигаешь... Смолток, каюсь, мимо прошел...

>>>что, для других языков этого делать не надо???

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

А со всем остальным, что ты написал, просто согласен, спасибо - твои субъективные ньюансы восприятия помогли восстановлению моего когнитивного консонанса!

>>>Блин, ну что опять за подчеркивание элитарности?:(

С чего ты это взял, тоже наверно от усталости померещилось...

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

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

Как удержаться в рамках разумного и приличного, если борешься не со своими страстиями/пристрастиями, а с чужой (в либах/DCOMaх/стандартах/чугуне/граните/бронзе отлитой) глупостью.

"Программирование было бы легким и красивым занятием, если бы до тебя не существовало других программистов" - может, кто знает автора тезиса?

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

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

> Конечно, если два авторских класса унаследованы от базового
> невиртуально, и вы хотите наследовать их оба -- тогда да, вилы:(

... но подразумевалось именно это :)

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

О! Итак, я пишу *один* класс, реализующий деревяшку, который что-то
делает, а к нему *два* класса, которые не делают *ничего*, кроме
делегирования своих методов. И в качестве бесплатного приложения
получаю в три раза большее количество требуемой для этой модели
памяти. Нехилые издержки, IMHO.

> Если для всех классов примеров, показывающих необходимость такой-то
> возможности, можно легко найти удобный workaround,
Даже если это утверждение истинно (что, строго говоря, надо еще
доказать :), то его можно парировать таким утверждением:
"Если workaround каждый раз легкий (всего лишь памяти в три раза
больше надо :) и удобный, но каждый раз разный, то может таки
фича все же нужна, и тогда workaround'ов не потребуется вообще ;) ?

> Так зачем же в яве и до-диезе оно порезано? Generic types отрезали,
> перегрузку операторов отрезали, явный инлайнинг отрезали -- да разве
> ж это жизнь?:)
А ведь есть workaround и для множественного наследования реализации,
причем ровно такой же, какой и для решения проблемы отсутствия
этой несчастной фичи :). Реализуете интерфейс в
классе-якобы-наследнике, а он делегирует методы передаваемой в
конструкторе или еще где-то реализации. Ну или не делегирует, а
выполняет сам, что аналогично перегрузке метода. Так что, убиваем
множественное наследование реализации (там, где оно есть), потому
что существует workaround ;))?

> "Программирование было бы легким и красивым занятием, если бы до тебя
> не существовало других программистов" - может, кто знает автора
> тезиса?
Я думаю, автор унаследован от "Мерфи" :)

>О! Итак, я пишу *один* класс, реализующий деревяшку, который что-то
делает, а к нему *два* класса, которые не делают *ничего*, кроме
делегирования своих методов.

Зато, когда вам понадобится еще какое-нибудь представление, вы не будете переколбашивать ваш класс, который реализует два интерфейса, чтобы реализовать третий (и счастье, что в java для этого не нужно перекомпилировать клиентов этого класса!) -- а всего навсего напишите новое view. Разве не красиво?

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

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

>"Если workaround каждый раз легкий (всего лишь памяти в три раза
больше надо :)

В С++ лишние траты были бы по четыре байта на каждый экземпляр представления, в java -- чуть больше. Я пишу не для embedded systems, и заплатил бы столько за расширяемость и понятность модели.

>Реализуете интерфейс в классе-якобы-наследнике, а он делегирует методы передаваемой в конструкторе или еще где-то реализации.

Не вопрос. Но, во-первых, в С++ пытались ввести делегирование и обломались -- была туча проблем, во-вторых, на каждый случай наследования пришлось бы писать такой вовсе не очевидный код (делегирование не есть наследование!), в третьих -- с явной поддержкой множественного наследования реализации можно сделать довольно красивые вещи (см. Booch components), а в четвертых -- ваш случай, и, я подозреваю, все случаи множественного наследования интерфейсов с методами с одинаковыми сигнатурами -- типичные примеры паттерна MVC. Резюме -- множественное наследование реализации полезно, множественное наследование "одноименных" интерфейсов -- нет:)

>Так что, убиваем множественное наследование реализации (там, где оно есть), потому что существует workaround ;))?

Нет, не убиваем, потому что workaround'ы не отражают _семантику_ множественного наследования.