Code: Alles auswählen
s := s + 'abc';
s += 'abc'
Code: Alles auswählen
s := s + 'abc';
s += 'abc'
Operatoren überladen ist doch genial, und vor allem wenn man mal mit vektoren und matrizen rechnen muss ist das viel angenehmer:
Code: Alles auswählen
res := v1 * m1 + v2;
// vs
res := AddVector(MultiplyMatrix(v1, m1), v2);
Code: Alles auswählen
procedure CopyJpegs(source: TDirectory; Target: TPath);
var
jpg: TFileInfo;
begin
for jpg in source/'**/*.jpg' do
jpg.Copy(Target/jpg.Path.RelativeTo(source));
end;
In deinem Code unter deinem Zugriff kein Problem.PS: man sieht es hier vielleicht nicht direkt, aber hier sind nicht nur der / operator am werk, sondern auch 2 Impliziete casts. Ohne operator überladen wäre das nicht möglich.
Ist doch eigentlich ziemlich offensichtlich, **/pattern ist ein ziemlich allgemeingültiger ausdruck um eine rekursive suche zu machen (wird so von java oder python und sogar verschiedenen shells wie zsh unterstützt), und pfade mit / zu conkatinieren finde ich deutlich intuitiver als:In deinem Code unter deinem Zugriff kein Problem.
Wenn ich als Außenstehender den Code sehe, würde ich denken: Sieht irgendwie nach Pascal aus, aber ich verstehe es nicht.
Code: Alles auswählen
IncludeTrailingPathDelimiter(source) + ExcludeLeadingPathDelimiter(Target)
Naja, wenn man eine alternative zum rad findet die stabiler, komfortabler und einfacher ist, würde ich sagen wir sollten das rad damit ersetzen.
Dann bist Du wohl kein "echter Progrmmier":Warf hat geschrieben: ↑Do 30. Jul 2020, 15:37[
Ich mein mit anderen Sprachen kann man sehr of viele Dinge viel einfacher und schneller machen und ist noch dazu weniger Fehleranfällig, bzw. in sprachen wie C# oder Java, wenn du da nen fehler hast ist das nicht einfach "SIGSGV XXXXX' sondern du bekommst eine detailierte beschreibung mit einer vorschlagsliste an fixes.
Ein bisschen Wahrheit steckt da schon dahinter.Winni hat geschrieben: ↑Do 30. Jul 2020, 21:08Dann bist Du wohl kein "echter Progrmmier":Warf hat geschrieben: ↑Do 30. Jul 2020, 15:37[
Ich mein mit anderen Sprachen kann man sehr of viele Dinge viel einfacher und schneller machen und ist noch dazu weniger Fehleranfällig, bzw. in sprachen wie C# oder Java, wenn du da nen fehler hast ist das nicht einfach "SIGSGV XXXXX' sondern du bekommst eine detailierte beschreibung mit einer vorschlagsliste an fixes.
http://www.bruder-franziskus.de/satire/it0.htm
Winni
Ich glaube du verwechselst hier das, was die IDE dir bei Compilefehlern vorschlägt mit dem was dir zur Laufzeit um die Ohren fliegt. Also zumindest ich bekomme zur Laufzeit auch nur schnöde Exceptions mit Stacktrace, sei es jetzt C#, Java oder Object Pascal. Zur Kompilierzeit kriegst du in Lazarus nur eine Zugriffsverletzung, wenn entweder in Lazarus oder im Compiler ein Bug ist. Und Lazarus bietet dir per Rechtsklick auf Fehler auch teilweise Abhilfen an, zumindest wenn diese implementiert und umsetzbar sind.Warf hat geschrieben: ↑Do 30. Jul 2020, 15:37Ich mein mit anderen Sprachen kann man sehr of viele Dinge viel einfacher und schneller machen und ist noch dazu weniger Fehleranfällig, bzw. in sprachen wie C# oder Java, wenn du da nen fehler hast ist das nicht einfach "SIGSGV XXXXX' sondern du bekommst eine detailierte beschreibung mit einer vorschlagsliste an fixes.
Cool kannte ich noch gar nichtPascalDragon hat geschrieben: ↑Fr 31. Jul 2020, 09:30Gerade in 2.0.10 getestet: ich hatte einen nicht gefundenen Bezeichner (in meinem Beispiel TRegistry). Lazarus bietet bei Rechtsklick auf den Fehler im Nachrichtenfenster oder auf das "!" im Gutter links bei der Fehlerstelle an danach zu suchen (sowohl mit Code-Browser als auch - falls installiert - mit Cody), ist der Bezeichner gefunden, dann kannst du dessen Unit recht einfach hinzufügen.
Hi!Warf hat geschrieben: ↑Fr 31. Jul 2020, 14:13Stimmt die vorschläge sind von der IDE, dennoch sind die Fehler die man bei Pascal produziert recht eklig, in C# oder Java hat man einfach keine Segfaults und wenn man fehler hat (wie nullpointer dereference) bekommt man eine sehr detailierte exception weil die IR deutlich mehr infos hat als das assembly was durch den fpc generiert wird
Ja, man glaubts kaum moderne sprachen werden so designed das sie Fehler minimieren. Ich bin auch immernoch ein riesen fan von Optionalen typen die Null Pointer ersetzen. In Swift oder Kotlin hat man einfach damit Nullpointer Fehler komlett losgeworden. Dazu noch referenzzählung (Swift) oder Garbage collection (Kotlin) und Memory fehler sind praktisch unmöglich zu machen.