Зачем два механизма ограничений?

[Дож]

Как здесь будет применён анализ достижимости веток? Будет ли компилятор анализировать на каких входах P(I) истинно, или просто посчитает F и G заведомом импортируемыми?

Когда я описывал, то считал правильным первый вариант. Так как невозможно понять какая ветка будет правильной не зная условия. Ведь, возможна ситуация, когда функция будет всегда выдавать True/False.

Провернуть такое для всей программы — это NP-полная задача :) Ваш алгоритм не годится.

[Лекс Айрин]

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

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

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

Код: Выделить всё

Program Test;
Begin
end;


Превращался в , за исключением заголовка, две инструкции:

Код: Выделить всё

call
ret


Добавлено спустя 1 минуту 22 секунды:
Ах нет... call это уже часть заголовка.

[скалогрыз]

сий сырой патч для fpc 2.6.4

позволяет комплировать вот такой код:

Код: Выделить всё

unit test2;

interface

{$mode delphi}

type
  TMyClass = class(TObject)
  public
    testval: integer;
    function GetVal: Integer;
    constructor Create(Avalue: integer);
  end;

implementation

type
  TMyClass = class(TObject)
  private
    fval: integer;
  end;

constructor TMyClass.Create(Avalue: integer);
begin
  fval:=Avalue;
  testval:=fval+5;
end;

function TMyClass.GetVal: Integer;
begin
  Result:=fval;
end;

end.

---------- main program ----------

{$mode delphi}
uses test2;

var
  mc : TMyClass;
begin
  mc := TMyClass.Create(48);
  writeln(mc.GetVal);
  writeln(mc.TestVal);
  mc.Free;
end.


[Дож]

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

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

Если бы всё было так просто, то проблем с оптимизацией не существовало бы. Вы набросали заведомо неработающие предложение, любой, кто хоть сколько-то интересовался темой подтвердит. NP-полнота — это не единственная проблема, есть и другие подводные камни.

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

Код: Выделить всё

Program Test;
Begin
end;


Превращался в , за исключением заголовка, две инструкции:

Код: Выделить всё

call
ret


Добавлено спустя 1 минуту 22 секунды:
Ах нет... call это уже часть заголовка.

Вот Вам интересное:

Код: Выделить всё

type
TObj = object
  constructor Init;
  procedure Foo;
  procedure Bar; virtual;
end;

constructor TObj.Init;
begin
  Writeln('_MARKER_INIT_MARKER_');
end;

procedure TObj.Foo;
begin
  Writeln('_MARKER_FOO_MARKER_');
end;

procedure TObj.Bar;
begin
  Writeln('_MARKER_BAR_MARKER_');
end;

var
  O: TObj;

begin
  O.Init;
end.


Код: Выделить всё

C:projcore>fpc -O3 opttest.pas
Free Pascal Compiler version 3.0.0rc1 [2015/08/10] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling opttest.pas
Linking opttest.exe
28 lines compiled, 0.1 sec, 25840 bytes code, 1252 bytes data

C:projtemp>grep _MARKER_INIT_MARKER_ opttest.exe
Binary file opttest.exe matches

C:projtemp>grep _MARKER_FOO_MARKER_ opttest.exe

C:projtemp>grep _MARKER_BAR_MARKER_ opttest.exe
Binary file opttest.exe matches


Вот ещё: http://wiki.freepascal.org/Whole_Program_Optimization

Добавлено спустя 4 минуты 58 секунд:

сий сырой патч для fpc 2.6.4 позволяет комплировать вот такой код:

Ух ты, круто! Надо будет опробовать, дифф на удивление очень компактный.

[скалогрыз]

Ух ты, круто! Надо будет опробовать, дифф на удивление очень компактный.

FPC-же!

[Лекс Айрин]

Если бы всё было так просто, то проблем с оптимизацией не существовало бы.

Что же нам теперь сесть и ножки свесить?

Вот Вам интересное:

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

[Дож]

Если бы всё было так просто, то проблем с оптимизацией не существовало бы.

Что же нам теперь сесть и ножки свесить?

Свешивание ножек не решит проблему, но и, прямо скажем, дилетанские филосовствования, выдаваемые за решение проблем, тоже так себе вариант. Я призываю поглубже разобраться в вопросе, почитать про WPO, про SAT problem и таки попытаться посмотреть как должен действовать Ваш алгоритм на моём примере (который перед опубликованием я проверял на компилируемость, он собирается).

[Mirage]

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

Документация часто бывает в виде комментариев как раз к публичной части класса/модуля. Что на мой взгляд наиболее практично и удобно. Причем удобнее всего именно когда она сосредоточена в интерфейсной секции. Так что разделение на секции рано списывать.
А усложнение от этого микроскопическое.

[Лекс Айрин]

но и, прямо скажем, дилетанские филосовствования, выдаваемые за решение проблем, тоже так себе вариант

Не бойтесь делать то, что не умеете. Помните, ковчег построил любитель, — профессионалы построили Титаник. (Дэйв Бер)
К тому же, если указанный способ решит проблему, то неважно насколько он будет медленным или дилетантским -- он будет работать, а значит профи смогут его улучшить. А не смогут, так придумают новый. А не решит, так я посмотрю где ошибка(и) и сделаю заново, с учетом этого.

А профи будут работать с объектом в старом стиле, не понимая, что они забивают гвозди микроскопом.Именно по этому, кстати, я долго не мог освоить объектный паскаль -- декларируется одно, а делается по другому. Пришлось долго разбираться что и как делается правильно. Зачем нужны все эти public, private, protected, inherrited и прочие ругательства. Dедь в объектной модели прямо декларируется недоступность полей снаружи... так почему я могу в них залезть? Ведь в описании ООП сказано, что изменения объектных полей снаружи невозможно.

А потом до меня дошло, что в объектном паскале объект это всего-лишь запись с плюшками.

А необходимость разделения определений на открытую (interface) и закрытую (implementation) .. так это те же public и private, но на глобальном уровне.

И вообще, ООП, само по себе, требует гипертекста/визуального проектирования. А современный стиль записи это всего-лишь попытка отразить многомерную структуру на одно измерение.

[Mikhail]

Документация часто бывает в виде комментариев как раз к публичной части класса/модуля. Что на мой взгляд наиболее практично и удобно. Причем удобнее всего именно когда она сосредоточена в интерфейсной секции. Так что разделение на секции рано списывать.

Разделение делает невозможным полноценное создание АТД либо показывай приватные члены либо делай специальную обертку над неким внутренним классом.
Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена. В больших же проектах такой документации просто недостаточно, необходима дополнительная документация о структуре библиотек (проекта) в целом, интерфейсах взаимодействия компонентов, некоторые общие соображения о принципах построения компонентов системы и т.п. Иначе все это приходится изучать по исходникам и вовсе не по секции интерфейса, что занимает много времени. Кстати, у FreePascal и Lazarus с этим плохо, мало документации именно о структуре компилятора, LCL и т.д.

А усложнение от этого микроскопическое.

Воспринимается это намного сложнее и ошибки будет искать сложнее. А вообще, например, в скроссплатформенном, якобы, модуле SysUtils в интерфейсе цепляется модуль Windows под Win32, Linux, под Linux и т.д.

[Дож]

Разделение делает невозможным полноценное создание АТД либо показывай приватные члены либо делай специальную обертку над неким внутренним классом.

Но ведь protected никто не предлагает отменять

Код: Выделить всё

type
TAbstract = object
protected
  procedure DoAbstract; virtual; abstract;
end;


Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.

Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена.

Комментарии для таких генераторов, как правило, очень механически написаны, с излишним синтаксисом и т.д. — ухудшают читаемость и кода, и неочевидной информации редко содержат. Как раз нормальные живые комментарии в интерфейсной части о том, как эту интерфейсну часть правильно использовать, лучше всех. Лучше их только отдельно написанная живая документация.

[Mikhail]

Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.

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

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

Это уже от автора зависит, а не от системы комментирования.

[Дож]

Под АТД такое подразумевается? Такое должно быть разрешено в любом случае.

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

В чём проблема все поля положить в implementation и сделать доступ к ним через свойства?

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

Это уже от автора зависит, а не от системы комментирования. :)

При прочих равных один подход к комментированию среднестатистически лучше другого.

[Mirage]

Проблема документирования надуманная, ИМХО, полно средств ее генерации из комментариев и все равно где именно в модуле она расположена.

Генерация используется, в основном, для создания веб-страничек с документацией. При работе с библиотекой веб-страничку неудобно использовать. Куда удобнее сразу видеть описание класса/метода перейдя к нему по ctrl+click.
А тюториалов это не заменит конечно.
Насчет порядка полей согласен, проблема.

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

Когда можно ждать реализацию?

[daesher]

А вам не кажется, что такой подход слегка нарушает логику введения interface/implementation? Ну да, может, она устарела, но, тем не менее, существует.
interface - это те объявления, которые переходят в другие модули, в основную программу. Причём переходят в машинном, а не в человеческом виде: определяя класс в interface, мы предполагаем, что этим классом будет пользоваться код из других модулей. Включая доступ к приватным методам/полям через общедоступные свойства (свойство само по себе не даёт ни кода, ни адреса в памяти). Секция реализации (implementation) - это внутреннее, личное дело модуля, она даёт только код + пространство данных, недоступные остальным частям программы иначе как по адресам, описанным в интерфейсной части. То есть, по большому счёту, интерфейс - это то, что хранится в .ppu, а весь implementation уходит в .o (ну, в некоторой степени исключением являются блоки данных, определённые в интерфейсной части).
Идея разбить описание класса на две части фактически нарушает эту логику: компилятору придётся поднимать в ppu из секции implementation описание класса, как вариант - создавать "дырявое" описание для класса, но что-то надо будет делать со свойствами.
Т.е., фактически мы всё дальше уходим от машинного представления к человеческому, но не связанному с машинным, что может порождать непонимание и коллизии (которые уже являются спутником последних версий FPC).