FPC, Lazarus зачем они Вам?

[скалогрыз]

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

рисково же! Вот допустим реализовали фичу до 100% делфи совместимости. А потом ещё и улучшили! Всё вроде бы отлично.
Но делфи в следующей версии сама доработает фичу, но доработка может оказаться несовместимой с FPC.

И кто будет виноват? конечно же команда FPC. Потому что есть понятие "совместимость с делфи", но почему-то никто не диктует делфи "совместимость с FPC".

Как итог. любая полу-фича в делфи, очень может оказаться полу-фичей в FPC. Но с тем плюсом, что её можно отлючить/использовать по своему вкусу.
Как скажем нумерация Ansi/Wide/Unicode строк с 0-элемента, а не с первого

[vitaly_l]

ну хз-хз. вот смотри пример.

Я например недавно столкнулся с тем, что класс перестал работать как только я назвал функции класса Inc и Dec ... Потом переименовал в Incl и Decl - всё работает. Так что, там, есть какие-то "ограничения/сбои" в названиях. Но они не смертельны (если заранее знать что они возможны).

никаких догонялок не требуется

По моему, это именно догонялки, т.к. в этих конструктах языка, взятых из других языков - особой надобности я не вижу. Просто не вижу такой задачи, в которой это было-бы удобнее или тем более необходимо. Более того, эти фиче-конструкты затормозят работу программы (хотя и не факт). Скалогрыз прав, завтра в Delphi придумают новую фичу и FPC - будет опять догонять. Но у них нет выхода, а Вам-то это зачем? Хотя... возможно это и удобно в некоторых случаях...


.

[скалогрыз]

Я например недавно столкнулся с тем, что класс перестал работать как только я назвал функции класса Inc и Dec ... Потом переименовал в Incl и Decl - всё работает. Так что, там, есть какие-то "ограничения/сбои" в названиях. Но они не смертельны (если заранее знать что они возможны).

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

program vitaly;
{$ifdef fpc}{$mode delphi}{$endif}
type
  TMyClass = class(TObject)
  public
    v: Integer;
    procedure Inc;
    procedure Dec;
  end;

procedure TMyClass.Inc;
begin
  system.inc(v);
end;

procedure TMyClass.Dec;
begin
  system.dec(v);
end;

var
  m: TMyClass;
begin
  m:=TMyClass.Create;
  m.Inc;
  writelN(m.v);
  m.Dec;
  writelN(m.v);
  m.Free;
end.


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

C:\projects\testDodge>fpc vitaly.pas
Free Pascal Compiler version 2.6.4 [2014/03/06] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling vitaly.pas
Linking vitaly.exe
28 lines compiled, 0.1 sec , 29008 bytes code, 1996 bytes data


что я делаю не так?

[kazalex]

рисково же! Вот допустим реализовали фичу до 100% делфи совместимости. А потом ещё и улучшили! Всё вроде бы отлично.
Но делфи в следующей версии сама доработает фичу, но доработка может оказаться несовместимой с FPC.

Собственный диалект FPC и так с дельфями не совместим, что мешает в нём всё делать хорошо и правильно, либо просто не уподобляться?

[скалогрыз]

Собственный диалект FPC и так с дельфями не совместим,

именно по-этому, благодяря, typeswitch-ам, все сомнительно/недодуманные фичи, в OBJFPC выключенны по-умолчани.
и по-вкусу можно их включить!
например TypeHelp-еры могут быть ключены в OBJFPC когда будут доведены до ума. (будут реализованы для object-ов, interface-ов ну и несколько могут быть использованы, но не ранее)

...либо просто не уподобляться?

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

И естественно, для чистоты, фича может быть не включена в $mode objfpc по-умолчанию, но зато будет доступна в $mode delphi

FPC команда удивительно ловко умеет "и вашим, и нашим" (возможно потому что пишут на паскле... )

[vitaly_l]

что я делаю не так?

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


type
TSomeClass = class // без объявления TObject
   function  Incl(cnt:word): dword;            // Inc
   function  Decl(cnt:word): dword;            // Dec   
end;



И вот эти штуки я тоже не указываю: {$ifdef fpc}{$mode delphi}{$endif} у меня там по умолчанию вот такие: {$mode objfpc}{$H+}
И программа у меня оконная. Всё остальное так же.

[скалогрыз]

И вот эти штуки я тоже не указываю: {$ifdef fpc}{$mode delphi}{$endif} у меня там по умолчанию вот такие: {$mode objfpc}{$H+}
И программа у меня оконная. Всё остальное так же.

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

{$ifdef fpc}{$mode objfpc}{$h+}{$endif}
type
  TMyClass = class
  public
    v: Integer;
    procedure Inc;
    procedure Dec;
  end;

procedure TMyClass.Inc;
begin
  system.inc(v);
end;

procedure TMyClass.Dec;
begin
  system.dec(v);
end;

var
  m: TMyClass;
begin
  m:=TMyClass.Create;
  m.Inc;
  writelN(m.v);
  m.Dec;
  writelN(m.v);
  m.Free;
end.


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

C:\projects\testDodge>fpc vitaly.pas
Free Pascal Compiler version 2.6.4 [2014/03/06] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling vitaly.pas
Linking vitaly.exe
28 lines compiled, 0.1 sec , 29008 bytes code, 1996 bytes data


?

правильнее тебе будет переименовать Incl в inc и запостить текст ошибки.
Но скорей всего проблема не в Inc, а в cnt

[vitaly_l]

На Ваш код не ругается, а на мой запускает приложение, и сразу появляется сообщение: Access violation.
При нажатии Ok программа работает. Переименовываю и сообщение перестаёт появляться.

[скалогрыз]

мне кажется FPC тут ни при чём. Ошибка между клавиатурой и креслом.

[vitaly_l]

Ошибка между клавиатурой и креслом.

Ладно буду искать ошибку между клавиатурой и креслом. Наверняка она где-то там

[kazalex]

именно по-этому, благодяря, typeswitch-ам, все сомнительно/недодуманные фичи, в OBJFPC выключенны по-умолчани

Nested types работают в 3.1.1. по дефолту. Однако:

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

program Project1;
{$mode objfpc}
uses typinfo;
type
  tobj=class
    type
     tnestedobj = class
     end;
  end;
begin
writeln(tobj.tnestedobj.classname);
writeln(ptypeinfo(typeinfo(tobj.tnestedobj))^.Name);
readln;
end.

output:

tobj.tnestedobj
tnestedobj

Баг-репорту скоро год исполнится. Это я снова о качественности проработки.

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

Это понятно, и совместимость с дельфями несомненно важная штука. Но почему-же перед включением фичи-"совместителя" не протестировать её основательно, что бы она работала хотя бы как в дельфях?

FPC команда удивительно ловко умеет "и вашим, и нашим" (возможно потому что пишут на паскле... )

При всём моём уважении к тиму, я до сих пор не могу нормально собрать дельфийский проект работающий даже в Delphi 2006. А там из фичей только advanced records, nested types (в сочетании дают гремучую смесь), strict visibility specifiers (а компилятор тень на плетень наводит) да unicode strings (тут тоже не всё гладко, но пока не задокументировано).

[скалогрыз]

Это понятно, и совместимость с дельфями несомненно важная штука. Но почему-же перед включением фичи-"совместителя" не протестировать её основательно, что бы она работала хотя бы как в дельфях?

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

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

output:
tobj.tnestedobj
tnestedobj

Баг-репорту скоро год исполнится. Это я снова о качественности проработки.

по мне так правильно выглядит. А какой ожидаемеый результат?

[vitaly_l]

Попробовал подключить все модули что и в проекте. Тоже работает. В общем на тестовом проекте - повторить появление предупреждения не удалось Между креслом и клавиатурой ошибку не нашёл, потому что, вот так работает и ошибка не выскакивает .

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

unit Unit1;

{$ifdef fpc}{$mode objfpc}{$h+}{$endif}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;

type
  TMyClass = class
  public
    v: Integer;
    function Inc(cnt:word):dword;
    function Dec(cnt:word):dword;
  end;

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  m: TMyClass;
begin

  m:=TMyClass.Create;
  caption := IntToStr(m.Inc(5));
  // writelN(m.v);
  caption := caption  + ' ' + IntToStr(m.Dec(5));
  // writelN(m.v);
  m.Free;
end;

function TMyClass.Inc(cnt:word):dword;
begin
  v := random(111);
  result:=v*cnt;
end;

function TMyClass.Dec(cnt:word):dword;
begin
  v := random(111);
  result:=v*cnt;
end;
end.     


[kazalex]

А какой ожидаемеый результат?

По какому имени можно обратиться к этому идентификатору извне?

[Дож]

ли я хочу сделать много глобальных функций Max, Intersect, Sort, IfThen и т.д., и для разных типов, разнесённых по разным модулям, то у меня ничего не выйдет, потому что функция из одного модуля полностью закроет функцию другого модуля с таким же названием. А неймспейсы и конструкции вида UnitName.Max подрывают идею перегруженных функций, к тому же with UnitName do не работает.

ну хз-хз. вот смотри пример.

<...>
maxstr.pas

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

unit maxstr;

interface

{$ifdef fpc}{$mode delphi}{$h+}{$endif}

function Max(const a,b: string): string; overload;

implementation

function Max(const a,b: string): string; overload;
begin
  if a>b then Result:=a
  else Result:=b;
end;

end.


<...>
компилится и работает.

WOW! Опробовал у себя, похоже, что действительно работает. Я не использовал overload, когда в модуле была всего одна функция. Вот откуда можно было узнать, что overload действует для функций из разных модулей? :)