SWT Style Bits API was bedeutet <<

[knowledge]

Hallo,

was bedeutet das << in der API???

"The FileDialog style constant for open file dialog behavior (value is 1<<12). "

1 kleiner 12 ja wohl kaum...

 

[maki]

Summary of Operators (The Java™ Tutorials > Learning the Java Language > Language Basics)

Unter "Bitwise and Bit Shift Operators"

 

[knowledge]

Hallo,

danke für deine Antwort. Hmm, warum wird der Wert denn mit nem Bitshift bearbeitet? Was hat das für nen Sinn. Verstehe ich nicht.

 

[Vayu]

weil es simpler ist seine Style constants so darzustellen.

public static final int STYLE_1 =  1;
public static final int STYLE_2 =  1<<1;
public static final int STYLE_3 =  1<<2;
public static final int STYLE_4 =  1<<3;
...
public static final int STYLE_12 =  1<<12;

vs

public static final int STYLE_1 =  1;
public static final int STYLE_2 =  2;
public static final int STYLE_3 =  4;
public static final int STYLE_4 =  8;
...
public static final int STYLE_12 =  4096;

mit der bitshift darstellung inkrementierst du einfach bei einem neuen stylebit die hintere zahl um 1. Ohne Bitshift musst erst jedes mal 2^x ausrechnen

achso und wieso man 2er potenzen nimmt weisst du aber oder?

 

[knowledge]

>achso und wieso man 2er potenzen nimmt weisst du aber oder?
Nein, weiss ich nicht Also das durch den Bitshift nach links nur 2er Potenzen entstehen is ja klar...

Das Bitshift ist doch somit nur eine verkürzte Schreibweise von 2 hoch 12. Soviel Schreibaufwand spart man da doch auch nicht, oder? Bzw. man könnte ja gleich 4096 hinschreiben

 

[Ebenius]

Bei der Schreibweise "1 << 11" weiß ich, dass es sich bei der Maske um das elfte Bit handelt. Bei 2048 muss ich erst nachdenken.

Wofür benutzt man das? Stell Dir vor, Du willst eine Schreibberechtigung, eine Leseberechtigung (und noch ein paar andere) abspeichern und dafür möglichst wenig Speicherplatz belegen: [HIGHLIGHT="Java"]// first bit
public static final int PERM_READ = 1 << 0;
// second bit
public static final int PERM_WRITE = 1 << 1;
...
private int permissionMask = ...;
...
public boolean canWrite() {
return (permissionMask & PERM_WRITE) != 0;
}

public boolean canRead() {
return (permissionMask & PERM_READ) != 0;
}[/HIGHLIGHT]
Ebenius

 

[knowledge]

>Bei der Schreibweise "1 << 11" weiß ich, dass es sich bei der Maske um das elfte Bit handelt. Bei 2048 muss ich erst >nachdenken.

Das sind doch einfach nur Zahlen. Klar, bei ner Bitmaske die ala Linux rw rechte setzt ist das nützlich, aber warum nimmt man das in SWT. Dort sagt das doch wie eine Komponente aussieht, oder nicht.

Oder ist das deshalb so nützlich, weil ich so nur ein paar byte brauche um das gesamte aussehen zu beschreiben und nicht 4000 int Variablen?

 

[Ebenius]

Natürlich handelt es sich um das 10te Bit. Ich bin noch nicht wach. Den Rest Deiner (berechtigten) Nachfrage überlasse ich mal den SWT-Jungens...

Ebenius

 

[Vayu]

ich weiss es nicht wieso die es verwenden, denke aber dass man auch dort auch bitmasken benutzt, weil es nunmal leichter ist diverse flags zu verodern, als irgendwo tausend verschiedene parameter setzen und abfragen zu müssen, als einfach eine StyleVariable zu haben, die man immer nur mit den versch. flags abprüft.

Also ich find es einfach, übersichtlicher und mache es in meinen Programmen genauso.

 

[byte]

Es wird verwendet, weil Du eben auch in SWT mehrere Styles übergeben kannst. Du kannst dann einfach mehrere Styles mit | konkatenieren. Durch die << Schreibweise ist sichergestellt, dass das Ergebnis der VerODERung beliebiger Styles eindeutig ist.

Sowas ist durch diese Style Bits möglich:
[HIGHLIGHT="Java"]new Button(parent, SWT.ARROW | SWT.DOWN | SWT.FLAT);[/HIGHLIGHT]

 

[knowledge]

Mehrere Styles köntne man ja auch in der Form (Style1Variable, Style2Variable,...,StyleNVariable) übergeben. Der größte Vorteil ist also das kein unnötiger Speicherplatz genommen wird (n Variablen) sondern nur 1 paar Byte abhängig von der Bitanzahl. Ich kann also mit einem Byte schon 8 Styles repräsentieren statt eigene 8 Variable zu nehmen. Ist das so richtig?

 

[maki]

Ist das so richtig?

Nein.

Es ist absolut kein "großer Vorteil" weil "kein unnötiger Speicherplatz genommen wird (n Variablen) " einfach kein Argument ist wenn es sich um ein paar Byte handelt und dafür seltsame Methodensignaturen ("(Style1Variable, Style2Variable,...,StyleNVariable)") die Konsequenz wären.

Aber prinzipiell wäre es möglich, ob es gut ist steht auf einem anderen Blatt

 

[knowledge]

Verstehe ich nicht. So wie es jetzt ist kann ich doch mit einem Byte locker 8 Styles darstellen. Wenn ich für jeden Style ne eigene Variable einführen würde, wären das 8 Variablen und somit mehr Speicher. Wieso ist da Platzverschwendung kein Argument?

 

[Gast2]

Verstehe ich nicht. So wie es jetzt ist kann ich doch mit einem Byte locker 8 Styles darstellen. Wenn ich für jeden Style ne eigene Variable einführen würde, wären das 8 Variablen und somit mehr Speicher. Wieso ist da Platzverschwendung kein Argument?

Warum denn? Ein Style ist ein ganz normaler int!

 

[byte]

Du hast es noch nicht begriffen.
Es geht darum, dass Du mit o.g. Lösung aus einer Zahl alle Styles per Bitshifting extrahieren kannst. Du kannst also mit nur einem int ALLE möglichen Kombinationen aus Styles darstellen.

Platzverschwendung? Hallo? 2009? :bahnhof:

 

[Gast2]

Platzverschwendung? Hallo? 2009?

 

[knowledge]

Hi,

danke für die Antworten. D.h. so kann in einer Schleife oder ähnlichen leicht geprüft werden (bit gesetzt oder nicht) ob der Style gilt, oder wie ist das zu verstehen? Wieviel mehr "Vergleichsaufwand" hätte man, wenn man für jeden Style eine eigene Variable einführen würde, also nicht nur "Bit gesetzt oder nicht"...

 

[byte]

Hier mal Beispielcode, vielleicht wirds dann klarer für Dich:

[HIGHLIGHT="Java"]int s1 = 1 << 1;
int s2 = 1 << 2;
int s3 = 1 << 3;

int flag = s1 | s3;

System.out.println("s1 gesetzt: " + ((flag & s1) == s1));
System.out.println("s2 gesetzt: " + ((flag & s2) == s2));
System.out.println("s3 gesetzt: " + ((flag & s3) == s3));[/HIGHLIGHT]

[HIGHLIGHT]s1 gesetzt: true
s2 gesetzt: false
s3 gesetzt: true[/HIGHLIGHT]

 

[knowledge]

Hallo,

danke für das Bsp. Hab das schon verstanden

s1: 1<<1 = 0010 = 2
s2: 1<<2 = 0100 = 4
s3: 1<<3 = 1000 = 8

flag = s1 | s3 = 1010

s1 | s3 wäre dann ja 1010. Nun weiss ich also s1 (Eigenschaft 1) und s3 (Eigenschaft 3) sind gesetzt, da das entsprechende Bit an diesen Stellen 1 ist. Wo ist da der Vorteil wenn ich das anders prüfen würde als über ein Bitmuster. Also ich hab schon verstanden das man das über die Bitmuster macht und dann leicht Eigenschaften setzen kann (über | Operator) und mittels & Operator prüfen kann ob die Eigenschaft gesetzt wurde.

Da flag & s1 == s1 dann true ist wenn das Bit 1010 im Flag gesetzt ist.

Aber wenn meine Annahme mit der Platzersparniss irrelevant ist, könnte ich doch über andere Konstrukte (if usw.) genauso prüfen welche Eigenschaften gesetzt wurden und welche nicht. Wo bringt mir das mit dem Bitshifting also signifikante Vorteile gegenüber einem anderen Ansatz... Ich steh leider noch immer auf dem Schlauch

 

[maki]

knowledge,

Theorie diskutieren ist oft witzlos.

Schreib dir doch mal dein eigenes Beispiel für deine Lösung, dann sollte dir etwas auffallen

 

[knowledge]

Hallo,

das hab ich ja schon. Mir fällt aber nix auf Deshalb diskutier ich ja. Wenn ichs verstanden hätte, würde ich nicht weiter nachfragen...

 

[byte]

Wenn wir über Vorteile der einen oder anderen Lösung sprechen, müsste ich erstmal wissen, wie Du es denn alternativ lösen willst.
Wenn ich Dich richtig verstanden habe, willst Du pro Style eine Flag machen? Das ist halt einfach unschön, weil Du dann sehr viele Membervariablen anlegen musst und man die Flags dann auch nicht mehr so schön am Stück setzen kann wie bei der VerODERung.

Ich würde es übrigens heutzutage nicht mehr mit per Bitshifting machen sondern per Enum in Kombination mit EnumSets. Denn da hat man den Vorteil der Typsicherheit, während man bei int Konstanten ziemlichen Unsinn machen kann.

 

[byte]

Beispiel:

[HIGHLIGHT="Java"]public enum Style {
ONE, TWO, THREE
}[/HIGHLIGHT]

[HIGHLIGHT="Java"]EnumSet<Style> styles = EnumSet.of(Style.ONE, Style.THREE);

System.out.println("one gesetzt: " + styles.contains(Style.ONE));
System.out.println("two gesetzt: " + styles.contains(Style.TWO));
System.out.println("three gesetzt: " + styles.contains(Style.THREE));[/HIGHLIGHT]

 

[knowledge]

Hallo,

ursprüngliche Frage bezog sich ja vorallem darauf, warum die SWT Klasse die StyleBits so setzt und nicht anders. Also warum z.B. die TRANSPARENCY_MASK mit 1<<1 initialisiert wird und man nicht einfach TRANSPARENCY_MASK = 2 oder sowas schreibt.

Ich könnt ja auch ein boolean machen Transparence_Mask = true und Border = tue und dann prüfen welche Werte true sind. Das funktioniert doch genauso

 

[Gast2]

@byto Wie würde dann dein Konstruktor aussehen?

Hallo,

ursprüngliche Frage bezog sich ja vorallem darauf, warum die SWT Klasse die StyleBits so setzt und nicht anders. Also warum z.B. die TRANSPARENCY_MASK mit 1<<1 initialisiert wird und man nicht einfach TRANSPARENCY_MASK = 2 oder sowas schreibt.

Ich könnt ja auch ein boolean machen Transparence_Mask = true und Border = tue und dann prüfen welche Werte true sind. Das funktioniert doch genauso

Poste doch einfach mal ein Beispiel, dass man weiß was du meinst.

 

[knowledge]

Ich will doch nur wissen warum diese Bitshift Lösung so toll ist, das die Java-Leute das genommen haben. Was sind daran die Vorteile. Das kann man doch auch unabhängig von einer alternativen Umsetzung diskutieren

 

[Gast2]

Die Vorteile wurden doch alle schon dargestellt ???:L...
Mich würde trotzdem interessieren wie deine alternative Lösung aussehen würde...

 

[byte]

Also warum z.B. die TRANSPARENCY_MASK mit 1<<1 initialisiert wird und man nicht einfach TRANSPARENCY_MASK = 2 oder sowas schreibt.

Wurde doch längst beantwortet: 1<<1 ist wesentlich eindeutiger als 2, wenn man mit der Binärdarstellung rechnen will. Du siehst sofort, welches Bit gesetzt ist. Und Du siehst vor allem sofort, dass auch wirklich nur ein Bit gesetzt ist. Das ist ja grade, um die eindeutig und reproduzierbar per OR zu kombinieren.

Ich könnt ja auch ein boolean machen Transparence_Mask = true und Border = tue und dann prüfen welche Werte true sind. Das funktioniert doch genauso

Das kannst Du ja auch machen, wenn Du sehr wenige Flags brauchst. Brauchst Du aber viele Flags, dann wird das furchtbar unübersichtlich.

 

[Gast2]

@byto wie würdest du dein Konstruktor mit den Enum machen?

 

[byte]

Wenn nix dagegen spricht einfach Varargs vom Typ der Enum.

 

[Wildcard]

SWT mapped auf native Widgets. Bei SWT wird das Native Widget direkt erstellt, sobald der Konstruktor aufgerufen wird (daher muss im Konstuktor auch ein Parent angegeben werden). Der Style bestimmt welches konkrete Widget verwenden muss.
Ohne die Style Mask bräuchte man also entweder endlos viele Konstruktorvarianten, oder einen riesigen.

 

[Vayu]

wieso nicht einfach

[HIGHLIGHT="Java"]public MyConstructor(Composite parent, EnumSet<Style>)[/HIGHLIGHT]

und aufruf dann

[HIGHLIGHT="Java"]new MyConstructor(myParent, EnumSet.of(Style.ONE, Style.THREE))[/HIGHLIGHT]

ist am Anfang vielleicht gewöhnungsbedürftig, aber wirklich mehr schreibarbeit isses nicht, und man muss nicht mit varargs "rumpfuschen"

 

[Wildcard]

Enums gab es allerdings noch gar nicht als SWT entwickelt wurde.

 

[Vayu]

jo, ich wollts ja jetzt auch ned für SWT benutzen, aber vom denkansatz her find ich die enums für sowas gar nicht schlecht.

 

[Wildcard]

Typsicherheit ist immer was nettes, aber für SWT ist das mit den Style Bits gar nicht so schlecht.
Es gibt schließlich auch sehr leichte Widgets, wie TreeItems von denen es potentiell sehr sehr viele geben kann und da sollte tatsächlich um jedes Bit Speicher gekämpft werden.

 

[Vayu]

ok das ist ein guter punkt. jetzt könnte sogar knowledge wieder kommen und "HAHA Speicher sparen, ich habs doch gesagt" sagen

Ich muss mal schauen, ob ich in Zukunft was die Enums mal für flags hernehme. Bin die Stylebits jetzt so gewöhnt ... aber man muss sich ja weiterentwickeln.

 

[byte]

Typsicherheit ist immer was nettes, aber für SWT ist das mit den Style Bits gar nicht so schlecht.
Es gibt schließlich auch sehr leichte Widgets, wie TreeItems von denen es potentiell sehr sehr viele geben kann und da sollte tatsächlich um jedes Bit Speicher gekämpft werden.

Enums bestehen ja im Grunde auch nur aus ints. Und die Implementierung von EnumSet#contains() benutzt selbst Bitshifting auf diesen ints, also Enum#ordinal().

 

[Wildcard]

Enums bestehen ja im Grunde auch nur aus ints. Und die Implementierung von EnumSet#contains() benutzt selbst Bitshifting auf diesen ints, also Enum#ordinal().

Also hat ein EnumSet nicht eine Referenz pro Enum, sondern nur ein int? Nice

 

[byte]

Je nach Anzahl der möglichen Enum-Werte ist es entweder ein long oder ein long Array. Referenzen auf Enum-Werte werden nicht gespeichert.