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

Цитата volvo877 @ 25.03.11, 21:40

Турбо-Паскаль, кстати, такое в принципе не компилирует,...

А, ну тогда понятно, почему не припомню. Я-то понимаю, откуда глюк. Потому что представляю, в какой код это компилируется. Но мы ж о Дельфи, а не Ассемблере, ведь так? Вот это ИМХО правильное "исправление" ситуации - незаконная с точки зрения языка конструкция.
Тогда вопрос звучит ещё жёстче. Если в Дельфи это теперь компилируемая конструкция, то на каком основании? И на каком основании она при своей законности не работает?

Цитата Qraizer @ 26.03.11, 17:27

Если в Дельфи это теперь компилируемая конструкция, то на каком основании?

Эта конструкция запрещенная, и некомпилируемая: при установке Typed @ operator в True компилятор пошлет программиста, написавшего такое куда подальше. И правильно сделает. Если DoSomething требует параметр типа TProcedure, а получает Pointer - это чья проблема? Программиста или компилятора?

Цитата volvo877 @ 26.03.11, 17:48

Цитата Qraizer @ 26.03.11, 17:27

Если в Дельфи это теперь компилируемая конструкция, то на каком основании?

Эта конструкция запрещенная, и некомпилируемая: при установке Typed @ operator в True компилятор пошлет программиста, написавшего такое куда подальше. И правильно сделает. Если DoSomething требует параметр типа TProcedure, а получает Pointer - это чья проблема? Программиста или компилятора?

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

Сообщение отредактировано: D_KEY - 26.03.11, 18:29

Цитата D_KEY @ 26.03.11, 18:26

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

Ты не понял. Передача локальной подпрограммы - это не

  DoSomething(@UseLocalVar);

, а

  DoSomething(UseLocalVar);

. Второй случай отсекается сразу, при любых настройках компилятор тебе сообщает, что произошла ошибка, ибо "Local procedure/function 'UseLocalVar' assigned to procedure variable". А вот первый случай - это как раз проблема программиста. Не надо куда не попадя пихать "@", это может плохо кончиться. Что, собственно, и происходит...

Сообщение отредактировано: volvo877 - 26.03.11, 18:33

Цитата volvo877 @ 26.03.11, 18:32

Цитата D_KEY @ 26.03.11, 18:26

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

Ты не понял. Передача локальной подпрограммы - это не

  DoSomething(@UseLocalVar);

, а

  DoSomething(UseLocalVar);

. Второй случай отсекается сразу, при любых настройках компилятор тебе сообщает, что произошла ошибка, ибо "Local procedure/function 'UseLocalVar' assigned to procedure variable". А вот первый случай - это как раз проблема программиста. Не надо куда не попадя пихать "@", это может плохо кончиться. Что, собственно, и происходит...

А, тогда спасибо за пояснения. И все-таки, почему нельзя передавать локальные подпрограммы?

Сообщение отредактировано: D_KEY - 26.03.11, 18:37

Цитата D_KEY @ 26.03.11, 18:37

И все-таки, почему нельзя передавать локальные подпрограммы?

"ниасилили" =) ты не забывай, что паскаль (и делфи, но в меньшей степени) -- очень примитивный язык. ибо Вирт любит примитивность =)

Цитата korvin @ 26.03.11, 19:18

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

Я бы попросил...

Вот такая вот программа

program pr_01;
 
type TProcedure = procedure;
 
procedure DoSomething(const AProc: TProcedure);
var X: Integer;
begin
  for X := 1 to 3 do AProc;
end;
 
function Test: Integer;
  var N: Integer;
  
  procedure UseLocalVar;
  begin
    Inc(N);
  end;
  
  begin
    N := 0;
    DoSomething(UseLocalVar);
    Test := N;
  end;
  
begin
  writeln(Test);
end.

прекрасно компилируется в GPC, и в результате получается ожидаемая тройка. Так что Паскаль-то как раз "асилил"...

Цитата volvo877 @ 26.03.11, 20:11

Цитата korvin @ 26.03.11, 19:18

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

Я бы попросил...

Вот такая вот программа

program pr_01;
 
type TProcedure = procedure;
 
procedure DoSomething(const AProc: TProcedure);
var X: Integer;
begin
  for X := 1 to 3 do AProc;
end;
 
function Test: Integer;
  var N: Integer;
  
  procedure UseLocalVar;
  begin
    Inc(N);
  end;
  
  begin
    N := 0;
    DoSomething(UseLocalVar);
    Test := N;
  end;
  
begin
  writeln(Test);
end.

прекрасно компилируется в GPC, и в результате получается ожидаемая тройка. Так что Паскаль-то как раз "асилил"...

а лексические замыкания уже асилили? и как с другими компиляторами паскаля?

Цитата D_KEY @ 26.03.11, 18:37

И все-таки, почему нельзя передавать локальные подпрограммы?

Потому что в локальной подпрограмме доступен локальный контекст в точке её определения. Вне области видимости её определения этого локального контекста нет, а значит "все адреса вымышлены, все совпадения имён случайны". Это сравнимо с прыжком во вложенный цикл, минуя внешний, или с нашими локальными шаблонами в функциях.
В приведённом примере процедура UseLocalVar либо получает указатель на стековый фрейм окаймляющей процедуры, либо прямо указатель на локальную, тем не менее видимую в её точке определения, N. В точке использования может не быть ни того, ни другого. А может и быть, как в приведённом примере. ИМХО UB чистой воды.

Добавлено 26.03.11, 22:04
volvo877, т.е. получается, что народ имел в виду, что компиляция прошла по причине нетипизированного указателя, возвращаемого @, и его совместимости с TProcedure, и это и есть та самая ошибка программиста? Ну, у нас void* совместим только в одну сторону, когда кастуешь к нему. А вот при касте из него - это даже в C варнинг, а в C++ эррор.
Вообще, нетипизированность указателей для Addr() и @ мне никогда не нравилась. Всегда ставил в опциях галку.

Сообщение отредактировано: Qraizer - 26.03.11, 22:06

Цитата Qraizer @ 26.03.11, 21:59

Цитата D_KEY @ 26.03.11, 18:37

И все-таки, почему нельзя передавать локальные подпрограммы?

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

Ну и что? Лямбде, например, он тоже доступен

Цитата

Это сравнимо с прыжком во вложенный цикл, минуя внешний

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

Цитата

или с нашими локальными шаблонами в функциях.

В новом стандарте разрешили же, или передумали?

Цитата

В приведённом примере процедура UseLocalVar либо получает указатель на стековый фрейм окаймляющей процедуры, либо прямо указатель на локальную, тем не менее видимую в её точке определения, N. В точке использования может не быть ни того, ни другого. А может и быть, как в приведённом примере. ИМХО UB чистой воды.

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

кстати, что-то вспомнилось АОП. допустим нам нужно, чтобы для объектов какого-то класса (и его потомков) перед или после выполнения какого-то метода происходили какие-то действия (запись в лог или что-то такое). причем классы эти могут быть не наши (т.е. изменить их определение может быть невозможным). как поступить в топиковых языках? дополнительно: если это нужно добавить ко всем объектам (в делфи и C# корень один, а в его нет, потому и вопрос)?

Цитата D_KEY @ 26.03.11, 22:47

Ну и что? Лямбде, например, он тоже доступен

Ну, во-первых, ламбде ты либо явно передаёшь по значению, что нужно захватить, и она получает себе копию, либо просто не используешь вне контекста, содержащего захваченное. В противном случае получишь то же UB, как и в случае ссылок на разрушенный объект. Не боись, народ ещё наломает себе мозг подобными ошибками, пока не привыкнет к технологии. Хотя, компиляторы, думаю, будут варнинговать, впрочем, вряд ли смогут отловить все случаи.
А вообще, я где-то говорил, что лямбды, которые не ограничиваются только собственным состоянием, но и что-то берут извне, это ИМХО косяк. Не стоило бы разрешать их в языке. Вот теперь будем получить ССЗБ себе с лоб.

Цитата D_KEY @ 26.03.11, 22:47

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

В приведённом примере - нет. Контекст, содержащий N, доступен, только лежит на один фрейм в стеке глубже. Я говорил об общем случае, когда указатель может использоваться в программе, где угодно. Беда в том, что невалидность указателя, когда он покидает область видимости, в которой определена указываемая им сущность, тут очень неочевидна, и это общая проблема указателей и ссылок на локальные сущности. Не задумывался, почему компилятор может успешно диагностировать такие левые ссылки, но не указатели?
Та даже в этом случае не всё так шоколодно. Иначе откуда бы AV взялось. Думаю, компилятор вместо передачи указателя на фрейм внешней функции явно обращается ровно на один фрейм выше. Или заюзал оптимизацию "подавления указателей на стековые фреймы". Или ещё чего, мало ли причин можно придумать. Любопытно было бы посмотреть в листинг.

Цитата D_KEY @ 26.03.11, 22:47

В новом стандарте разрешили же, или передумали?

Э-э-э... не припомню. Помню, что обычные шаблоны разрешили конкретизировать локальными сущностями, а вот касательно локальных шаблонов...

Сообщение отредактировано: Qraizer - 27.03.11, 02:09

Сделаем вброс

Цитата Qraizer @ 27.03.11, 01:59

Цитата D_KEY @ 26.03.11, 22:47

Ну и что? Лямбде, например, он тоже доступен

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

Что мешает "локальным функциям" действовать также, как лямбдам?

Цитата

А вообще, я где-то говорил, что лямбды, которые не ограничиваются только собственным состоянием, но и что-то берут извне, это ИМХО косяк.

Если они не будут этого делать, то они перестанут быть лямбдами.

Цитата

Не стоило бы разрешать их в языке. Вот теперь будем получить ССЗБ себе с лоб.

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

Добавлено 27.03.11, 12:48

Цитата MyNameIsIgor @ 27.03.11, 11:04

Сделаем вброс

Хорошо. В многом верно(ошибки только в подпунктах, вроде как).
Явный бред про превосходство С, исключения в конструкторах, управления памятью, медленную работу(исключений), некорректность кода в шаблонах. Ну и по ряду пунктов слишком сильная "паника".

Цитата D_KEY @ 27.03.11, 12:40

В многом верно(ошибки только в подпунктах, вроде как).

Правда?

Цитата

3. Никакого ABI
5. Дублирование функционала Си
6. Стандартная библиотека убога
8. Объектная система убога
9. Шаблоны
10. Исключения

Ты, считаешь, что все эти пункты свидетельствуют против плюсов и нигде нет ошибок?