Umsteigen nach C++ oder lieber c#?

[Gregor]

Shade Of Mine schrieb:

Allerdings bietet Java hier den Vorteil, dass es 'Fehlertoleranter' ist.
zB wenn du über die Grenzen eines Arrays schreibt wirft Java ne Exception, ein C++ Programm schmiert ab.

Also ich würde das eher als "Intoleranter gegenüber Fehlern" bezeichnen.

Shade Of Mine schrieb:

Aber Gregor hat mir die Antwort schon weggenommen

Ätsch! :p :p :p

Shade Of Mine schrieb:

Natürlich kann Java auch kompliziertere Sachen - aber welcher Anfänger braucht schon Reflexion & Co?

1. Ich. ...und natürlich bin ich noch Anfänger. Ich habe ja noch nichtmal ein vernünftiges Programm fertiggestellt.

2. Eigentlich sind Reflection & Co garnicht so kompliziert. Das einzige, was ich momentan an Java kompliziert finde, sind die Möglichkeiten, die sich jetzt mit den Generics ergeben. Ich komme da momentan noch nicht so ganz mit der Denkweise zurecht, so dass ich teilweise nur mehr oder weniger auf "gut Glück" programmiere. Zum Beispiel bin ich mir momentan nicht sicher, ob ich das Aussehen einer von der folgenden abstrakten Klassen abgeleiteten nicht-generischen Klasse durch die Generics wirklich so genau festgelegt habe, wie ich es wollte:

package math;

public abstract class FieldElement<Element extends FieldElement<Element,F>, F extends Field<Element>>
{
   public abstract Element getAdditiveInverseElement();
   public abstract Element getMultiplicativeInverseElement();
   public abstract Element sumWith(final Element element);
   public abstract Element multiplyWith(final Element element);
   public abstract F getField();

   public final Element getAdditiveNeutralElement()
   {
      return getField().getAdditiveNeutralElement();
   }

   public final Element getMultiplicativeNeutralElement()
   {
      return getField().getMultiplicativeNeutralElement();
   }
}

Kann mir einer von euch sagen, ob das "eindeutig genug" ist? Eine davon abgeleitete Klasse "KonkretesKörperElement" soll genau so aussehen:

public class KonkretesKörperElement extends FieldElement<KonkretesKörperElement,KonkreterKörper>
{
   //...
}

und KonkreterKörper:

public class KonkreterKörper extends Field<KonkretesKörperElement>
{
   //...
}

...ok, ich sehe ein, dass ich gerade abschweife.

[Real]

Hi,

Optimizer schrieb:

Das wird sich mit Java 1.5 zum Glück (wenigstens scheinbar) ändern. Die schlechte Performance dieser Vorgehensweise bleibt.
Echt schade, da hat man echt eine Riesenchance verpasst. Es lebe C#! :p

Kannst du bitte genauer erläutern, was du damit meinst?

Wird für Real aber auch zu komplex sein.

Du Clown.

[Gregor]

Real schrieb:

Hi,

Optimizer schrieb:

Das wird sich mit Java 1.5 zum Glück (wenigstens scheinbar) ändern. Die schlechte Performance dieser Vorgehensweise bleibt.
Echt schade, da hat man echt eine Riesenchance verpasst. Es lebe C#! :p

Kannst du bitte genauer erläutern, was du damit meinst?

Ab Java 1.5 gibt es das sogenannte "Autoboxing/Autounboxing". Damit wird implizit dafür gesorgt, dass ein primitiver Typ in einen Wrappertyp verpackt wird und andersherum, wenn dies erforlderlich ist.

Wenn du bisher folgenden Code hattest:

int i = 456;
Integer integer = new Integer(i);

Dann kannst du das ab Java 1.5 auch so schreiben:

int i = 456;
Integer integer = i;

Ich bin nicht wirklich von diesem Feature begeistert, weil hierdurch Dinge implizit gemacht werden, die besser explizit geblieben wären. Wenn ein Schritt viel Zeit kostet, dann soll dieser Schritt im Code IMHO durchaus etwas unangenehmer sein. Ich sehe nicht, dass das bischen Codeersparnis das wert ist.

[Real]

Hi Shade of Mine,
gut, kann sein, dass Java gegenüber C++ schlank wirkt, aber was ist dann C?
Gerade weil C so extrem schlank ist, halte ich es für sehr angebracht es als erstes zu lernen.
Mein Gott, die typischen Fehler wie z.B. BufferOverflow merkt man doch schnell.
Ich habe auch mal gezielt ein BufferOverflow in einen Array gemacht und ich fand das auch irgendwie cool!
Bevor ich in der Schule Java gelernt habe, habe ich mich einige Monate vorher etwas mit C++ beschäftigt. Ich kam dann auch bis zu dem Gebiet Zeiger.
Egal, was ich in C/C++ implementiert habe, es war doppelt so einfach wie in Java!

1. Schnell implementiert, wegen kurze Befehle!
2. Es ist unglaublich logisch!
3. Bin ich motivierter es zu lernen, da mir mehr Freiheiten offen stehen (nenn mich von mir aus Masochist) und ich mehr Möglichkeiten habe (z.B. hardwarenah programmieren )

Jojo

Das war´s meinerseits.

Mich würde interessieren, warum du eher C++ preferierst (denk ich jetzt mal) als Java.

Liebe Grüße
Real

[Gast]

@Gregor:
Ich finde es nicht gerade sehr sinnvoll, eine generische Klasse beim Ableiten in ihrer Generizität einzuschränken.
Geht das überhaupt gut?

Außerdem ist mir nicht klar, warum du zwischen verschiedenen Elementen unterscheidest. Ein Körper wird doch dadurch definiert, dass die Menge der Elemente (beliebige Elemente!) über zwei Operationen bestimmte Voraussetzungen erfüllen. Die Elemente selber könnten jedoch auch Mitglieder eines ganz billigen Gruppoiden sein. Dort gibt es halt dann kein multiplikativ inverses Element, aber das ist doch Sache der Struktur und nicht der Elemente.
Genauso wie die Rechenoperationen eigentlich Sache der Struktur sind und nicht der Elemente -> ich würde add und mult nicht in die Elementklasse tun.
Ist natürlich dann schwierig für konkrete Elemente und Rechenoperationen verschiedene Operationen anzubieten und wahrscheinlich geht es gar nicht anders als wie du es grad machst. Aber es ist schon spät und ich wollte einfach nur unkontrolliert rumkritisieren.

@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt, sondern es wird für alle primitiven Typen ein eigener Native Code zur Laufzeit erstellt. Dadurch fällt das ständige einpacken und auspacken weg, was wirklich hardcore ineffizient ist.
Außerdem werden die Generics nicht so realisiert, dass man z.B. einen Container von Object-Elementen hat, wo nur der Compiler automatisch 932478657 Typecasts hinsetzt. Gut, ich kann jetzt keinen Typfehler mehr machen. Aber die dadurch eigentlich unnötigen Typecasts stehen trotzdem im Bytecode, weil die VM sonst kreischt.

[Gregor]

Optimizer schrieb:

@Gregor:
Ich finde es nicht gerade sehr sinnvoll, eine generische Klasse beim Ableiten in ihrer Generizität einzuschränken.
Geht das überhaupt gut?

Natürlich ist das sinnvoll und natürlich geht das gut. Das zeigt doch dieses Beispiel! Noch Fragen?

Optimizer schrieb:

Außerdem ist mir nicht klar, warum du zwischen verschiedenen Elementen unterscheidest. Ein Körper wird doch dadurch definiert, dass die Menge der Elemente (beliebige Elemente!) über zwei Operationen bestimmte Voraussetzungen erfüllen.

Es geht darum, dass der Körper bezüglich dieser beiden Operationen abgeschlossen ist. Ich möchte nicht, dass es möglich ist, eine Klasse von meiner abstrakten Körperklasse bzw. der Körperelementklasse abzuleiten, die die Abgeschlossenheit bezüglich dieser beiden Operationen verletzt.

[Gregor]

Optimizer schrieb:

@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt

Oh, sind die Generics bei C# inzwischen schon da? Habe ich da etwas verpaßt?

[Gast]

Gregor schrieb:

Optimizer schrieb:

@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt

Oh, sind die Generics bei C# inzwischen schon da? Habe ich da etwas verpaßt?

In einem Jahr. Sind sie bei Java schon aus dem Beta-Status raus? Hab ich was verpasst?

[Real]

Hi,

Optimizer schrieb:

@Real: In C# werden primitive Typen bei der Benutzung von Generics nicht verpackt, sondern es wird für alle primitiven Typen ein eigener Native Code zur Laufzeit erstellt. Dadurch fällt das ständige einpacken und auspacken weg, was wirklich hardcore ineffizient ist.

ist das ein- und auspacken ineffizient oder dadurch dass es wegfällt?
Ich denke du meinst eher das Erstere. Aber dadurch dass C# Native-Code erzeugt, wird es doch nicht mehr plattformunanhängig sein, oder (Was C# ja imho nicht ist)?

Liebe Grüße
Real

[Gregor]

Optimizer schrieb:

Sind sie bei Java schon aus dem Beta-Status raus? Hab ich was verpasst?

Momentan ist die Beta-2 Version aktuell. Endgültig kommt Java 1.5 wohl im September heraus (BTW: Java 1.6 soll schon ziemlich bald danach folgen, ich rechne mit einer Java 1.6 Beta noch in diesem Jahr, spätestens aber relativ früh im nächsten Jahr). Die aktuelle Beta-2-Version von Java 1.5 ist aber sehr gut nutzbar. Ich hatte damit noch keinerlei Stabilitätsprobleme und ich hatte bei dieser Version auch noch keine Probleme mit Bugs, dabei habe ich bei mir schon einige tausend Codezeilen, die massiven Gebrauch von den neuen Sprachmitteln machen (Naja, bis auf static Imports. Die scheinen aus meiner Sicht vollkommen uninteressant zu sein!).

[Gast]

Real schrieb:

Hi,
ist das ein- und auspacken ineffizient oder dadurch dass es wegfällt?
Ich denke du meinst eher das Erstere. Aber dadurch dass C# Native-Code erzeugt, wird es doch nicht mehr plattformunanhängig sein, oder (Was C# ja imho nicht ist)?

Natürlich das erstere.
Der C# Compiler erzeugt keinen Native Code. Ich habe ja extra geschrieben, dass zur Laufzeit ein eigener Native Code Pfad für jeden benutzten primtiven Typen erzeugt wird (so, jetzt noch ausführlicher ). Das JIT-Prinzip ist in Java und C# gleich. "Plattformunabhängig" ist bei C# natürlich relativ, aber nicht wegen der Generics.

@Gregor: Java 1.6? Was wird das bieten? Hoffentlich eine direkte Unterstützung der Generics von der VM.
Das mit einem Jahr ist übrigens sehr pessimistisch geschätzt, ich denke mal, dass VS Whidbey Anfang 2005 rauskommt.

[Gast]

static imports rocken doch! Mich nervt das Math.sqrt() schreiben schon ziemlich. Das könnte auch C++ und C# IMHO gut vertragen.

[Gregor]

Optimizer schrieb:

@Gregor: Java 1.6? Was wird das bieten? Hoffentlich eine direkte Unterstützung der Generics von der VM.

Das halte ich für mehr als unwahrscheinlich. Ich denke, dass es mit Java 1.6 in erster Linie Änderungen in der Standardbibliothek geben wird. Das ist jetzt aber pure Spekulation, eigentlich weiß ich da garnichts drüber.

[Gast]

Naja, ungewiss, was die Zukunft bringt...
Meine Mami hat mich jetzt ins Bett geschickt, cya.

[Helium]

@Real: Du willst ein schlanke Sprache? Dann wirst du BETA lieben. Es gibt enter, do, exit, inner, leave, restart, if then else, for repeat, suspend und die Bezeichner für die Typen. Mehr fällt mir gerade nicht ein. Und mit suspend wirst du als Anfänger nicht viel zu tun haben, da Coroutinen und Concurrency nunmal nichts für Anfänger ist. Du musst nurnoch wissen, wie man Pattern definiert. Perfekt oder?
Trotzdem kannst du dir Konstanten, Funktionen, Klassen, ... bauen:

pi : @(#
   exit 3.14159;
#)

add : (# x, y : @integer;
   enter (x, y)
   exit (x, y)
#)

Point : (# x, y : @integer;
   moveBy : (# byX, byY : @Integer;
      enter (byX, byY)
      do x + byX -> x;
         y + byY -> y;
      exit this(Point)
   #)
   enter (x, y)
   exit (x, y)
#)

Du kannst dir auch 1eigene Konstrollstrukturen, wie neue schleifen, ... schreiben.

[MA]

Hey Leute,

also ich kann nur zu COBOL raten! Ist echt ne supi Sprache. Wer ein bisschen Englisch kann, kann auch COBOL!