3. Bitmaske zu groß

Bitmaske zu groß

  • Z

    Gibt es eine Alternative zu folgendem typdef als Basis für ein Suchpattern?

    typedef enum {
XXX_YYY = ((unsigned _int64)1) << 64 // produces warning C4293: "<<":
}

    Für solche große Bitmasken suche ich noch eine Alternative Lösung. Jemand einen Vorschlag, der auch ähnlich performant ist?

    0
  • Mod

    `const unsigned long XXX_YYY = 1 << 64;

    `

    0
  • ?

    zwei Bitmasken.

    0
  • K

    Für den Fall, dass eine Ganzzahlvariable, nennen wir sie "zahl", nur N Bit breit ist, dann ist sowohl zahl<<s als auch zahl>>s für den Fall s>=N oder s<0 sowieso nicht erlaubt ... also entweder "undefined behaviour" oder "implementation-defined" (bin zu faul zum Nachgucken).

    0
  • ?

    Der Fall X << 0 und X >> 0 übrigens auch!

    0
  • Z

    D.h. mit der Bitmaske kann ich nicht mehr als 64 Werte prüfen. Müsste ich also selber mit einer Liste/set die Elemente halten und nach dem suchenden Wert abgleichen?

    0
  • Mod

    Zickedi schrieb:

    D.h. mit der Bitmaske kann ich nicht mehr als 64 Werte prüfen. Müsste ich also selber mit einer Liste/set die Elemente halten und nach dem suchenden Wert abgleichen?

    Was hast du überhaupt vor? Es gäbe da zum Beispiel noch std::bitset.

    0
  • ?

    SeppJ schrieb:

    Es gäbe da zum Beispiel noch std::bitset.

    Ist die nicht auch begrenzt?

    0
  • Z

    Was hast du überhaupt vor?

    typedef enum {
[...]
XXX_YYY = ((unsigned _int64)1) << 64, // produces warning C4293: "<<":
[...]
} MyType;

typedef unsigned int TypeMask;
TypeMask myMask = XXX_YYY | [..];

if ( myMask & currentType ) {
[...]

    Problem ist nur, dass ich mehr als 64 Typen habe.

    Beschreibung:
    Es soll ein (Text)Parser sein, der mit einem vorgegebenen Suchpattern filtern kann und gleichzeitig performant arbeitet.

    0
  • U

    Versuch mal zu beschreiben, was du vor hast - nicht, wie du es implementieren willst

    0
  • I

    Wenn die Variable nur 64 Bit hat, kann man eben auch nur auf 64 Bit prüfen.
    Da musst du dir wohl was anderes einfallen lassen.

    0
  • Z

    Vielen Dank für den qualifizierten Beitrag.
    Ich habe mich gerade deshalb an das Forum gewandt, weil hier eigentlich immer gute Hinweise/Ideen gemacht werden.

    0
  • V

    Zickedi schrieb:

    Vielen Dank für den qualifizierten Beitrag.
    Ich habe mich gerade deshalb an das Forum gewandt, weil hier eigentlich immer gute Hinweise/Ideen gemacht werden.

    Wird schon, keine Bange.
    Aber ich fürchte, die Lösung, die wir nachher zusammen erarbeiten, wird Dich überraschen. Und sie wird kaum noch so aussehen wie Dein Ansatz. Sie wird sogar Techniken und Sprachmittel einsetzen, die Du noch nicht kennst. Aber das ist auch gut so. Deswegen magst Du ja dieses Forum.
    Jetzt ist unskilled stark zielführend.
    "Versuch mal zu beschreiben, was du vor hast - nicht, wie du es implementieren willst"
    Vielleicht gibt es in C++ viel stärkere Tricks als Bitfelder. Laß mal unskilled ein wenig rumzaubern, der kann entgegen seines Nicks schon einiges. So Dinge halt. So Dinge, weshalb C++ bei einigen Spielern einen schlechten Ruf hat.
    *Popcorn hol*

    0
  • ?

    Zickedi schrieb:

    Was hast du überhaupt vor?

    typedef enum {
[...]
XXX_YYY = ((unsigned _int64)1) << 64, // produces warning C4293: "<<":
[...]
} MyType;

typedef unsigned int TypeMask;
TypeMask myMask = XXX_YYY | [..];

if ( myMask & currentType ) {
[...]

    Problem ist nur, dass ich mehr als 64 Typen habe.

    Damit kann man 1.84467441 × 1019 Typen definieren, wenn man mask == currentType vergleicht.

    Beschreibung:
    Es soll ein (Text)Parser sein, der mit einem vorgegebenen Suchpattern filtern kann und gleichzeitig performant arbeitet.

    Wozu brauchst du dazu so ein Enum?

    0
  • M

    ähm schrieb:

    Damit kann man 1.84467441 × 1019 Typen definieren, wenn man mask == currentType vergleicht.

    Damit hast du "Typ" aber neu definiert 😉 Denn bei dir kann nur ein einzelner "Typ" gleichzeitig auftreten, der OP will aber mehr als 64 voneinander unabhängige "Typen", die in Kombinationen auftreten können.

    0
  • ?

    Michael E. schrieb:

    der OP will aber mehr als 64 voneinander unabhängige "Typen", die in Kombinationen auftreten können.

    Solche Bitflag-Vergleiche funktionieren mit std::bitset doch problemlos, auch mit sehr vielen Bits. Was spricht also dagegen ?

    0
  • M

    Von meiner Seite aus nichts, frag den OP 🤡

    0

  • nn schrieb:

    Michael E. schrieb:

    der OP will aber mehr als 64 voneinander unabhängige "Typen", die in Kombinationen auftreten können.

    Solche Bitflag-Vergleiche funktionieren mit std::bitset doch problemlos, auch mit sehr vielen Bits. Was spricht also dagegen ?

    Vermutlich dass es langsam wäre.

    0
  • U

    Ich verstehe auch noch immer nicht, wie ein Typ mehrere Typen sein kann...
    Ich meine - in welchem Bereich macht es denn Sinn, einen Variablen-Typ so dynamisch gestalten zu wollen? Wie soll der User-Code dazu dann aussehen?

    Oder kanns doch immer nur 1 Typ sein und du dachtest, dass es so einfach schneller ausgewertet werden kann?

    0

  • unskilled schrieb:

    Ich verstehe auch noch immer nicht, wie ein Typ mehrere Typen sein kann...

    Mehrfachvererbung?
    Bzw. reicht auch schon ganz normale Vererbung...

    0
  • U

    hustbaer schrieb:

    unskilled schrieb:

    Ich verstehe auch noch immer nicht, wie ein Typ mehrere Typen sein kann...

    Mehrfachvererbung?
    Bzw. reicht auch schon ganz normale Vererbung...

    da wärs vrmtl einfacher und performanter, für jeden typen ne fkt anzubieten...

    0
Anmelden zum Antworten