![]() |
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Ja, mit Variablen (festen Typen als Array) funktioniert es,
mein Problem bei dieser Variante liegt in der Nutzbarkeit.
Delphi-Quellcode:
Leider wird hier ein SET generiert, es wird wegen der Grenzen gemeckert und der Operator mit dem ARRAY wird garnicht erst gesucht.
if m96 in [m0, m128, m256, m512, m1024] then begin
// Nein end else if m512 in [m0, m128, m256, m512, m1024] then begin // Ja end; Man müsste das Array somit erstmal erzwingen.
Delphi-Quellcode:
Und das ist einfach nur umständlich.
if m96 in CreateArray([m0, m128, m256, m512, m1024]) then begin
// Nein end else if m512 in CreateArray([m0, m128, m256, m512, m1024]) then begin // Ja end; function CreateArray(const Values: array of Word): TArray<Word>; Oder man baut eben die Contains-Funktion und verwendet kein IN, was aber auch unschön ist. |
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Wie gesagt, aus dem Gedächtnis. Ich könnte auch erst in drei Wochen nachschauen. Klar ist das umständlich. Mir wäre es auch lieber es gäbe größere set of. Oder man könnte class operatoren per Helper an einfache Arrays dranflanschen. Irgendwie mogelt man sich nur um das Problem herum und dieses Problem besteht einfach darin, ohne in-Operator sehr unschöne if-and-Blasen bauen zu müssen.
|
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Wir haben auch meisten kleinere Mengen. Grosse kommen auch mal vor und ich würde es begrüssen wenn auch die Sets mit den grösseren funktionieren würden. Auch das CharInSet nehmen zu müssen finde ich bescheuert. Und auch dass man bei case keine sets verwenden kann, selbst wenn Sie Konstanten sind.
Generell würde ich mir wünschen dass EMB Dinge einfach mal zu 100% implementiert und nicht meist irgendwelche Ausnahmen macht. Das hier und z.B. bei class helper constraints auf enums und sets, RTTI bei unechten enums, etc. |
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Große Mengen sind auch relativ. (Ein Stein sagte mal sowas)
z.B. als Published-Property einer Komponente sind nur Integer (4 Byte) erlaubt behandelbar, womit dort ein SET schon ab nur 33 Werten zu groß wird, denn der Default-Wert, der gespeicherte Wert in der DFM und die Propery-Editoren können nur die ersten 32 Bit aufnehmen/verarbeiten. |
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Klar sind grosse Mengen relativ. Aber 32 oder 255 sind eindeutig heutzutage klein.
Und wenn jemand ein enum mit 2000 Elementen möchte ist klar, dass man dann 2000 Bits dazu benötigt. Ja und? Warum man bei dfm nur 32-Bit nehmen kann verstehe ich nicht so ganz. String oder Images sind doch auch grösser. Wie dem auch sei - dann ist auch das nicht 100% umgesetzt. (Dass es historische Gründe gibt verstehe ich ja.) |
AW: Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente
Das liegt in der RTTI.
Es wird nur ein Integer (NativeInt) zur Speicherung verwendet. Dort drin ist dann entweder der Wert codiert (32 Bit) oder ein Funktionszeiger, falls man eine Stored-Funktion angibt. Auch die Funktionen für den Property-Editpor haben nur 32 Bit für die SET-Funktionalitäten. Theoretisch würde ja ein String auch dort rein passen, aber den kann man unterklärlicher Weise nicht "direkt" als DEFAULT angeben.
Delphi-Quellcode:
geht nicht, aber das kann man inzwischen (hässlich mehrzeilig) über ein Attribut
property Str: string read GetStr write SetStr default 'leer';
Delphi-Quellcode:
erledigen.
[Default('leer')]
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz