Eure Meinung: Syntaxerweiterung Set-Typen auf mehr als 255 Elemente

[Codehunter]

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.

[freimatz]

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.

[himitsu]

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.

[freimatz]

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.)

[himitsu]

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.
property Str: string read GetStr write SetStr default 'leer'; geht nicht, aber das kann man inzwischen (hässlich mehrzeilig) über ein Attribut [Default('leer')] erledigen.