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

[Mathias]

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

Hast du die Unit Windows eingebunden ?
Vielfach macht die bei Points und Rect Probleme.

Code: Alles auswählen

implementation
 
uses Windows;
 
{$R *.lfm}
 
procedure Irgendwas(x, y: integer);
var
  pt: TPoint;
  r: TRect;
begin
  pt.x := x;
  pt.y := y;
  PtInRect(r, pt);
  PtInRect(r, Types.Point(x, y)); // unit Types erzwingen.
end;
 
end.   

[fpGUIcoder]

Eine andere Typinterprtetation.

Was meine ich damit:

Einerseits ist eine strenge Typprüfung wichtig, andererseits kann die aber auch das Leben schwer machen.

Ich habe aktuell das Problem, daß wenn ich mehrere Units eingebunden habe, in denen ein Datentyp jeweils separat definiert ist, sei es durch Neuimplementation des Typs oder auch nur durch mitgeführte Include Dateien, in denen der Typ definiert ist,

das dann der Typ nicht akzeptiert wird. Dann kommt eine Compilermeldung der Art:

Error: Incompatible types, Got unit1.Tpoint, expected unit2.Tpoint.

Wobei doch der Compiler sich die beiden Typdefinitionen anschauen kann und wenn die Datengroße stimmt, einen der beiden Typen auswählen könnte. Klar könnte ich uni1.TPoint mit:

Code: Alles auswählen

 
type
  TPoint = record
     x,y: Longint;
  end;
 

und unit2.TPoint mit:

Code: Alles auswählen

 
type
  TPoint = record
    x,y: Integer;
  end;
 

definieren, dann stimmt ja die Datengröße, ich hatte aber auch das hier definieren können:

in unit1:

Code: Alles auswählen

 
type
  TPoint = record
    x,y: Smallint;
  end;
 

in unit2:

Code: Alles auswählen

 
type 
  TPoint = record
     x,y: Longint;
  end;
 

Dann stimmen die Datengrößen natürlich nicht. Dann muss der Compiler ALarm schlagen.

Es sei in allen Fällen entweder record oder packed record in allen Units vorausgesetzt.

Im zweiten Fall ist die strenge Typprüfung gerechtfertigt, im ersten Fall nicht.


Deshalb wünsche ich mir einen Compilerschalter, mit dem ich selber Unitweise festlegen kann, ob ich strenge Typprüfung brauche oder ob die Anerkennung der korrekten Datengröße ausreicht.

Schön wäre auch bei Konstanten, wenn die Compilermeldung Doppelter Bezeichner dann entfallen würde, wenn der Konstantenwert jeweils gleich ist. Nur wenn ich zwei mal desnselben Konstantenbezeichner mit unterschiedlichem Wert belegt habe, ist die Fehlermeldung berechtigt.

Beispiel:

Code: Alles auswählen

 
unit1:
 
const
   a=1;
 

unit2:

Code: Alles auswählen

 
const
  a=1;
 

Hier hat der doppelte Konstantenbezeichner den gleichen Wert, die Compilermeldung kann entfallen und der Compiler kann eine der Kontanten einfach einkompilieren.

Zweites Beispiel:


unit1:

Code: Alles auswählen

 
const
  b=2;
 

unit2:

Code: Alles auswählen

 
const
  b=22;
 

Hier muss der Compiler den doppelten const Bezeichner anmeckern.

[m.fuchs]

Was spricht denn gegen eine eigene Unit für deine Typdefinition? Die kannst du dann von beiden Units referenzieren und alles ist gut.

Auf die strenge Typprüfung sollte man keinesfalls verzichten. Das ist ein essentieller Beitrag zur Sauberkeit von Pascal.

[fpGUIcoder]

Bei Compilerfehler Error while linking mehr detaillierte Informationen zur Ursache.

Ist das Bibliotheksformat ungültig?

Wurde die Linkdirektive falsch verwendet, ich kann ja statisch linken, eine .a Bibliothek oder auch dynamisch. Muss ich das eventuell detailliert angeben?

Habe ich den Bibliothekspfad falsch gesetzt, so daß die Bibliothek nicht gefunden wird (falscher Pfad)?


Aber nur "error while linking" ist nicht aussagekräftig bezüglich der Ursache. Da kann alles Mögliche schief gelaufen sein.

[Warf]

Eine andere Typinterprtetation.

Was meine ich damit:

Einerseits ist eine strenge Typprüfung wichtig, andererseits kann die aber auch das Leben schwer machen.

Ich habe aktuell das Problem, daß wenn ich mehrere Units eingebunden habe, in denen ein Datentyp jeweils separat definiert ist, sei es durch Neuimplementation des Typs oder auch nur durch mitgeführte Include Dateien, in denen der Typ definiert ist,

das dann der Typ nicht akzeptiert wird. Dann kommt eine Compilermeldung der Art:

Error: Incompatible types, Got unit1.Tpoint, expected unit2.Tpoint.

Wobei doch der Compiler sich die beiden Typdefinitionen anschauen kann und wenn die Datengroße stimmt, einen der beiden Typen auswählen könnte. Klar könnte ich uni1.TPoint mit

Damit würde man in Teufels Küche kommen Beispiel

Code: Alles auswählen

TType1 = record
  Num: Single;
end;
TType2 = record
  Num: Integer;
end;

Selbe Größe, aber das eine ist normale Binärdarstellung und das andere ist IEEE 754. Da muss der Compiler meckern.

Außerdem gehört so etwas zu der strikten Syntax von Pascal, weswegen ich auch damit Programmiere. Sonst könnte ich ja auch C nehmen

[Komoluna]

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;

Woher soll der Compiler denn wissen, ob die Konstante, die du festlegst ein dynamisches oder statisches Array sein soll?

MFG

Komoluna

[Mathias]

Woher soll der Compiler denn wissen, ob die Konstante, die du festlegst ein dynamisches oder statisches Array sein soll?

Code: Alles auswählen

array[0..7] of byte;

Dies macht natürlich nur Sinn bei einer statischen Array.

Hier würde das ganze Sinn machen, dann könnte man sich den Umweg über const sparen..

Code: Alles auswählen

 
....
  private
    FMatrix: Tmat4x4;
....
 
procedure TMatrix.Identity;
const
  m: Tmat4x4 = ((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, 0.0, 0.0, 1.0));
begin
  FMatrix := m;
end;

[Warf]

Eine Sache die definitiv mal eingeführt werden sollte ist, ein Methoden Modifikator der ein Event kennzeichnet, um so Hinweise wie Hint: (5024) Parameter "Sender" not used zu unterdrücken. Ich mein bei normalen Funktionen ergibt das sinn, bei Events aber nicht. Dieser Modifikator könnte dann von der IDE selbst bei der erstellung eines Event setzen

[fpGUIcoder]

Was spricht denn gegen eine eigene Unit für deine Typdefinition? Die kannst du dann von beiden Units referenzieren und alles ist gut.

Auf die strenge Typprüfung sollte man keinesfalls verzichten. Das ist ein essentieller Beitrag zur Sauberkeit von Pascal.

Widerspruch!

Nicht weil Typprüfung generell schlecht, sondern weil dieses Prinzip der Typabgrenzung zwischen PtrInt und Integer zum Beispiel verletzt wird.

In Freepascal kann ich Variablen vom Typ PtrInt zu Variablen vom Typ Integer addieren oder voneinander subtraheren. Delphi meckert hier konsequenterweise, was es aber frustrierend macht, Freepascal Quellcode nach Delphi zu portieren. Hier wird offenbar nicht sauber zwischen Pointern und Integertypen getrennt. Bin mir bei den betroffenen Kostrukten auch nicht sicher, ob das ERgebnis immer das gewünschte ist, ich denke hier an die UTF8-Stringfunktionen, von denen die fpGUI leider massiv Gebrauch macht und wo die Stringlänge dann als PtrInt zurück gegeben wird und Index und Längenangaben nicht als Interger, sondern als PtrInt zu übergeben sind. ALs Pointer, obwohl Index und Läge eines Strings eindeutig Integerwerte sind. Kann doch innerhalb der Funktion dann als passender Pointer umgewandelt werden, der auf die richtige Speicherstelle zeigt. Aber die ständige Konvertierung zwischen Integer und PtrInt, die dort auch nötig ist, macht diese Funktionen reichlich unhandlich. Ob das für Delphi portabel übersetzbar ist?

Wollte letzteres schon mal für Komponenten machen, die es für Lazarus, nicht aber für Delphi gibt. Und ich würd gerne die fpGUI auch für Delphi verfügbar machen. Ist aber wegen der PtrInt Geschichte, die leider in der fpGUI massiv in fast jeder Unit verwendet wird, unmöglich. Portierung geht wohl dann nur über Interfaces mit einer dll, die den fpgui code und alle Interfaces enthält, was aber auch ein ganzes Stück Arbeit ist.

Eine eigene Unit für eigene Typdefinitionen geht, wenn ich ein neues Projekt anfange, aber nicht bei Übersetzung eines vorhandenen, wo die Typen schon definiert sind.

[MacWomble]

Warum sollte man von FPC nach Delphi portieren?

Ich empfinde die Kompatibilität zwischen Delphi und FPC eher als vernachlässigbar und hinderlich - auch was Innovationen angeht.
"Das gibts in Delphi nicht, also brauchen wir das auch nicht!"

FPC ist doch ebenso erwachsen wie Delphi... und Plattformunabhängig

[BeniBela]

In Freepascal kann ich Variablen vom Typ PtrInt zu Variablen vom Typ Integer addieren oder voneinander subtraheren. Delphi meckert hier konsequenterweise, was es aber frustrierend macht, Freepascal Quellcode nach Delphi zu portieren. Hier wird offenbar nicht sauber zwischen Pointern und Integertypen getrennt. Bin mir bei den betroffenen Kostrukten auch nicht sicher, ob das ERgebnis immer das gewünschte ist, ich denke hier an die UTF8-Stringfunktionen, von denen die fpGUI leider massiv Gebrauch macht und wo die Stringlänge dann als PtrInt zurück gegeben wird und Index und Längenangaben nicht als Interger, sondern als PtrInt zu übergeben sind. ALs Pointer, obwohl Index und Läge eines Strings eindeutig Integerwerte sind. Kann doch innerhalb der Funktion dann als passender Pointer umgewandelt werden, der auf die richtige Speicherstelle zeigt. Aber die ständige Konvertierung zwischen Integer und PtrInt, die dort auch nötig ist, macht diese Funktionen reichlich unhandlich. Ob das für Delphi portabel übersetzbar ist?

Ich wünschte, ich könnte pointer zu ptrint casten, ohne dass es eine Warnung gibt.

Was soll der Unsinn? ptrint ist doch gerade zum portablen Casten da

Eine Sache die definitiv mal eingeführt werden sollte ist, ein Methoden Modifikator der ein Event kennzeichnet, um so Hinweise wie Hint: (5024) Parameter "Sender" not used zu unterdrücken. Ich mein bei normalen Funktionen ergibt das sinn, bei Events aber nicht. Dieser Modifikator könnte dann von der IDE selbst bei der erstellung eines Event setzen

Ich habe mir mal dafür

Code: Alles auswählen

 
procedure ignore(const intentionallyUnusedParameter: TObject); inline; begin end;
 

definiert

Und dann ignore(sender); überall

[Warf]

Was spricht denn gegen eine eigene Unit für deine Typdefinition? Die kannst du dann von beiden Units referenzieren und alles ist gut.

Auf die strenge Typprüfung sollte man keinesfalls verzichten. Das ist ein essentieller Beitrag zur Sauberkeit von Pascal.

Widerspruch!

Nicht weil Typprüfung generell schlecht, sondern weil dieses Prinzip der Typabgrenzung zwischen PtrInt und Integer zum Beispiel verletzt wird.

In Freepascal kann ich Variablen vom Typ PtrInt zu Variablen vom Typ Integer addieren oder voneinander subtraheren. Delphi meckert hier konsequenterweise, was es aber frustrierend macht, Freepascal Quellcode nach Delphi zu portieren. Hier wird offenbar nicht sauber zwischen Pointern und Integertypen getrennt. Bin mir bei den betroffenen Kostrukten auch nicht sicher, ob das ERgebnis immer das gewünschte ist, ich denke hier an die UTF8-Stringfunktionen, von denen die fpGUI leider massiv Gebrauch macht und wo die Stringlänge dann als PtrInt zurück gegeben wird und Index und Längenangaben nicht als Interger, sondern als PtrInt zu übergeben sind. ALs Pointer, obwohl Index und Läge eines Strings eindeutig Integerwerte sind. Kann doch innerhalb der Funktion dann als passender Pointer umgewandelt werden, der auf die richtige Speicherstelle zeigt. Aber die ständige Konvertierung zwischen Integer und PtrInt, die dort auch nötig ist, macht diese Funktionen reichlich unhandlich. Ob das für Delphi portabel übersetzbar ist?

Wollte letzteres schon mal für Komponenten machen, die es für Lazarus, nicht aber für Delphi gibt. Und ich würd gerne die fpGUI auch für Delphi verfügbar machen. Ist aber wegen der PtrInt Geschichte, die leider in der fpGUI massiv in fast jeder Unit verwendet wird, unmöglich. Portierung geht wohl dann nur über Interfaces mit einer dll, die den fpgui code und alle Interfaces enthält, was aber auch ein ganzes Stück Arbeit ist.

Eine eigene Unit für eigene Typdefinitionen geht, wenn ich ein neues Projekt anfange, aber nicht bei Übersetzung eines vorhandenen, wo die Typen schon definiert sind.

Pointer und Integer lassen sich addieren weil der Operator dafür überladen wurde. Die Typtrennung ist immer noch strikt, und das ist auch genau einzusehen was passiert.

Und der Typ IntPtr wird für die Länge genommen, da Strings auf einem 32 Bit system maximal High(LongWord) werden können, auf einem 64 Bit System High(QWord). Das hat alles seinen Sinn. IntPtr oder PtrInt ist übrigens kein Pointer sonder ein NativeInt weshalb die Zuweisung von Int zu PtrInt impliziet abläuft aber die zuweisung von Pointer expliziet gecastet werden muss.

Daher macht es auch keinen sinn IntPtr und Integer zu trennen, aber Pointer unt Integer/IntPtr schon

Beispiel:

Code: Alles auswählen

procedure Foo;
var i:Integer;
  p: Pointer;
  ip: IntPtr; //PtrInt
begin
  i:=ip; //Funktioniert da Impliziet gecastet wird
  p:=ip; //Compiler error
  p:=Pointer(ip); //Funktioniet
end;

[Socke]

Eine Sache die definitiv mal eingeführt werden sollte ist, ein Methoden Modifikator der ein Event kennzeichnet, um so Hinweise wie Hint: (5024) Parameter "Sender" not used zu unterdrücken. Ich mein bei normalen Funktionen ergibt das sinn, bei Events aber nicht. Dieser Modifikator könnte dann von der IDE selbst bei der erstellung eines Event setzen

Ich habe mir mal dafür

Code: Alles auswählen

 
procedure ignore(const intentionallyUnusedParameter: TObject); inline; begin end;
 

definiert

Und dann ignore(sender); überall

Die Meldung "Parameter "Sender" not used" filtert die IDE in den Standardeinstellungen seit einiger Zeit heraus. Bei anderen Parametern kann man die IDE auch extra anweisen, den Hinweis zu ignorieren:

Code: Alles auswählen

procedure myproc({%H-}a: TObject);

Meiner Meinung nach also kein Problem am Compiler sondern in der IDE oder am Benutzer.

[Martin V]

- wirklich stabile Hauptersionsnummern, die auch auf anderen Plattformen als Windows ohne Gepfriemel sofort laufen, und bei denen die Basisfunktionalität getestet ist (z. B. build Lazaurs).

- eine bessere Verwaltung der Verzeichnisse. Oft hängt der Compiler, findet Quelltexte nicht, die der Editor mit Ctrl-Return auf den Dateinamen bei uses sofort findet. Konkret etwa Suchpfade, wo man ein /* am Ende angeben kann und dann alle Unterverzeichnisse nach fehlenden Quelltexten abgesucht wird; man müßte das ganze Konzept der Suche in Verzeichnissen überarbeiten und der fpc sollte auf dieselben Infos zugreifen wie der Lazarus Editor.

- als Funktionserweiterung eine Kleinigkeit, und zwar /* */ als Kommentar-Klammern wie bei C. Ein anderer Delphi-ähnlicher Compiler unterstützt das, und das ist ganz praktisch, wenn man etwas temporär auskommentieren will, und schon (* *) enthalten ist. { } benutze ich dagegen für dauerhafte Kommentare.

[m.fuchs]

- wirklich stabile Hauptersionsnummern, die auch auf anderen Plattformen als Windows ohne Gepfriemel sofort laufen, und bei denen die Basisfunktionalität getestet ist (z. B. build Lazaurs).

Also abgesehen von MacOSX hatte ich bisher noch keine Probleme bei der Installation. Und da könnte es an meinen begrenzten Kenntnissen des Systems und der sowieso schon instabilen Umgebung durch Virtualisierung liegen.
Oder meinst du mit "Gepfriemel" den Aufruf von make im Lazaurs-Verzeichnis?
Stabil läuft eigentlich alles seit geraumer Zeit, was für konkrete Probleme sollen das denn sein?

[...]man müßte das ganze Konzept der Suche in Verzeichnissen überarbeiten und der fpc sollte auf dieselben Infos zugreifen wie der Lazarus Editor.

Klingt als ob du fpc von der Kommandozeile aufrufst um ein Lazarus-Projekt zu bauen. Dann gibt es natürlich Probleme mit den Verzeichniseinstellungen. Falls dass dein Problem ist, schau dir mal lazbuild (http://wiki.freepascal.org/lazbuild) an.