Von Stackoverflow:
(a<=b && b<=a && a!=b)
Was müssen a und b sein, damit der Ausdruck true ergibt?
[spoiler]
Irgendwas mit Autounboxing und Konstruktoraufruf (*), z.B.:
Integer a = new Integer(1);
Integer b = new Integer(1);
(*) bzw. Factory-Methode jenseits des Konstantenpools, also Integer.valueOf(4711);
[/spoiler]
Link?
Gibts auf Stackoverflow auch ein „Quiz“ oder wie läuft das dort ab dass dort solche Fragen gestellt werden? Bin nähmlich kein Stackoverflow Kenner or gar großer Fan von dem System.
(a<=b && b<=a && a!=b)
in Suchmaschine reicht hier schon wie oftmals 
[QUOTE=SlaterB](a<=b && b<=a && a!=b)
in Suchmaschine reicht hier schon wie oftmals ;)[/QUOTE]
Von 2013? Achso, dann ist das garkeine Frage von Stackoverflow sondern einfach etwas interessantes Rätsel das einmal auf Stackoverflow gestellt wurde. Okay, verstanden. 
Danke
Eigentlich This ‘if’ evaluation in Java with three simultaneous expressions - Stack Overflow , aber das war ein duplicate von einem duplicate, deswegen habe ich (zum ersten Mal!!!111) meinen “Dupehammer” ausgepackt…
Was wird ausgegeben und warum ?
int a = 1;
int b = 1;
if (++a > 1 || ++a > 0) {
//...
}
if (++b > 1 | ++b > 0) {
//...
}
System.out.println(a);
System.out.println(b);
}```[SPOILER]
2
3
zuerst wird a um 1 erhöht und ist damit größer 1 der zweite Teil des OR wird gar nicht ausgeführt.
Bei b wird auch zuerst um eins erhöht aber hier verwendest du das Binary OR daher wird auch der zweite Teil ausgeführt, daher nocheinmal um 1 erhöht
[/SPOILER]
jop^^
Wollte den Thread mal wiederbeleben 
Danke für die Belebung, auch wenn dieses Quiz für mich nicht schwer war. Ich finde es aber auch nicht ganz einfach, gute Quizaufgaben zu finden, die zum einen nicht irgendwelches seltsames Randverhalten, das man sonst tunlich vermeidet, nutzt, und anderseits nicht irgendwie trivial wird.
Ich denke, da habe ich was Nettes aus JavaFX…
nichts kompliziertes, kann man aber drüber stolpern:new Task<Void>() { @Override protected Void call() throws Exception { for (int i = 1; i < 1000; i++) { int intValue = progressProperty().intValue(); updateProgress(intValue + new Random().nextInt(1000- intValue),1000); } return null; } };
Was ist das Ergebnis?
bye
TT
Nachdem ich etwas in der API gelesen habe komme ich zu folgendem Schluss …
Task und return null; ist in Ordnung da es dort selbst so als Beispiel aufgeführt ist.
Also bleibt die Schleife übrig, bzw. deren Rumpf
int intValue = progressProperty().intValue();
Worker (JavaFX 2.2)
Da in der API zum definierenden Interface Worker nachzulesen ist,
dass progressProperty einen Prozentwert der Fertigstellung zwischen 0 und 1 hat, wird intValue() immer 0 zurückgeben, außer im Ausnahmefall -1.
updateProgress hat als Parameter zwei Werte workDone und max, welcher dann intern die Umrechnung in Prozent macht.
Folglich wird die Anzeige Tausend mal völlig Zufällige Werte anzeigen. Also vor und zurück springen, anstatt stetig Richtung Vollendung voranzuschreiten.
Korrekt wäre also das Property WorkDone zu verwenden, wenn man fortlaufenden Fortschritt möchte.
int intValue = workDoneProperty().intValue();
[quote=ionutbaiu]Korrekt wäre also das Property WorkDone zu verwenden, wenn man fortlaufenden Fortschritt möchte.[/quote]Guter Punkt, ist aber nicht das, was ich meine.
Das Problem auf das ich hinaus will tritt auch mit workDoneProperty() auf.
bye
TT
public class ArraySyntaxQuiz
{
public static void main(String[] args)
{
int[][]i[][] = get();
}
static int[]get()[][][]
{
return null;
}
}
Compiliert’s?
Warum nicht, sieht doch toll aus…
Grauslich… ich nutze lieber Listen. schmunzelt
Ja, es war schon fast eine rethorische Frage: Man hätte es nicht gefragt, wenn das Ergebnis nicht “überraschend” gewesen wäre. Zumindest wußte ich vorher nicht, dass
static int get()[] { ... } genausogut funktioniert wie
static int[] get() { ... }
Neues Spiel, neues Glück: Ändere den String so, dass die Funktion crasht:
public class LetItCrash
{
public static void main(String[] args)
{
String s = "Which String do you need here?";
letItCrash(s);
}
static void letItCrash(String s)
{
if (s == null)
{
return;
}
int h = Math.abs(s.hashCode());
int i = h % 5;
int array[] = new int[5];
System.out.println(array**);
}
}
@Marco13
String s = new String( new char[]{ 2, 13, 0, 9, 30, 12, 2 } );
Der String selber ist nicht als Text darstellbar.
[SPOILER]String s = boomGoesTheDynamite( Integer.MAX_VALUE + 1L );
int checksum = (int) hash;
StringBuilder preResult = new StringBuilder();
while (hash != 0) {
long c = hash % 31L;
hash = (hash - c) / 31L;
preResult.append((char) c);
System.out.print(c);
}
String result = preResult.reverse().toString();
System.out.println();
System.out.println("Result:" + result);
System.out.println("Hash is " + (result.hashCode() == checksum ? "valid!" : "invalid!"));
return result.toString();
}```[/SPOILER]Naja, mit Unicode-Trickserei: "\u0915\u0009\u001e\u000c\u0002" (hab’ ich aber auch nicht selbst ausgeklügelt). Aber es stimmt, es geht um einen String, dessen hashCode Integer.MIN_VALUE ist.
Ist aber ein gutes Beispiel dass man zum programmieren immer länger benötigt als man annimmt.
30Minuten war Anfangs meine Vermutung, am Ende waren es zwei Stunden bis alle Bugs beseitigt waren und endlich der richtige String aus dem Hash erzeugt wurde.
Wenn mich jemand nach einer Deadline frägt, nehme ich immer meine Vermutung, runde sie auf ganze Tage auf und multiplizieren sie mit 5 