Umsteigen nach C++ oder lieber c#?

Shade Of Mine

Real schrieb:

So? Wo habe ich das gesagt?! Ich habe gesagt, dass ich strikt dagegen bin, dass man Java als erste Programmiersprache lehrt! Assembler von Anfang an, ist natürlich für den Anfänger auch zu schwierig. Lieber mit C anfangen und später zu C++ wechseln und dann vielleicht noch Java lernen.

*lol*

Du weisst schon, dass C auch hin und wieder als Makro Assembler bezeichnet wird?

C als erste Sprache ist eine Katastrophe. Denn C ist eine Sprache für Profis - du hast alle Freiheiten, kannst machen was du willst, der Compiler meckert nicht viel.

Das ist natürlich schlecht, wenn du nicht weisst was du tust. Was bei Anfängern ja durchaus mal vorkommen kann.

C++ ist eine extrem komplexe Sprache. Am Anfang verwendet man C++ sowieso nicht anders als Java: denn man wird keine höheren Features einsetzen.

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.

Ist natürlich geil für einen Anfänger wenn die Programme einfach so abschmieren - da sind Exception natürlich besser.

Der Anfänger schon und genau darum ging es hier.

Nein, auch ein Anfänger hat diese 'Zeit' nicht. Er hat zwar die 'Zeit' aber es macht keinen Sinn.

Ich zB habe QSort noch nie implementiert. Ich denke aber trotzdem, dass ich weiss, wie es funktioniert.

Ich würde einem Anfänger lieber erstmal BubbleSort und dann vielleicht ein schnelleres, wie zB ShellSort oder so zu implementieren geben. Das reicht eigentlich. Man kann nicht alles selber implementieren - man muss nur verstehen.

Und wie schon öfters erwähnt: nur weil die Sprache etwas anbietet, muss man es ja nicht gleich verwenden. zB bietet C auch ein QSort.

Java ist eine sehr komplexe und überfüllte Sprache.

Überfüllt??
Gerade Java ist ne schlanke Sprache - C++ Programmierer sagen hier auch des öfteren 'verkrüppelt'. Da ist definitiv kein Bloat drinnen.

Ich lerne gerade autodikatatisch (den Unterricht in der Schule kann man vergessen) aus einem über 800 seitigen Java-Buch.

Ah, du lernst gerade - aber kannst uns schon etwas über die Sprache erzählen was wir noch nicht wissen

Super, es wird erklärt, dass einfache Datentypen wie int in einer Collection nicht unterstützt werden, darum muss man Integer nehmen. Warum, das weiss ich natürlich nicht, hab mich im Internet informiert und nichts logisch erklärbares gefunden warum das so ist und warum ausgerechnet einfache Datentypen wie int nicht unterstützt werden.

Dann ist dein Buch schlecht.
Die Erklärung ist nämlich recht simpel:
Aber Gregor hat mir die Antwort schon weggenommen
[quote]
Ich würde gerne einen Überblick haben, was bei Java (als Anfänger) nicht sehr leicht ist.
[quote]
Dann hast du dir noch nicht C oder C++ angesehen.
Java ist nämlich recht schlank und auch recht simpel. Zumindest als Anfänger. Natürlich kann Java auch kompliziertere Sachen - aber welcher Anfänger braucht schon Reflexion & Co?

Raucher beklagen sich über die so hohen Zigarettensteuer, aber wer zwingt sie zum Rauchen, was ausserdem dumm ist?! Verstehst du was ich meine?!

Nein. Der Vergleich hinkt.
Nikotin ist ein Suchtgift. Du fängst einmal an und dann hat es dich. Aufhören ist nur schwer möglich.

Wenn ich rechnen lerne, dann lerne ich es mit Stift und Papier und rechne nicht alles mit einem TR.

Wenn man nicht die Disziplin hat das so durchzuziehen sondern immer wieder zum TR greift - dann wird man nie gut rechnen können. Disziplin gehört halt zum programmieren dazu.

Für Fortgeschrittene und Profis ist es allemal spitze!

Und Anfänger verwenden diese 'Features' einfach nicht.

Mit welcher Sprache sollte man denn Anfangen? Es gibt doch für nahezu alle Sprachen irgendwelche Bibliotheken die diese grundlegenden Dinge bereitstellen. Wenn ich faul bin und nichts lernen will, kann ich auch ohne viel Ahnung von C zu haben dort ne Linked List implementieren. Warum? Weil ich Copy&Paste beherrsche...

Und ob ich diese Linked List per Copy&Paste in mein Programm einbaue, oder per #include <list> oder sie selber schreibe ändert das Resultat nicht. Nämlich das Resultat: ich habe eine Linked List.

Der Unterschied ist lediglich der: nur bei Punkt 3 habe ich wirklich etwas dabei gelernt.

Aber wenn ich nicht lernen _will_ - dann kann man mich auch nicht dazu zwingen.

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

@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?

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!).

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.

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.

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.

Hey Leute,

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