Beiträge von sauzachn

Ich habe schon immer gewusst, dass man in Java gar nicht OO schreiben sollte, einfacher C-Code sieht viel schöner aus. Garniert noch mit SWING-JTables. Würg.

Also wegen Templates kriegst du sicher keine Laufzeitfehler (Exceptions), weil es die zur Laufzeit nicht mehr gibt (wird alles statisch aufgelöst). D.h. dein Problem reduziert sich auf ein Pointerproblem.

Die übliche Nomenklatur: Generizität nennt man das allgemeine Konzept; Templates nennt man die Implementierung in C++. Wobei es in Java z.b. auch Generics heißt, so klar kann man das nicht trennen. Aber Templates wird jedenfalls nur für C++-Generizität benutzt.

Je nachdem brauchst du also ein generelles Buch über Programmiersprachen oder ein C++-Buch. Die Themen werden in zahlreichen Foren und Webseiten besprochen. Google ist dein Freund. Vielleicht möchtest du ja auch näher darauf eingehen, was du wissen willst.

Schade, dass es diesmal unter der Woche ist... kann ich nicht wirklich hingehen.

Genau so ist es, ist erst mit ISO C 99 erlaubt.

Kein Problem.

Seien die beiden Klassen A und B, ihre Headerdateien a.h und b.h.

In a.h deklarierst du die andere Klasse mit "class B;". Dann kannst du einen "B* b;" in der Klasse A verwenden.

Umgekehrt gehts genauso: In b.h ein "class A;" und in Klasse B ein "A* a;".

Das funktioniert, weil der Compiler gar nicht wissen will, wie A und B konkret aussehen. Es reicht ihm, dass er ja immer weiß, wie groß ein Zeiger ist.

> Es gibt genuegend Garbage Collectoren fuer C/C++, und GC macht
> eine C++ Implementierung nicht non-conforming.

Natürlich gibt es verschiedene Ansätze für GC in C++, aber nicht im ISO-Standard. Also: C++ (das C++, das durch ISO definiert wird) besitzt keine GC. Ist ja nicht so schwer zu verstehen, oder? Und volatile_void hat ja schon Gründe genannt, warum GC in C++ prinzipiell nicht so "sauber" sein kann wie in anderen Sprachen.

> So kann man das nicht sagen. Erstens gibt es mal keinen
> ISO-Standard, also koennen wir uns nur an die
> Referenz-Implementierung einer einzigen Firma, und ein paar mehr
> oder weniger obskure Papers halten.

Dass Java nicht standardisiert ist, ist ein Problem für sich. Die Referenzimplementierung, die gleichzeitig (derzeit) die Definition der Sprache ist, enthält aber GC.

"The Java virtual machine assumes no particular type of automatic storage management system" -> Ich interpretiere das so, dass das "automatic" sicher benötigt wird, aber du dir den Typ aussuchen kannst (Mark and sweep, ... ). Also hat laut diesem Paper jede Java-Runtime GC zu haben.

> Nicht nur primitive Datentypen, sondern auch Packages,
> Klassen, Operatoren, null, loops, Blöcke oder Methoden
> haben in Java eine Sonder rolle bekommen, so dass sie
> entweder nicht wie gewöhnliche Objekte behandelt, oder
> zumindest von der Syntax speziell berücksichtigt werden
> müssen.

Ah, ok, darauf möchtest du hinaus.

Da musst du aber schon sehen, dass es zwei große Familien von OO Sprachen gibt: Die dynamischen (Smalltalk-ähnlichen) und die statischen (C++/Java/C#/Eiffel/...). Man kann jetzt ewig drüber diskutieren, welche davon besser ist. Aber eine Sprache ist nicht weniger OO, nur weil sie statisch ist und abseits von Objekten und Nachrichten auch andere Konzepte bietet.

> Eine weitere Folge sind die unkonventionellen APIs, die
> aus der uneinheitlichen Syntax entstehen. Dinge
> Math.abs(-5) oder Collections.sort(list) zeugen nicht
> gerade von gutem Design.

Das hat aber nur mit API-Design zu tun und nicht mit grundlegenden Eigenschaften von Java. Es spricht ja nichts dagegen, list.sort(); zu ermöglichen. Schwieriger wird es bei Konstanten, etwa wie in (-5).abs(); das in Java so ohne weiteres nicht möglich ist. Sollte aber zumindest über new Integer(-5).abs(); o.ä. erreichbar sein.

> Instanzvariablen können öffentlich sein, und wenn man
> ordentliche Kapselung implementieren will, muss man
> einen Haufen Get- und Setmethoden schreiben, auch wenn
> man sie zunächst überhaupt nicht benötigen würde.

Es gibt auch statische Sprachen, wo es so ist, dass man auf öffentliche Variablen nur lesend zugreifen kann. Eiffel z.b.

@Blog:
1. Die Anzahl der Keywords ist nicht wirklich ein geeignetes Mittel zur Bestimmung der Komplexität einer Sprache.
2. Dein Schleifenbeispiel kann man auch in nicht-dynamischen Sprachen durch spezielle Syntax ermöglichen (die Nachricht in Ruby muss auch irgendwie speziell implementiert sein, damit man damit eine Schleife darstellen kann), die Zeile "number += 25.percent_of number" schaut mit "number += 0.25*number;" auch nicht viel anders aus.
3. Variablen-Mitglieder einer Klasse sollten sowieso niemals öffentlich sein, da dadurch die Invarianten der Klasse von einem Client nicht beachtet werden müssen (z.b. dass x keine negativen Werte annehmen darf oder so was). Ich stimme aber zu, dass Setter/Getter-Methoden eine Krücke sind.
btw: Der physikalische Overhead im Vergleich zum restlichen Programm dürfte eher vernachlässigbar sein.
4. "Point = Struct.new(:x,:y,:color)" Zumindest in C++ kann man so etwas mit einem Präprozessor-Macro erreichen - wenn man wirklich will.

Zitat von Spockman

Mit dem Zusatz ist die Behauptung ja sogar faktisch falsch, da Garbage Collection nicht mal mehr noch Jahre vor der Entstehung von C++ eine "Neuerung" darstellte.

C/C++: hat keine Garbage Collection.
Java: hat Garbage Collection.

Java ist eine Nachfolgesprache von C/C++ -> Garbage Collection ist eine wichtige Neuerung in Java _gegenüber_ C++.

Ich verstehe deinen Einwand einfach nicht.

Natürlich gibt es GC schon sehr lange, aber eben nicht in C++, und nur auf diese Sprache habe ich mich in meiner Aussage bezogen.

Zitat von Lord Binary

Die höchste Ebene dieser Schwachsinnigkeit kommt aber erst: Es ist völlig irrelevant

Aber z.b. nicht bei GUI-Anwendungen. Jedem graphischen Java-Programm, das ich bisher in die Finger bekommen habe, hat man sofort angesehen, dass es ein Java-Programm ist. Schon einfachste Aktionen laggen wie Sau.

Zitat von Lord Binary

Die Existenz eines langsamen/eher schlechten GUI Frameworks heisst IMHO nicht, daß Java generell ungeignet für GUI Anwendungen ist.

Zustimmung von mir.

Übrigens: Wenn ich sage, "Java ist langsamer als C++", dann meine ich: "Die gebräuchlichen Java-Development-Systeme sind langsamer als die gebräuchlichen C++-Development-Systeme" (wo du DS durch Kombinationen von Compiler/Interpreter ersetzen kannst). Und das stimmt zweifellos immer noch (icc, msvc, g++, ...).

Zitat von Spockman

Garbage collection ist eine Selbstverstaendlichkeit fuer jede high-level Sprache seit den 60ern. Sie als "sehr wichtige Neuerung" zu bezeichnen ist entweder an Ignoranz oder Humor schwer zu ueberbieten.

Wenn du schon von Ignoranz sprichst, das "gegenüber C++" hast du überlesen, stimmts?

Zitat von mdk

und weil wir gerade dabei sind:

Code

.DATA
HelloWorld db "Hello world.$"
.CODE
Start: lea dx, HelloWorld
mov ah, 09h
int 21h
xor al, al
mov ah, 4Ch
int 21h
END Start

Funktioniert das außerhalb von DOS noch? So was habe ich schon lange nicht mehr gesehen

Zitat von a9bejo

Java ist leider nicht gerade ein Musterbeispiel fuer eine Objektorientierte Programmiersprache, weshalb diese Dinge oft nicht so offensichtlich sind wie sie es eigentlich sein sollten.

Ach, das passt schon. Reflection ist halt eine eigene Sache. Dadurch, dass Klassen auch nur Instanzen einer "Metaklasse" sind, hat Java eine Idee von Smalltalk übernommen.

Java ist sogar ein sehr gutes Beispiel für eine OO Sprache.

Leider hat es die Syntax und einige "dumme" Features von C++ übernommen (genauso wie C#), dafür andere sinnvolle nicht. Viele Möglichkeiten für große Verbesserungen wurden einfach übersehen (z.b. kann man ohne weiteres aus den primitiven Typen Klassen machen, ohne Performanceverlust; Eiffel zeigt, wie's geht). Generizität hätte auch vom Anfang an drin sein sollen. Leider ist es unsauber und typunsicher implementiert, damit man die JVM nicht updaten musste.

Aber schon allein Garbage Collection ist eine sehr wichtige Neuerung gegenüber C++. Im Allgemeinen ist der Performanceverlust dadurch nur 10% gegenüber manueller Speicherverwaltung. Das ist locker verschmerzbar, weil man dadurch viele Bugs einfach nicht einbauen kann.

Schade, dass (trotz allen Gegenbekundungen) Java immer noch für Programme mit User Interfaces saulangsam ist und Swing so eine Krücke (in jeder Hinsicht) ist. Beides merkt man sofort, sobald man ein Java Programm vor sich hat. Ersteres sogar schon beim Starten

Ich glaub mich zu erinnern, dass das dangling-else-Problem sogar das einzige shift-reduce-Problem ist, warum man C nicht so ohne weiteres mit LR(1) (also z.b. dem yacc) parsen kann.

Wollt nur noch hinzufügen: Es gibt auch Sprachen (z.B. perl), wo die Blockklammern _immer_ geschrieben werden müssen.

In Eiffel gibt es übrigens von den "and" und "or" zwei Varianten:
a and b linke und rechte Seite wird immer ausgewertet
a and then b wie in C++ lazy
a or b wieder alles ausgewertet
a or else b wie in C++ lazy

Diese explizite Schreibweise gefällt mir etwas besser:
if a /= Void and then a.value = 3 then .... end
als in C++:
if(a && a->value == 3) ...

Zitat von RolandU

Apropos Ubuntu: Bin ein Freund von KDE..... Funktioniert das Kubuntu mittlerweile schon brauchbar - die ersten Versionen (also vom letzten Jahr) waren einfach Ubuntu mit einem KDE draufgeschmissen, was aber irgendwie nicht gut zusammengepasst hat - viele Tools haben nicht funktioniert.

Ich verwende es am Notebook und am Arbeits-PC und konnte keine größeren Probleme beobachten als mit allen anderen Distributionen auch...

Was meinst du mit Grafik - normale Dialoge und Fenster? Dazu kannst du einen Layout Manager verwenden, der das dann je nach Auflösung und Fenstergröße ausrichtet.

Die Auflösung des Bildschirms für ein User-Programm zu ändern, ist in 99.9% der Fälle der falsche Weg.

Mit Google (hast du eigentlich gesucht?) hätte ich da mal auf Anhieb für C++ so was gefunden: http://www.codeproject.com/tips/resswitch.asp
http://www.experts-exchange.com/Programming/Pr…Q_20805745.html

Wird sich in C# wohl auch ähnlich machen lassen, den ChangeDisplaySettings Call zu erreichen.

Wer hat das bitte geschrieben? Hoffentlich kein Prof. Das ist nach wie vor voll von Fehlern.

Z.B. Ausgabe heißt oben immer noch "i", unten dann "u"; "u = -1" sollte heißen "u := -1".

Naja, dann füg halt mal ein.
Vorbedingungen: a >= 0, n >= 0, b >= 0
Nachbedingung: u >= -1
Und dann Zeile für Zeile durchbeweisen.

Die ersten ganz einfach mit der Statementregel:
{P} u := -1 {P'}
{P'} y := x+y {P''}
{P''}......
...... {Q}

Die Schleifeninvariante ist auch gegeben (muss man normal mühsam finden). Einfach mit der Schleifenregel schauen, obs passt.

Für If-Verzweigungen gibt es auch eine eigene Regel.

Kannst du die Angabe so abschreiben, dass man alle Symbole hat? Außerdem ist die Ausgabe nicht "i", sondern "u". Hast du vielleicht sonst noch Fehler gemacht? Soll das unter dem Code eine Schleifeninvariante sein? Formatierung in einer CODE-Umgebung würde der Lesbarkeit auch nicht schaden.

Zitat von Spockman

Default-Initializer in C++ ist 0 (des entsprechenden Typs)

Wie meinst du das?