Was wünscht ihr euch für Pascal Features in der Zukunft

[and4more]

Zuallererst finde ich Lazarus ganz super. Es ist der komplett richtige Ansatz. Hatte früher in C/C++ programmiert weil mir die Bezeichnung 'PASCAL' für eine Programmiersprache irgendwie seltsam klang und mir außerdem suggeriert wurde, dass C/C++ plattformübergreifend sein, naja. Mit C/C++ kann man zwar sehr viel machen, aber es hat so viele 'Macken' und macht es einem nicht wirklich leicht zu programmieren. Für mich sollte eine Programmiersprache leicht zu erlernen sein, dem Programmierer bei seiner Arbeit helfen durch gute Typenprüfung, plattformübergreifend sein, Garbage Collector und vor allem ... viel Arbeit abnehmen durch Unterstützung mittels geeigneter Tools. Wer würde sich heute einen Traktor kaufen wenn er mit einem anderen Fahrzeug bequemer zum Ziel kommt. Die Sprache sollte für den Programmierer da sein und nicht umgekehrt, also 'make it as easy as possible'. Die Kompatibilität zu Delphi mag eventuell einen Vorteil darstellen doch manchmal sind einige Funktionen doch ein wenig hintenrum durch's Knie. Hier wäre es schön wenn man sich um Konsistenz bemühen könnte, sodass grundlegende Funktionen einfach dem allgemeinen 'Bedienungsschema' entsprechen (z. B. sollte es auch ein TIpHtml.Clear geben und viele Subroutinen sollten einfach das tun was sie sprachlich suggerieren ohne irgendwelche vor- und nachbereitenden Funktionen benutzen zu müssen). Warum PASCAL als Sprache so unterrepräsentiert ist kann ich beim besten Willen nicht verstehen (nur weil es eine 'alte' Sprache ist?!?), es ist nicht schwerer als Python und ich kann den Hype um Python, Ruby und Konsorten absolut nicht verstehen. Es gibt kaum aktuelle Literatur zu PASCAL, dafür aber umso mehr für C/C++, obwohl eigentlich offensichtlich ist, dass (sehr) viele Programmierer mit C/C++ überfordert sind. Insgesamt würde ich mir für Lazarus wünschen, dass es zu einer Sprache FÜR den Programmierer wird, also insgesamt noch einfacher in Bedienung und Codierung.

[BeniBela]

Meinst du ich hätte ein Chance, wen ich 2.7.1 installiere ?

Wenn du den Patch manuell mergst

Die haben es wohl vergessen

[marcov]

...und des Minimums von 32 Elementen (für die interne Speichernung) - wenn man z.B. das Set z.B. auf ein Word oder Byte abbilden muß und dabie mit weniger Elementen leben kann.

welches minimum?

Code: Alles auswählen

 
{$mode delphi}
var x : set of 0..7;
 
begin
writeln(sizeof(x));
end.
 

gibt "1" aus.

Was du meinst ist ein "Feature" von objfpc.

[Mathias]

Meinst du ich hätte ein Chance, wen ich 2.7.1 installiere ?

Wenn du den Patch manuell mergst

Die haben es wohl vergessen

Was meinst du damit ?

[BeniBela]

Meinst du ich hätte ein Chance, wen ich 2.7.1 installiere ?

Wenn du den Patch manuell mergst

Die haben es wohl vergessen

Was meinst du damit ?

Den Patch auf den ich oben verlinkt habe

[Mathias]

Ich habe es endlich geschaft, FPC 3.1.1 zu installieren, aber so wie es aussieht, wird $INCLUDESTRING noch nicht unterstützt.

Den Patch auf den ich oben verlinkt habe

Muss ich dort die *.diff runterladen und irgendwie installieren ?

[fpGUIcoder]

Code: Alles auswählen

for int i := 0 to 10 do WriteLn();  

Achso, du willst mitten im Quellcode eine Variable deklarien. Warum?

Ich bin echt erstaunt über einige Wünsche. Pascal ist so eine schöne saubere Sprache, warum wollt ihr sie immer mit soviel Unfug anreichern?

Damit das einen Syntaxfehler gibt:

Code: Alles auswählen

 
  for i := 0 to rowCount do begin
    for j := 0 to colCount do  
      changeCell(i, j);
    completeRow(j);
  end;
 

Hier sollte satandardmäßig die Bereichsüberwachung eingeschaltet sein. Und der Compiler sollte dann hier einen Bereichsfehler melden, da Rowcount bereits außerhalb des Wertebereiches ligt. In einem größeren Programm sucht man sich dann dusselig, wegen so enes Fehlers.

[fpGUIcoder]

Ich wünsche mir, daß die Direktive {mode objfpc} nicht mehr explzit gestzt werden muss, sondern bereits Standard ist. Ich versuche so manches Mal Freepascal Quellen nach Delphi zu portieren. Da stört diese Direktive dann gewaltig, weil ich sie in jeder Quelldatei umklammern muss.

Mach ich dann so hier: {$ifdef FPC} {$mode objfpc}{$H+}{$endif}

Ist aber nervig, wenn ich das in einer großen Bibliothek dann mit jeder Quelldatei machen muss.

[marcov]

Ich wünsche mir, daß die Direktive {mode objfpc} nicht mehr explzit gestzt werden muss, sondern bereits Standard ist. Ich versuche so manches Mal Freepascal Quellen nach Delphi zu portieren. Da stört diese Direktive dann gewaltig, weil ich sie in jeder Quelldatei umklammern muss.

Mach ich dann so hier: {$ifdef FPC} {$mode objfpc}{$H+}{$endif}

Ist aber nervig, wenn ich das in einer großen Bibliothek dann mit jeder Quelldatei machen muss.

Ich möchte gern eine Einstellung haben um Forms mit {$ifdef fpc} {$mode delphi} {$endif} herzustellen. Sonst muss man zb alle Events mit @ assignen.

[Mathias]

Ich wäre noch für eine kleine Verbesserung von Lazarus.

Wen beim Entwickeln ein Laufzeitfehler kommt, z.B. SIGSEV, dann muss man immer Ctrl+F2 drücken, bevor man mit F9 neu starten kann.
Schön wäre es, wen man direkt F9 drücken könnten und sich automatisch das alte Programm beendet, so wie es Delphi macht.

[fpGUIcoder]

Ich wünsch mir einfacheres Typecasting

Habe gerade eine Übersetzung laufen, da wird die Funktion

ptInRect(r, pt) aufgerufen.

Wenn ich das statt pt mit den Koordinaten Point(x,y) übergebe, weist das der Compiler ab, weil TPoint erwartet wird, wenn ich aber dann Topint schreibe, wird die Typumwandling nicht akzeptiert, obwohl doch klar sein sollte, was ich erreichen will, nämlich die beiden x,y Koordinaten in Point bzw. Tpoint Casten.

Ein anderer Fall:

Ich musste soeben die Deklaration einer Funktion DrawPolygon(Points: PPOint); andern in DrawPolygon(Points: array of TPoint);

Grund: Der Cpmpiler maldet mir Fehler:
Error: Incompatible Type for arg no. 1: Got dynamic array of TPoint expexted OpenArray of TPoint

Hatte gehofft, wenn ich den ursprünglichen Typ PPoint durch ein dynamisches Array ersetze, könne ich die Werte übergeben.

Die Frage nach der optimalen Lösung stelle ich in einem separaten Thread.

Hier nur der Feature Request, die Typkonvertierung programmiererfreundlicher zu gestalten.

[Michl]

Wenn ich das statt pt mit den Koordinaten Point(x,y) übergebe, weist das der Compiler ab, weil TPoint erwartet wird

Code: Alles auswählen

var
  x, y: Integer;
  r: TRect;
begin
  ptInRect(r, x, y);          //geht nicht
  ptInRect(r, Point(x, y));   //das schon
end;  

Auch könnte man die Funktion ptInRect überladen, dass dies gänge.

Ich bin sehr zufrieden, wie Pascal das zur Zeit macht, es sind klare Strukturen - ein Vorteil von Pascal, den man nicht aufgeben sollte.

[Mathias]

So wäre auch noch praktisch.

Code: Alles auswählen

var
  testArray: array[0..7] of byte;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  testArray := [0, 1, 2, 3, 4, 5, 6, 7]; // gibt Fehler
end;

[fpGUIcoder]

Wenn ich das statt pt mit den Koordinaten Point(x,y) übergebe, weist das der Compiler ab, weil TPoint erwartet wird

Code: Alles auswählen

var
  x, y: Integer;
  r: TRect;
begin
  ptInRect(r, x, y);          //geht nicht
  ptInRect(r, Point(x, y));   //das schon
end;  

Auch könnte man die Funktion ptInRect überladen, dass dies gänge.

Ich bin sehr zufrieden, wie Pascal das zur Zeit macht, es sind klare Strukturen - ein Vorteil von Pascal, den man nicht aufgeben sollte.

Ich übersetze gerade die fpGUI neu, hab da paar Änderungen vorgenommen. In keiner der Units funktionirt da die zweite Variante. Möcht gerne wissen welche Zusatzoption ich da einstellen muss damit das wirder klappt, jede Unit der fpGUI ruft ein bis mehrmals die Funktion ptInRecht auf.

Erwartet wird TPoint, das Casting aber liefert POint. Aber auf TPoint andern bringt nix.

Da muss ich doch bestimmt bloß ganz simpel einen Compierschalter setzen, nicht wahr?


Aber welchen. Was also muss ich das setzen?


Derzeit ändere ich jeden Aufruf so ab:

Code: Alles auswählen

 
procedure Irgendwas(x,y: Integer);
var
 pt: TPoint;
 r: TRect;
begin
   pt.x := x;
   pt.y := y;
   PtInRect(r, pt);
end;
 

Weil das Typcasting Point(x,y) nicht geht!

Wenn es bei Dir aber geht, dann ist es doch bestimmt nur eine simple Einstellung, die ich nicht habe? Aber welche?


Ich habe:

Lazarus Version #: 1.2.6
Date 2015-7-12
FPC Version 2.6.4
SVN Revision: 46529
i386-win32-win32/win64

CPU -> 32Bit

[Warf]

Wenn ich das statt pt mit den Koordinaten Point(x,y) übergebe, weist das der Compiler ab, weil TPoint erwartet wird

Code: Alles auswählen

var
  x, y: Integer;
  r: TRect;
begin
  ptInRect(r, x, y);          //geht nicht
  ptInRect(r, Point(x, y));   //das schon
end;  

Auch könnte man die Funktion ptInRect überladen, dass dies gänge.

Ich bin sehr zufrieden, wie Pascal das zur Zeit macht, es sind klare Strukturen - ein Vorteil von Pascal, den man nicht aufgeben sollte.

Ich übersetze gerade die fpGUI neu, hab da paar Änderungen vorgenommen. In keiner der Units funktionirt da die zweite Variante. Möcht gerne wissen welche Zusatzoption ich da einstellen muss damit das wirder klappt, jede Unit der fpGUI ruft ein bis mehrmals die Funktion ptInRecht auf.

Erwartet wird TPoint, das Casting aber liefert POint. Aber auf TPoint andern bringt nix.

Da muss ich doch bestimmt bloß ganz simpel einen Compierschalter setzen, nicht wahr?


Aber welchen. Was also muss ich das setzen?


Derzeit ändere ich jeden Aufruf so ab:

Code: Alles auswählen

 
procedure Irgendwas(x,y: Integer);
var
 pt: TPoint;
 r: TRect;
begin
   pt.x := x;
   pt.y := y;
   PtInRect(r, pt);
end;
 

Weil das Typcasting Point(x,y) nicht geht!

Wenn es bei Dir aber geht, dann ist es doch bestimmt nur eine simple Einstellung, die ich nicht habe? Aber welche?


Ich habe:

Lazarus Version #: 1.2.6
Date 2015-7-12
FPC Version 2.6.4
SVN Revision: 46529
i386-win32-win32/win64

CPU -> 32Bit

Die Funktion Point(X, Y: Integer) ist in der Classes unit Implementiert, hast du diese vielleicht nicht eingebunden?

Außerdem gibt es einen Unterschied zwischen dem typen TPoint aus der Classes Unit und dem typen TPOINT aus der windows Unit, daran könnte es auch liegen