Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата wo1f @ 19.03.11, 18:37

т.е. лишних объектов нет..

А в делфи из-за отсутствия М.Н. тратятся ресы
Запишем слив делфи

Цитата D_KEY @ 19.03.11, 17:50

Так методы(сами по себе) ничем не отличаются друг от друга.

Цитата D_KEY @ 19.03.11, 17:50

А интерфейс - это разве не просто множество методов(а также атрибутов и внутренних типов, если язык поддерживает)? В таком случае, чем они отличаются от абстрактных классов?

В чисто теоретическом изложении может быть и так. Только реально интерфейс требует не только наличие метода с такими то именем и сигнатурой, но ещё и определяет некий контракт, расписанный в документации. Долго за примером ходить не надо, вот у меня лежит Саттер "Решение сложных задач на C++" та, которая 87 штук И в задаче 3.9 он пишет про Джона Кдллина, который взялся реализовать COM интерфейсы IOleObject и IConnectPoint. Собственно

Цитата

а) оба интерфейса содержали функцию-член, объявленную как virtual HRESULT Unadvise(unsigned long);, и б) обычно (выделение моё - MyNameIsIgor) требуется замещение каждой из Unadvise() для выполнения своих специфичных действий.

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

Цитата D_KEY @ 19.03.11, 17:50

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

Я не особо в них вдавался, т.к. их убрали... Концепт является интерфейсом в том смысле, что требует наличия каких-то методов. Если ты отнаследуешься от двух классов, реализующих один концепт, и попытаешься впихнуть экзепмляр получившегося наследника в шаблон, то получишь ошибку компиляции. Так о каком поведении по умолчанию идёт речь? Подразумевается, что ты либо настроишь инстанцируемый шаблон соответствующим образом, либо всё же кастанёшь наследника к одному из предков. Или, на сколько я помню, были concept map или как-то так - возможность указать (написать) реализацию требований концепта.
Я не вижу, чем это поведение отличается от случая реализации двух интерфейсов с требованиями "одинаковых" методов - если мы сделаем это, то нам придётся, например, при передаче параметров функции, ожидающей один из интерфейсов, кастовать экземпляр реализующего класса к нужному интерфейсу. Каст, конечно, неявный будет.

Сообщение отредактировано: MyNameIsIgor - 19.03.11, 18:46

Цитата wo1f @ 19.03.11, 18:44

А в делфи из-за отсутствия М.Н. тратятся ресы

Ну а в C++ из-за отсутствия интерфейсов

Цитата wo1f @ 19.03.11, 18:44

Цитата wo1f @ 19.03.11, 18:37

т.е. лишних объектов нет..

А в делфи из-за отсутствия М.Н. тратятся ресы

Какие?

Цитата D_KEY @ 19.03.11, 18:50

Какие?

Пальцоклавишопечантые видимо

Цитата MyNameIsIgor @ 19.03.11, 18:45

В чисто теоретическом изложении может быть и так. Только реально интерфейс требует не только наличие метода с такими то именем и сигнатурой, но ещё и определяет некий контракт, расписанный в документации. Долго за примером ходить не надо, вот у меня лежит Саттер "Решение сложных задач на C++" та, которая 87 штук И в задаче 3.9 он пишет про Джона Кдллина, который взялся реализовать COM интерфейсы IOleObject и IConnectPoint.

нет, единственный контракт, который создает интерфейс -- именование множества сообщений, которые может обработать объект и всё. непонимание С++никами этого простого факта и порождает задачи, подобные "3.9 про Джона Кдллина" у всяких саттеров и/или неверная интерпретация задачи. не всё то интерфейс с точки зрения ООП, что имеет в названии слово "интерфейс"

Цитата MyNameIsIgor @ 19.03.11, 18:45

Да, они требуют реализации одноимённых методов с одинаковыми сигнатурами, но разной семантики.

Вот такие хреновые методы Тебе не кажется, что название должно отражать, что делает метод? С операторами тут не поспоришь, но их число ограничено. Но вообще-то, в идеале, должна быть одна семантика на одно название метода. Как operator+ для int и std::string...
А если еще и полностью совпадает сигнатура... В любом случае сделать две реализации тебе никто не мешает

Цитата

Совпадение же ещё и семантики вообще редкость и никак не может претендовать на поведение по умолчанию.

Хм.. А мне вот так не кажется.

Цитата

Цитата D_KEY @ 19.03.11, 17:50

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

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

Которая имеет отношение к проблеме множественного наследования, а не интерфейсов.
Если у тебя будут два концепта, требующих, среди прочего, метод "void mf()const", то объект класса, которые его обеспечит, будет соответствовать обоим концептам, и для обоих это будет один и тот же метод. Вот я о чем.

Цитата MyNameIsIgor @ 19.03.11, 18:45

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

интерфейсы не должны строить предположения о реальной семантике конкретной реализации реакции на вызов метода объектами конкретного класса. для различия семантики есть абстрактные классы.

Цитата korvin @ 19.03.11, 18:58

у всяких саттеров и/или неверная интерпретация задачи.

Не надо гнать на Саттера Он, кстати, несколько языков знает и о С++ говорит разное.

Цитата D_KEY @ 19.03.11, 19:00

Как operator+ для int и std::string...

эээ у них вообще-то разная семантика: сложение и конкатенация

Добавлено 19.03.11, 19:06

Цитата D_KEY @ 19.03.11, 19:02

Не надо гнать на Саттера Он, кстати, несколько языков знает и о С++ говорит разное.

ну значит Игорь путает ООП-интерфейс и COM-интерфейс. я же написал:

Цитата korvin @ 19.03.11, 18:58

и/или неверная интерпретация задачи.

Сообщение отредактировано: korvin - 19.03.11, 19:07

Цитата korvin @ 19.03.11, 19:01

Цитата MyNameIsIgor @ 19.03.11, 18:45

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

интерфейсы не должны строить предположения о реальной семантике конкретной реализации реакции на вызов метода объектами конкретного класса. для различия семантики есть абстрактные классы.

Вот мне тоже так кажется...

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

Добавлено 19.03.11, 19:11

Цитата korvin @ 19.03.11, 19:03

Цитата D_KEY @ 19.03.11, 19:00

Как operator+ для int и std::string...

эээ у них вообще-то разная семантика: сложение и конкатенация

"Добавление" Но вообще ты прав теоретически, а вот практически... никаких проблем не было.

Сообщение отредактировано: D_KEY - 19.03.11, 19:14

korvin, D_KEY, видите, мне насрать с высокой колокольни, какие теоретические выкладки господа от computer science понаписали в трактатах "О влиянии лунного света на рост телеграфных столбов". С теоретической точки зрения на ООП интерфакесы могут быть хоть оборотнем в погонах - мне всё равно Я инженер, следовательно, не пишу трактаты, а на практике выращиваю столбы под лунным светом, и если голимая теория не помогает мне в практической деятельности, то я с ней поступаю как всегда поступают с теорией, не соответствущей практике: "в печку её"
Ну, где вы видели интерфейсы без предположений о семантике? Где реализующий интерфейс метод делает хз что захотела реализация? А как вы тогда код то пишете, опираясь на такие интерфейсы? В студию! И уж тем более не представляю себе интерфейс, где в названии требуемого метода всё отражено. Это так что ли выглядит?

interface
{
  ТутТакойМетодОнДелаетТоИТоПредусловияУНегоТакиеАВотПостУсловияТакие
}

Вот скажи мне, D_KEY, auto_ptr разве чем-то не удовлетворяет концепту, который CopyConstrucable хотели сделать в С++0x? Так если посмотреть на сигнатуры, то он вполне себе copy! Запихнём в контейнер? Вывод прост: концепт подразумевает семантику, и иначе может быть только в лекции чокнутого профессора "от ООП", а auto_ptr как был с move семантикой так и остался.
Вообще, от korvin'а то реакция предсказуемая Он давно меня дивит "некополебимостью" теории И то временами такой странной, что я даже и не слышал. Но от тебя не ожидал Поэтому я скажу так же, как говорил, когда пытались сравнивать языки, не принимая во внимание их реализации: я не предрасположен к сфероконям

Цитата D_KEY @ 19.03.11, 17:50

В таком случае, чем они отличаются от абстрактных классов?

Цитата korvin @ 19.03.11, 19:01

для различия семантики есть абстрактные классы.

Да, D_KEY, сразу забыл ответить. Отличия только в присутствии реализации.

Цитата D_KEY @ 19.03.11, 19:08

Кстати, такой вопрос возник... Я часто применяю паттерн "шаблонный метод"(начал еще до того, как узнал его название), и вообще считаю, что виртуальным функциям не место в открытом интерфейсе(т.к. это интерфейс для наследников, а не клиентов). Вот только как это все сочетается с активным использованием интерфейсов, где все открытое и при этом обязательно "переопределяется"... В общем, как с этим жить?

я ничего не понял =)

Цитата MyNameIsIgor @ 19.03.11, 19:30

Я инженер, следовательно, не пишу трактаты, а на практике выращиваю столбы под лунным светом

Хорошо сказано. Но я тоже инженер. И призываю тебя не забывать о различии между моделью и реализацией. А также о пользе такого разделения при проектировании любой системы.

Цитата

и если голимая теория не помогает мне в практической деятельности, то я с ней поступаю как всегда поступают с теорией, не соответствущей практике: "в печку её"

Что и чему мешает?
Практика формирует теорию, теория улучшает практику, новая практика формирует теорию, ...
Ваш КЭП.

Цитата

Вот скажи мне, D_KEY, auto_ptr разве чем-то не удовлетворяет концепту, который CopyConstrucable хотели сделать в С++0x?

CopyConstructable описан и в нынешнем стандарте и auto_ptr ему не соответствует, т.к. консруктор копирования принимает неконстантную ссылку и модифицирует переданный ему объект(думаю, что ты это знаешь).

Цитата

Но от тебя не ожидал Поэтому я скажу так же, как говорил, когда пытались сравнивать языки, не принимая во внимание их реализации: я не предрасположен к сфероконям

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

Цитата

Цитата D_KEY @ 19.03.11, 17:50

В таком случае, чем они отличаются от абстрактных классов?

Цитата korvin @ 19.03.11, 19:01

для различия семантики есть абстрактные классы.

Да, D_KEY, сразу забыл ответить. Отличия только в присутствии реализации.

А рассмотреть интерфейс как, скажем по простому, отдельно описанную часть открытого интерфейса класса ты не хочешь?

Цитата MyNameIsIgor @ 19.03.11, 19:30

korvin, D_KEY, видите, мне насрать с высокой колокольни, какие теоретические выкладки господа от computer science понаписали в трактатах "О влиянии лунного света на рост телеграфных столбов". С теоретической точки зрения на ООП интерфакесы могут быть хоть оборотнем в погонах - мне всё равно Я инженер, следовательно, не пишу трактаты, а на практике выращиваю столбы под лунным светом, и если голимая теория не помогает мне в практической деятельности, то я с ней поступаю как всегда поступают с теорией, не соответствущей практике: "в печку её"
Ну, где вы видели интерфейсы без предположений о семантике? Где реализующий интерфейс метод делает хз что захотела реализация? А как вы тогда код то пишете, опираясь на такие интерфейсы? В студию!

как интерфейс может знать реализацию метода? я не зря использовал эпитет "конкретная".
вот тебе абстрактный интерфейс:

interface File {
    Open,
    Close,
    Read,
    Write
}

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