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

Цитата MyNameIsIgor @ 28.04.11, 08:42

Господа, я не могу понять: а зачем вам видеть код конструктора копирования и оператора присваивания? Для чего? Они либо есть, либо их нет...

Их смущает то, что присваивание может на самом деле не присваивать а допустим вычитать... Наверное по этому притензии как я понял... Ну так такие случае очень редкие, и в основном тщательно документируются так, что код кк / = смотреть не нужно... Зачем его смотреть я до сих пор хз, может просто, ради интереса

Цитата MyNameIsIgor @ 28.04.11, 07:56

Цитата D_KEY @ 28.04.11, 07:31

И как же? Присваивает все поля? А как же инкапсуляция?

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

Ну, "добраться до потрохов", можно и в С++

Цитата D_KEY @ 28.04.11, 08:53

Ну, "добраться до потрохов", можно и в С++

У тебя есть .h и .obj. Твои действия?

Цитата IL_Agent @ 28.04.11, 08:07

Цитата D_KEY @ 28.04.11, 07:31

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

Нет, могла иметь место опечатка.

Где именно? Опечатался и разрешил срезы ?

Цитата

Пойди, отлови её потом в рантайме. А будь пример посложнее и програмист чуть менее опытный - хрен найдёшь.

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

Цитата

Цитата D_KEY @ 28.04.11, 07:31

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

Деление вполне явное. И принципы, установленные данном языке - не нарушает.

Деление неявное, поскольку из

my_type x;

Совершенно не понятно, ссылочная тут семантика или значений.

Цитата

Цитата D_KEY @ 28.04.11, 07:31

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

Я тебе ответил, где это используется. Возможно ли от этого отказаться ? Не знаю, возможно, как раз-таки и буду нарушены какие-либо принципы.

Какие?
Вводим везде ссылки, примитивные типы объявляем иммутабельными, запрещаем от них наследоваться(это ведь итак нельзя?). Какие недостатки ты видишь?

Цитата

Цитата D_KEY @ 28.04.11, 07:31

И как же? Присваивает все поля? А как же инкапсуляция?

Чем это хуже кк по умолчанию в плане инкапсуляции ?

Тем, что "кк по умолчанию" может быть заменен на другой.

Добавлено 28.04.11, 09:01

Цитата MyNameIsIgor @ 28.04.11, 08:59

Цитата D_KEY @ 28.04.11, 08:53

Ну, "добраться до потрохов", можно и в С++

У тебя есть .h и .obj. Твои действия?

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

Цитата D_KEY @ 27.04.11, 07:21

Цитата (Romkin @ Вчера, 10:49)
1. Метакласс и метапрограммирование: тип объекта тоже объект.

Согласен. В чистом С++ это есть на уровне шаблонов и только на время компиляции. В рантайм это не вынести, поскольку противоречит принципу "что не использую, за то не плачу".

Цитата
2. RTTI: полная информация об объекте, объем которой контролируется программистом. С возможностью обмена этой информацией отдельно от собственно объекта.

Согласен. Но не допустимо на уровне чистого С++, ибо также противоречит вышеуказанному принципу и ограничивает сферы применения языка. Может быть реализовано на уровне среды разработки и конкретного компилятора.

Вот этот "вышеуказанный принцип" и указывает по крайней мере на ориентированность языка на микроконтроллеры.
Экономить несколько байт для метакласса за счет удобства программиста - в этом весь С++. Объединили структуру и класс. В Delphi просто - если класс, то это подразумевает наследование, и как следствие, VMT (сорри, наследование без виртуальных методов редкость большая). Если структура - то и VMT нет. Определяет программист.
Да, если что, обычный объект в Delphi RTTI не имеет. Включение RTTI (и ее объем) определяется программистом.

Цитата D_KEY @ 27.04.11, 07:21

Объясни, зачем это нужно, кроме как затыкания дырок в дизайне?
В рамках метапрограммирования, во время компиляции - да. Выбираем стратегию поведения в зависимости от "вида" объекта/класса. А вот во время выполнения... Почему не завести интерфейс с нужным методом?

Можно и интерфейс. Но это - лишний код, еще одна абстракция и часто лишняя связь. Между тем абстракция "тип-функция" достаточно проста для понимания и применения. Проще - оно и надежнее.
В чем такая уж разница между переменной-функцией и переменной-методом?
Это позволяет определять стратегию поведения объекта его владельцем, причем без написания дополнительного кода и без двусторонней связи между ними.

Цитата D_KEY @ 27.04.11, 07:21

Нет, дело не в "структуре". Множественное наследование(в том числе и классов, а не интерфейсов) - вполне етественно, а его запрет отражается на возможностях моделирования. Читай теорию ООП, того же Б.Мейера. Чистые интерфейсы(в том виде, в котором они есть в C#, Java, Delphi) нужны только для затыкания дыры запрета множественного наследования. Никакой другой полезной нагрузки они не несут.

Я ничего не говорил о множественном наследовании Это не затыкание дыры, это простое решение вопросов множественного наследования. Просто все посмотрели, как оно с множественным наследованием, и послали его нафиг, есть способы попроще

Цитата D_KEY @ 27.04.11, 07:21

5. Наличие дженериков с контрактными объявлениями, то есть шаблонов с четким контролем контракта объекта.

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

Концепты, только в С# и Delphi - полная фигня, а не концепты. А ведь могли в Delphi сделать хорошо. Требовать надо не класса, а описывать поведение, которому должен удовлетворять параметр.

Цитата Romkin @ 28.04.11, 09:04

В Delphi просто - если класс, то это подразумевает наследование, и как следствие, VMT (сорри, наследование без виртуальных методов редкость большая). Если структура - то и VMT нет. Определяет программист.

гыгы. Если я в C++ напишу virtual - будет VMT, если не напишу - не будет. "Определяет программист."

Цитата Romkin @ 28.04.11, 09:04

Вот этот "вышеуказанный принцип" и указывает по крайней мере на ориентированность языка на микроконтроллеры.

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

Цитата

Объединили структуру и класс.

Нет. Ключевое слово class в С++ нужно не только для того, чтобы создавать ООП-классы. Но оно позволяет это делать

Цитата

В Delphi просто - если класс, то это подразумевает наследование, и как следствие, VMT (сорри, наследование без виртуальных методов редкость большая). Если структура - то и VMT нет. Определяет программист.

Не вижу принципиальной разницы.
Завел виртуальные функции - получил VMT. Не завел - не получил.

Цитата

Да, если что, обычный объект в Delphi RTTI не имеет. Включение RTTI (и ее объем) определяется программистом.

Интересно, наверно, ты уже рассказывал, а я пропустил.

Цитата

Цитата D_KEY @ 27.04.11, 07:21

Объясни, зачем это нужно, кроме как затыкания дырок в дизайне?
В рамках метапрограммирования, во время компиляции - да. Выбираем стратегию поведения в зависимости от "вида" объекта/класса. А вот во время выполнения... Почему не завести интерфейс с нужным методом?

Можно и интерфейс. Но это - лишний код, еще одна абстракция и часто лишняя связь.

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

Цитата

В чем такая уж разница между переменной-функцией и переменной-методом?

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

Цитата

Цитата D_KEY @ 27.04.11, 07:21

Нет, дело не в "структуре". Множественное наследование(в том числе и классов, а не интерфейсов) - вполне етественно, а его запрет отражается на возможностях моделирования. Читай теорию ООП, того же Б.Мейера. Чистые интерфейсы(в том виде, в котором они есть в C#, Java, Delphi) нужны только для затыкания дыры запрета множественного наследования. Никакой другой полезной нагрузки они не несут.

Я ничего не говорил о множественном наследовании Это не затыкание дыры, это простое решение вопросов множественного наследования. Просто все посмотрели, как оно с множественным наследованием, и послали его нафиг, есть способы попроще

Пожертвовав простой естественной логикой множественного наследования(ведь все его проблемы исключительно на уровне реализации).

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

Цитата

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

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

Цитата D_KEY @ 28.04.11, 08:59

Не понял. Я о том, что ты можешь достучаться до приватных полей, например.

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

Цитата D_KEY @ 28.04.11, 08:59

Если конечно не pimpl.

В шарпе подобных оговорок нет. Ты можешь делать всё, что взбредёт в голову.

Цитата D_KEY @ 28.04.11, 08:59

Но это не значит, что это плохо и что ты будешь это делать.

Я уже писал про рефлексию в шарпе: чаще всего ею пользуются для затыкания дыр в дизайне.

Цитата Romkin @ 28.04.11, 09:04

Можно и интерфейс. Но это - лишний код, еще одна абстракция и часто лишняя связь.

Если взглянуть в исходники VCL, то убеждаешься, что вопрос лишнего кода, еще одной абстракции и т.д. в Delphi просто не рассматривается.

Прикреплённая картинка

Цитата IL_Agent @ 28.04.11, 08:07

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

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

Цитата MyNameIsIgor @ 28.04.11, 09:15

Цитата D_KEY @ 28.04.11, 08:59

Не понял. Я о том, что ты можешь достучаться до приватных полей, например.

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

Самый простой вариант - использовать измененную .h-ку, с public вместо private.
Ну или так:

#define private public
#include "MyHeader.h"

Цитата

Цитата D_KEY @ 28.04.11, 08:59

Если конечно не pimpl.

В шарпе подобных оговорок нет. Ты можешь делать всё, что взбредёт в голову.

Не знаю, тоже не вижу, какую проблему это составляет...

Цитата

Я уже писал про рефлексию в шарпе: чаще всего ею пользуются для затыкания дыр в дизайне.

А это уже не язык виноват. Я бы не стал использовать. Хотя всякое в жизни бывает.

Выше - это более ранние версии. Потом еще добавили.

Прикреплённая картинка

Цитата D_KEY @ 28.04.11, 09:20

Самый простой вариант - использовать измененную .h-ку, с public вместо private.

Тебе надо объяснять, что это недокументированно и вообще неопределённое поведение?

Цитата MyNameIsIgor @ 28.04.11, 09:23

Цитата D_KEY @ 28.04.11, 09:20

Самый простой вариант - использовать измененную .h-ку, с public вместо private.

Тебе надо объяснять, что это недокументированно и вообще неопределённое поведение?

С чего вдруг это неопределенное поведение? Если ошибаюсь - поправь.

Цитата D_KEY @ 28.04.11, 09:20

Самый простой вариант - использовать измененную .h-ку, с public вместо private.

Проблема в том, что члены класса могут расположиться в памяти иначе.

Сообщение отредактировано: trainer - 28.04.11, 09:26