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

Цитата korvin @ 23.04.11, 21:27

Цитата D_KEY @ 23.04.11, 21:17

Брр... Я им придаю ровно то значение, которое они имеют. Так ответишь по существу или нет? Тут всего два пункта.

я тебе уже отвечал. третий вариант: (типизированные) термы.

Добавлено 23.04.11, 21:28

Цитата D_KEY @ 23.04.11, 21:26

Как это связано с обсуждаемым и вообще со ссылочными типами? Может еще о достаточно часто применяемом в С++ pimpl(вариант opaque pointer) поговорим ?

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

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

Цитата D_KEY @ 23.04.11, 21:17

Или может ты мне хотя бы скажешь, где именно о ссылочных типах можно почитать что-то из теории?

хз, в гугле наверное. вот некто Павел Наумов что-то пишет (не читал):
*

Добавлено 23.04.11, 21:45

Цитата D_KEY @ 23.04.11, 21:33

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

ээ... что вижу на практике? в Racket это работает.

тип -- это [символ (метка), обозначающий некое множество значений] или [безымянный тип, созданый по правилам комбинации типов]

и для объектов, и для "простых" типов это будет символ. однако реализации у них будут разными.

Сообщение отредактировано: korvin - 23.04.11, 21:48

Цитата korvin @ 23.04.11, 21:39

и для объектов, и для "простых" типов это будет символ. однако реализации у них будут разными.

в дельфи еще и внезапно поведение.

Цитата DesweR @ 23.04.11, 20:19

Это малая цена за избавление от лишнего...

Этой малой ценой избавления от необходимости указывать единственную литеру & вас незаметно от вас лишили прекрасной прелести под названием "обощённость". Вы можете сколько угодно играть в неё дженериками, но получите только "универсальность". Мне, как автору шаблона, важно, чтобы операции над параметром-типом были теми, которые мне нужны, и делали то, что мне нужно. Если я хочу присваивание, то использую =. Если пользователь моего шаблона подсунет мне тип, в котором operator= отнюдь не делает копию правого операнда в левом, полностью уничтожая предыдущий контекст левого и сохраняя контекст правого неизменным, идиотом будет он, а не я. Если аналогично поступит сам язык, идиотом будет язык. Логично?
Конечно, нет, другого ответа я не ждал. Естественно это я идиот, что не подумал о том, что семантика operator= разная для разных типов. Поэтому я не пишу дженериков, а пишу шаблоны. В них, между прочим, я мог бы различить семантику, если бы вдруг понадобилось. Ирония в том, что это не нужно, а в дженериках вот нужно, но возможно ли?..
Ну естественно нет, потому что это я думаю, что нужно, а на самом деле не нужно. Потому что есть другие способы, которые "правильные". А конкретно тут вместо := для получения копии я должен использовать встроенную в язык фабрику. Ой, у Integer нет фабрики. Чьёрт (тьфу-тьфу-тьфу).
Внимание - вопрос: занафиг мне такая универсальность, если в обобщённых шаблонах я просто либо ставлю &, либо нет? Так у кого из нас гемо?

P.S. Про операцию присваивания - это я условно. На её месте может быть любая операция, контекстно-чувствительная к ссылкам vs значениям.

Цитата DesweR @ 23.04.11, 20:26

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

Уверен? Посмотри на свой тип ещё раз. Он соответствует ТЗ? Уверен??

Цитата DesweR @ 23.04.11, 20:55

Хорошо, а вот такой вариант?

'yes' -это мультибайтовый символ в C/C++, а не строка.

Цитата Adil @ 23.04.11, 23:31

в дельфи еще и внезапно поведение.

я тебя шокирую наверно, но это везде так

Цитата korvin @ 24.04.11, 06:23

Цитата Adil @ 23.04.11, 23:31

в дельфи еще и внезапно поведение.

я тебя шокирую наверно, но это везде так

В Delphi - да, в C# - тоже.
В той же Java переменные являются ссылками, просто для примитивных типов сделано исключение. Т.е. эта модель ближе к той, что я описывал.
Если бы вместо особого поведения примитивных типов их сделали бы неизменяемыми - было бы идеально.
Где еще? И я все жду от тебя более развернутого ответа, поскольку твой ответ для меня прозвучал через чур обще, я не понимаю, как это будет выглядеть на практике. Формально "значение" не может меняться, меняется только переменная(указывает на другое значение в случае ссылочной семантики или содержит другое значение в случае семантики значений).

Добавлено 24.04.11, 07:38

Цитата korvin @ 23.04.11, 21:39

Цитата D_KEY @ 23.04.11, 21:17

Или может ты мне хотя бы скажешь, где именно о ссылочных типах можно почитать что-то из теории?

хз, в гугле наверное. вот некто Павел Наумов что-то пишет (не читал)

Спасибо, посмотрю.

Цитата

Цитата D_KEY @ 23.04.11, 21:33

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

ээ... что вижу на практике? в Racket это работает.

тип -- это [символ (метка), обозначающий некое множество значений] или [безымянный тип, созданый по правилам комбинации типов]

и для объектов, и для "простых" типов это будет символ. однако реализации у них будут разными.

Так замечательно. Как это связано с переменными ?

Сообщение отредактировано: D_KEY - 24.04.11, 07:39

korvin вот смотри.
Присваиваем переменной x некоторое новое значение(псевдоязык):

var x = new somevalue

Теперь мы используем еще одну переменную:

var y = x

Меняем что-то через x.
Должно ли меняться то, что нам доступно через y?
ИМХО, но ответ должен зависеть не от типа, а от того, какая семантика принята в языке для переменных - ссылочная или значений.
Зачем тут вводить зависимость от типа? Ради мифического удобства использования и/или из-за лени поставить лишний символ, обозначающий ссылку(для языков с семантикой значений) или копию(для языков с семантикой ссылок)?
Т.е. например:
Создание ссылки в языке с семантикой значений:

var &y = x

Или создание копии в языке с семантикой ссылок:

var y = new x

Цитата D_KEY @ 24.04.11, 07:35

Так замечательно. Как это связано с переменными ?

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

Цитата D_KEY @ 24.04.11, 08:40

ИМХО, но ответ должен зависеть не от типа, а от того, какая семантика принята в языке для переменных - ссылочная или значений.

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

Сообщение отредактировано: korvin - 24.04.11, 10:23

Заметил, кроме Дельфи и С++, все остальные упоминаемые языки - интерпретируемые. Для которые естественнее использование единого дерева классов и ссылок даже для простых значений. Передача в качестве параметров в функцию значений в их случаях не дает никакого выигрыша.

В случае С++ мы имеем, среди прочего, необходимость совместимости с С, в частности идеологической. В С все аргументы передаются только по значению. Исключение составляют массивы и функции, для которых используется псевдоссылочный метод (на самом деле передаются указатели, но специфика работы с указателями в С такова, что в данном случае они почти не отличаются от ссылок).
Идеология передачи аргументов в С++ такова, что все они по умолчанию тоже передаются строго по значению. Исключение опять же сделано только для массивов и функций. Однако постоянно применять *var и var->... не очень удобно, поэтому были введены явно описанные ссылки.
Однако иногда использование ссылок оказывается неэффективным, поэтому в новом стандарте ввели еще один тип ссылок. Дело в том, что С++ - промышленный язык программирования, используемый кроме всего прочего и во встроенных системах, и потому ориентированный кроме всего прочего на получение максимальной эффективности программы. Такой подход не позволяет реализовывать в языке некоторые чистые концепции, зато он оказался неожиданно хорош в плане обобщенного программирования. А концепции в результате оказываются вполне реализуемы существующими средствами.

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

Цитата amk @ 24.04.11, 16:35

Заметил, кроме Дельфи и С++, все остальные упоминаемые языки - интерпретируемые.

не все. Haskell, Ocaml, CL и Racket компилируются в машкод

Цитата korvin @ 24.04.11, 10:17

Цитата D_KEY @ 24.04.11, 07:35

Так замечательно. Как это связано с переменными ?

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

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

Цитата

Цитата D_KEY @ 24.04.11, 08:40

ИМХО, но ответ должен зависеть не от типа, а от того, какая семантика принята в языке для переменных - ссылочная или значений.

это семантика не переменных, а типов.

Почему типов, если данное поведение касается только премененных и никак не связано ни с типами ни со значениями(если связано, то объясни как, почему и зачем)?

Добавлено 24.04.11, 19:38
amk, речь не столько о явных-неявных ссылках и значениях, сколько о том, допустимо ли и нужно ли разделение на неявные ссылочные и не ссылочные типы. Т.е. вот этот вид типов всегда пораждает экземпляры, всегда являющиеся ссылками на данные некоторого скрытого типа, а другой вид типов порождает экземпляры, представленные значениями.

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

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

Цитата D_KEY @ 24.04.11, 19:34

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

Допустимо и нужно, вот к примеру строковый тип в Delphi - string, он имеет счетчик ссылок и автоматически увеличивает размер памяти под себя, переменная этого типа представляет собой указатель на значение, хранящиеся в динамической памяти. Преимущества "неявной ссылочности" этого типа:
• эффективная работа со строками, при копировании строки - копируется только указатель, при изменении строки - создаётся отдельная копия;
• нет необходимости вручную управлять памятью, она автоматически изменяется под размер строки;
• не подвержен эксплойтам на переполнении стека, т.к. значение хранится в динамической памяти.

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

Сообщение отредактировано: DesweR - 25.04.11, 02:15

Цитата amk @ 24.04.11, 20:46

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

ты уже второй раз несешь подобную чушь

http://stackoverflow.com/questions/913671/are-there-lisp-native-code-compilers

http://en.wikipedia.org/wiki/Common_Lisp#Implementations

Цитата

Most Common Lisp implementations compile source code to native machine code.

а что с остальной "половиной"? Racket компилируется через промежуточную трансляцию в C (или C у нас тепереь тоже не компилируемый?), Haskell и Ocaml тоже + Ocaml имеет свой прямой компилятор.