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

Цитата amk @ 26.04.11, 18:40

korvin, ты там для меня привел две цитаты, содержащие выражения "компилируется в нативный код" и "транслируется в программу на C". Это ни капельки не делает программу не интерпретируемой. Мне по работе пришлось написать более десятка разных интерпретаторов (не очень сложных, но все же). Так вот, только три из них интерпретировали текст напрямую, остальные транслировали программу в текст С-программы (кроме этого сгенерированного файла были и другие). Тем не менее, я-то знаю, что в результате транслированный текст просто интерпретировался.

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

т.е. С -- интерпретируемый язык? так и запипшем...

ну и если для тебя компиляция в нативный код -- это интерпретация, то что вообще такое компиляция по-твоему?

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

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

Цитата Qraizer @ 26.04.11, 11:14

korvin мыслит эвклидово, теми аксиомами, которые вычитал. Ему не докажешь, что геометрия нашего мира вообще-то неэвклидова. Это не просто заметить, а он ещё и не хочет.

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

Нет, не показывает Почему тебе так кажется - вопрос открытый.

Цитата D_KEY @ 26.04.11, 18:11

Цитата Red @ 25.04.11, 20:38

Цитата D_KEY @ 25.04.11, 20:08

IL_Agent, от тебя ну никак не ожидал.
Сто раз обсуждали. Это некорректный код.
Требуешь создание нового объекта конкретного типа - какой тут полиморфизм?
Ничего не сделал, чтобы предотвратить срез(конструирование объекта базового класса из объекта производного) - какой ты программист?

В C# нельзя делать структуры (типы значений) базовыми или производными типами других классов или структур. Хотя они неявно наследуются от класса ValueType.

А также неявно наследуются от object, вот что самое поразительное
Просто верх изящества

Абстрактный класс ValueType наследует Object, переопределяя метод Equals (в котором теперь будут сравниваться все поля структур) и GetHashCode соответственно. Так что можно ограничиться "Неявно наследует ValueType".
Чтобы вызвало твое веселье, я, честно говоря, не очень понимаю. Так же структуры могут реализовывать интерфейсы. И с ними можно работать через ссылки на интерфейс.

Сообщение отредактировано: Red - 26.04.11, 18:54

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

Цитата 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, 18:54

Цитата korvin @ 26.04.11, 18:16

Цитата D_KEY @ 26.04.11, 18:11

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

но это же не значит, что ООП-часть должна быть реализована неполно и через чур сложно

А она реализована полно и не так и сложно.

Цитата MyNameIsIgor @ 26.04.11, 18:43

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

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

Цитата korvin @ 26.04.11, 18:54

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

Чорд! Мне кажется, или это же самое я и втирал не так давно?
Да, не научились. Да, это решается организационными мерами. Да, в том числе юнит тестами. Только что с того? Это вся равно не реализация интерфейса

Цитата D_KEY @ 26.04.11, 18:52

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

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

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

Цитата Adil @ 26.04.11, 18:19

В чём неполнота и сложность?

неполнота в некоторой "структурности" объектов, т.е. то, что в С++ называют объектами, в других ЯП -- структуры, не более (единственное отличие -- множественное наследование).

Ошибаешься. Просто в С++ ключевое слово class используется не только для ООП части языка. Я уже рассказывал, что можно описывать с помощью него и какие виды классов и объектов(с точки зрения логики) существуют.

Добавлено 26.04.11, 18:57

Цитата

но таки зачем вообще давать эту возможность? зачем подменять общепринятое значение слова class?

Ты уже про Haskell?

Цитата MyNameIsIgor @ 26.04.11, 18:56

Чорд! Мне кажется, или это же самое я и втирал не так давно?
Да, не научились. Да, это решается организационными мерами. Да, в том числе юнит тестами. Только что с того? Это вся равно не реализация интерфейса

с точки зрения компилятора -- реализация. Вы программы пишете на ЯП, а не на языке документации

Добавлено 26.04.11, 18:58

Цитата D_KEY @ 26.04.11, 18:56

Ошибаешься. Просто в С++ ключевое слово class используется не только для ООП части языка.

это называется подмена понятий, очень свойствена плюсам, да =)

Цитата korvin @ 26.04.11, 18:39

объектов-значений

Что это? Класс - это тип. Объект(вернее его текущее состояние) - значение этого типа.

Цитата D_KEY @ 26.04.11, 18:56

Ты уже про Haskell?

нет

Добавлено 26.04.11, 18:59

Цитата D_KEY @ 26.04.11, 18:58

Что это? Класс - это тип. Объект(вернее его текущее состояние) - значение этого типа.

вернемся к вопросу об идентичности объектов?

Цитата korvin @ 26.04.11, 18:57

с точки зрения компилятора -- реализация. Вы программы пишете на ЯП, а не на языке документации

Да не существует такого языка, чтобы документация не понадобилась.

Цитата korvin @ 26.04.11, 18:56

Цитата D_KEY @ 26.04.11, 18:52

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

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

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

Добавлено 26.04.11, 19:01

Цитата korvin @ 26.04.11, 18:57

Цитата D_KEY @ 26.04.11, 18:56

Ошибаешься. Просто в С++ ключевое слово class используется не только для ООП части языка.

это называется подмена понятий, очень свойствена плюсам, да =)

Нет тут никакой подмены понятий

Добавлено 26.04.11, 19:02

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

Цитата D_KEY @ 26.04.11, 18:58

Что это? Класс - это тип. Объект(вернее его текущее состояние) - значение этого типа.

вернемся к вопросу об идентичности объектов?

Начинай

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

Цитата MyNameIsIgor @ 26.04.11, 18:59

Да не существует такого языка, чтобы документация не понадобилась.

не существует, но это не значит, что нужно перекладывать обязанности языка на формально неверифецируюмую документации

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

не существует, но это не значит, что нужно перекладывать обязанности языка на формально неверифецируюмую документации

Не значит. Но чаще всего иного выхода просто нет.

Добавлено 26.04.11, 19:04
Я же не говорю, что это хорошо. Это просто есть. Оно не может не есть