Beiträge von Ramses13

    In deinem Code fehlt so einiges, weshalb es schwierig herauszulesen ist, was du eigentlich machen willst.
    Wenn ich den Code richtig interpretiere, dann willst du in methodeB() (Nach dem Klick auf Anmelden) eine Auswahl anbieten, welches Spiel man spielen will?
    Dann brauchst du doch gar nichts mehr zur Combobox hinzufügen?!? Oder willst du die Combobox zur Startseite hinzufügen, wenn der Button geklickt wurde?

    Problem gelöst.
    Der Browser sendet den (oben angeführten) Request. Der gehört nicht weitergeleitet (hatte mich sowieso schon gewundert), sondern mit einem Reply an den Browser beantwortet:

    HTTP
    HTTP/1.0 200 Connection established\r\n
    Proxy-agent: ProxyServer/1.0\r\n
    \r\n

    Danach geht der Rest 1:1 über den Proxy.

    Ich habe einen Proxy geschrieben, der lokal auf dem Rechner läuft und http-Anfragen (Proxy im Browser entsprechend eingestellt) einfach nur weiterleitet (weil's mich interessiert und vllt. für einen späteren Filter/Tunnel/...). Das ganze in Java, per Sockets, über den Request finde ich den Zielrechner raus und leite dorthin weiter.
    Beispiel:

    Code
    GET http://www.google.at/ HTTP/1.1


    Request wird weitergeleitet an http://www.google.at
    Läuft so weit ganz gut (http://www.orf.at, wird z.B. korrekt inkl. Bildern und so dargestellt).

    Zum Problem: Eine Anfrage per https funktioniert jedoch nicht, obwohl ich die Anfrage 1:1 weiterleite.

    Code
    CONNECT www.google.at:443 HTTP/1.1


    Request wird weitergeleitet an http://www.google.at:443, es geht weiter mit:

    Code
    <CR><LF>
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0<CR><LF>
    Proxy-Connection: keep-alive<CR><LF>
    Connection: keep-alive<CR><LF>
    Host: www.google.at:443<CR><LF>
    <CR><LF>


    Unmittelbar darauf: Server - connection closed

    Und das verstehe ich nicht. Warum lehnt der Server (es ist nicht nur bei google so) die https-Verbindung ab?
    Ich habe die Anfrage 1:1 weitergeleitet (byte für byte, per Input-/OutputStreams).
    Gibt es da irgendeine Kommunikation, die da noch nebenher läuft? Oder mache ich sonst irgendeinen Fehler?
    Liegt es vielleicht an der Stückelung der Pakete, da ich alles byte für byte weiterleite, könnte es da sein, dass nicht alles in einem Paket ankommt und der Server das aber so haben will?
    Ich habe schon einiges herumprobiert, aber ich kriege ja nicht mal eine ordentliche Fehlermeldung oder sonst irgendeinen Hinweis vom Server was da schief läuft. :(

    Danke für die Fragen, also jeder der Interesse hat denn kann ich klar und deutlich darlegen das das System zu einem Erfolg werden wird. Seine Rechnungen kann er danach sehr gut zahlen, da wir für einmalige Arbeit einen dauerhaften Verdienst Bieten können.

    Und warum dann keinen Kredit aufnehmen, einen Programmierer zu den üblichen Konditionen einstellen und selber nachher absahnen?

    Zitat

    Wir haben ein einfaches Konzept das ich Interessenten gerne in einem Persönlichen Gespräch nahe lege.Kurz gesagt
    Großer Markt, hohe Nachfrage an genau so einem System. Stetig wachsender Markt = Erfolg

    Und warum ließ sich kein Bankmanager (oder sonst einer mit Geld) davon überzeugen? Oder gar nicht erst probiert?

    Zitat

    Es hat nichts mit Whats App zu tun. Bitte unterlasse solche Kommentare. Das Unternehmen wird hohe Gewinne einfahren das ist Sicher. Leider fehlen mir ein Haufen Programmier Kenntnisse um dieses Aufzubauen.

    Ähmmm... also wenn mir von jemandem ein Programmierprojekt mit >fährt "sicher" "hohe Gewinne" ein< angepriesen wird, dann bin ich schon mal skeptisch. Wenn das dann auch noch jemand verspricht, der vom Programmieren eigentlich wenig Ahnung hat, naja. Und das kreative Deutsch macht es auch nicht wirklich besser.

    Wünsche aber trotzdem Viel Erfolg

    Anzahl Taktzyklen: n = 150000 * 1.45 = 217500 Taktzyklen
    Dauer: t = n / 1250000000 = 174 µs
    CPI ist nur ein Durchschnittswert, also ist das Ganze nur eine Abschätzung.
    Eine Pipeline würde die CPI verändern (im Idealfall auf 1) bzw. man unterteilt einzelne Instruktionen in mehr Phasen und erhöht die Taktzykluszeit. Es gilt dabei aber: Je mehr Phasen, desto mehr Stalls (Pipelinehemmnisse) und damit würde eine Pipeline-Länge von 10 keinen Speedup von 10 erreichen.

    Es geht um das Rucksackproblem, allerdings mit Wert, Volumen & Gewicht


    Klingt mir etwas unvollständig.
    Ich vermute mal, dass in den Rucksack Gegenstände reinkommen, wobei nach Wert maximiert werden soll und ein bestimmtes Volumen/Gewicht nicht überschritten werden soll? Wobei diese Gegenstände mit einer Flüssigkeit gefüllte Luftballons (o.ä) sind, damit die jede beliebige Form annehmen können und man beim Volumen die Abmessungen der Gegenstände nicht berücksichtigen muss?

    Zitat

    Allerdings funktioniert es einfach nicht für alle Eingaben und ich sitze schon einige Zeit daran, weiß nicht mehr weiter hab den Code schon gefühlte tausende Male geändert.

    Zitat

    Weiß jemand vielleicht meinen Fehler oder kennt einen guten Pseudocode? Ich wäre zu ewigem Dank verpflichtet!!


    Den Code nach zu urteilen, wird versucht ein 2-dimensionales Array mit Werten zu füllen, d.h. das Problem wird versucht mittels dynamischer Programmierung zu lösen. Allerdings:
    - Gewicht und Volumen sind zwei unterschiedliche Paar Schuhe, die 2. Dimension von c hat aber nur die Länge des Gewichts (ist also das Gewicht wertmäßig immer größer als das Volumen - bei nicht näher definierten Einheiten?)
    - Ist dynamische Programmierung gefordert?
    - Hast du schon mal versucht eine Lösung für Wert und Gewicht alleine (ohne Volumen) zu finden? Das könnte man dann ja versuchen auszubauen.

    Hoffe es hilft.

    Sähe so aus, wenn du das so gemeint hast:

    Code
    command 2> /dev/null


    > ... Ausgabeumleitung stdout
    2> ... Selbiges stderr
    &> ... Selbiges für beide gleichzeitig

    Edit:
    Sorry, das hatte ich jetzt falsch verstanden. Du willst innerhalb eines Programms umleiten.
    In C gibt es die Variable stderr in stdio.h
    FILE * stderr;
    Die gilt es (temporär) neu zu setzen (mit einem Stream, der ins Leere geht).
    Siehe auch hier:
    http://www.gnu.org/software/libc/…tandard-Streams

    Theoretisch könnte man das in die Objektfile reinpacken. Wird halt sicher nicht gerade so eine einfache Implementierung werden wenn die Exception die ein Funktion in Objectfile A wirft, im Objectfile B deklariert ist, welche wiederum von eine anderen Exception abgeleitet wurde die in Objectfile C steckt.


    Ja, C/C++ kann einem ganz schön auf die Nerven gehen. Oder wie meinen?

    Zitat

    Ich denke das größere Problem ist doch eher die Tatsache das `new` im Normalfall einen std::bad_alloc wirft wenn der Memory aus ist. Alleine bei so etwas überall eine Behandlung machen oder `throw()` deklarieren ist hochgradig uninteressant.


    Exceptions, die überall geworfen werden könnten, sind natürlich keine sinnvollen Kandidaten für Checked Exceptions. Genauso bei einem Stack Overflow, oder wenn in C/C++ wieder mal ein Pointer ins Leere geht.

    Exceptions selbst sind in Ordnung.


    Das sowieso.

    Zitat

    Checked Exceptions zwingen dich unterschwellig, die Exceptions so tief im Code wie möglich abzufangen (weil du sonst deine API mit throws-Klauslen vollpfeffern musst), was nicht immer sinnvoll ist.


    Nun ja, Exceptions früh zu fangen finde ich nichts schlechtes dabei. Problematisch ist nur, wenn man sie an einer ungeeigneten Stelle fängt (da gehört wie immer beim Programmieren Disziplin dazu) und noch schlimmer wenn man Fehler gar nicht behandelt bzw. übersieht zu fangen (und da helfen Checked Exceptions).
    Und ja, (Checked) Exceptions quer durch ein Programm zu schleifen finde ich grundsätzlich auch nicht gut, aber das ist auch eher die Ausnahme (und da überwiegt meist der Nutzen die Nachteile deutlich und wenn Unchecked Exceptions an einer Stelle notwendig sind, dann gibt es die ja auch). Außerdem sehe ich bei Checked Exceptions nicht mehr Ärgernisse, als wenn man z.B. von einer Programmiersprache gezwungen wird Typen anzugeben, oder einen Parameter über mehrere Methoden mitzuschleppen, weil er vielleicht irgendwo gebraucht wird.

    Dann müsste aber der Compiler vor allem bei bereits Kompiliertem wissen, ob die dortigen Funktionen/Methoden irgendwelche Exceptions werfen und, wenn ja, welche.

    Ja, das wäre schön.

    Zitat

    immerhin haben sich die äquivalenten checked exceptions als eine der größten Designfehler von Java herauskristallisiert

    Nun ja, ich weiß, dass die manchmal nerven (mich eingeschlossen) und viele sich um Exceptions einfach nicht kümmern (wollen) bzw. nicht wenige überhaupt nicht wissen wofür die eigentlich gut sein sollen. Dennoch finde ich sie nach wie vor gut, wenn man sie richtig einsetzt. Und, in zumindest so einigen Situationen, findet dann (wie man hier im Thread sieht) einige Fehler auch der Compiler (gerade bei der meist unbeliebten Fehlerbehandlung) und man entdeckt diese nicht erst bei den Tests (wenn die denn gut gemacht sind) - oder eben auch nicht.


    vl. koennt ihr mir ja helfen, ich muesste eine Funktion welche eine Exception werfen darf
    von einem Thread aus aufrufen...


    Wenn die Funktion eine Exception werfen darf und aus der run-Methode eines Threads aufgerufen werden soll, dann spricht doch nichts dagegen diese Exception in der run-Methode zu fangen und dort darauf zu reagieren, oder?

    Zitat

    der laesst mich natuerlich nicht, Fehler: Runnable overriden does not throw... und wenn ichs nicht mit
    throws Exception erweitere, dann hab ich must to be delcared or thrown...


    Wenn das Problem sein sollte, dass die Exception weitergeleitet werden soll, dann stellt sich jedoch die Frage: An wen? Den Starter des Threads? Oder sonst irgendwen?
    In diesem Fall würde ich mal das Package java.util.concurrent empfehlen und im speziellen das Interface Callable und je nach Aufgabenstellung mal in die Doku von FutureTask/ForkJoinTask, bzw. ExecutorService, ... reinschauen.


    Von der Hashtabelle alleine kann ich noch nicht ableiten was zuerst drin war. Nachdem die Schlüssel keine Daten anhängen haben, geht es genau genommen nur um den Einfügeindex.

    Von der Hashtabelle alleine nicht, aber wenn jedes Element einen Schlüssel (zur Suche) und einen Einfügeindex enthält, dann können die 2 Elemente gesucht und anschließend die Reihenfolge verglichen werden.

    Zitat

    Das verstehe ich jetzt nicht ganz.

    Meine Idee war diese: Bei jedem add(e) wird dem e der aktuelle Zähler zugewiesen und dieser anschließend erhöht. Wenn ich wissen will ob a vor b eingefügt wurde, dann muss ich nur die beiden Zähler vergleichen. Das funktioniert selbst dann wenn zwischendurch Elemente (samt ihrem Zähler) wieder gelöscht wurden. Problem ist halt dass ich einen Index niemals wiederverwenden darf weil sonst die Ordnung zerstört wird.

    Ja, davon geht man aus und erweitert dieses Konzept so, dass für die ganze Datenstruktur (egal ob Hashtabelle oder Baum) ein minimaler Index midx mitgespeichert wird. Vergleicht man nun a und b, so vergleicht man nicht a < b, sondern (a - midx) < (b - midx), wobei midx <= dem kleinsten aller Indizes sein muss.
    Beispiel: Angenommen der Überlauf ist bei 999, der aktuelle Einfügeindex e = 999 und die Datenstruktur ist gefüllt mit { m:820, k:834, p:846, d:990, w:995 }
    midx ist 820 (im Idealfall, evtl. auch etwas kleiner)
    Vergleich man m mit d, so vergleicht man (820-820) < (990-820), also 0 < 170 und damit ist m kleiner.

    Fügt man nun ein weitere Elemente ein: z und g
    { m:820, k:834, p:846, d:990, w:995, z:999, g:0 }
    So gibt es einen Überlauf auf 0 (ich gehe mal von unsigned aus, geht aber auch bei signed).
    Vergleicht man nun m mit g, so funktioniert das mit 820 < 0 nicht. Jedoch mit (820 - 820) < (0 - 820), also 0 < 180 schon. Wobei 0-1 eben 999 ist.

    Wichtig dabei ist, dass der Wertebereich aller Indizes nie 1000 erreichen darf (wenn midx immer genau dem kleinsten Einfügeindex entspricht). Ist midx eine etwas schlechtere Abschätzung (also etwas kleiner als 820), muss der Bereich halt entsprechend kleiner sein.

    Geht man von einem Zahlenbereich von long (32 Bit) aus (4 Mrd Zahlen) und weiß man, dass ein Element spätestens nach 2 Mrd. Einfügeoperationen wieder entnommen worden ist, so reicht es, wenn man midx auf e - 2 Mrd. setzt und man muss nie die Indizes durchlaufen und neu nummerieren. In diesem Fall muss man midx nicht mal als Variable mitspeichern, sondern könnte sie immer bei Bedarf berechnen.

    Zuerst ein paar grundsätzliche Fragen:
    - Was bedeutet "feststellen, welches von 2 Elementen zuerst eingefügt wurde"? 2 beliebige Elemente nach einem Schlüssel suchen und deren Einfügezeit vergleichen?
    - Wie viele Elemente sind denn so durchschnittlich in der Datenstruktur?
    - So effizient wie möglich? Wie wäre es dann mit etwas selbst implementiertem und auf das Wesentliche reduzierte? Etwas vorgefertigtes ist halt meist etwas allgemein gehalten. Oder geht es nur um die Laufzeitkomplexität?

    Variante I: Nur wenn es eher wenige Elemente sind (bei im Schnitt <=10 Elemente ist das sicher die beste Lösung, über 20 Elemente ist das sicher nicht mehr das Optimum)
    Variante II: Nur wenn es sich um einen balancierten Baum handelt (Rot-Schwarz, AVL, oder so)

    Meine Empfehlung:
    Eine Hashtabelle. Einfügen konstant, löschen konstant, 2*suchen und vergleichen ebenfalls konstant. Zahlt sich auch erst ab vielen Elementen aus.
    Ein Einfügeindex ist hier auch nötig.

    Einfügeindex: Wie weit liegen minimaler und maximaler Index maximal auseinander (< MAX_INT)? Weiß man wo ungefähr der minimale Index liegt, kann man diesen von beiden Indizes abziehen und erst danach vergleichen. Dann sind beide immer positiv und der Vergleich immer korrekt, selbst wenn man immer hinaufzählt.

    Objekterzeugung und Import kann man gerade noch auswendig lernen.

    Ja, aber warum sollte man das tun, wenn man es nicht muss?

    Zitat

    Oder lernt ein Anfänger alle Nuancen der Klassen- und Methodendeklaration? Kaum.

    Bei mir so wenig wie möglich. Aber man kann es natürlich auch anders machen.

    Zitat

    Dass JavaSE-fremde Hilfsklassen die Verwendung nicht allgemein einsetzbarer Insellösungen propagieren, und seit der Klasse Scanner kaum bis keine Vorteile bieten, sind ausreichend Argumente gegen ihre Verwendung.

    Sehe ich anders. "Allgemein einsetzbar" sind die Klassen für Programmieranfänger sehr wohl. Darüber hinaus nicht, aber über das Logging hinaus ist ja auch log4j nicht wirklich "allgemein einsetzbar", ... oder welche Nicht-JavaSE-"Hilfsklassen" sind über Ihren Einsatzzweck hinaus sinnvoll "allgemein einsetzbar"?

    Zitat

    Nur, wenn man des Klugscheißens wegen dürftige Argumente aneinander reiht.

    ??? Also wenn das eine Beleidigung sein sollte, dann akzeptiere ich Ihre fachliche Kapitulation, falls das aber ein Argument sein sollte, dann sollten Sie sich nicht über die Dürftigkeit meiner Argumente aufregen.

    Zitat

    Ich habe noch den Student nicht getroffen, der den Scanner nach einer kurzen Erklärung nicht verwenden konnte.

    Und? Habe ich etwas anderes behauptet? Ich finde es nur etwas übertrieben, umständlich und unnötig, weil nicht unbedingt für diese Zielgruppe gedacht.
    Jedenfalls fand ich es nie sinnvoll Programmieranfänger zu nötigen ein Scanner-Objekt (auch über Methoden hinweg) mitzuschleifen, deswegen mache ich es nicht und spare mir so einige Erklärungen.

    Die Verwendung solcher eigenen Hilfsklassen zum Einlesen und Ausgeben stammt aus einer Zeit vor Java 1.5, wo es den Scanner noch nicht gab, und man noch über Streams einlesen musste (BufferedReader, Integer.parseInt(), ..).

    Ja, die waren damals praktisch unentbehrlich für Anfänger. Selbst für Fortgeschrittenere war System.in & Co. meist ein Graus.

    Zitat

    Der Scanner ist ebenso einfach in der Handhabung, wie solche fremden Hilfsklassen,

    Hmmm..., nein.
    Mit dem Scanner ist zwar alles deutlich leichter geworden, aber solche fremden Hilfsklassen können durchaus noch einfacher sein. Das liegt an mehreren Gründen: Keine Objekterzeugung notwendig, auf das notwendige eingeschränkte Funktionalität, kurz gehaltene Dokumentation, kein(e) imports, ...

    Zitat

    sauberer implementiert,

    Das bringt einem Programmieranfänger genau gar nichts.

    Zitat

    und dazu ein "Bordmittel" von Java, von dem man sicher gehen kann, dass es immer zur Verfügung steht.

    Das ist für einen Anfänger wohl auch kein wirkliches Kriterium.

    Zitat

    Kann man, aber die Praxis zeigt, dass man schwer ablegt, was man einmal gelernt hat: Ich kann mich noch an Studenten erinnern, die in fortgeschrittenen LVAs die EProgIO in ihre Programme einbanden, um einzulesen.

    Und? Solche Studenten erkennt man auch an anderen Unsinnigkeiten. Und wenn es reicht, spricht grundsätzlich nichts dagegen selbige Klassen zu verwenden. Abgesehen davon kann man jede Klasse falsch verwenden, das heißt aber nicht, dass diese Klassen an sich schon schlecht seien.

    Zitat

    Lernt man von Anfang an mit dem Scanner zu arbeiten, passiert das nicht.

    Deswegen werden aus diesen Studenten aber keine besseren Programmierer. Man verschleiert es bestenfalls etwas.

    Zitat

    Die Klasse Scanner kann nichts dafür, wie sie erklärt wird ;)

    Doch. Sie ist nicht speziell für Anfänger gedacht, sondern zielt eher auf Fortgeschrittene ab, die bequem Ein-/Ausgabe machen wollen.

    Zitat

    Allgemein ist es zu bevorzugen, Sprachmittel zu verwenden, wenn diese angeboten werden (z. B. Scanner statt Hilfsklassen, java.util.Logging statt log4j, slf4j, ..). Verwendet man fremde Bibliotheken, dann sollte man gute Gründe dafür haben (MigLayout statt GridBagLayout, Joda statt Date oder Calendar).

    Tja, und es gibt ja für solche Hilfsklassen (auch immer noch) einen Grund.

    Besuche mal die Webseite zu diesem Buch: http://www.ssw.uni-linz.ac.at/JavaBuch/
    Dort gibt's die Klassen In und Out zum Herunterladen.

    Ja. Und selbige kopiert man entweder in das Verzeichnis des jeweiligen Programms (sollte für's erste genügen), oder in ein beliebiges Verzeichnis und setzt die Umgebungsvariable CLASSPATH dort hin.

    Zitat

    Ich halte es aber nicht für gut, wenn man solche Hilfsklassen verwendet. Zum einen ist der Umgang mit System.in und System.out nicht wirklich schwierig, sodass sich mir nicht wirklich erschließt, wozu man diese Klassen überhaupt braucht.

    Das sehe ich etwas anders. Gerade bei der Klasse System.in sollte man schon etwas über Exceptions Bescheid wissen und komfortabel ist selbige Klasse auch nicht. Zudem ermöglichen die beiden Klassen ein einfaches Lesen und Schreiben in eine Datei (ohne sich z.B. groß mit Objekten auseinander setzen zu müssen).

    Zitat

    Zum anderen lernt man nur den Umgang mit den Hilfsklassen und steht vor dem Problem, umlernen zu müssen, wenn man mal ein "richtiges" Programm schreibt.

    Und? Wenn man mal Programmieren kann, ist das kein Problem. Ist es ein Problem, ist man wohl sowieso noch etwas vom "richtige Programme schreiben" entfernt.

    Zitat

    In der Lehrveranstaltung "Einführung in das Programmieren" (Eprog) an der TU Wien gab's mal eine ähnliche Hilfsklasse, genannt EprogIO. Sie war ebenfalls dafür verantwortlich, die Handhabung von System.in und System.out zu übernehmen. Mit dem Ergebnis, dass Eprog-Absolventen zunächst hilflos waren, wenn sie später mal nicht die EprogIO zur Verfügung hatten.

    Eprog-Absolventen sind meist so oder so hilflos, das zeigt alleine schon, dass sie sich ohne eine solche Hilfsklasse nicht wirklich zurecht finden.
    Langer Rede kurzer Sinn:
    Für Einsteiger sind solche Klassen durchaus (sehr) sinnvoll, da man sich mehr auf das jeweilige Programm konzentrieren kann und sich nicht mit den Details der (dafür mächtigeren) Standard-IO Klassen herumschlagen muss. System.in kann man außerdem vergessen, wenn schon, dann java.util.Scanner.

    Du brauchst das Array nicht extra mit delete löschen. Du hast sie ja auch nie mit new auf dem Heap angelegt.
    Oder anders gesagt: Der Speicher für das Array wird direkt in der Matrix reserviert und mit dem Löschen der Matrix frei gegeben. Und wenn du immer nur eine 2x2 Matrix brauchst, dann ist das wohl auch so die beste Lösung.
    Lösche also ganz einfach den Destruktor[edit].

    Wie gesagt, bei Super Mario bewegen sich (normalerweise) sowieso alle möglichen Elemente. D.h. du wirst Spielfiguren in regelmäßigen (kurzen) Zeitabständen einen Animationsschritt machen lassen und danach neu zeichnen müssen. Etwas wie eine Animationsschleife ist daher sowieso notwendig und diese kann gleichzeitig auch die Mario-Figur bewegen (abhängig von der gerade gedrückten Taste, die man sich eben beim letzten keyPressed gespeichert hat).
    Das funktioniert für jedes Betriebssystem, in jeder Programmiersprache, ob Applet oder nicht, ...