SWT Style Bits API was bedeutet <<

Status
Nicht offen für weitere Antworten.

knowledge

Bekanntes Mitglied
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...
 

knowledge

Bekanntes Mitglied
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.
 
V

Vayu

Gast
weil es simpler ist seine Style constants so darzustellen.

Code:
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

Code:
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?
 
Zuletzt bearbeitet von einem Moderator:

knowledge

Bekanntes Mitglied
>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
 
Zuletzt bearbeitet:

Ebenius

Top Contributor
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
 
Zuletzt bearbeitet:

knowledge

Bekanntes Mitglied
>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?
 
Zuletzt bearbeitet:

Ebenius

Top Contributor
:oops: 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
 
V

Vayu

Gast
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

Top Contributor
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

Bekanntes Mitglied
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?
 
M

maki

Gast
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

Bekanntes Mitglied
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?
 
G

Gast2

Gast
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

Top Contributor
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:
 

knowledge

Bekanntes Mitglied
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

Top Contributor
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

Bekanntes Mitglied
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
 
Zuletzt bearbeitet:
M

maki

Gast
knowledge,

Theorie diskutieren ist oft witzlos.

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

knowledge

Bekanntes Mitglied
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

Top Contributor
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

Top Contributor
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

Bekanntes Mitglied
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
 
G

Gast2

Gast
@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

Bekanntes Mitglied
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 :)
 
G

Gast2

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

byte

Top Contributor
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.
 

Wildcard

Top Contributor
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.
 
V

Vayu

Gast
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"
 
V

Vayu

Gast
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

Top Contributor
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.
 
V

Vayu

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

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

Top Contributor
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().
 

byte

Top Contributor
Je nach Anzahl der möglichen Enum-Werte ist es entweder ein long oder ein long Array. Referenzen auf Enum-Werte werden nicht gespeichert.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
MiMa Login mit CSS Style AWT, Swing, JavaFX & SWT 9
J JavaFX Dialog - Style AWT, Swing, JavaFX & SWT 6
L JavaFX ListView oder TableView Style überschreiben? AWT, Swing, JavaFX & SWT 6
M JavaFX Scrollpane: Style von Contentpanel default AWT, Swing, JavaFX & SWT 1
M Swing JColorchooser anpassen - custom style? AWT, Swing, JavaFX & SWT 0
T SWT benötige den richtigen SWT style --> org.eclipse.swt.SWT.* AWT, Swing, JavaFX & SWT 2
S Swing Style Attribute aus JTextPane kopieren AWT, Swing, JavaFX & SWT 1
M SWT Sprache bei SWT Style Constants AWT, Swing, JavaFX & SWT 9
E SWT ExpandBar Style AWT, Swing, JavaFX & SWT 2
W JButton verliert den Style AWT, Swing, JavaFX & SWT 4
M AWT - XP Style AWT, Swing, JavaFX & SWT 4
S Iphone Style Schliessen AWT, Swing, JavaFX & SWT 3
G SWT Style AWT, Swing, JavaFX & SWT 8
R JTextArea im JTextField Style AWT, Swing, JavaFX & SWT 2
I "default"-Style im DefaultStyledDocument AWT, Swing, JavaFX & SWT 2
K Windows Style als standard? AWT, Swing, JavaFX & SWT 2
I Swt Label und style AWT, Swing, JavaFX & SWT 5
A Probleme mit Windows Style (Background) AWT, Swing, JavaFX & SWT 4
D Kann jeditorPane CSS Style-Sheets und javascript AWT, Swing, JavaFX & SWT 2
Q sun.awt.X11.XException: Cannot write XdndAware property - Was bedeutet das? AWT, Swing, JavaFX & SWT 2
G Swing Component.toString() was bedeutet flags AWT, Swing, JavaFX & SWT 8
V JComboBox gleicher Inhalt bedeutet gleicher Index? AWT, Swing, JavaFX & SWT 7
F Was bedeutet FontData AWT, Swing, JavaFX & SWT 6

Ähnliche Java Themen


Oben