Größe von SETs festlegen

[himitsu]

Mit {$MINENUMSIZE x} / {$Zx} kann man ja dir Größe von "enumerated types" festlegen,

Gibt es da auch eine Möglichkeit dieses für SETs zu machen?


in C sind diese ja Integer-groß, aber in Delphi standardmäßig so klein wie möglich :wall:

Code:

enum tagLOCKTYPE
  {  LOCK_WRITE     = 1,
     LOCK_EXCLUSIVE = 2,
     LOCK_ONLYONCE  = 4
  }  LOCKTYPE;

so geht es zwar, aber dann sind ide Konstanten vom Typ getrennt

Delphi-Quellcode:

const
  LOCK_WRITE     = 1;
  LOCK_EXCLUSIVE = 2;
  LOCK_ONLYONCE  = 4;

type
  LOCKTYPE = Type Integer;

und dises geht auch, aber es sieht irgendwie blöd aus :?

Delphi-Quellcode:

type
  LOCKTYPE = Set (
    LOCK_WRITE      = 1;
    LOCK_EXCLUSIVE  = 2;
    LOCK_ONLYONCE   = 4;
    _locktype_align = 31);

[alzaimar]

Wieso sollte ein Kompiler die Größe einer Menge *nicht* so klein wie möglich machen? Gerade eine typenstrenge Sprache wie Pascal ist da sehr genau.

Gottseidank gibt es aber sowas wie variant records, wenn Du also partout möchtest, das deine Menge z.B. 8 bytes hat, dann deklariere einen variant record datentyp:

Delphi-Quellcode:

TMySet = Record
  Case Boolean Of
    False : (M : TMySet);
    True  : (Dummy : Array [0..7] Of Byte);
  End;

P.S.: Die Mehrzahl von SET ist SETS und *nicht* SET's. Das Apostroph ist ein Auslassungszeichen, und hier wird nichts ausgelassen.

[himitsu]

Zitat:

Zitat von alzaimar

Wieso sollte ein Kompiler die Größe einer Menge *nicht* so klein wie möglich machen? Gerade eine typenstrenge Sprache wie Pascal ist da sehr genau.

Weil ich kompatibel zur WinAPI sein muß, in welcher die SETS 4 Byte klein sind?

Und das mit dem record geht nicht, da dann die Variable ein Record ist und kein SET.
Als Parameter in einer Funktion kann man dann kein SET mehr verwenden/setzen
> [a, b, c]

Zitat:

Zitat von alzaimar

P.S.: Die Mehrzahl von SET ist SETS und *nicht* SET's. Das Apostroph ist ein Auslassungszeichen, und hier wird nichts ausgelassen.

da hab ich mich wohl von wem falsch verleiten lassen :oops:

Zitat:

Zitat von Delphi-OH

provided the upper and lower bounds of the set's base type have ordinal values

[nicodex]

Dein gewünschtes Feature gibt es in Delphi nicht (in FPC {$PACKSET x}).
Du kannst die entsprechende Aufzählung um Dummies erweitern, oder das größtmögliche Aufzählungsmitglied (31) als einzigen Dummy definieren (für nicht fortlaufende oder nicht mit 0 beginnende Aufzählungen wird allerdings keine RTTI-Information erzeugt!).

ps: siehe http://www.delphipraxis.net/internal...=882557#882557

pps:

Zitat:

Zitat von himitsu

und dises geht auch, aber es sieht irgendwie blöd aus :?

Delphi-Quellcode:

type
  LOCKTYPE = Set (
    LOCK_WRITE      = 1;
    LOCK_EXCLUSIVE  = 2;
    LOCK_ONLYONCE   = 4;
    _locktype_align = 31);

Das ist nicht korrekt, es müsste so aussehen:

Delphi-Quellcode:

type
  PLockType = ^TLockType;
  TLockType = set of (
    LockTypeWrite,      // (Bit) 0
    LockTypeExclusive,  // (Bit) 1
    LockTypeOnlyOnce,   // (Bit) 2
    LockTypeForceDWORD = 31
  );
const
  LOCK_WRITE     = DWORD(1 shl DWORD(LockTypeWrite));
  LOCK_EXCLUSIVE = DWORD(1 shl DWORD(LockTypeExclusive));
  LOCK_ONLYONCE  = DWORD(1 shl DWORD(LockTypeOnlyOnce));

Die Ordinalwerte von LockTypeXxx und LOCK_Xxx sind unterschiedlich! (bis aufs erste ;)

[alzaimar]

[quote="himitsu"]

Zitat:

Zitat von alzaimar

Und das mit dem record geht nicht, da dann die Variable ein Record ist und kein SET.Als Parameter in einer Funktion kann man dann kein SET mehr verwenden/setzen ...> [a, b, c]

Äh...

Delphi-Quellcode:

MyRecord.MySet := [1,2,3]

Oder meinst du als Parameter? Ja, das wäre blöd, aber Du kannst Dir ja mit einer dreckigen 'absolute' direktive helfen, aber dafür werden wir hier bestimmt gesteinigt.

Delphi-Quellcode:

Function Foobar (MySetParam : TMySet) : TBarFoo;:
Var
  MySetParamEx : TMyRecord Absolute MySetParam;

Begin 
  ....
End;

Oder eben nicht mit Sets sondern mit Bitoperationen. Sets sind sowieso leider bedauerlicherweise fast nie nicht zu gebrauchen. Wir hatten mit -hoika glaube ich- eine sehr interessante und hitzige Diskussion über Sets im allgemeinen.

Wenn Du bitkompatibel mit einer API-Vorgabe sein willst, würde eh auf die Sets verzichten, da die Implementierung ja maschinenabhängig sein könnte bzw. Dir keiner garantiert, das CodeGear dafür in Zukunft auch Bits genauso verwendet.

[himitsu]

jupp, auch als Parameter

und Absolute geht nur bei gleichgroßen Typen ... bringt also nichts :wink:


Und ja, sie ist Maschienen- nja, eher Windows-API-abhängig

Delphi-Quellcode:

SizeOf(Set) = SizeOf(Integer)

hab es jetzt doch anders gelöst :angel2:

in den WindowsHeaderFiles ist es als Record definiert, daher wollte ich es möglichst auch so definieren :stupid:

in Delphi hat man die erste Variante mit Typ+Konstanten verbaut

und ich mach jetzt erstmal

Delphi-Quellcode:

type LOCKTYPE = Set (LOCK_WRITE=1;   ...;   _locktype_align=SET_HIGH_BIT);

// und (INT_2..INT_8 sind private Definitionen aus FInclude.inc)
type SET_HIGH_BIT = {$IFDEF INT_2}15{$ENDIF} {$IFDEF INT_4}31{$ENDIF} {$IFDEF INT_8}63{$ENDIF};

nja, Bit-Klassen/Records hab ich schon genug :mrgreen:
> http://www.delphipraxis.net/internal...=879295#879295 > FType.pas

Zitat:

Das ist nicht korrekt, es müsste so aussehen:

:freak: schau ich mir nochma an ... schon nett, diese Unterschiede in den Sprachen

aber dann ließe sich ja etwas wie STGTY nicht als SET übersetzen :wall:

Code:

typedef 
enum tagSTGTY
    {   STGTY_STORAGE   = 1,
   STGTY_STREAM   = 2,
   STGTY_LOCKBYTES   = 3,
   STGTY_PROPERTY   = 4
    }    STGTY;

typedef 
enum tagSTREAM_SEEK
    {   STREAM_SEEK_SET   = 0,
   STREAM_SEEK_CUR   = 1,
   STREAM_SEEK_END   = 2
    }    STREAM_SEEK;

typedef 
enum tagLOCKTYPE
   {   LOCK_WRITE   = 1,
   LOCK_EXCLUSIVE   = 2,
   LOCK_ONLYONCE   = 4
    }    LOCKTYPE;

[nicodex]

Zitat:

Zitat von himitsu

aber dann ließe sich ja etwas wie STGTY nicht als SET übersetzen :wall:

Jupp, genau das ist die Stelle an der Sets keine Vorteile mehr bringen und eher für mehr Arbeit beim Entwickler sorgen.
Aber STGTY ist auch kein "Set", sondern eine Aufzählung :)

[himitsu]

irgendwie raucht grad mein Köpfchen ... nach meheren Wochen fast nur noch im PSDK, den Headerfiles und meiner Übersetzung unterwegs ... vorallem wenn MSDN, PSDK und die HeaderFiles was Unterschiedliches sagen
http://fnse.de/S01/0AT.gif

also geht ich wohl doch erstmal wieder zu der "guten" alten Typ-Konstante-Variante über

Delphi-Quellcode:

Const
  // LOCKTYPE values
  LOCK_WRITE       = 1;
  LOCK_EXCLUSIVE   = 2;
  LOCK_ONLYONCE    = 4;

Type 
  LOCKTYPE = Type _INT;

@Daniel: wir brauchen noch ein KopfRauchSmilie, weil besoffen bin ich noch nicht :drunken:

[grenzgaenger]

aber sag mal, weshalb willste unbedingt den typ vergrössern? das sollte doch der compiler bei der übergabe selbst anpassen :-) und für den prozessor, ist es immer 'n INT breit :-) . also bei 'ner 8 BIT CPU 8 bit, bei 'ner 16'er 16 BIT, 32'er 32 Bit und bei 'ner 64'er eben 64 Bit. Die aufrufkonventionen sorgen dann schon dafür, dass du bei 'ner 64 CPU dann auch die richtigen 32 Bit wieder zurückbekommst ... :-)

<HTH> GG

[nicodex]

Zitat:

Zitat von himitsu

also geht ich wohl doch erstmal wieder zu der "guten" alten Typ-Konstante-Variante über

Das dürfte wohl am einfachsten und flexibelsten sein :)

Ich würde es persönlich anders schreiben, um die Konstanten im Quelltext zu "dokumentieren":

Delphi-Quellcode:

type
  PLockType = ^TLockType;
  TLockType = type LongInt;  // TEnumInt
const
  LOCK_WRITE     = TLockType(1);
  LOCK_EXCLUSIVE = TLockType(2);
  LOCK_ONLYONCE  = TLockType(4);

Man _könnte_ ein Set TLockTypes deklarieren (für TStatStg.grfLocksSupported)... doch
1) würde man dann LOCK_Xxx nicht mehr definieren, damit der nutzende Entwickler nicht verwirrt wird (durch andere Ordinalwerte) und gar nicht erst auf die Idee kommt LOCK_Xxx im Sinne von Bitmasken zu verwenden,
2) müsste man alle Funktionen die _einen_ Locktyp erwarten dennoch mit einem Set-Parameter definieren (da es LOCK_Xxx nicht mehr gibt) - was den nutzenden Entwickler noch mehr verwirrt, weil er laut Deklaration davon ausgehen muss, dass man 'mehrere' Locktypen übergeben kann (was nicht der Fall ist).

Kurz, lass es bei den Konstanten :)

[himitsu]

Wenn z.B. das SET nur 1 Byte groß ist, aber die WinAPI-Funktion ein SET in Integergröße erwartet, dann sind die höheren 3 Byte unbestimmt
und da Delphi diese 3 Byte nicht setzt, erhält am Ende der Parameter, welcher an die WinAPI übergeben wurde 24 Bits mit unvorhersagbaren Werten :?


hmmm, sowas hatte ich doch früher schonmal gamacht ... :shock:

Delphi-Quellcode:

Type
  LOCKTYPE = Type _INT;  // nicht wundern ... _INT entspricht [msdn:8a2af38416]INT[/msdn:8a2af38416] 
                         // es gab aber Probleme mit der Delphi-Funktion Int
Const
  // LOCKTYPE values
  LOCK_WRITE       = LOCKTYPE(1);
  LOCK_EXCLUSIVE   = LOCKTYPE(2);
  LOCK_ONLYONCE    = LOCKTYPE(4);

nur gab es da ein paar kleine Probleme ... vorallem da wo in einem Parameter verschiedene Typen gemischt werden können.
z.B. FILE_ATTRIBUTE_* und FILE_FLAG_*



nja, was mir grad noch aufgefallen ist, als SET würde man die Konstanten ja auch nichtmehr MSDN/C-typisch per "or" ( "|" ) verknüpfen können

[nicodex]

Zitat:

Zitat von himitsu

nur gab es da ein paar kleine Probleme ... vorallem da wo in einem Parameter verschiedene Typen gemischt werden können.
z.B. FILE_ATTRIBUTE_* und FILE_FLAG_*

Das liegt an der Definition eines neuen, "nicht kompatiblen" Typs (= type Basistyp).

Zitat:

Zitat von himitsu

als SET würde man die Konstanten ja auch nichtmehr MSDN/C-typisch per "and" ( "|" ) verknüpfen können

Du meinst "or" :)
Jupp, dann könnte/müsste man nur noch die Sets verwenden (was man in diversen Fällen nicht möchte, da diese in Delphi streng typisiert sind - oder weil es sich gar nicht über ein Set abbilden lässt).

[himitsu]

Ups "or" :wall:

dann geht's halt nicht anders,
aber was solls :? ... nja, manchmal ist die strenge Typisierung auch garnicht sooo schlecht :stupid:

[himitsu]

Bloß mal zur Rücksicherung.

Es gibt hierfür immernoch keine wirkliche Lösung, für ein {$MINSETSIZE}, oder hab ich's nur übersehn?


Ich Schreib grade mal ein paar Sachen mir zusammen, um bald das neue Quality-Portal mit Millionen Bugreports in die Knie zu zwingen ... je länger sie brauchen, um so schlimmer wird es.
Und auf der Suche über meinen eigenen uralten Thread gestolpert ... echt mal, bald 20 Jahre, aber immernoch nichts.

Ich würde ja auch nochmal im Quality suchen (bin der Meinung dort gab es schon was), aber QC ist tot/gelöscht und das Quality ist seit Gestern auch mal wieder garnicht erreichbar/einloggbar.


Benötige mal wieder ein SET mit zwei Werten, welches aber dennoch Integer groß ist.
Das geht sehr einfach, mit dummy=31 am Ende, aber dann ist ja sowas wie SetToString im Arsch.

[Uwe Raabe]

Delphi-Quellcode:

type
  TEnum = (one, two);
  TEnums = set of TEnum;

type
  TWindowsEnums = record
    class operator Implicit(A: TEnums): TWindowsEnums; overload;
  case Integer of
    0: (Enums: TEnums);
    1: (Fake: set of 0..31);
  end;

class operator TWindowsEnums.Implicit(A: TEnums): TWindowsEnums;
begin
  Result.Fake := [];
  Result.Enums := A;
end;

procedure MyWindowsProc(Par: TWindowsEnums);
begin
  Write('TWindowsEnums: ');
  var sep := '(';
  for var enum in Par.Fake do begin
    Write(sep, enum);
    sep := ',';
  end;
  Writeln(')');
end;

procedure Test;
var
  Enums: TEnums;
begin
  Writeln('Sizeof(TEnum)=', Sizeof(TEnum));
  Writeln('Sizeof(TWindowsEnums)=', Sizeof(TWindowsEnums));
  Enums := [one, two];
  MyWindowsProc(Enums);
end;

[himitsu]

Maaa, es wäre jetzt zu einfach gewesen. :roll:

Delphi-Quellcode:

type
  TWindowsSet<T> = record
    class operator Implicit(A: T): TWindowsSet<T>;
  case Integer of
    0: (TheSet:  T);
    1: (Aligned: Integer);
  end;

Aber neeeeeeeeee. :cry:

Code:

type
  TMyEnum = (one, two);
  TMySet  = set of TMyEnum;

  TMyRecord = record
    Field: Integer;
  end;

  TMyManagedRec = record
    Field: string;
  end;

  TMyRecordCon = record
    //constructor Create;  // [dcc32 Fehler] E2394 Parameterlose Konstruktoren sind für Record-Typen nicht zulässig
    constructor Create(i: Integer);
  end;

  TMyClass = class
    constructor Create;
  end;

  TMyProcedure = procedure;
  TMyMethod    = procedure of object;
  TMyReference = reference to procedure;

  TWithConstructor<T: constructor> = record
  end;

  TWithClass<T: class> = record
  end;

  TWithRecord<T: record> = record
  end;

  //TTheRecord  = TWithConstructor<TMyRecord>;      // [dcc32 Fehler] E2513 Typparameter 'T' muss parameterlosen Konstruktor haben
  //TTheRecord2 = TWithConstructor<TMyRecordCon>;   // [dcc32 Fehler] E2513 Typparameter 'T' muss parameterlosen Konstruktor haben
  TTheConClass  = TWithConstructor<TObject>;        // äähhhhhm, eigentlich hat TMyRecordC Einen, sber mit Klassen geht es
  TTheClass     = TWithClass<TObject>;              // class = constructor, aber hier wenigstens eindeutg
  TTheRecord    = TWithRecord<TMyRecord>;           // jupp
  TTheManaged   = TWithRecord<TMyManagedRec>;       // jupp
  //TTheSet     = TWithRecord<TMySet>;              // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein
  TTheEnum      = TWithRecord<TMyEnum>;             //
  TTheBoolean   = TWithRecord<Boolean>;             //
  TTheInteger   = TWithRecord<Integer>;             //
  //TTheStatic  = TWithRecord<IntegerArray>;        // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : ein Integer geht, aber Viele nicht?
  //TThePointer = TWithRecord<Pointer>;             // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : Pointer und Integer sind doch das "Gleiche" ?
  //TTheShort   = TWithRecord<ShortString>;         // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : ein Record, bzw. statisches Array und ist doch das Gleiche, wie ein ShortString
  //TTheString  = TWithRecord<String>;              // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : OK, das ist ein Managed-Type
  //TTheArray   = TWithRecord<TBytes>;              // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : OK, Managed wie beim String

  //TTheProc    = TWithRecord<TMyProcedure>;        // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : eigentlich wie ein Pointer/Integer
  //TTheMethod  = TWithRecord<TMyMethod>;           // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : wie ein Pointer, außer wenn ARC aktiv (eventuell managed)
  //TTheRef     = TWithRecord<TMyReference>;        // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein : das ist ein Interface (immer managed)

  {
  TWindowsSet<T> = record
    class operator Implicit(A: T): TWindowsSet<T>;
  case Integer of
    0: (TheSet:  T);  // [dcc32 Fehler] E2569 Typparameter 'T' benötigt evtl. Finalisierung - im varianten Record nicht zulässig.  Verwenden Sie die RECORD-Einschränkung
    1: (Aligned: Integer);
  end;
  }

  TWindowsSet<T: record> = record
    class operator Implicit(A: T): TWindowsSet<T>;
  case Integer of
    0: (TheSet:  T);
    1: (Aligned: Integer);
  end;

  TEnum4  = TWindowsSet<TEnum>;   // kompiliert, aber ist eigentlich falsch
  //TSet4 = TWindowsSet<TSet>;    // [dcc32 Fehler] E2512 Typparameter 'T' muss ein nicht-nullable Wertetyp sein

  //TWindowsEnumSet<T:ordinal> = record                        // [dcc32 Fehler] Unit2.pas(47): E2003 Undeklarierter Bezeichner: 'ordinal'
  TWindowsEnumSet<T: record> = record
    type TSet = set of T;                                      // [dcc32 Fehler] E2001 Ordinaltyp erforderlich
    class operator Implicit(A: set of T): TWindowsEnumSet<T>;  // [dcc32 Fehler] E2029 Bezeichner erwartet, aber 'SET' gefunden
    class operator Implicit(A: TSet): TWindowsEnumSet<T>;      // geht nicht, da das TSet fehlt
  case Integer of
    0: (TheSet:  TSet);
    1: (Aligned: Integer);
  end;

https://docwiki.embarcadero.com/RADS...isierte_Typen)

Code:

<T>                             keine Einschränkung
<T, T2>                         keine Einschränkung
<T: IInterface; T2>             Interace welches Dieses implementieren muß
<T: IInterface,IIntf,...; T2>   Interace welches Diese implementieren muß
<T: TObject; T2>                Klasse oder Nachfahr
<T: constructor; T2>            muß einen Konstrutor enthalten, also Klassen (keine Records, obwohl Die auch Einen haben können)
<T: class; T2>                  nur Klassen
<T: record; T2>                 nur records und "einfache" Typen

also im Prinzip fehlt ja Vieles
"ordinal", wo wirklich nur ordinale Typen rein passen
"simple" für einfache Typen (keine Records, inkl. noneManaged)
"noneManaged", wo keine LongStrings, Variants, Interfaces und dynamische Arrays rein dürfen, sowie keine CustomManagedRecords und ARC, und ebenso keine Records/StaticArrays, wo sowas drin ist
"array", nja, halt bloß Arrays
"array,managed", bloß dynamische Arrays
"array,noneManaged", bloß statische Arrays
"array,****" ... ähhhh ja, statische Arrays, welche aber Managed-Zeugs enthalten dürfen?
OK, dann halt "array", "staticArray" und "dynamicArray" (mit anderem kombinierbar, für die Felder)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1534117)

Maaa, es wäre jetzt zu einfach gewesen. :roll:

Na ja, deine Anforderung war ja aber auch lediglich:

Zitat:

Zitat von himitsu (Beitrag 1534103)

Benötige mal wieder ein SET mit zwei Werten, welches aber dennoch Integer groß ist.

[himitsu]

Wäre aber auch zu einfach, wenn es das SET selbst könnte. :stupid:

[Dennis07]

Habe dazu vor Jahren mal einen Typen erstellt und veröffentlicht. So, wie ich das sehe, ist es wohl noch immer die beste implementierung, die es öffentlich gibt:

https://github.com/Manhunter07/CustomSets

Delphi-Quellcode:

uses Sets;

type TLargeNumber: 100000 .. 109999;
var Numbers: TSet<TLargeNumber>

begin
  Numbers := [100572, 100285];
end

[himitsu]

Das hilft hier nur leider absolut nichts, da es eben kein SET ist ... da sind die Daten intern in einem Pointer (ByteArray) versteckt.
Somit leider inkompatibel und nicht verwendbar, um eine bestehende API von C++ (Windows) nach Delphi zu portieren.

Mit einen überladen Record ginge es, womöglich noch mit impliziten Casts, aber da es generisch nicht funktioniert, müsste man jeden einzelnen Typen das neu deklarieren/implementieren, was einen Albtraum an Code ergäbt,
obwohl ja einfach nur sowas wie {$MinEnumSize} fehlt, bloß halt auch für Sets.

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1534121)

Wäre aber auch zu einfach, wenn es das SET selbst könnte. :stupid:

Fände ich nur bedingt. Eine Sprache sollte in sich selbst konsistent sein. (Nicht das Delphi das immer wäre, aber das ist ein anders Thema.) Wenn es dann zu einer Schnittstelle geht die anders implementiert ist darf es auch etwas mühsamer machen.
Ich würde vermutlich eh einen Wrapper machen mit interface das man dann auch mocken kann. Der Wrapper wäre nach außen schönes Delphi, innen dann das was nötig ist für die WinApi.