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

[Codehunter]

Moin!

Wie ist eure Meinung zu der Thematik Aufzählungstypen: Könnten evtl. mehr als 256 benannte Elemente ermöglicht werden?

Delphi-Quellcode:

type
  TMyEnum = (meNull, meEins, meZwei, {...} meZweihundertfuenfundfuenfzig, meZweihundertsechsundfuenfzig);

{...}

var
  I: Integer;
begin
  I := Integer(meZweihundertfuenfundfuenfzig); // I = 255
  I := Integer(meZweihundertsechsundfuenfzig); // I = 0
  I := Integer(TMyEnum(256)); // I = 256
  I := Integer(TMyEnum(1024)); // I = 1024
  I := Integer(TMyEnum(-1)); // I = -1
end;

So isses ja derzeit. Der Typ als solches kann durchaus mehr als 256 Elemente aufnehmen, nur benannt werden können sie nicht. Das 257ste Element führt dann zum Wert "0", was ich auch nicht gerade sinnig finde.

Ich stoße immer wieder auf Fälle, wo ich durchaus mehr als 256 benannte Elemente gebrauchen könnte und dann auf Konstanten ausweichen muss. Die haben aber den Nachteil, dass sie nicht typisiert sind und mir da schon mehrmals passiert ist, dass ich versehentlich zwei gleiche Werte hatte.

Ich könnte mir z.B. eine Syntax wie diese hier gut vorstellen:

Delphi-Quellcode:

type
  TMyEnum[-1..1024] = (meMinusEins, meNull, meEins, meZwei, {...} meZweihundertfuenfundfuenfzig, meZweihundertsechsundfuenfzig, {...} meTausendvierundzwanzig);

{...}

var
  I: Integer;
begin
  I := Integer(meMinusEins); // I = -1
  I := Integer(meZweihundertfuenfundfuenfzig); // I = 255
  I := Integer(meZweihundertsechsundfuenfzig); // I = 256
  I := Integer(meTausendvierundzwanzig); // I = 1024
end;

und dann entsprechend

Delphi-Quellcode:

type
  TMyEnum[-1..1024] = (meMinusEins, meNull, meEins, meZwei, {...} meTausendvierundzwanzig, meTausendfuenfundzwanzig); // <- Compilerfehler "Außerhalb des Bereichs"

Grüße
Cody

[Frickler]

Zitat:

Zitat von Codehunter (Beitrag 1408578)

Moin!

Wie ist eure Meinung zu der Thematik Aufzählungstypen: Könnten evtl. mehr als 256 benannte Elemente ermöglicht werden?

Delphi-Quellcode:

type
  TMyEnum = (meNull, meEins, meZwei, {...} meZweihundertfuenfundfuenfzig, meZweihundertsechsundfuenfzig);

Grüße
Cody

Wofür möchtest Du das verwenden?

Ich kann ja mal kurz skizzieren, wofür ich Aufzählungen benutze: bei mir sind die allermeisten Aufzählungstypen ein "sprechender Ersatz" für Boolean. Statt

Delphi-Quellcode:

var Lampe: boolean;
Lampe := true;

schreibe ich der Lesbarkeit halber lieber

Delphi-Quellcode:

type TLampenStatus = (lsAus, lsAn);
var Lampe: TLampenStatus ;
Lampe := lsAn;

vor allem, weil ich dann den Typen noch erweitern kann

Delphi-Quellcode:

type TLampenStatus = (lsAus, lsAn, lsDefekt);

was mit Boolean dann eine zweite Variable benötigen würde.

[Jasocul]

Ich sehe es ähnlich wie Frickler.
Bisher hatte ich auch noch keine Bedarf in dem Bereich. Was natürlich nicht heißen muss, dass es den nicht gibt.
@Codehunter: Kannst du mal ein realistisches Beispiel skizzieren, wofür das benötigen könntest?

OT:
Ich fände ein case, das auch Strings verarbeiten kann, eine sinnvolle Sache :wink:

[Schokohase]

Also bei mir kommt bei

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
  TMyEnum = ( me0, me1, me2, me3, me4, me5, me6, me7, me8, me9, me10, me11, me12, me13, me14, me15, me16, me17, me18, me19, me20, me21, me22, me23, me24, me25, me26, me27, me28, me29, me30, me31, me32, me33, me34, me35, me36, me37, me38, me39, me40, me41, me42, me43, me44, me45, me46, me47, me48, me49, me50, me51, me52, me53, me54, me55, me56, me57, me58, me59, me60, me61, me62, me63, me64, me65, me66, me67, me68, me69, me70, me71, me72, me73, me74, me75, me76, me77, me78, me79, me80, me81, me82, me83, me84, me85, me86, me87, me88, me89, me90, me91, me92, me93, me94, me95, me96, me97, me98, me99, me100, me101, me102, me103, me104, me105, me106, me107, me108, me109, me110, me111, me112, me113, me114, me115, me116, me117, me118, me119, me120, me121, me122, me123, me124, me125, me126, me127, me128, me129, me130, me131, me132, me133, me134, me135, me136, me137, me138, me139, me140, me141, me142, me143, me144, me145, me146, me147, me148, me149, me150, me151, me152, me153, me154, me155, me156, me157, me158, me159, me160, me161, me162, me163, me164, me165, me166, me167, me168, me169, me170, me171, me172, me173, me174, me175, me176, me177, me178, me179, me180, me181, me182, me183, me184, me185, me186, me187, me188, me189, me190, me191, me192, me193, me194, me195, me196, me197, me198, me199, me200, me201, me202, me203, me204, me205, me206, me207, me208, me209, me210, me211, me212, me213, me214, me215, me216, me217, me218, me219, me220, me221, me222, me223, me224, me225, me226, me227, me228, me229, me230, me231, me232, me233, me234, me235, me236, me237, me238, me239, me240, me241, me242, me243, me244, me245, me246, me247, me248, me249, me250, me251, me252, me253, me254, me255, me256, me257, me258, me259, me260, me261, me262, me263, me264, me265, me266, me267, me268, me269, me270, me271, me272, me273, me274, me275, me276, me277, me278, me279, me280, me281, me282, me283, me284, me285, me286, me287, me288, me289, me290, me291, me292, me293, me294, me295, me296, me297, me298, me299 );

begin
  WriteLn(Integer(TMyEnum.me299));
  ReadLn;
end.

wie zu erwarten

Code:

299

heraus.

Kann ich also hier nicht nachvollziehen.

[Uwe Raabe]

Mir ist auch nicht bekannt, daß es eine 256-Elemente-Begrenzung bei Aufzählungstypen gibt. Dagegen spricht auch die Compiler-Option Mindestgröße für Enum, in der man Byte, Word oder Double Word auswählen kann.

Die 256-Elemente-Begrenzung gibt es allerdings bei Sets.

[sakura]

Zitat:

Zitat von Schokohase (Beitrag 1408588)

Also bei mir kommt bei ... wie zu erwarten

Code:

299

heraus.

Hier auch, in D7 und D10.2.3.

Auch in einer FOR-Schleife für alle Werte korrekt.

...:cat:...

[Codehunter]

Also jetzt bin ich endgültig verwirrt! Bei mir ist das seit 20 Jahren Usus dass ein Enum 256 benannte Elemente haben kann. Wenn ich das Codesample von Schokohase verwende, dann kommt bei mir 43 raus und nicht 299. Das deckt sich auch mit der Bechreibung hier:

https://de.wikibooks.org/wiki/Progra...z%C3%A4hlungen (insbesondere der letzte Absatz ganz unten)

Ein praktisches Beispiel zu bringen ist nicht ganz einfach, weil das sehr tief in den betreffenden Anwendungscode geht. Vorallem um Bestandscode, in dem sehr viel mit hartcodierten Array-Indizes gearbeitet wurde und dadurch Erweiterungen sehr mühsam werden weil man den ganzen Code nach dem höchsten Vorkommen eines Index durchgrasen muss. Und wenn ich mir die Arbeit schon machen muss, dann würde ich das gern auch gleich aufräumen und mit benannten Aufzählungen arbeiten. Allerdings lande ich in dem Fall schon bei 306 Elementen.

EDIT: Fast übersehen!

Zitat:

Zitat von Uwe Raabe (Beitrag 1408593)

Dagegen spricht auch die Compiler-Option Mindestgröße für Enum, in der man Byte, Word oder Double Word auswählen kann.

Das ist des Rätsels Lösung! Das steht per Default auf Byte und schon hat man den Effekt wie beschrieben. Stellt man höher, passt es. Das ist so ein Fall von Kopf knallt auf Tischplatte... Uwe du solltest Bücher schreiben! :-)

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1408601)

Wenn ich das Codesample von Schokohase verwende, dann kommt bei mir 43 raus und nicht 299.

Also, du erzeugst eine neue Konsolenanwendung, kopierst den Beispielcode da rein, startest und bekommst 43? Dann solltest du erstmal dieses Problem lösen, denn das passiert hier und offenbar bei den anderen auch nicht.

[gammatester]

Zitat:

Zitat von Codehunter (Beitrag 1408601)

Also jetzt bin ich endgültig verwirrt! Bei mir ist das seit 20 Jahren Usus dass ein Enum 256 benannte Elemente haben kann. Wenn ich das Codesample von Schokohase verwende, dann kommt bei mir 43 raus und nicht 299. Das deckt sich auch mit der Bechreibung hier:

Und wie ist Deine Enum-Size-Einstellung? Hast Du eine CFG mit Option Z1?

[Schokohase]

@Codehunter

So irgendwelche Quellen sind ja teilweise hilfreich, aber warum nicht mal einen Blick in die Doku des Herstellers werfen?

http://docwiki.embarcadero.com/RADSt...Typen_(Delphi)

Zitat:

Enthält der Aufzählungstyp mehr als 256 Werte oder wurde er im Status {$Z2} deklariert, wird er als vorzeichenloses Wort gespeichert.

Nebenbei könntest du auch noch erklären, ob es dir um Set- (wie im Titel) oder Aufzählungs-Typen (wie in deinem Beitrag) geht.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1408601)

Das deckt sich auch mit der Bechreibung hier:

https://de.wikibooks.org/wiki/Progra...z%C3%A4hlungen (insbesondere der letzte Absatz ganz unten)

Nein, das tut es nicht. Der angesprochene Absatz beschreibt nur das Verhalten der von mir bereits angesprochenen Mindestgröße für Enum, mit der festgelegt wird, welcher Speicherbereich für ein Enum verwendet wird. Bei der Standardeinstellung Byte tritt genau das in dem Absatz beschriebene Verhalten auf. Konkretes Beispiel: TMyEnum hat 300 Elemente und belegt somit mindestens 2 Byte. Daher lassen sich einer Variablen vom Typ TMyEnum auch Ordinalwerte bis 65535 zuweisen, obwohl der Typ diese eigentlich nicht mehr unterstützt.

[gammatester]

Zitat:

Zitat von Schokohase (Beitrag 1408606)

@Codehunter

So irgendwelche Quellen sind ja teilweise hilfreich, aber warum nicht mal einen Blick in die Doku des Herstellers werfen?

http://docwiki.embarcadero.com/RADSt...-Typen_(Delphi)

Zitat:

Enthält der Aufzählungstyp mehr als 256 Werte oder wurde er im Status {$Z2} deklariert, wird er als vorzeichenloses Wort gespeichert.

Also bei mit gibt's nur

Code:

Diese Seite enthält momentan noch keinen Text und du bist auch nicht dazu berechtigt, diese Seite zu erstellen. Du kannst ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.

[Neutral General]

Zitat:

Zitat von Codehunter (Beitrag 1408601)

EDIT: Fast übersehen!

Zitat:

Zitat von Uwe Raabe (Beitrag 1408593)

Dagegen spricht auch die Compiler-Option Mindestgröße für Enum, in der man Byte, Word oder Double Word auswählen kann.

Das ist des Rätsels Lösung! Das steht per Default auf Byte und schon hat man den Effekt wie beschrieben. Stellt man höher, passt es. Das ist so ein Fall von Kopf knallt auf Tischplatte... Uwe du solltest Bücher schreiben! :-)

Die Sache ist die... Es funktioniert auch mit Mindestgröße = 1 Byte (siehe Anhang)

[Uwe Raabe]

Zitat:

Zitat von gammatester (Beitrag 1408609)

Also bei mit gibt's nur

Code:

Diese Seite enthält momentan noch keinen Text und du bist auch nicht dazu berechtigt, diese Seite zu erstellen. Du kannst ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.

Links mit schließender Klammer werden in diesem System nicht korrekt wiedergegeben. Häng halt noch eine Klammer dran, dann passt es.

[Codehunter]

Zitat:

Zitat von Schokohase (Beitrag 1408606)

So irgendwelche Quellen sind ja teilweise hilfreich, aber warum nicht mal einen Blick in die Doku des Herstellers werfen?

http://docwiki.embarcadero.com/RADSt...-Typen_(Delphi)

Der war gut!

Zitat:

Zitat von Embarcadero-Website

Mindestgröße für Enum-Typen (Delphi

Diese Seite enthält momentan noch keinen Text und du bist auch nicht dazu berechtigt, diese Seite zu erstellen. Du kannst ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.

Davon ab hast du natürlich Recht, es geht mir um Enums (und davon nachrangig dann auch wieder um Sets wie TMySet = set of TMyEnum). In meinem Sprachgebrauch hat sich Set=Enum und SetOf=set of Enum eingebürgert. Daher die irreführende Überschrift.

EDIT: So richtig erklärlich ist dieses Verhalten mit dem (ich nenne es mal so) "Loop-Überlauf" oder "Ringpuffer" bei benannten Aufzählungen aber nicht. Dass es nicht nur mir allein so geht belegt ja der von mir verlinkte Beitrag. Zugegeben der Fall kommt sehr selten vor dass man so viele benannte Zähler braucht, vielleicht wurde das deshalb noch nicht thematisiert?

[Schokohase]

Ich habe den Link korrigiert

Hier aber nochmal Mindestgröße für Enum-Typen (Delphi)

[gammatester]

Zitat:

Zitat von Codehunter (Beitrag 1408614)

So richtig erklärlich ist dieses Verhalten mit dem (ich nenne es mal so) "Loop-Überlauf" oder "Ringpuffer" bei benannten Aufzählungen aber nicht. Dass es nicht nur mir allein so geht belegt ja der von mir verlinkte Beitrag.

Lies mal die letzten beiden Sätze des Beitrags:

Code:

Ist die letzte Position 256 oder höher, können Werte bis 65535 angegeben werden usw. Auch negative Werte sind möglich, wenn entsprechende benannte Positionen definiert werden.

[himitsu]

Ursprünglich bassiert der ENUM auf einem Set von Assemblerbefehlen, welche allerdings "sehr" suboptimal (lahmarschig) von praktisch allen CPU-Entwicklern umgesetzt sind.
Und diese Befehle kennen nunmal ausschließlich eine Byte-Adressierung.
https://en.wikipedia.org/wiki/Bit_Test

ABER SET ist nicht gleich SET.
Genauso, wie bei den Arrays, gibt es da Unterschiede wo etwas definiert ist.

Delphi-Quellcode:

array of xyz

als Methodenparameter sind ein Sonderfall, welcher ganz anders behandelt wird.

Delphi-Quellcode:

if x in [...] then

wird als CASE vom Compiler implementiert,
aber wenn

Delphi-Quellcode:

[...]

aus einer Variable kommt, dann mit den erwähnten Assembler-Befehlen.
Konstanten sind hierbei sehr oft typisiert, womit es eigentlich "schreibgeschützte Variablen" sind, welche dann nicht inplace als CASE behandelt werden können.



Und ja, wenn man das Ganze "manuell" als Bitmasken auf einem statischen IntegerArray mit SHL SHR AND OR XOR umsetzen würde, dann gingen auch viel mehr Bits.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1408625)

dann gingen auch viel mehr Bits.

Für mehr Bits gibt es ja die Klasse TBits.

[Redeemer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408593)

Die 256-Elemente-Begrenzung gibt es allerdings bei Sets.

Finde ich nervig und das sollte mal verbessert werden. Da zählen nämlich auch Lücken im Enum mit. Folgender Code kompiliert somit nicht:

Delphi-Quellcode:

TMeinEnum = (meHallo = 0, meWelt = 256);
TMeinSet = set of TMeinEnum;

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408628)

Zitat:

Zitat von himitsu (Beitrag 1408625)

dann gingen auch viel mehr Bits.

Für mehr Bits gibt es ja die Klasse TBits.

Der Compiler könnte es aber auch problemlos nativ bei einfachen Enum-Typen umsetzen, wenn man auf BT verzichtet.

Gut,

Delphi-Quellcode:

BT EDX, AL

(2-4 Byte) hat weniger Bytes, als irgendwas in der Richtung

Delphi-Quellcode:

TEST LONG PTR EDX + [EAX shr 5], EAX and $1F

(

Delphi-Quellcode:

if LongBool(A[i shr 5] and (i and $1F)) then

20+ Bytes), aber schneller ist es dennoch meistens nicht.

OK, ein volles 256er-ENUM ist auch nur 32 Byte groß und nur weniger wollen statische Arrays mit bis zu 0,5 GB auf dem Stack haben, welche bis 4 Milliarden Werte enthalten dürfen :angle:

[Delphi-Laie]

Hallo Delphifreunde, vor einem ähnlichen Problem (bei Delphi 7) stehe ich seit längerem auch. Zwar mag es für Aufzählungstypen keine Anzahlsbegrenzung auf 256 zu geben, der "in"-Befehl scheitert aber ab dem 257. Element. Folgender Beispielcode mit einer Aufzählungsmenge mit 257 Elementen:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);

type  TMenge = (
m0, m1, m2, m3, m4, m5, m6, m7, m8, m9, 
m10, m11, m12, m13, m14, m15, m16, m17, m18, m19,
m20, m21, m22, m23, m24, m25, m26, m27, m28, m29,
m30, m31, m32, m33, m34, m35, m36, m37, m38, m39,
m40, m41, m42, m43, m44, m45, m46, m47, m48, m49, 
m50, m51, m52, m53, m54, m55, m56, m57, m58, m59,
m60, m61, m62, m63, m64, m65, m66, m67, m68, m69, 
m70, m71, m72, m73, m74, m75, m76, m77, m78, m79, 
m80, m81, m82, m83, m84, m85, m86, m87, m88, m89,
m90, m91, m92, m93, m94, m95, m96, m97, m98, m99, 
m100, m101, m102, m103, m104, m105, m106, m107, m108, m109, 
m110, m111, m112, m113, m114, m115, m116, m117, m118, m119, 
m120, m121, m122, m123, m124, m125, m126, m127, m128, m129, 
m130, m131, m132, m133, m134, m135, m136, m137, m138, m139,
m140, m141, m142, m143, m144, m145, m146, m147, m148, m149, 
m150, m151, m152, m153, m154, m155, m156, m157, m158, m159, 
m160, m161, m162, m163, m164, m165, m166, m167, m168, m169,
m170, m171, m172, m173, m174, m175, m176, m177, m178, m179, 
m180, m181, m182, m183, m184, m185, m186, m187, m188, m189, 
m190, m191, m192, m193, m194, m195, m196, m197, m198, m199, 
m200, m201, m202, m203, m204, m205, m206, m207, m208, m209,
m210, m211, m212, m213, m214, m215, m216, m217, m218, m219, 
m220, m221, m222, m223, m224, m225, m226, m227, m228, m229, 
m230, m231, m232, m233, m234, m235, m236, m237, m238, m239,
m240, m241, m242, m243, m244, m245, m246, m247, m248, m249, 
m250, m251, m252, m253, m254, m255, m256);

var Menge: TMenge;

begin
if Menge in [m255] then beep;
if Menge in [m256] then beep;//hier Compilerfehler!
end;

end.

Bis zur viertletzten Codezeile compiliert er, bei der drittletzten Codezeile jedoch, beim Zugriff auf das 257. Element, moniert der Compiler: "Konstantenausdruck verletzt untere Grenzen" (hä, untere??).

Woran liegt das, und hat man eine Chance, das wegzubekommen? Mit {$Z2} oder {$Z4} war ich auch nicht erfolgreich.

Danke und Gruß

Delphi-Laie

[Uwe Raabe]

Mit dem Konstukt [m256] wird vom Compiler ein Set erzeugt, was wegen der bekannten Beschränkung eben nicht geht. Das kriegst du auch nicht weg - zumindest nicht mit Sets.

[Delphi-Laie]

OK, danke! Nun bin ich allerdings völlig verwirrt.

Da wurde doch eine Aufzählungsmenge und eben kein Set deklariert! Jedenfalls wurde das Schlüsselwort "set" doch gar nicht verwendet. Nicht zuletzt, Du warst es, der früher in dieser Diskussion schon schrieb:

Zitat:

Zitat von Uwe Raabe (Beitrag 1408593)

Mir ist auch nicht bekannt, daß es eine 256-Elemente-Begrenzung bei Aufzählungstypen gibt. Dagegen spricht auch die Compiler-Option Mindestgröße für Enum, in der man Byte, Word oder Double Word auswählen kann.

Die 256-Elemente-Begrenzung gibt es allerdings bei Sets.

Ich hoffe, daß es nachvollziehbar ist, wieso das alles mehr verwirrt als erhellt.

[himitsu]

Doch, denn das nach dem IN ist ein SET.


TMenge kann intern Byte, Word oder LongWord sein, also bis 4 Millarden Werte enthalten,
aber als SET ist hier maximal Byte-ENUM erlaubt. (bis 256 Werte aka Bits = 32 Byte)

Man kann über eine Funktion das Set durch ein Array ersetzen, am Besten als OpenArray, um hier auch die direkte Angabe zu unterstützen.

Delphi-Quellcode:

if ContainsMenge(Menge, [m256]) then ;

function ContainsMenge(Value: TMenge, List: array of TMenge): Boolean;

In neuren Delphis könnte man auf die Idee kommen das als ClassOperator zu bauen, aber leider verfällt Delphi immer beim [...] auf EMUM zurück und prüft erst dann ob es einen Operator gibt. :wall:

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1472211)

Da wurde doch eine Aufzählungsmenge und eben kein Set deklariert!

Ich sagte doch:

Zitat:

Zitat von Uwe Raabe (Beitrag 1472210)

Mit dem Konstukt [m256] wird vom Compiler ein Set erzeugt

Genauso wenig compiliert eben auch sowas:

Delphi-Quellcode:

var
  I: Integer;
begin
  if I in [256] then;

[himitsu]

Ach ja, {$Zx} bzw. {$MINENUMSIZE x} definiert nur die Mindestgröße (MinEnumSize) und das leider auch nur vom ENUM und nicht vom SET.

Hast du ein ENUM mit nur 3 Werten, dann ist es standardmäßig 1 Byte groß.
Aber in C++ bzw. der WinAPI sind ENUMs gern ganze ein INT, was man im Delphi z.B. mit $Z4 erreichen könnte.

[Delphi-Laie]

Danke Euch beiden mit Eurer Geduld!

Dann ist es eben auch ohne das Schlüsselwort "set" ein Set, jedenfalls bei der Verwendung mit "in", und dann ist es auch nachvollziehbar, warum der Zugriff scheitert. Der scheitert aber nur (?) mit dem Schlüsselwort "in". Hingegen wird z.B.

Delphi-Quellcode:

showmessage(inttostr(ord(m256)))

anstandslos compiliert und auch ausgeführt, zeigt dann richtigerweise "256" an.

[himitsu]

Weil das kein SET ist.
Beim [OrdinalerTyp] oder [OrdinalerTyp, ...] wird nunmal implizit ein SET aus deinem ENUM generiert.
Schön wäre es, wenn ab einer gewissen Größe hier stattdessen das als ARRAY generiert würde (aber das geht leider "noch" nicht), bzw. auch bei Weniger ARRAY unterstützt wird, bei der Suche nach kompatiblen Funktionen.

Mit ORD wird nur der Wert des ENUMs in einen anderen ordinalen Typen "Integer" konvertiert. (das ist wie beim

Delphi-Quellcode:

Integer(EinPointer)

)

Delphi-Quellcode:

ShowMessage(IntToStr(Word(m256)));  // weil der ENUM 9 bis 16 Bit groß ist ... bei $Z4 LongWord(m256) weil 32 Bit, bzw. 4 Byte

[Codehunter]

Mir ist bewusst dass der Fragende sich hier auf D7 bezog. Dennoch:

Nennt mich Ketzer aber ich löse das bei neueren Delphis inzwischen in etwa so (aus dem Gedächtnis, da kein Delphi zur Hand, deshalb als Pseudocode betrachten)

Delphi-Quellcode:

type
  PBigSetOf = ^TBigSetOf; // Ich arbeite meist mit Zeigern um Speicherkuddelmuddel zu vermeiden
  TBigSetOf = record
    FElements: TArray<word>;
    class operator implicit(A: TBigSetOf): TArray<word>;
    class operator implicit(A: TArray<word>): TBigSetOf;
    class operator in(A: Word, B: TBigSetOf): Boolean;
  end;

implementation

const
  // Für die Erzeugung der Konstanten habe ich mir ein kleines Tool geschrieben
  m0 = 0;
  {...}
  m1024 = 1024;

class operator implicit(A: TBigSetOf): TArray<word>;
begin
  Self.FElements := A.FElements:
  Result := Self.FElements;
end; 

class operator implicit(A: TArray<word>): TBigSetOf;
var
  LElement: Word;
begin
  for LElement in A do begin
    if not LElement in Self then begin
      Self.FElements := Self.FElements + [LElement];
    end else begin
      raise // Irgendwas wegen nicht eindeutig
            // deswegen auch der Umweg über einen Record
            // anstatt einfach nur ein array of Word zu benutzen
    end;
  end;
  Result := Self;
end; 

class operator in(A: Word, B: TBigSetOf): Boolean;
var
  LElement: Word;
begin
  Result := False;
  for LElement in B.FElements do begin
    if LElement = A then begin
      Result := True;
      Break;
    end;
  end;
end; 

procedure Test;
var
  LBigSetOf: TBigSetOf;
begin
  LBigSetOf := [m0, m128, m256, m512, m1024];
  if m96 in LBigSetOf then begin
    // Nein
  end else if m512 in LBigSetOf then begin
    // Ja
  end;
end;

Die Performance kommt mit Sicherheit nicht an set of heran, kommt daher auf den Einzelfall an. In meinem Fall sind die implicit-Operatoren deutlich umfangreicher, weshalb die Prüfung auf Eindeutigkeit wichtig ist.

[himitsu]

Ja, mit Variablen (festen Typen als Array) funktioniert es,
mein Problem bei dieser Variante liegt in der Nutzbarkeit.

Delphi-Quellcode:

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;

Leider wird hier ein SET generiert, es wird wegen der Grenzen gemeckert und der Operator mit dem ARRAY wird garnicht erst gesucht.

Man müsste das Array somit erstmal erzwingen.

Delphi-Quellcode:

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>;

Und das ist einfach nur umständlich.

Oder man baut eben die Contains-Funktion und verwendet kein IN, was aber auch unschön ist.

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

Delphi-Quellcode:

property Str: string read GetStr write SetStr default 'leer';

geht nicht, aber das kann man inzwischen (hässlich mehrzeilig) über ein Attribut

Delphi-Quellcode:

[Default('leer')]

erledigen.