Beiträge von sauzachn

    Zitat von klausi

    :confused: Verstehe ich nicht ganz. Wenn ich ein C-struct ersetzen will, dann mach ich mir eine eigene Klasse mit den verschiedenen benötigten Datentypen als Klassenvariablen und fertig.


    Warum als Klassenvariablen? Instanzvariablen entsprechen eher einem Struct. Und in C++ unterscheiden sich Structs und Klassen - abgesehen vom Default-Zugriffsschutz - überhaupt nicht voneinander. Das ist ein Hinweis an den Java-Array-Mißbraucher ;) Wenn es schon keine Klasse sein soll, dann wenigstens ein Set oder so was. Bitte! Wofür gibt es denn Algodat, wenn man dann so was macht ;)

    Zitat von klausi


    der gute sauzachn wird da immer so leidenschaftlich :devil:


    Wenn man einmal das Paradies (Eiffel) gesehen hat, will man nicht mehr zurück auf die Erde.

    Zitat von Lord Binary

    Naja, also das würd ich nicht unbedingt als DEN mörderischen Vorteil bezeichnen ...
    Selbst wenn man täglich tausende dieser lästigen klassischen collection-iterator-loops mit typecasts schreibt ...
    dürfte die Zeitersparnis im Sekundenbereich liegen ;)


    Ich meinte keinen Geschwindigkeitsvorteil bei der Ausführung, der ist sowieso nicht vorhanden (der Compiler macht dasselbe, was der Programmierer machen müsste). Ich meine den Zeitvorteil beim Schreiben! Der ist schon erheblich, wenn man Generizität viel einsetzt.

    Zitat von hal

    Auf der anderen Seite kann man so nimmer verschiedene Objekte mischen in einem Array.


    Das soll man aber eh nicht tun. Ein Array ist eine Sammlung von Objekten vom gleichen (Basis-)Typ.

    Zitat von hal


    Damit würden aber vermutlich alte Java-Apps nimmer in der neuen VM laufen.


    Ja, das stimmt natürlich. Aber ein JVM Update wäre wohl nicht wirklich schwierig durchzusetzen gewesen. Bei C# funktionierts ja auch.

    Zitat von hal


    Du hast dir deine Frage selber beantwortet. Java ist eine dynamische Programmiersprache. Dass der Syntax C++ so ähnlich sieht sollte einen da nicht in die Irre führen.
    Vermutlich war die Entscheidung, die Dynamik von Java so zu verstecken eine, die das Marketing gemacht hat, und nicht die Sprachdesigner.


    Hm. Die Dynamik ist in der Tat sehr versteckt. Nach klassischer Definition halte ich Java für keine dynamische Sprache. Jedenfalls nicht in der Liga von Smalltalk. Java ist viel zu stark typisiert für eine echte dynamische Sprache. Auch noch viele andere Dinge werden statisch überprüft (ob es bestimmte Methoden gibt, welche Argumente die übernehmen usw.).

    Zitat von hal

    Du hast offensichtlich noch nie eine C++-Compilerfehlermeldung gesehen :)


    Leider viel zu viele :) Vor allem im Zusammenspiel mit Boost tut jede einzelne Template-Fehlermeldung körperlich und geistig weh.

    Zitat von Lord Binary

    Vollste Zustimmung.
    Frage: Ist diese schwache Pseudo-Generizität besser als gar keine ???
    (Bin mir da nicht sicher)


    Es ist definitiv schon mal eine Verbesserung, weil damit zumindest der Typecast beim Rausholen eines Elements aus einer Collection auf der Seite des Programmierers wegfällt.

    Besser wäre es aber gewesen, die JVM zu updaten und damit echte, typsichere Generizität zu erlauben. Bei C# gibt es daher den Sprung von 1.1 auf 2.0.

    Aber was ich mich überhaupt frage: Warum hat man nicht Generizität gleich von Anfang an in den beiden Sprachen berücksichtigt? Es war sowieso klar, dass die früher oder später kommen muss (alle ernsthaften statischen OO Sprachen hatten davor schon Generizität (C++ und Eiffel fallen mir ein), dynamische brauchen es ja nicht). Man hätte es ja nicht gleich aktivieren müssen, aber zumindest im Code-Layout vorsehen, dass es das mal geben wird.

    EDIT: Einen Punkt hab ich noch vergessen: Bessere Lesbarkeit.

    Zitat von hal

    Naja, das passiert, wenn ein paar Tunnelblick-C++-Programmierer daherkommen und glauben, dass man in jeder Sprache Generizität haben muss, weil das in C++ ja auch absolut notwendig ist.


    Aber es ist auch tatsächlich notwendig. Hauptsächlich für die Implementierung homogener Collections (Listen, Arrays, ...). Object stattdessen zu verwenden ist dann ein Problem, wenn du aus der jeweiligen Collection wieder was rausnehmen willst, weil du dann zwingend einen Cast brauchst und der ist in Java nicht typsicher (man kann schließlich alles in eine Collection stecken, das von Object erbt).

    In C++ hat man das "Problem", dass es keine oberste Klasse in der Vererbungshierarchie gibt (ein void* wäre so was, aber auch nur für Zeiger "Person* p", nicht für z.b. "Person p"). Daher _kann_ man Generizität überhaupt nur so erreichen, wie es gemacht wurde.

    Und die Generizität in 1.5 ist einfach nur krank, schwach und nicht typsicher. Nur damit sie die VM nicht ändern mussten, ist eine List<Person> dasselbe wie eine List<Auto>, weil die Übersetzung homogen ist (Übersetzung in die Klasse List, die statt dem generischen Parameter einfach "Object" einsetzt).

    Zitat von jimbeam

    Mir kommt aber vor das wir in der Schule auch mit JDK1.4.2 programmiert haben! Und da hat es funktioniert!


    Es gab für die älteren Java-Versionen verschiedene generische Erweiterungen. Aber die sind nun alle obsolet.

    Die Fehler sind "in Ordnung", da du versucht hast, ein KDE-Programm ohne laufendes X zu starten (bzw. weiß dein Textlogin nix vom X-Display).

    Du kannst von der Textoberfläche mal versuchen, mit

    Code
    X -configure :1


    noch ein X zu starten, das dir hoffentlich zumindest mal eine funktionierende Konfiguration ausspuckt. Beenden kannst du dieses neue Display mit Strg+Alt+Backspace. Wenn das klappt, kopier die erzeugte Datei (steht dort, wie die heißt) über die alte Konfiguration (ich hab keine Ahnung, welche Pfade/Versionen SuSE verwendet).

    Gar nix. Die Zeile ist so sonnenklar, dass ein Kommentar sich wie eine Verarschung des Codereaders liest. Es ist einfach ein Klassikerbeispiel, wie Kommentare NICHT aussehen sollen. Kommentare sollten dort stehen, wo etwas nicht offensichtlich ist. "Weise der Variable i den Wert 1 zu" für "i = 1;" wäre ein anderes Beispiel.

    Der zweite Teil ist einfacher zu beantworten:

    Code
    read -p "Bitte Taste druecken..."


    als letzte Zeile in dein Script geben.

    Der erste Teil lässt sich auch irgendwie machen, ich komm aber grad nicht drauf, wie... es geht jedenfalls manuell auch, in der .desktop Datei muss der Exec-Eintrag "konsole -e dein_script" sein...

    Zitat

    bound to 128.131.200.94 -- renewal in 695 seconds.


    Das würde schon mal in die Richtung von 10 Minuten kommen...

    Du kannst evt. auch mal einen anderen DHCP Client ausprobieren - pump fällt mir da ein.

    Ich habe noch keinen Weg gesehen, wie man das mit ssh machen könnte. Wäre interessant, ob das überhaupt geht (glaub eher nicht).

    Graphisch gibt es für KDE "krdc", das auch eine bestehende X-Session übernehmen kann (dazu muss auf dem lokalen zu übernehmenden X ein krdc-Server laufen, der die Autorisierung vornimmt). Und das funktioniert tatsächlich ziemlich gut (sogar über Modem wars erstaunlich flott).

    Die einzige Einschränkung sollte AFAIR sein, dass man NFS-Mounts nicht erneut über NFS freigeben kann. Deine Methode könnte also funktionieren.

    "Permission denied" deutet eher darauf hin, dass auf PC B in der /etc/exports PC C nicht richtig eingetragen ist? Zeig mal die Datei.

    Ich nehme an, eine Firewall verhindert, dass du gleich von PC A aus auf PC C mountest?

    Was spricht eigentlich dagegen, zwischen PC B und PC C auch Samba zu verwenden?