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

Цитата MyNameIsIgor @ 26.04.11, 13:03

Никогда не слышал понятия "приведение интерфейса". То, что вы показываете, - приведение типа. Тип в данном случае ссылочный. Это в какой-то степени соответствует приведению ссылок в C++ (что тоже является приведение типов).

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

Цитата korvin @ 26.04.11, 13:15

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

Понятно, сами только что придумали так же, как IL_Agent придумывает семантику для C++.
Так вот, сообщаю вам: это приведение типов.

Цитата IL_Agent @ 26.04.11, 13:04

Но не прочтёт то, что написал первый.

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

Добавлено 26.04.11, 13:23
И за кросскомпиляторность. Тоже актуально.

Цитата MyNameIsIgor @ 26.04.11, 13:20

Понятно, сами только что придумали так же, как IL_Agent придумывает семантику для C++.
Так вот, сообщаю вам: это приведение типов.

не придумал, а вывел.

Большинство (если не все) ЯП устроено так, что типы в них определяются не только интерфейсом, но и реализацией, и приведение интерфейса не есть приведение всего типа

Цитата korvin @ 26.04.11, 13:33

не придумал, а вывел.

Большинство (если не все) ЯП устроено так, что типы в них определяются не только интерфейсом, но и реализацией, и приведение интерфейса не есть приведение всего типа

Это называется "приведение типа". Так считает большинство, так сказано в книгах по обсуждаемым языкам. Что такое "приведение всего типа" - я без понятия. И не надо мне объяснять - мне это не надо. Поэтому, когда вы в следующий раз начнёте использовать термины, которые "вывели", то сделайте пометку: так, мол, и так, это вот мой термин, а значит он то-то и то-то.

Сообщение отредактировано: MyNameIsIgor - 26.04.11, 13:45

Цитата Romkin @ 26.04.11, 13:03

А в С++ знать отличие ссылки и значения - необходимо, потому что объект там по сути просто набор предков. Из-за этого приходится активно использовать шаблоны.

Как-то не улавливаю связи между тезисами в этих предложениях, два из них - просто ложны. Это ты сам придумал или где прочел?

Цитата Romkin @ 26.04.11, 13:03

В Delphi это знание просто не нужно, так зачем указывать звездочку, если иного не дано?

Тогда зачем в Delphi указатели? Зачем указывать '^' ?

Цитата Romkin @ 26.04.11, 13:08

Тебя не должно интересновать, ссылочный это тип или нет, это - детали реализации

Неверно. Это - особенности поведения. Детали реализации - это то, что не видно пользователю.

Цитата IL_Agent @ 26.04.11, 13:04

Вывод : КО не любит С++ и не подсказывает его сторонникам.

Правильный вывод: тебе таки надо научиться четко изъяснять свои мысли.

Цитата trainer @ 26.04.11, 14:20

В Delphi это знание просто не нужно, так зачем указывать звездочку, если иного не дано?
Тогда зачем в Delphi указатели? Зачем указывать '^' ?

Это - только на самом низком уровне, чаще всего работа с API. На чуть более высоком уровне абстракции их уже нет. Они намеренно скрываются, чтобы не раскрывать детали реализации.

Цитата trainer @ 26.04.11, 14:20

Неверно. Это - особенности поведения. Детали реализации - это то, что не видно пользователю.

Особенности поведения не обязаны зависеть от деталей реализации. Ссылка - это именно деталь реализации. Можно же сделать копирование ссылочных типов? Конечно можно. Тогда какую информацию тебе даст знание, что передача идет по ссылке?
На нижнем уровне знать ссылка это или нет надо, а вот на последующих слоях - нафиг не надо, это лишнее знание, раскрывающее детали реализации, что греховно.

Цитата trainer @ 26.04.11, 14:20

Как-то не улавливаю связи между тезисами в этих предложениях, два из них - просто ложны. Это ты сам придумал или где прочел?

Объект - набор предков. Это и выглядит как набор предков, и работает так же, по внешним признакам.
В Delphi (не сомневаюсь, что и в C#) объект - целостная сущность. Ты никогда не можешь получить предка из потомка иначе как создав предка и скопировав в него нужные данные из потомка. Явно.
Более того, активное использование шаблонов происходит из технологических ограничений принятой реализации объектов, в частности, невозможности вызовов виртуальных методов из конструктора. Вот только не надо уверять, что так должно быть, потому что... Не обязано быть так, другие языки вполне нормально себя чувствуют без этих ограничений.
Шаблоны - это фишка С++, призванная исправить неудачную абстракцию объектов. В других языках их нет, за ненадобностью и неудобством. А исключи шаблоны из С++ - и многие вещи там просто нельзя будет сделать. Проходили уже.

Добавлено 26.04.11, 15:21
Разработчики Delphi нашли в себе силы отказаться от такой же реализации объектов еще в самом начале. Сейчас тип object считается безнадежно устаревшим:

Цитата

The Win32 Delphi compiler allows an alternative syntax to class types. You can declare object types using the syntax:

type objectTypeName = object (ancestorObjectType)
memberList
end;
where objectTypeName is any valid identifier, (ancestorObjectType) is optional, and memberList declares fields, methods, and properties. If (ancestorObjectType) is omitted, then the new type has no ancestor. Object types cannot have published members.

Since object types do not descend from System.TObject, they provide no built-in constructors, destructors, or other methods. You can create instances of an object type using the New procedure and destroy them with the Dispose procedure, or you can simply declare variables of an object type, just as you would with records.

Object types are supported for backward compatibility only. Their use is not recommended on Win32.

Эти объекты были в Turbo Pascal, в начале девяностых. Устаревшая реализация абстракции "объект". В C#, который в определенной мере наследник Delphi, их просто нет. Намекаю: это практически та же реализация объектов, что и в C++.

Цитата Romkin @ 26.04.11, 15:12

Эти объекты были в Turbo Pascal, в начале девяностых.

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

Цитата MyNameIsIgor @ 26.04.11, 13:45

Это называется "приведение типа". Так считает большинство, так сказано в книгах по обсуждаемым языкам. Что такое "приведение всего типа" - я без понятия. И не надо мне объяснять - мне это не надо.

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

Тынц

в теории оно так, но в реальной жизни (привет, Qraizer =) ) приходится сталкиваться с тем, что две реализации одного и того же интерфейса могут иметь сильно разную семантику, несмотря на то, что автором интерфейса могла подразумеваться какая-то конкретная семантика (снова привет, Qraizer =) ), соответственно полностью абстрагироваться от реализаций и утверждать, что интерфейс определяет тип уже нельзя.

вот если бы в интерфейсах можно было как-то (пусть не полностью, но более-менее удовлетворительно) контролировать семантику, например определять мм... аксиоматику типа (это не мой термин, могу привести пример кода на существующем языке =) ), тогда другое дело. правда нужно еще и при этом уметь как-то контролировать сайд-эффекты (наподобие статически проверяемых исключений в джаве). в отношении таких интерфейсов я даже согласен с Qraizer'ом, что два сигнатурно одинаковых методов разных интерфейсов -- это разные методы с разной семантикой. точнее так: если брать в качестве сигнатур только имена и типы методов (здесь под типом я подразумеваю полный тип вида (a -> b -> ...)), то да, нельзя говорить, что они одинаковы, но если полные спецификации идентичны (кроме имен интерфейсов), тогда -- одинаковы. ну это уже другая история =)

В Хаскелле это можно частично делать, например тайпкласс Eq определен так:

class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool
 
    x /= y  =  not (x == y)

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

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

именно поэтому

Цитата Повстанець @ 26.04.11, 15:24

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

++
зря Борланд для делфи выбрали его, уж если хотелось чего-то паскалеподобного, то взяли б лучше Оберон или Компонентный Паскаль

Добавлено 26.04.11, 15:32

вот пример с другого форума

Цитата

по методу алгебраического проектирования класса от
raise development group (http://agp.hx0.ru/oop/ClassDesign.pdf)
напишем спецификации для класса Rectangle и Square

scheme Rectangle =  class
    type                        
      Figure
     ,UReal  =  {| r: Real :- r > 0.0 |}  
    value
      SetWidth  : Figure >< UReal -> Figure  
     ,SetHeight : Figure >< UReal -> Figure  
     ,GetWidth  : Figure          -> UReal      
     ,GetHeight : Figure          -> UReal      
    axiom
      [gw_sw]          
        all w: UReal, f: Figure:- GetWidth(SetWidth(f, w)) = w
     ,[gw_sh]
        all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = GetWidth(f)
     ,[gh_sh]          
        all h: UReal, f: Figure:- GetHeight(SetHeight(f, h)) = h
     ,[gh_sw]
        all w: UReal, f: Figure:- GetHeight(SetWidth(f, w)) = GetHeight(f)
  end

scheme Square =  class
    type                      
      Figure
     ,UReal  =  {| r: Real :- r > 0.0 |}  
    value
      SetWidth  : Figure >< UReal -> Figure  
     ,SetHeight : Figure >< UReal -> Figure  
     ,GetWidth  : Figure        -> UReal      
     ,GetHeight : Figure        -> UReal      
 
    axiom
      [gw_sw]          
        all w: UReal, f: Figure:- GetWidth(SetWidth(f, w))= w
     ,[gw_sh]
        all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = h
     ,[gh_sh]          
        all h: UReal, f: Figure:- GetHeight(SetHeight(f, h)) = h
     ,[gh_sw]
        all w: UReal, f: Figure:- GetHeight(SetWidth(f, w)) = w
  end

Цитата korvin @ 26.04.11, 15:28

++
зря Борланд для делфи выбрали его, уж если хотелось чего-то паскалеподобного, то взяли б лучше Оберон или Компонентный Паскаль

Не, ну понять то можно. Любой новый язык заботится о своём первичном наполнении, за редкими исключениями. Вот ява и шарп сделали ставку на переучивание плюсовиков, к примеру. В Борланде, видимо, понадеялись на активное изучение паскаля (в то время) в учебных заведениях.

Цитата Повстанець @ 26.04.11, 15:24

А ты пробовал писать на этих объектах? Это пипец вообще был. Зато вписывались в парадигму паскаля.

Вы до сих пор практически на таких объектах и сидите. Единственное - есть множественное наследование и шаблоны, на чем и выезжаете
Угу. Кривой и нерасширябельный. Ну да, Object Pascal ну совсем-совсем другой язык. Открою тайну: по сравнению с TP в Delphi просто добавили реализацию классов. И все достаточно мило вписалось в парадигму, что бы ты под этим ни подразумевал.

Цитата Повстанець @ 26.04.11, 15:33

Не, ну понять то можно. Любой новый язык заботится о своём первичном наполнении, за редкими исключениями. Вот ява и шарп сделали ставку на переучивание плюсовиков, к примеру. В Борланде, видимо, понадеялись на активное изучение паскаля (в то время) в учебных заведениях.

думаю, определенную роль также сыграла некотороя база кода на (Турбо/Борланд) Паскале

Добавлено 26.04.11, 15:39

Цитата Romkin @ 26.04.11, 15:33

Угу. Кривой и нерасширябельный. Ну да, Object Pascal ну совсем-совсем другой язык.

то-то Эппл его бросило

Цитата IL_Agent @ 26.04.11, 11:27

Остальной батхёрт, с твоего позволения, проигнорирую, т.к. всё не в кассу

Слив подтверждён. Я не сомневался, что уместить в две строки философию Решёточных типов не получится.

Цитата korvin @ 26.04.11, 11:29

вовсе нет, практика показывает, что C++ -- белая ворона, с какими-то своими, особыми понятиями

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

Цитата korvin @ 26.04.11, 11:36

нет, ты путаешь ссылочный тип и передачу по ссылке

Кстати нет. Ссылки в Плюсах - это именно тип. Это в оппозиции ссылки ограничены либо передачей параметров, либо неким врождённым свойством некоторых типов. У белой и пушистой "вороны" любой тип может стать ссылочным при необходимости и желании программера.

Цитата IL_Agent @ 26.04.11, 11:44

Ограниченностью и write-only (см. boost).

Не насмешил. IL_Agent, счас скажешь, что джереники мощнее? Аминь.

Romkin, ты путаешь (по крайней мере я так понял) понятия "ссылка" и "указатель". То, в чём ты обвиняешь - и совершенно справедливо, в сообществе Плюсовиков ситуация аналогичная - указатели, не применимо к ссылкам. Нет у них этих недостатков.
У вас введение ссылочных типов было оправдано большей ориентированностью языка на уменьшение человеческого фактора ценой уменьшения свободы выражения идей. Разумеется за это надо платить. Навязанным полиморфизмом, например. Или его отсутствием, но и фактически вообще отсутствием ООП в таком случае. Или множеством похожих, но в чём-то мелком разных, типов. Или кучей всякоразных специальных методов. Или длинным списком различных возможнох модификаторов методов и их комбинаций. И вы с этим всем согласны, вы готовы зубрить все эти разницы и мелочи и согласны с неизбежным оверхедом защиты от человеческого фактора.
Наш язык возможности не урезает. Для всего у него найдётся лазейка, даже для нарушения инкапсуляции. Просто чем опаснее и неочевиднее последствия, тем больше букв придётся писать. Это тоже весьма действенная защита от человеческого фактора, ибо многобуквенная конструкция с гораздо меньшей вероятностью написана случайно и ненамеренно. Зато запретов по сути и нет вовсе.
И за это тоже надо платить, разумеется. Как бы то ни было, но большая свобода требует большей ответственности. Это же я и малой уже третий год твержу: хочешь больше свободы, покажи, что сумеешь ею граммотно распорядиться; если не будет получаться, будешь учиться на своей шкуре; не будешь учиться, значит будет ещё полтора года до совершеннолетия в 22⁰⁰ домой, карманные расходы - под предъявление чеков из магазина, телефон - после демонстрации выполненных уроков, итп; тебя свободой никто не пичкает, либо ты несёшь ответственность за свои поступки, либо не требуй свободы. Я лично свободы вкусил, и я согласен нести ответственность за свои ошибки в Плюсах. Бывает, накалываюсь, не ангел. Вероятно ты не поверишь, насколько редко это бывает. Обсуждаемые сейчас тут проблемы - это детский сад. Это не проблемы, это даже не темы для обсуждения в C/C++ Общих вопросах, разве что нуб какой зайдёт и FAQ не почитает.
Зато я счастлив. Я с компилятором дружу, мы с ним прекрасно договариваемся. Если меня посадят за что-то типа кнута Дельфийной объектной модели или неочевидности ссылочности Решёток, я с компилятором вряд ли договорюсь. Ибо не его собачьего ума дело, что я хочу. Что я хочу - я ему говорю прямо. И не надо за меня додумывать. Однако предупреждения компилятора я завсегда готов выслушать, и всегда добавлю несколько буковок, чтобы его успокоить и убедить в отсутствии человеческого фактора конкретно здесь и сейчас или же наоборот, сказав спасибо, подправить свою конструкцию.

Цитата Romkin @ 26.04.11, 13:08

Яркий пример как раз тип string в Delphi. Реализован через ссылку, но при программировании с ним программист это "забывает". Потому что этот факт не нужно знать.

Ты тоже делаешь ту же ошибку, что и DesweR? Romkin, реализация через ссылки не делает тип ссылочным. Ваши строки реализуют семантику значения, и делают это прозрачно. Это не ссылочный тип. Ссылочный - это если я A присвою B, а потом поменяв один, обнаружу изменённым и второй. Такое "определение" понятнее?

Цитата Romkin @ 26.04.11, 15:12

Шаблоны - это фишка С++, призванная исправить неудачную абстракцию объектов. В других языках их нет, за ненадобностью и неудобством. А исключи шаблоны из С++ - и многие вещи там просто нельзя будет сделать. Проходили уже.

Точно-точно. Помнится, шаблонам слили.

Цитата Romkin @ 26.04.11, 15:33

Открою тайну: по сравнению с TP в Delphi просто добавили реализацию классов. И все достаточно мило вписалось в парадигму, что бы ты под этим ни подразумевал.

Передёргиваешь. Это "просто" возымело тот же эффект, как и шаблоны в Плюсах. Без классов Дельфи просто объектный Паскаль, а без шаблонов Плюсы - самый что ни на есть C с классами. А Решётки без классов вообще скорее Ассемблер напоминать будут, чем ЯВУ.

Цитата Qraizer @ 26.04.11, 15:59

Если меня посадят за что-то типа кнута Дельфийной объектной модели или неочевидности ссылочности Решёток, я с компилятором вряд ли договорюсь.

А можно подробней на счет "неочевидности ссылочности Решёток"? Интересно.