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

Проектирование и разработка идеального средства программирования.

Модератор: Модераторы

Пожалуйста, прочтите верхний пост, и скажите какой подход к дизайну языка лучше.

Лучше как сейчас
10
53%
Лучше так, как сейчас, и никак иначе!
2
11%
Лучше без private и strict (но с остальными секциями)
4
21%
Мне пофиг
1
5%
Лучше убрать interface и implementation
2
11%
 
Всего голосов : 19

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

Сообщение Дож » 26.10.2015 19:00:49

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


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

Провернуть такое для всей программы — это NP-полная задача :) Ваш алгоритм не годится.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Лекс Айрин » 26.10.2015 19:33:47

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

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

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

Код: Выделить всё
Program Test;
Begin
end;


Превращался в , за исключением заголовка, две инструкции:
Код: Выделить всё
call
ret


Добавлено спустя 1 минуту 22 секунды:
Ах нет... call это уже часть заголовка.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение скалогрыз » 26.10.2015 19:55:48

сий сырой патч для 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.
Вложения
privateimpl.zip
(1.02 КБ) Скачиваний: 627
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение Дож » 26.10.2015 20:00:19

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

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

Если бы всё было так просто, то проблем с оптимизацией не существовало бы. Вы набросали заведомо неработающие предложение, любой, кто хоть сколько-то интересовался темой подтвердит. 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 позволяет комплировать вот такой код:


Ух ты, круто! Надо будет опробовать, дифф на удивление очень компактный.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение скалогрыз » 26.10.2015 20:07:54

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

FPC-же!
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

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

Сообщение Лекс Айрин » 26.10.2015 20:11:32

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


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

Дож писал(а):Вот Вам интересное:


на самом деле, это неинтересный тестовый пример. самым для, винды, правильным был бы вызов пустого окна. Чем от меньше, тем лучше работает компилятор (тем правильнее написана библиотека)
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение Дож » 26.10.2015 20:33:16

Лекс Айрин писал(а):
Дож писал(а):Если бы всё было так просто, то проблем с оптимизацией не существовало бы.

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

Свешивание ножек не решит проблему, но и, прямо скажем, дилетанские филосовствования, выдаваемые за решение проблем, тоже так себе вариант. Я призываю поглубже разобраться в вопросе, почитать про WPO, про SAT problem и таки попытаться посмотреть как должен действовать Ваш алгоритм на моём примере (который перед опубликованием я проверял на компилируемость, он собирается).
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Mirage » 26.10.2015 23:13:35

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


Документация часто бывает в виде комментариев как раз к публичной части класса/модуля. Что на мой взгляд наиболее практично и удобно. Причем удобнее всего именно когда она сосредоточена в интерфейсной секции. Так что разделение на секции рано списывать.
А усложнение от этого микроскопическое.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение Лекс Айрин » 27.10.2015 10:00:29

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


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

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

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

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

И вообще, ООП, само по себе, требует гипертекста/визуального проектирования. А современный стиль записи это всего-лишь попытка отразить многомерную структуру на одно измерение.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

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

Сообщение Mikhail » 27.10.2015 11:03:11

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

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

Mirage писал(а):А усложнение от этого микроскопическое.

Воспринимается это намного сложнее и ошибки будет искать сложнее. А вообще, например, в скроссплатформенном, якобы, модуле SysUtils в интерфейсе цепляется модуль Windows под Win32, Linux, под Linux и т.д. :)
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение Дож » 27.10.2015 11:23:14

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

Но ведь protected никто не предлагает отменять
Код: Выделить всё
type
TAbstract = object
protected
  procedure DoAbstract; virtual; abstract;
end;

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

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

Комментарии для таких генераторов, как правило, очень механически написаны, с излишним синтаксисом и т.д. — ухудшают читаемость и кода, и неочевидной информации редко содержат. Как раз нормальные живые комментарии в интерфейсной части о том, как эту интерфейсну часть правильно использовать, лучше всех. Лучше их только отдельно написанная живая документация.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Mikhail » 27.10.2015 11:27:00

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

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

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

Это уже от автора зависит, а не от системы комментирования. :)
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

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

Сообщение Дож » 27.10.2015 12:28:57

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

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


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

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

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

При прочих равных один подход к комментированию среднестатистически лучше другого.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

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

Сообщение Mirage » 27.10.2015 23:24:06

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


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

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


Когда можно ждать реализацию?
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

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

Сообщение daesher » 28.10.2015 08:49:39

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

Пред.След.

Вернуться в Компилятор / язык программирования

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7

Рейтинг@Mail.ru