# Nachteile von Java



## ttt@web.de (21. Mai 2008)

Hallo,

bin neu in der Java-Welt und muss sagen ist schon irgendwie ein Durcheinander, im Gegensatz zu MS. Viele schimpfen über MS, wie ich finde absolut zu unrecht. Habe mir ein bißchen was zu Java durchgelesen und mir sind folgende Nachteile aufgefallen (vor allem im Gegensatz zu C#).

- int, double... sind Primitive Typen, keine Referenztypen
- Keine Operatorüberladung möglich, String + String dennoch überladen
- Keine Exception bei Überlauf von primitiven Datentypen
- Java akzeptiert keine numerischen Werte als Wahrheitswerte
- Kein Datentyp für int32, int64, int128
- Division durch Null bei Ganzzahlen liefert ArithmeticException, besser wäre wie bei .Net DividedByZeroException
- Division durch Null bei Gleitkommazahlen liefert 0.0 keine Exception
- Modulorechnung, der erste Operand (Divident) bestimmt immer das Vorzeichen des Restes. Bei Division durch 0 gibt es entweder eine    
  ArithmeticException oder eine 0.0. Ein Test ob eine Zahl gerade ist mit: value % 2 == 1 funktioniert nur bei positiven Zahlen.
- Bessere Implementierung für das Switch Case in C#, da das break zwingend erforderlich ist.
- break und continue unterstützten Sprungmarken, wie beim goto
- Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept
- Keine Unterstützung von Standardwerten in Parametern
- final verhindert nicht, dass Objekte geändert werden dürfen (kein const wie in C++)

Gebt ihr mir Recht, oder nicht?

Bei OO bin ich noch nicht angelangt, aber ich bin mal gespannt was mich da für Schreckliches erwartet.
LG Isaak


----------



## lhein (21. Mai 2008)

- Java akzeptiert keine numerischen Werte als Wahrheitswerte

--> ja und? Nenne mir einen echten Nachteil? Sowas macht den C - Code imho nur schwerer zu durchschauen.

- Bessere Implementierung für das Switch Case in C#, da das break zwingend erforderlich ist.

--> und was ist, wenn mehrere Cases die selben Konsequenzen haben?


```
switch (Zeichen)
{
   case 'A':
   case 'B':
   case 'C':   tuDiesUndDas
                   break;
   case 'D':   tuWasAnderes
                   break;
   ...
}
```

Ich sehe hier nur einen Vorteil, keinen Nachteil.


- break und continue unterstützten Sprungmarken, wie beim goto

--> das geht in Java auch


- Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept

--> Klassen werden gross geschrieben, Variablennamen klein...wo ist das Problem?

- final verhindert nicht, dass Objekte geändert werden dürfen (kein const wie in C++)

--> versuche mal einen final static String CONSTANT_STRING = "bla"; im Nachhinein zu verändern. Was Du sicherlich meinst sind Objekte wie ArrayList oder ähnliches. Klar, hier kannst Du das Objekt nicht verändern, wohl aber dessen Inhalt.

Gebt ihr mir Recht, oder nicht?

--> nur teilweise


lhe


----------



## Saxony (21. Mai 2008)

Is schon komisch, wieso Programmiersprachen manchmal Nachteile haben!

Am besten du entwickelst da mal deine eigene Sprache, welche dann nur noch Vorteile hat! Damit dürfte sich dann dein Problem auch schon erledigt haben.

bye Saxony


----------



## maki (21. Mai 2008)

> [- Keine Operatorüberladung möglich, String + String dennoch überladen
> ..
> - Java akzeptiert keine numerischen Werte als Wahrheitswerte
> ..
> - Keine Unterstützung von Standardwerten in Parametern


Das sind VORTEILE, keine Nachteile 



> - Kein Datentyp für int32, int64, int128


Dafür gibt es long und BigInteger.



> Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept


Doch doch, das Konzept ist sehr durchgängig(sogar besser als bei M$), out ist keine Klasse  

Zu deinen anderen Punkten:
Das meiste ist reine Definitionssachen, keine "Nachteile", liegt daran dass du vorbelastet bist.
Natürlich gibt es die einen oder anderen Dinge die nicht so schön sind, aber damit kann ich sehr gut leben, dazu gehört zB. das es primitive Datentypen gibt.


----------



## foobar (21. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> - int, double... sind Primitive Typen, keine Referenztypen


Es gibt seit Java 1.5 Wrappertypen



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Keine Operatorüberladung möglich, String + String dennoch überladen


Es gibt wenige Fälle in denen sowas Sinn machen würde z.b. BigDecimal. Hoffentlich kommt das in Java 1.7



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Java akzeptiert keine numerischen Werte als Wahrheitswerte


Das ist stringent



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - break und continue unterstützten Sprungmarken, wie beim goto


Das muß man ja nicht benutzen. Ich bin auch kein großer Freund davon.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept


out ist keine Klasse sondern ein statischer Member der Klasse System. Java ist in dieser Hinnsicht sehrwohl durchgängig was man von C++ nicht behaupten kann. Dort werden in manchen APIs die Methoden mit einem Groß und in einer anderen wieder mit einem Kleinbuchstaben begonnen. In Java gibts Styleguides an die sich alle halten. Zumindest was solche Basics angeht.


----------



## ARadauer (21. Mai 2008)

Es kommt immer drauf an, wie man es gewohnt ist. Gewisse Dinge die man immer benutzt, empfindet man vielleicht in einer fremden Sprache als Nachteil, wenn sie nicht da sind. Warum brauch ich unbedingt operatoren überladung? 
p1+p2 oder Punkt.add(p1,p2), tja... stört mich nicht....


----------



## Templon (21. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> - int, double... sind Primitive Typen, keine Referenztypen


Aus Performance gründen so, und auch gut so. Kannst ja die Wrapper Klassen verwenden.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Keine Operatorüberladung möglich, String + String dennoch überladen


Das Operatoren überladen fehlt mir persönlich auch. Aber ich verstehe schon warum das es es nicht gibt in Java. Darüber gab es schon unmängen an Diskusionen.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Keine Exception bei Überlauf von primitiven Datentypen


Warum sollte hier eine Exception nötig sein? Integer.MAX + 1 wird einfach Integer.MIN



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Java akzeptiert keine numerischen Werte als Wahrheitswerte


Empfinde ich als Vorteil



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Kein Datentyp für int32, int64, int128


dafür gibt es long.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Division durch Null bei Ganzzahlen liefert ArithmeticException, besser wäre wie bei .Net DividedByZeroException


Keine eigene Exception nötig. Hast du dir schonmal die Message von der Exception angeschaut? Sieht etwa so aus "/ by zero".



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Division durch Null bei Gleitkommazahlen liefert 0.0 keine Exception


Liefert nicht 0. Sondern Infinity.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Modulorechnung, der erste Operand (Divident) bestimmt immer das Vorzeichen des Restes. Bei Division durch 0 gibt es entweder eine
> ArithmeticException oder eine 0.0. Ein Test ob eine Zahl gerade ist mit: value % 2 == 1 funktioniert nur bei positiven Zahlen.


Lies mal den Modulo Operator durch, der funktioniert überall so -> kein Argument gegen Java



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Bessere Implementierung für das Switch Case in C#, da das break zwingend erforderlich ist.


Ist in C# das break notwendig das es kein kompilier Fehler gibt?



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - break und continue unterstützten Sprungmarken, wie beim goto


Ja das stimmt.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept


out ist ein static final Member von der System Klasse



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Keine Unterstützung von Standardwerten in Parametern


Jedem das seine.



			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - final verhindert nicht, dass Objekte geändert werden dürfen (kein const wie in C++)


Const fehlt mir persönlich nicht, wieder jedem das seine.


----------



## SlaterB (21. Mai 2008)

foobar hat gesagt.:
			
		

> IsaakTaylor@web.de hat gesagt.:
> 
> 
> 
> ...





> public final class Integer [..]
> Since:
> JDK1.0




------------



> out ist ein static final Member von der System Klasse


dann müsste es OUT heißten,
ist aber nicht final


----------



## maki (21. Mai 2008)

> Warum brauch ich unbedingt operatoren überladung?


Um Entwickler zu verwirren sind Operatorüberladungen sehr sehr gut geeignet, deswegen gibt es die auch nicht


----------



## Templon (21. Mai 2008)

SlaterB hat gesagt.:
			
		

> > out ist ein static final Member von der System Klasse
> 
> 
> dann müsste es OUT heißten,
> ist aber nicht final




```
public final static PrintStream out = nullPrintStream();
```


----------



## ttt@web.de (21. Mai 2008)

Zunächst einmal hab ich recht viel mit C# gemacht und vergleich eben gerne Java mit C#. 

Numerischen Werte
Finde eher beim switch case es schwer zu durchschauen wenn man in den Fällen "durchfällt". Bei nicht-unterstützen von numerischen Werten ist in Java ein zusätzlicher Cast notwendig. Aber das ist wohl Ansichtssache. Gebe da maki Recht!!!

Break und Continue
Dass eben diese Sprungmarken noch unterstützt werden finde ich nicht gut. Muss sie zwar nicht benutzten, aber...

@final
Eben, das const in C++ verhindert wirklich eine Änderung des Objekts (auch mit SetMethoden)!

@Operatorüberladung
Finde es fehlt wirklich, op-überladung ist je nach anwendungsgebiet schon nützlich.

@standardwerte bei parameter
sehe da keinen vortiel, dass es das nicht gibt

@referenztypen, primitive typen, int32, int64, int128
Also wenn java schon ne oo-sprache ist, dann hätte man auch die einfachen typen oo machen können. .net unterstützt zusätzlich für double, int... int32, int64, int128 das selbe für long. da ist man einfach flexibler. 
Auch das anhängen eines l bzw. eines f an eine zahl finde ich nicht schön, zumal das bei double wieder nicht notwendig ist.

@Exceptions
dass mit der division durch 0 ist auch nicht so toll gelöst, oder beim überlauf. Die ArithmeticException sieht mir sehr allgemein aus. Kann man überhaupt anhand dieser Exception programmiertechnisch auf eine / 0 schließen? Bei M$ sagt der Name sofort wo das Problem liegt.

@switch
Wie oft ist ein "Durchfallen" notwendig. Meistens ist das nicht zwingende break eine Fehlerquelle. Genau deswegen ist es in .net pflicht.

Ach ja, hab mir noch etwas SWT angeschaut. Diese "Gott-Klasse" SWT die alle möglichen Konstanten anbietet... Als Anfänger kommt man da ohne API nicht aus, ständig muss man nachsehen wo man welche Konstanten einsetzen darf. Oder das | in den Parametern, auch nicht sehr schön. Separate Enums wären da viel viel schöner gewesen.


----------



## maki (21. Mai 2008)

> @final
> Eben, das const in C++ verhindert wirklich eine Änderung des Objekts (auch mit SetMethoden)!


Gut, da muss ich dir zustiimmen.



> @Operatorüberladung
> Finde es fehlt wirklich, op-überladung ist je nach anwendungsgebiet schon nützlich.


Sehe ich anders, Operatorüberladungen richten mehr schaden an als sie gutes tun, oft ein problem in C++ (welche Methode von welcher Klasse wird genau aufgerufen?? Polymorphie und casten halten da ihre Überraschungen bereit.)


----------



## SlaterB (21. Mai 2008)

Templon hat gesagt.:
			
		

> ```
> public final static PrintStream out = nullPrintStream();
> ```


tatsächlich, obwohl es setOut() gibt,

dann sollte das aber doch OUT geschrieben werden oder?
naja, nativer Spezialfall..


----------



## Marco13 (21. Mai 2008)

Einige Nachteile von C# gegenüber Java:

- Für jede Variable muss ein Objekt erstellt werden, weil es keine primitiven Typen unterstützt
- Operatoren können beliebig überladen werden, und man sieht bei "a+b" nie, was dort gemacht wird
- Bei elementaren Dingen (wie z.B. einem Variablenüberlauf) werden schon Exceptions geworfen
- Numerische Werte sind manchmal numerisch, manchmal boolean - sehr verwirrend
- Unnötige, grausam benannte Datentypen wie int32, int64 oder int128
- Division durch Null wirft irgendwelche Exceptions
- Bei switch/case muss immer das break hingeschreiben werden, auch wenn man das nicht will

EDIT: Für mich persönlich einer der wichtigsten Punkte:

- C# stammt von einer Firma, die in verschiedenen wichtigen Kernbereichen unseres Lebens schon die Grenze zwischen "Marktführerschaft" und "Monopol" überschritten hat, und drauf und dran ist, das auch in anderen Bereichen zu tun, deren Chef in den letzten 20 Jahren in jeder Stunde um 1 Million $ reicher geworden ist, und die (im Gegensatz zu Sun) vermutlich NIE die Quellen für ihre Compiler und VM offen legen wird.


----------



## lhein (21. Mai 2008)

SWT ist nicht mit Java ansich gleichzusetzen. Die SWT Api ist leider Gottes etwas gewöhnungsbedürftig. Aber das liegt vor allem daran, dass es ein IBM Projekt war und nicht von Sun kommt.
Gleiches kannst Du auch bei der MQSeries API von IBM nachvollziehen, die mit einer gleichwertigen Klasse MQC aufwartet...das ist irgendwie der gewisse IBM Stil


----------



## AlArenal (21. Mai 2008)

Lass mich mal raten, du hast zuvor nie ernsthaft was anderes als C# gemacht, oder? Deine Kritikpunkte und zugehörigen Argumentationen sind reine Umstellungsschwierigkeiten, weil mal mehr oder minder andere Konzepte und Denkweisen hinter den Systemen stecken.
Wäre Java genau dasselbe wie C#, wäre MS ganz schön in den Arsch gekniffen gewesen 

Wenn alles überall gleich wäre, gäbe es nicht soviele Sprachen und APIs. Wärst du vom Background her etwas breiter aufgestellt, hättest du die Erfahrung schon früher gemacht.

Das liest sich alles irgendwie wie: "Ich kann bei meinem Golf den Wischintervall selbst einstellen. Weil du das nicht kannst ist dein Porsche langsamer." ;-)


----------



## ttt@web.de (21. Mai 2008)

Marco13 hat gesagt.:
			
		

> Einige Nachteile von C# gegenüber Java:
> 
> - Für jede Variable muss ein Objekt erstellt werden, weil es keine primitiven Typen unterstützt
> *und, wen stören die paar bytes mehr? Finde es einfach sauberer in einer OO Sprache auch wirklich überall OO zu verwenden*
> ...



@AlArenal
Hab in modernen Sprachen nur die .NET Welt kennen gelernt, das ist richtig (C#, VB.NET, APS.NET 2.0) und ab und zu etwas PHP. Sonst nur hardwarenahe Geschichten mit C, Assembler aber nicht sooo viel. Nun bin ich in ner neuen Firma, muss Java lernen. Hab mich aber *freiwillig * dazu entschlossen meinen Horizont zu erweitern und mal von MS etwas Abstand zu gewinnen.


----------



## ms (21. Mai 2008)

Jetzt ist es definitiv ein Flamewar.

@Isaak
Was erwartest du, wenn du diese Argumente hier postest?
Viele hier (mich eingeschlossen) kennen C# zuwenig, als dass man hier wirklich argumentieren kann.
Genauso ist es bei dir, du kennst Java offensichtlich zu wenig um wirklich behaupten zu können, dass einige Punkte echte Nachteile sind.
Hinter jede Entscheidung die bei Java (und wahrscheinlich auch bei C#) getroffen wurde steckt ein Grundgedanke, warum dies so gemacht wurde. Jedes Sprachkonstrukt ist nicht einfach passiert sondern wurde lange überlegt, abgewogen und entschieden. Wenn man dem zugrunde geht wird vielleicht einiges klarer.
Und wie schon oben erwähnt sind viele Punkte einfach nur ungewohnt und im Grunde vernachlässigbar.

ms


----------



## ARadauer (21. Mai 2008)

horizont erweitern ist ein gutes thema. ich denk wir als java programmierer sollten uns nicht angegriffen fühlen, nur weil jemand nachteile in java findet.
es gibt auch noch andere sprachen wo gewisse dinge besser gelöst sind.
und ganz ehrlich wenn ich mir mal die massen an webframeworks ansehe und den aufwand den man betreiben muss um eine webanwendung zu konfigurieren, deployen usw.. dann wünsch ich mir auch mal eine große firma über dem ganzen die mal auf den tisch haut und eine einheitliche richtung vorgibt....

es hat alles seine vor und nachteile


----------



## foobar (21. Mai 2008)

SlaterB hat gesagt.:
			
		

> foobar hat gesagt.:
> 
> 
> 
> ...



Oops, ich meinte damit natürlich das Autoboxing.


----------



## ttt@web.de (21. Mai 2008)

@ms
Nein, ist es nicht! Wir bleiben hier doch alle sachlich und freundlich  

Du hast echt absolut recht, mir sind die Dinge einfach beim Lesen aufgefallen und ich wollte die mal hier posten. Meistens ist es wirklich Ansichtssache buw. Gewohnheit. Für mich wäre das Topic also hiermit abgeschlossen. Werde in Zukunft hier die ein oder andere Frage (auch bestimmt mal dumme Fragen) posten. Hoffe ihr werdet mir helfe.

LG Isaak


----------



## Templon (21. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> @Exceptions
> dass mit der division durch 0 ist auch nicht so toll gelöst, oder beim überlauf. Die ArithmeticException sieht mir sehr allgemein aus. Kann man überhaupt anhand dieser Exception programmiertechnisch auf eine / 0 schließen? Bei M$ sagt der Name sofort wo das Problem liegt.



Das sagt mir der Compiler. Wo liegt das Problem? 

```
Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Test.main(Test.java:8)
```

Und was soll an dem overflow von primitiven nicht schön sein?


----------



## Marco13 (21. Mai 2008)

@IsaakTaylor@web.de / ms: Diese "invertierte" Auflistung der genannten Punkte sollte lediglich eine subtile Andeutung sein, dass vieles davon Ansichtssache ist...


----------



## ttt@web.de (21. Mai 2008)

Marco13 hat gesagt.:
			
		

> @IsaakTaylor@web.de / ms: Diese "invertierte" Auflistung der genannten Punkte sollte lediglich eine subtile Andeutung sein, dass vieles davon Ansichtssache ist...



schon klar...
danke an alle


----------



## tfa (21. Mai 2008)

ARadauer hat gesagt.:
			
		

> und ganz ehrlich wenn ich mir mal die massen an webframeworks ansehe und den aufwand den man betreiben muss um eine webanwendung zu konfigurieren, deployen usw.. dann wünsch ich mir auch mal eine große firma über dem ganzen die mal auf den tisch haut und eine einheitliche richtung vorgibt....


Ich finde die Vielfalt an Frameworks, Plattformen, Bibliotheken usw. (gerade in der Java-Welt) richtig gut. Man kann den Leuten ja nicht verbieten, eigene (neue) Richtungen einzuschlagen, um es besser zu machen als eine große Firma. Sonst müssten wir uns z.B. heute noch ausschließlich mit EJBs < 3.0 herumärgern. Und das kann doch keiner wollen.
Auswahl ist wichtig, auch wenn es lästig sein mag, die verschiedenen Möglichkeiten erst zu evaluieren. 



> es hat alles seine vor und nachteile


Eben.


----------



## e9926044 (21. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> Hallo,
> 
> bin neu in der Java-Welt und muss sagen ist schon irgendwie ein Durcheinander, im Gegensatz zu MS. Viele schimpfen über MS, wie ich finde absolut zu unrecht. Habe mir ein bißchen was zu Java durchgelesen und mir sind folgende Nachteile aufgefallen (vor allem im Gegensatz zu C#).




Das ist ja ganz lustig, nur weil du ei bisschen was von Java gelesen hast, kommst du auf die Kritikpunkte,
ich bin gerade beim Einlesen in C# schon ziemlich weit, würde mich aber noch immer nicht trauen, ein Urteil abzugeben, man muss meiner meinung nach mind ein 1/2 jahr damit gearbeitet haben um die vorteile und nachteile herauszufinden,

Aber eines kann ich schon sagen, das zwingende break in der switch- Anweisung stört mich sehr, das ist für mich nicht verständlich, das man das so implementiert,


----------



## Gelöschtes Mitglied 6946 (21. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> - Keine Unterstützung von Standardwerten in Parametern


Meinst du sowas wie public asd(String hui = "1", String pfui = "2") ? Das gäbe doch Überschneidungen mit dem Überladen von Methoden, denn wenn es noch public asd(String hui) gäbe und man jetzt asd("blah"); aufruft, dann weiß die VM doch nicht mehr, welche der beiden Methoden sie aufrufen soll... Mit der Überladung der Methoden kann man diese Standardwerte ja auch selber machen (auch wenn es bei vielen Parametern, die alle einzeln weglassbar sein sollen, eine Menge an Methoden werden).


----------



## Beni (21. Mai 2008)

Uh, ich will auch noch ein bisschen Senf in die Wurst drücken:


			
				IsaakTaylor@web.de hat gesagt.:
			
		

> - Kein Datentyp für int32, int64, int128


int32 = int
int64 = long
int128 = BigInteger
int512 = BigInteger

:bae:

[Edit: Achja, ein Nachteil von C#: man schreibt Methoden gross. (Ist das flamewartauglich? Will hier das Niveau nicht zusehr heben  ) ]


----------



## Templon (21. Mai 2008)

Also ein Flamewar ist es meiner Meinung nicht. Es wurde immer sachlich geantwortet. Ich finde solche Threads ziemlich Spannend. Bin ich niveaulos?


----------



## AlArenal (21. Mai 2008)

e9926044 hat gesagt.:
			
		

> Aber eines kann ich schon sagen, das zwingende break in der switch- Anweisung stört mich sehr, das ist für mich nicht verständlich, das man das so implementiert,



Ich wiederum halte es für sauberer und empfinde es als guten Stil (nicht nur) in Java immer mit break zu arbeiten. Für mich ist das ein Automatismus und daher ist es unerheblich ob es zwingend ist oder nicht. Sinnvoll ist es in jedem Fall, denn ein vergessenes break hat schon so manch einem, gerade in den Anfängen, den Nerv geraubt.

Allerdings, wenn wir schon gerade bei Stilfragen sind... : 
Wenn man sich schon entscheidet beim Sprachdesign ein break zwingend vorauszusetzen, wäre es nur vernünftig beim Erreichen des nächsten case von Seiten des Compiler aus gleich ein implizites break zu machen. Dann wiederum könnte man das Schreiben des break wieder optional machen, mit dem Hinweis, dass in der Sprache eben implizit ein break vorm case gemacht wird und nicht wie in allen mir sonst bekannten Sprachen ein Fall-Through stattfindet.
Würde einem unnötigen Code und damit Zeit und Codezeilen sparen und die Lesbarkeit erhöhen, denn so wie es in C# implementiert ist, ist das break im switch ja mal sowas von redundant...


----------



## ms (21. Mai 2008)

Templon hat gesagt.:
			
		

> Also ein Flamewar ist es meiner Meinung nicht. Es wurde immer sachlich geantwortet. Ich finde solche Threads ziemlich Spannend. Bin ich niveaulos?


Es wurde niemand beleidigt, das stimmt.
Aber ob das hier wirklich sachlich ist?



> EDIT: Für mich persönlich einer der wichtigsten Punkte:
> 
> - C# stammt von einer Firma, die in verschiedenen wichtigen Kernbereichen unseres Lebens schon die Grenze zwischen "Marktführerschaft" und "Monopol" überschritten hat, und drauf und dran ist, das auch in anderen Bereichen zu tun, deren Chef in den letzten 20 Jahren in jeder Stunde um 1 Million $ reicher geworden ist, und die (im Gegensatz zu Sun) vermutlich NIE die Quellen für ihre Compiler und VM offen legen wird.
> 
> *Und? MS hat das beste Office Produkt, sehr gute OS, die Server sind mitlerweile auch recht gut, viele weitere gute, nützilche Anwendungen. Keine andere Firma hat so ein breites Spektrum. Bin auch nicht mit allem einverstanden was MS macht so ist es nicht. Aber ich sehe kein anderes vergleichbares Unternehmen. *



ms


----------



## tfa (21. Mai 2008)

AlArenal hat gesagt.:
			
		

> Ich wiederum halte es für sauberer und empfinde es als guten Stil (nicht nur) in Java immer mit break zu arbeiten. Für mich ist das ein Automatismus und daher ist es unerheblich ob es zwingend ist oder nicht. Sinnvoll ist es in jedem Fall, denn ein vergessenes break hat schon so manch einem, gerade in den Anfängen, den Nerv geraubt.



Das Problem ist meiner Meinung  nach, dass man sich beim Entwurf von Java bzw. C# zu sehr auf die alte C/C++ Syntax festgelegt hat. Hier wäre eine Chance für Verbesserungen gewesen. Zum Beispiel hätte man nach jedem Case einen Block { } vorschreiben können wie bei try-catch, und für den Wertebereich eine Komma-separierte Liste.



> Wenn man sich schon entscheidet beim Sprachdesign ein break zwingend vorauszusetzen, wäre es nur vernünftig beim Erreichen des nächsten case von Seiten des Compiler aus gleich ein implizites break zu machen.


Seh ich genauso. Wenn bei C# das break schon Pflicht ist, wieso muss man es dann noch hinschreiben? Wahrscheinlich um die alten C++ Leute nicht zu verwirren...

_[Edit by Beni: code durch quote-Block ersetzt]_


----------



## ARadauer (21. Mai 2008)

> Das Problem ist meiner Meinung nach, dass man sich beim Entwurf von Java bzw. C# zu sehr auf die alte C/C++ Syntax festgelegt hat.


was ich widerum als vorteil empfinde, da sich einfach die masse der programmierer die c oder c++ beherschen, leicher tun wenn sie umsteigen.

ich denk java wär jetzt nicht so erfolgreich, wenn sie eine komplett neue syntax entworfen hätten....


----------



## thE_29 (21. Mai 2008)

> - int, double... sind Primitive Typen, keine Referenztypen


TJo, ist ja mit Java 1.5 egal



> - Keine Operatorüberladung möglich, String + String dennoch überladen


Ok, da ich von C/C++ komme, nervt mich das auch extremst! Vorallem da die String Implementierung anscheinend im Compiler fest eingebaut ist, den im Source is nix zu finden



> - Keine Exception bei Überlauf von primitiven Datentypen


Tjo, das könnte man mit Punkt 1 gleichsetzen!



> - Java akzeptiert keine numerischen Werte als Wahrheitswerte


Jo, das vermisse ich eigentlich auch, aber ob jetzt if(METHOD()) oder if(METHOD() != 0) steht, ist ja nicht so schlimm..



> - final verhindert nicht, dass Objekte geändert werden dürfen (kein const wie in C++)


Jo, das kann man entweder per reflection oder man ändert den Typ nach der Kompilezeit ab! So ein Verhalten kann man aber immer haben, wenn man kein einzelnes Compiliertes Objekt erhält, sondern mehrere von einander Abhängige!



> - Keine Unterstützung von Standardwerten in Parametern


Jo, das nervt mich auch, konnte man in C auch schon.



> - Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein durchgängiges Konzept


Naja, stimmt doch 



> - Bessere Implementierung für das Switch Case in C#, da das break zwingend erforderlich ist.


Was besser oder schlechter ist, liegt immer im Auge des Betrachters ;-)


Auf den Rest wurde auch schon eingegangen!


Meiner Meinung nach hat C# da schon Vorteile, die aber nicht gravierend sind. Dadurch das es später als Java erschienen ist, hat es einfach von allem (meiner Meinung nach) die Vorteile zusammen.

default Parameter und Operatorenüberladung wären für mich schon sehr interressant. Aber wenn es das auch nicht gibt, kann man auch nix machen.
Operatorenüberladung hätte ich erst selten gebraucht und die Defaultparameter, kann man ja mit Methodenüberladung umgehen 

Aber ich werde mir in der nahen Zukunft C# noch ein bißchen genauer ansehen und mal wieder drin rumtesten!

Aber, da C# ja nicht von grund aus "Plattformunabhängig" ist, hat da Java schon einen großen Vorteil (wenn man es denn auch braucht/einsetzt).

Desweiteren gibts sowas wie LookAndFeel für C#?


----------



## Marco13 (21. Mai 2008)

@ms: Sachlich fand ich das schon. Es war ja, wie auch deutlichst drüber stand, nur ein _für mich pesönlich_ wichtiger Punkt - anderen ist es vielleicht egal, wenn sie sich selbst einer bösen Firma ausliefern (DAS war jetzt unsachlich :wink: ). Die Gegenargumentation "MS Office ist toll, deswegen verwende ich C#" ist für mich zwar auch nicht nachvollziehbar, aber _darauf_ einzugehen, würde wirklich einen flamewar provozieren ... und das hatte ja (offenbar) auch mit dem, was ich geschrieben hatte, nichts zu tun :roll:


----------



## ms (21. Mai 2008)

Das eine ergibt das andere und so schaukelt es sich auf.
Wie auch immer.
Spätestens wenn Jango da ist, ist hier sowieso die Hölle los.  

ms


----------



## Leroy42 (21. Mai 2008)

_- Keine Operatorüberladung möglich, String + String dennoch überladen _

Operatorüberladung verwirt hauptsächlich nur.
Den +  Operator bei Strings finde ich hilfreich, könnte man aber tatsächlich
als Überladung ansehen; nunja  :roll:  

_- Keine Exception bei Überlauf von primitiven Datentypen _

Könnte ich zustimmen.

_- Java akzeptiert keine numerischen Werte als Wahrheitswerte _

...und das ist auch gut so!  :applaus: 

_- Kein Datentyp für int32, int64, int128 _

Genau!    Und int256, int512, int1024 gibts auch nicht. Und nun?

_- Division durch Null bei Ganzzahlen liefert ArithmeticException, besser wäre wie bei .Net DividedByZeroException _

Ansichtssache. Ich selbst bin da hin- und hergerissen.

_- Division durch Null bei Gleitkommazahlen liefert 0.0 keine Exception _

 :shock: 

_- ...Ein Test ob eine Zahl gerade ist mit: value % 2 == 1 funktioniert nur bei positiven Zahlen. _

 :shock: Eine Zahl ist gerade, wenn value%2 == *0* ist

_- Bessere Implementierung für das Switch Case in C#, da das break zwingend erforderlich ist. _

Ist das so in C#? Gut! Aber dies ist Java nicht vorzuwerfen, da es
die Semantik von C übernommen hat.

_- break und continue unterstützten Sprungmarken, wie beim goto _

Mir egal; ich benutze sowieso *nie* Sprungmarken!   

_- Klassen werden groß geschrieben, nicht aber System.out das out Objekt wird kleingeschrieben, kein 
durchgängiges Konzept _

Und ob das ein durchgängiges Konzept ist; zumindest die Styleguides

_- Keine Unterstützung von Standardwerten in Parametern _

Na, Gott (ähhmm, ich meine die Java-Designer   ) sei Dank!

_- final verhindert nicht, dass Objekte geändert werden dürfen (kein const wie in C++)_

Der einzige Punkt, dem ich mich uneingeschränkt anschließe! Die _const-correctness_ von C++ vermisse ich!


----------



## AlArenal (21. Mai 2008)

ARadauer hat gesagt.:
			
		

> > Das Problem ist meiner Meinung nach, dass man sich beim Entwurf von Java bzw. C# zu sehr auf die alte C/C++ Syntax festgelegt hat.
> 
> 
> was ich widerum als vorteil empfinde, da sich einfach die masse der programmierer die c oder c++ beherschen, leicher tun wenn sie umsteigen.
> ...



Das glaube ich wiederum nicht, weil das Nuancen sind, die eine Sprache nicht grundsätzlich schwerer oder leichter erlenbar machen. Der eigentliche Lernprozess beginnt nicht bei der Syntax von irgendwelchen Basics, sondern bei der API und dem alltäglichen Umgang und der Planung mit den zur Verfügung gestellten Stilmitteln der OOP.

Schau ich mir z.B. Python an, sind die Basics leicht erlernbar, egal wie vorbelastet ich mit PHP und Java sein mag. Aber gerade als Umsteiger hält man sich nicht groß mit den Syntax-Basics auf, sondern will wissen wie man das, was man bisher kannte, the-python-way umsetzt. So gilt das natürlich auch für andere Sprachen.

Ob da dann geschweifte Klammern oder Einrückung verwendet werden, nach dem Schlüsselwort runde Klammern folgen müssen oder nicht, das ist ebenso Schnickschnack wie to-type-a-break-in-a-switch-or-not 

Eher noch mag es was mit Vorbelastung seitens derer zu tun haben, die die Sprache einst entwickelten. Das klingt hier und da in Interviews auch mal durch, wenn man auf alte Designentscheidungen zu sprechen kommt, sowohl was Syntax als auch Aufbau der API angeht.

Manchmal ist es auch einfacher es dem User recht zu machen und eben nicht seine Erwartungshaltung widerspiegelt, sondern sich als Freigeist wirklich um die Lösung von Problemen des Coders kümmert. Da sehe ich Python, um bei dem Beispiel zu bleiben, ein wenig als Apple unter den Programmiersprachen an.

----

Auch wenn es erstmal schwer fällt, muss man das was man kennt erstmal beiseite legen, um sich frei zu machen. Wenn man frei ist, kann man sich viel einfacher auf etwas neues einlassen, als wenn man ständig Opfer der eigenen Gewohnheiten und Erwartungen wird. Dann kann man auch eher erfassen, was da an Konzepten und Gedanken hintersteht und MIT diesen arbeiten, anstatt immer nur dagegen, weil man, um auf den Thread-Starter zu kommen, eher dazu neigt in Java wie in C# zu arbeiten, als nunmal wie in Java.

If you're in Rome, do like the Romans do.


----------



## Templon (21. Mai 2008)

AlArenal hat gesagt.:
			
		

> Auch wenn es erstmal schwer fällt, muss man das was man kennt erstmal beiseite legen, um sich frei zu machen. Wenn man frei ist, kann man sich viel einfacher auf etwas neues einlassen, als wenn man ständig Opfer der eigenen Gewohnheiten und Erwartungen wird. Dann kann man auch eher erfassen, was da an Konzepten und Gedanken hintersteht und MIT diesen arbeiten, anstatt immer nur dagegen, weil man, um auf den Thread-Starter zu kommen, eher dazu neigt in Java wie in C# zu arbeiten, als nunmal wie in Java.



Da gebe ich dir recht. 

PS: Heisst es nicht "When in Rome, do as the Romans do"?


----------



## AlArenal (21. Mai 2008)

Kommt drauf an, ob es eine Frage des Wann oder des Wenn ist


----------



## Wildcard (22. Mai 2008)

Die Diskussion an sich ist IMO ziemlich unnötig, da es um winzige Syntax Details geht, mit denen man im Alltag keine echten Probleme hat.
Aber das:



> Und? MS hat das beste Office Produkt, sehr gute OS, die Server sind mitlerweile auch recht gut, viele weitere gute, nützilche Anwendungen. Keine andere Firma hat so ein breites Spektrum. Bin auch nicht mit allem einverstanden was MS macht so ist es nicht. Aber ich sehe kein anderes vergleichbares Unternehmen.


will ich nicht unkommentiert stehen lassen. OpenOffice.org lässt MS-Office mal locker im Regen stehen.
Und das du kein anderes vergleichbares Unternehmen nennen kannst, ist ein echter Segen, denn kein Unternehmen missbraucht seine Stellung so schamlos wie Microsoft. Die grundlose/böswillige Demontage der ISO ist für mich das jüngste Ereignis einer beispiellosen Unternehmensgeschichte.


----------



## Guest (22. Mai 2008)

Wildcard hat gesagt.:
			
		

> Die Diskussion an sich ist IMO ziemlich unnötig, da es um winzige Syntax Details geht, mit denen man im Alltag keine echten Probleme hat.
> Aber das:
> 
> 
> ...



Seh ich ganz anderst, open office ist bei weitem nicht so gut wie ms office.


----------



## SlaterB (22. Mai 2008)

selbst wenn man inhaltlich alles mögliche zu OpenOffice behaupten kann
bleibt die Tatsache, dass es niemand benutzt, also nicht existent ist,

genau wie beim Betriebssystem Windows vs alles andere,
was nützt es dass Linux besser ist? benutzt trotzdem keiner,
das ist kein normales Betriebssystem, sondern ein exotische Experten-Anwendung, für normale User noch keine Alternative

erst wenn es eine gewisse Verbreitung gibt, kann man überhaupt von einer Konkurrenz sprechen,
bei den Browsern klappts schon recht weit, 
allerdings: wenn man sich da mal den Unterschied zwischen FireFox und dem grottigen IE anschaut und wie mühsam da nur kleine Marktanteilbrocken abgezwackt werden, dann kann man erahnen, welch uneinholbare Macht Excel & Co. (noch) haben


----------



## Wildcard (22. Mai 2008)

Excel ist AFAIK noch etwas besser als Calc, das benutze ich auch nicht, aber ich kann dir versichern, OOo Writer ist das wesentlich mächtigere Werkzeug als MS-Word.
Ausserdem quelloffen und hält sich an internationale Standards, beides ein dickes Plus.


----------



## AlArenal (22. Mai 2008)

SlaterB hat gesagt.:
			
		

> selbst wenn man inhaltlich alles mögliche zu OpenOffice behaupten kann
> bleibt die Tatsache, dass es niemand benutzt, also nicht existent ist,
> 
> genau wie beim Betriebssystem Windows vs alles andere,
> ...



Großartiges Argumentationskino, das du da zeigst. Deiner Meinung nach ist also der "normale User" (was immer das auch ist) alles und alles andere ist "nicht existent".

Mit so fundierten Argumenten kann man auch beweisen, dass die Erde sowohl hohl, als auch eine Scheibe ist und noch dazu von der Sonne umkreist wird.


----------



## Wildcard (22. Mai 2008)

SlaterB hat gesagt.:
			
		

> selbst wenn man inhaltlich alles mögliche zu OpenOffice behaupten kann
> bleibt die Tatsache, dass es niemand benutzt, also nicht existent ist,



http://wiki.services.openoffice.org/wiki/Market_Share_Analysis
Wenn du recht hättest, wären wir nicht mitten im Office Krieg und Microsoft hätte keinen Grund gehabt etliche Standardisierungsgremien zu bestechen und sabotieren.

[EDIT]
Gerade auf Heise gelesen:
Soviel dazu das OOo unwichtig wäre :roll:
http://www.heise.de/newsticker/Micr...rstuetzen-Update--/meldung/108277/from/atom10


> genau wie beim Betriebssystem Windows vs alles andere,
> was nützt es dass Linux besser ist? benutzt trotzdem keiner,
> das ist kein normales Betriebssystem, sondern ein exotische Experten-Anwendung, für normale User noch keine Alternative



Ich habe meiner Freundin (keine PC-Expertin) Linux installiert. Seitdem hat sie weder Viren, noch Anwendungsprobleme, keine Arbeit mehr mit dem System und ist so zufrieden damit, das sie es jetzt auch auf dem Desktop anstatt Windows haben möchte.
Das gleiche berichtete mir ein Arbeitskollege von seiner Freundin.
Wenn meine Mutter das nächste mal ihre Windows zerstört, bekommt sie Linux drauf und dann ist Ruhe.
Also erzähl mir nichts  :roll:


----------



## Guest (23. Mai 2008)

Schade, ich dachte schon wir kämen tatsächlich um einen größeren Flamewar herum...
Mit dem Thema hat das alles aber sowieso nix zu tun, jetzt sind wir schon beim Vergleich von Betriebssystemen, wie war nochmal das Thema? Ach ja, "Nachteile von Java" und ist es nicht gerade der Vorteil dass das Betriebssystem bei java egal ist? Somit würde ich sagen sind wir sogar doppelt off-topic  :wink:


----------



## Siassei (23. Mai 2008)

Servus,

@Offtopic! 





			
				Leroy42 hat gesagt.:
			
		

> AlArenal hat gesagt.:
> 
> 
> 
> ...



Ich müsste mich jetzt sehr täuschen, aber hat MicroSchrott (schöne Bezeichnung   ) nicht Mac(OS) übernohmen/aufgekauft?  :### 

@Topic
Zurück zum Topic. Java und C# -> Äpfel und Birnen
C# hat denn Vorteil, dass es nach Java erschienen ist und einige Nachteile von Java beseitigt wurden. Zudem besitzt C# einige nützliche Vorteile die Java nicht hat.
z.B. ref und out bei Parameter, internal Zugriffsbeschränkung, partial Klassen, Methodensteuerungen (den genauen Begriff kenne ich jetzt nicht), Implizite und Explizite Operatorüberladung, Präproduzer (praktisch zum erstellen von Lib mit versch. Performance z.B. für Debug, Core (internal) oder offene (Public) Lib (siehe Mono-Projekt))...
C# besitzt im Verlgeich zu Java auch einige Nachteile
z.B. unsafe (Zeigeroperationen wieder möglich), kleine Library -> etwas ähnliches wie EJB steht erst ab C#4.0 zur Verfügung, kein >>> :!: , wenige O/R-Mapper und ApplikationsServer

Was zähle ich hier lange auf, einfach mal rein lesen und 2-3 Projekte mit C# abwickeln. Dann seht ihr schon

Aber vielleicht kommen diese noch und in 1-2 Jahren wird Sun sowieso Java ein neues Gewand verpassen (Version: 2.0). Warum? Für mich nur logisch, da
- Sun zur Zeit mit Jogl versucht den 3D Nachteil aufzuhollen (in C# werden mittels WPF die Win.Forms abgelöst und diese mittels der GraKa dargestellt. Zudem besitzten sie bereits ein Data-Kozept, ähnlich wie in JSF)
- AJAX ist schön und gut. Doch für einige Aufgaben benötigt man immer noch eine andere Technologie ala Applet, Flashplayer, ... Sun kann bei einem Redesign die Fehler bei den Applets ausmerzen.
- endgültiges Entfernen von Altlasten möglich wird
- ...

So und jetzt habe ich wohl eine kleine Lawine losgetretten  :wink: Beachtet bitte, dass diese Aufzählung nur meine PERSÖNLICHE Meinung darstellt und auf KEINERLEI Fakten beruht. Achja vielleicht noch eines. Was mir persönlich an Java gefällt ist die große Bibliothek von SE und EE. Zudem bietet Sun und auch einige andere zusätzliche und sinnvolle Bibliotheken an und hier kann keine andere Sprache Java das Wasser reichen. Das geht sogar so weit, dass in C# seit einiger Zeit von dieser Bibliotheke sogar abgeschrieben wird. Ein Beispiel dazu findet ihr unter CodeProject: UnixScript (laden und Kommentar lesen) oder seht euch mal die BigInteger - Umsetzung im MonoProject an.

MfG,
  Thomas

Kommentar-Auszug (ersten beiden Zeilen) aus UnixCrypt.

```
/// This class is a port from Java source. I do not understand the underlying algorithms, I just converted it to C# and it works.
    /// Because I do not understand the underlying algorithms I cannot give most of the variables useful names. I have no clue what their
```


----------



## Guest (24. Mai 2008)

Marco13 hat gesagt.:
			
		

> - Operatoren können beliebig überladen werden, und man sieht bei "a+b" nie, was dort gemacht wird


Pseudo-Argument. Der Programmierer ist halt dafür verantwortlich, die Operatoren sinnvoll zu überladen. Es ist ja auch nicht die Schuld der Programmiersprache, wenn Du eine Methode "setzeName" so implementierst, dass darin etwas passiert, was mit dem Setzen eines Namens nicht das geringste zu tun hat.



			
				Siassei hat gesagt.:
			
		

> kein >>> :!:


Wer unsigned Arithmetik braucht, verwendet einfach unsigned Datentypen. Der >>> Operator in Java ist nur deswegen notwendig, weil es keine unsigned Datentypen gibt.

Fred


----------



## AlArenal (24. Mai 2008)

Anonymous hat gesagt.:
			
		

> Marco13 hat gesagt.:
> 
> 
> 
> ...



Wenn #setzeName keinen Namen setzt, ist der Coder eben scheiße, denn der Name suggeriert nunmal, dass die Methode den Namen setzt. Aber ein mathematischer Operator ist für nichtmathematische Operationen nunmal alles andere als "sprechend". Was passiert ,wenn ich zwei Instanzen der Klasse Person mit einem "+" addiere? Kommt dann eien Intanz der Klasse Gruppe zurück, die die beiden Personen enthält? 

Solche Fragen sollte man sich nicht stellen müssen. Wer gerne Operatoren überlädt, sollte Perl-Coder werden. Die Jungs gehen voll darin auf in kryptischen Zeichenkombinationen Funktionalitäten zu verpacken, die sie 5 Minuten später selbst nicht mehr entziffern können, geschweige denn dokumentieren.


----------



## Marco13 (25. Mai 2008)

Operatorenüberladung finde ich an sich nicht schlecht. Allerdings sollte das ganze nicht so "beliebige" möglich sein, wie z.B. bei C++. Etwas anderes wäre es, wenn irgendwie "erzwungen" werden würde, dass die Operatoren eine bestimmte Semantik haben. *rumspinn* ... sowas wie Interfaces "Monoid", "Group" oder "Field", bei denen dann die passenden Operatoren automatisch erkannt werden (nicht so ernst nehmen, ist nicht durchdacht, sondern sollte nur verdeutlichen, was ich mit dem "Verhindern der Beliebigkeit" meinte....)


----------



## ttt@web.de (28. Mai 2008)

Was mir auffällt, entweder fangen die Java-Gurus mit einer Grundsatzdiskusstion an (beispielsweise: Operatorüberladung ist an sich schlecht) oder es wird auf Microsoft geschossen (da Feindbild).

Aber was man hier kaum hört/sieht ist dass die Leute direkt gegen C# bzw. Net Argumente haben.

PS: das mit den "Destruktoren" ist in Java nicht wirklich toll gelöst, auch zum Thema virtuelle Methoden hab ich schon einiges gelesen, auch Attribute ala Objekt.value = 5; hätte man ja auch endlch mal einbauen können...


----------



## Marco13 (28. Mai 2008)

Was mir auffällt ist, dass es ziemlich albern ist, in einem Java-Forum Nachteile von Java aufzulisten, und dann (anscheindend) noch zu erwarten, bedingungslose Zustimmung zu den (sehr subjektiven, und z.B. im Falle von System.out auch noch nicht nur unbedeutenden, sondern schlicht und einfach _falschen_) genannten Punkten zu ernten. 

Etwas seltsam ist auch, dass man in einem Java-Forum die Nachteile von Java auflistet, und dann erwartet, im Gegenzug Nachteile von C# aufgezählt zu bekommen  ???:L  (Wobei ich das ja gemacht habe :wink: )

Man kann davon ausgehen, dass jede neu entwickelte Sprache, die in direkter (marktstrategischer!!! NICHT "akademischer"!) Konkurrenz zu einer anderen Sprache steht, bestimmten Punkte "anders" macht - insbesondere, wenn diese Punkte als Schwächen der anderen Sprache angesehen werden. Wenn die Punkte, die du aufgelistet hast, die größten "Vorteile" von C# gegenüber Java darstellen, hat man das bei C# offenbar versäumt: Man presst eine neue Sprache in den Markt, bei der es nichts wirklich neues gibt, außer, dass man sich hier und da ein 'break' spart, oder hier und da eine Exception mehr oder weniger behandeln muss - was aber an der "Mächtigkeit" oder dem "Komfort" der Sprache nichts ändert. 

Schön wäre eine systematischere Unterstützung von Generics (sinngemäß: Reifikation statt Type Erasure, und Typeninferenz - Generics wirken bei Java schon recht "aufgesetzt" - und das SIND sie auch), Closures, Unterstützung von Aspektorientierten Aspekten  , XML-Unterstützung auf Sprachebene, ... viele Dinge, die nicht nur klein-klein-Firlefanz wären, sondern eine (potentielle) Bereicherung der Sprache. Aber all das bietet C# (unter dem Vorbehalt, dass du es ja ansonsten aufgezählt hättest) auch nicht .... dafür muss man leider auf Java 7 warten  :wink:


----------



## ttt@web.de (28. Mai 2008)

Marco13 hat gesagt.:
			
		

> Was mir auffällt ist, dass es ziemlich albern ist, in einem Java-Forum Nachteile von Java aufzulisten, und dann (anscheindend) noch zu erwarten, bedingungslose Zustimmung zu den (sehr subjektiven, und z.B. im Falle von System.out auch noch nicht nur unbedeutenden, sondern schlicht und einfach _falschen_) genannten Punkten zu ernten.
> 
> Etwas seltsam ist auch, dass man in einem Java-Forum die Nachteile von Java auflistet, und dann erwartet, im Gegenzug Nachteile von C# aufgezählt zu bekommen  ???:L  (Wobei ich das ja gemacht habe :wink: )
> 
> ...



Wobei in dem Fred MS kritisiert worden ist, von daher ist meine Bemerkung zu C# auch nicht ganz unbegründet. Außerdem hab ich zu Beginn geschrieben dass ich in Java Anfänger bin! Durch diesen Fred hier wollte ich eben ein paar Punkte disktuieren - und auch einiges lernen.

Also für deine letzten beide Absätze hast meine volle Zustimmung. Bin halt noch keine so Guru... wirst mir also noch mal hoffentlich verzeichen können.

LG und schönen Abend


----------



## schalentier (29. Mai 2008)

Marco13 hat gesagt.:
			
		

> Schön wäre eine systematischere Unterstützung von Generics (sinngemäß: Reifikation statt Type Erasure, und Typeninferenz - Generics wirken bei Java schon recht "aufgesetzt" - und das SIND sie auch), Closures, Unterstützung von Aspektorientierten Aspekten  , XML-Unterstützung auf Sprachebene, ... viele Dinge, die nicht nur klein-klein-Firlefanz wären, sondern eine (potentielle) Bereicherung der Sprache. Aber all das bietet C# (unter dem Vorbehalt, dass du es ja ansonsten aufgezählt hättest) auch nicht .... dafür muss man leider auf Java 7 warten  :wink:



Gugg dir ma Groovy an. ;-)

Java (die Sprache) und C# zu vergleichen is sinnfrei (wenn dir die Sprache nicht gefaellt, nimm eine andre die den entsprechenden Bytecode generiert -> Groovy oder VBS). Ein besserer Vergleich waere wohl .NET und Java (die Platform). Ein paar Kriterien, die ich fuer interessant halte:

Weiterentwicklung der Kernsprache (Macht das eine Firma oder eine Community?)
Offene Spezifikationen, um alternative und kompatible Impementierungen zu ermoeglichen? (JavaVM <-> Mono)
Anzahl verfuegbarer konkurierender Frameworks und Libraries (z.B. ORM, ApplicationServer, Algorithmen)
Buildmanagement (ANT vs nmake (oder wie auch immer das bei .NET heisst))
Toolunterstuetzung (IDE, UML, MDA, ...)
...
Leider bin ich in .NET nicht firm genug, um diesen Vergleich anstellen zu koennen... aber interessieren taete es mich 

Noch ne Frage: Gibts in C# wirklich keine primitiven Datentypen? Wie realisiert man dann z.B. grosse (sehr grosse) Arrays (z.B. ein Image)? Schon mal den Effekt zwischen einem new int[5000000] und new Integer[5000000] verglichen?


----------



## SlaterB (29. Mai 2008)

da im Array nur Referenzen stehen wären beide Arrays gleich groß,
Double (4 Byte) sogar kleiner als double (8Byte)


----------



## tfa (29. Mai 2008)

Marco13 hat gesagt.:
			
		

> Schön wäre eine [...] XML-Unterstützung auf Sprachebene, ...


Echt? Da bist du der erste der mir über den Weg läuft und das gut findet. Ich glaube (und hoffe) kaum, dass
soetwas je umgesetzt wird. XML ist wirklich nur dann gut, wenn man es nicht sehen muss -- meine Meinung.
Man sollte eine Sprache auch nicht mit zu Features vollstopfen, die sich gut durch APIs realisieren lassen (oder schon
realisiert sind).

Die anderen angesprochenen Punkte halte ich auch für interessant, wobei ich ARM-Blöcke (auch ein Feature von C# ) noch hinzufügen würde. Am gespanntesten bin ich auf Closures, wobei ich hoffe, dass man sich für eine weniger komplizierte Variante entscheidet. 

Übrigens: eine "Vorhersage", was alles in Java 7 umgesetzt werden könnte, findet man in der Java-Lobby.


----------



## schalentier (29. Mai 2008)

SlaterB hat gesagt.:
			
		

> da im Array nur Referenzen stehen wären beide Arrays gleich groß,
> Double (4 Byte) sogar kleiner als double (8Byte)



Meinetwegen is das Array genauso gross, aber die VM braucht insgesamt deutlich mehr Speicher...


```
public class ArrayTest {
    public static final int COUNT = 10000000;
    public static void main(String[] args) {
        // wait for vm initialization
        int[] intArray0 = new int[COUNT];
        for (int i = 0; i < COUNT; i++) {
            intArray0[i] = i;
        }

        long start = System.currentTimeMillis();
        int[] intArray = new int[COUNT];
        for (int i = 0; i < COUNT; i++) {
            intArray[i] = i;
        }
        System.out.println(System.currentTimeMillis()-start);
        System.out.println((Runtime.getRuntime().totalMemory()- Runtime.getRuntime().freeMemory())/1024/1024+"MB");
        System.out.println("-------");

        start = System.currentTimeMillis();
        Integer[] integerArray = new Integer[COUNT];
        for (int i = 0; i < COUNT; i++) {
            integerArray[i] = i;
        }
        System.out.println(System.currentTimeMillis()-start);
        System.out.println((Runtime.getRuntime().totalMemory()- Runtime.getRuntime().freeMemory())/1024/1024+"MB");
        
    }
}
```

-->


```
44
38MB
-------
1501
191MB
```

Mh... ;-)


----------



## SlaterB (29. Mai 2008)

dann hättest du einfach nur 500000 int vs 500000 Integer vergleichen sollen, mit Array hat das nix zu tun 

falls die Integer aus einem kleinen Wertebereich kommen, kann man übrigens durch Cache noch sparen


----------



## Marco13 (29. Mai 2008)

tfa hat gesagt.:
			
		

> Marco13 hat gesagt.:
> 
> 
> 
> ...



OK, das "schön" bezog sich primär auf den [...] ausgelassenen Punkt. Die XML-Unterstützung wäre nicht notwendigerweise "schön", aber zumindest interessant (auch abhängig davon, wie genau es umgesetzt wäre). 

_ XML ist wirklich nur dann gut, wenn man es nicht sehen muss_

Der Meinung bin ich auch. Trotzdem muss man es ja irgendwie verarbeiten. Es gibt zwar etliche Bibliotheken dafür, aber wenn man XML "per Hand" mit _reinem_ Java (oder auch anderen Sprachen!) parsen und behandeln muss, ist das ziemlich ... krampfig... :?  und langweilig: Die Strukturen und Abläufe, um simple Tags aus dieser Baumstruktur rauszuparsen, sind so eintönig... Trotzdem verstehe ich Bedenken in dieser Richtugn: Es bestünde dadurch die Gefahr, dass Leute "jeden Scheiß" als XML speichern, und dann keine Objektorientierte Programmierung mehr betreiben, sondern XML-Datei-Orientierte  :lol:  :?


----------



## Joker (29. Mai 2008)

> gespanntesten bin ich auf Closures, wobei ich hoffe, dass man sich für eine weniger komplizierte Variante entscheidet.



Ich auch. Wenn man sich an der aus groovy bekannten Syntax orientiert wäre das super.


----------



## ARadauer (29. Mai 2008)

hab da schon mal ein elendslanges dokument über Closures gelesen. aber ich habs nciht verstanden....
kann mir jemand in ein bis zwei sätzen sagen, worums da geht?

hat was mit funktionspointer zu tun. bzw das ich einer variable eine methode zuweisen kann wie in javascript, oder?


----------



## Saxony (29. Mai 2008)

Hiho,

gugg einfach mal bei Wikipedia. Dabei gehts um die Sichtbereiche von Variablen und wie man diese "künstlich" verlängern kann.

bye Saxony


----------



## tfa (29. Mai 2008)

Ein Closure ist eine (anonyme) Funktion, die auf Variablen in ihrem Kontext zugreifen kann.
Anonyme innere Klassen sind recht ähnlich, nur dass hier die Variablen als final deklariert sein müssen.
Hier ein paar Beispiele, wie es vielleicht einmal in Java umgesetzt werden könnte:


```
int summe = { int x, int y => x + y }.invoke(1, 2);
//Ergebnis: summe==3


// Funktionstyp (Funktion in Variable stecken):

{int,int => int} addierer = { int x, int y => x + y };
int summe = addierer.invoke(1,2);
//Ergebnis: summe==3


// Freie Variablen:
int x=1;
{ => int } inx = { => ++x };
System.out.println(inx.invoke());  // -> 2
System.out.println(inx.invoke());  // -> 3
System.out.println(inx.invoke());  // -> 4
```

Wenn man sich jetzt noch vorstellt, dass Funktionen als Rückgabe- und Parametertypen
weitere Closures haben können (Funktionen höherer Ordnung) und man die ganze Sache auch
noch mit Generics garnieren kann, kann einem recht schnell schwindeling werden


----------



## Marco13 (29. Mai 2008)

Ja, aber nicht dieses überlkeitserregende Drehwurm-schwindelig, sondern dieses angenehm bewußtseinserweiternde stoned-schwindelig  :wink:  Ein bißchen plakativ und vereinfacht könnte man sagen, dass ein Closure in diesem Sinne "das gleiche" wie eine anonyme innere Klasse ist ... nur eben ohne eine Klasse   also eine anonyme innere Methode - womit auch sowas wie "Funktionspointer" etwas handlicher umsetzbar würden...


----------



## tfa (29. Mai 2008)

Marco13 hat gesagt.:
			
		

> Ja, aber nicht dieses überlkeitserregende Drehwurm-schwindelig, sondern dieses angenehm bewußtseinserweiternde stoned-schwindelig


Dann brauch ich den LSD-Schnaps endlich nicht mehr   
Aber es wird grob geschätzt eh noch 10 Jahre dauern, bis ich das mal (in Java) produktiv einsetzen kann.


----------



## schalentier (29. Mai 2008)

Man kann das schon jetzt produktiv im Java Umfeld einsetzen... Mit Groovy halt. Der GroovyCompiler erzeugt normalen Java Bytecode und es muss lediglich eine zusaetzliche Library eingebunden werden. Man kann sowohl Groovyklassen sowohl von normalen (bestehenden) Java Klassen ableiten, als auch andersrum. Wenn ich richtig informiert bin, soll Groovy eh zur zweiten "offiziellen" Sprache werden, die auf der JavaPlatform basiert... Druecken wir die Daumen ;-)


----------



## AlArenal (29. Mai 2008)

schalentier hat gesagt.:
			
		

> Wenn ich richtig informiert bin, soll Groovy eh zur zweiten "offiziellen" Sprache werden, die auf der JavaPlatform basiert... Druecken wir die Daumen ;-)



Was ist denn an JRuby und Jython inoffiziell,  wo deren Entwickler doch gar extra von Sun eingestellt wurden? James Strachan, Schöpfer von Groovy, ist dagegen nicht bei Sun. Was soll also an Groovy so "offiziell" sein?


----------



## SlaterB (29. Mai 2008)

vielleicht auf dieser Seite hier erwähnt zu werden:
http://java.sun.com/

allerdings ist dort im Moment Ruby zu finden, Groovy nicht


----------



## Felli (30. Mai 2008)

IsaakTaylor@web.de hat gesagt.:
			
		

> Aber was man hier kaum hört/sieht ist dass die Leute direkt gegen C# bzw. Net Argumente haben.



Da gibt's schon einiges, was man an C#/.NET kritisieren kann.  So leidet C# durch seinen Versuch, Java zu übertrumpfen doch etwas an Featuritis, was auch Fehlerquellen in sich birgt. 

Nehmen wir Strukturen (struct) und Klassen; aus den einen ergeben sich Werttypen, aus den anderen Referenztypen: beide verhalten sich vollkommen unterschiedlich.


```
struct Wert
    {
        private uint x;

        public uint X
        {
            get { return x; }
            set { x = value; }
        }
        public Wert(uint x)
        {
            this.x = x;
        }
    }
```


```
class Program
    {
        static void TueWas(Wert w)
        {
            w.X = 12;
        }
        
        static void Main(string[] args)
        {
            Wert w = new Wert(1);
            TueWas(w);
            Console.WriteLine("Der Wert von X ist {0}", w.X); //gibt 1 aus
            Console.ReadKey();
        }
    }
```

Ist Wert hingegen eine Klasse, so ist die Ausgabe 12 und nicht 1 (das in Java übliche Verhalten).  Auf den ersten Blick lässt sich auch nicht erkennen, ob nun eine Struktur oder Klasse vorliegt (es sei denn die IDE oder API verrät es), was bei mir schon zu einiger Verwirrung führte.


----------



## Yzebär (30. Mai 2008)

Die Diskussion ist doch albern und lächerlich. Kein Unternehmen entscheidet sich für eine Programmiersprache, weil diese weniger Fehler hat, subjektiv logischer aufgebaut ist oder der Sourcecode eleganter aussieht. In welcher Sprache man entwickelt ist eine strategische Entscheidung. Unabhängig davon welche Sprache ausgewählt wurde, werden die Entwickler immer wieder vor großeHerausforderungen gestellt werden, was aber in der bisherigen Diskussion an "Nachteilen" für die eine oder andere Sprache genannt wurde, sind mit Sicherheit keine echten Herausforderungen, das ist eher Kindergarten auf Hochschulniveau!!!


----------



## Guest (30. Mai 2008)

maki hat gesagt.:
			
		

> > [- Keine Operatorüberladung möglich, String + String dennoch überladen
> > ..
> > - Java akzeptiert keine numerischen Werte als Wahrheitswerte
> > ..
> ...


----------



## AlArenal (30. Mai 2008)

Anonymous hat gesagt.:
			
		

> Der selbe Code in Java würde in etwa 30 Zeilen Programmcode beanspruchen (Berechnung auf jeder Vektorenkomponente, Berechnung von Zwischenergebnissen, etc.)



Streng genommen benötigt derselbe Code auch denselben Platz, sonst wäre es ja nicht mehr derselbe Code. ;-)

Nun hast du dir mit Arithmetik aber auch wirklich die einzig sinnvolle Anwendung für das Überladen von Operatoren herausgepickt. Ich selbst hatte bisher noch nie einen Bedarf dafür und bin dankbar mir nie den Kopf darüber zerbrechen gemusst zu haben, was irgendwer sich dabei gedacht hat, als er in seinem Code mit Überladung von Operatoren außerhalb der Numerik gearbeitet hat.

Ich meine, wie dividiert man Unternehmensprozesse im Qualitätsmanagement? ;-)

An dieser Stelle sei auf einen Artikel, den darin verlinkten Artikel und die anhängende Diskussion verwiesen:
http://cafe.elharo.com/blogroll/operator-overloading/

Ich hab erst weiter unten in den Kommentaren realisiert, dass der Artikel von Elliotte Rusty Herold ist...


----------



## Marco13 (31. Mai 2008)

Yzebär hat gesagt.:
			
		

> Die Diskussion ist doch albern und lächerlich.


Aber offenbar nicht albern und lächerlich genug, dass du dich nicht dran beteiligst.

_... was aber in der bisherigen Diskussion an "Nachteilen" für die eine oder andere Sprache genannt wurde [...] ist eher Kindergarten auf Hochschulniveau!!!_
... oder "klein-klein-Firlefanz", wie ich es oben genannt hatte. Die genannten Punkte waren eben wirklich Kleinigkeiten. Wie sehr man die Eignung eine Sprache für ein bestimmtes Anwendungsfeld in so eine Diskussion einfließen lassen sollte, weiß ich nicht - das führt zu Glaubenskriegen und Grabenkämpfen. Wenn man C# und Java aber trotzdem gegenüberstellt, und für diese "ähnlichen" Sprachen (zumindest) "ähnliche" Zielanwendungen voraussetzt, kann man IMHO zumindest ein bißchen über die Frage philosophieren, ob die Menschheit C# wirklich braucht, oder ob das nur Marktstrategie eines Quasi-Monopolisten ist, und wenn schon nicht DArüber (weil das als Microsoft-Bashing interpretiert werden... oder zumindest dazu ausarten könnte) dann doch zumindest über allgemeine Frage, welche Features der beiden Sprachen "gute" oder "elegante" Programmierung ermöglichen (was auch immer DAS jetzt wieder sein mag :roll: )


@AlArenal: Beim Hinterfragen der "Mächtigkeit" von Operatorenüberladung stimme ich dir mal zu. String+String ist klar, für Person+Person könnte man sich auch noch irgendwelche schmutzigen Analogien überlegen, aber spätestens bei Person*Person hört's dann schon auf. Das oben genannte Beispiel mit den Vektoren ist tatsächlich einer der wenigen Fälle, wo Operatorenüberladung Sinn macht. Dazu kommen noch Strings (Verkettung), Matrizen, Quaterninen, Tensoren... hey, da fällt einem doch schon irgendwas auf: Man kann die Fälle, in denen Operatorenüberladung Sinn macht, IMHO ziemlich genau spezifizieren ... aus dem Post von Seite 4:


			
				Marco13 hat gesagt.:
			
		

> *rumspinn* ... sowas wie Interfaces "Monoid", "Group" oder "Field", bei denen dann die passenden Operatoren automatisch erkannt werden


(etwas ähnliches wird auch in den Kommentaren zu dem verlinkten Blogeintrag erwähnt). 

Er sagt ja auch: _"If you don’t know the difference between a group, a ring, and a field, you have no business overloading operators" _. Da stimme ich demnach auch mal zu. Aber direkt danach sagt er..._"Now I’m not saying that one has to take a course in abstract algebra before you can be a competent programmer."_ Und DAS kann man IMHO schon in Frage stellen. Natürlich ist man nicht automatisch ein schlechter Programmierer, wenn man diesbezüglich keine Kenntnisse hat. Aber die Algebra ist die Grundlage der _Objektorientierten_(!) Programmierung, und viele Prinzipien daraus (Vollständigkeit, Abgeschlossenheit, ggf. Existenz neutraler und inverser Elemente, ...) sollte man zumindest so weit kennen, dass man sie einigermaßen auf das Klassendesign anwenden kann - oder zumindest weiß, wie eine Klasse bzw. Schnittstelle definiert sein _müßte_, damit sie in diesem Sinne "gut" ist :wink: Man kann auch "competent"  sein, ohne diese Prinzipien zu kennen - aber WENN man sie kennt, ist das "competent" sein vermutlich erheblich leichter...


----------



## Gast (31. Mai 2008)

jaca ist doch toll zu schreiben, im vergleich zu c++....aber halt bei vielem lahmer...


----------



## SlaterB (31. Mai 2008)

Anonymous hat gesagt.:
			
		

> Kd * (N dot L) + Ks * (N dot ( L + V / 2))^n;
> 
> Der selbe Code in Java würde in etwa 30 Zeilen Programmcode beanspruchen (Berechnung auf jeder Vektorenkomponente, Berechnung von Zwischenergebnissen, etc.)



Kd.multiply(N.dot(L)).add(Ks.multipy(N.dot(L.add(V.divide(2))).pow(n)));

wow, 30 Zeilen..


----------



## Guest (31. Mai 2008)

SlaterB hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...



Natürlich geht es auch, in dem man die entsprechenden Operationen als Methoden ausprogrammiert. Das ist aber a) wenig intuitiv und schlecht les- und wartbar bei mathematischen Berechnungen, und b) hat man dann den selben Aufwand produziert, den man für die Implementierung von Überladenen Operatoren in C++ benötigt.


----------



## Guest (31. Mai 2008)

AlArenal hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...



Du hast natürlich recht, ich denke das die Arithmetik einer der wenigen sinnvollen Anwendungsmöglichkeiten ist. Gleichzeitig macht sie für mich aber den Hauptteil der Programmierung bei meiner Arbeit aus (wir entwickeln Software die ihren Schwerpunkt bei 3D-Berechnungen hat). Und da führt an C++  einfach kein Weg vorbei. (allein schon aus Performance-Gründen).


----------



## SlaterB (31. Mai 2008)

Anonymous hat gesagt.:
			
		

> Natürlich geht es auch, in dem man die entsprechenden Operationen als Methoden ausprogrammiert. Das ist aber a) wenig intuitiv und schlecht les- und wartbar bei mathematischen Berechnungen,


was ist an einem multiply schlechter lesbar als an einem *?
mehr Tipparbeit, ok, aber ein anderer Unterschied ist schlicht nicht vorhanden

ich schätze dabei auch die Vorteile von Operationen,
etwa Logging/ Debugging in dieser Operation, Parameter prüfen/ Exceptions, Vererbung, einfache Definitions-Öffnung in einer IDE,
könnte aber bei der Überladung auch alles vorhanden sein, keine Ahnung



			
				Anonymous hat gesagt.:
			
		

> und b) hat man dann den selben Aufwand produziert, den man für die Implementierung von Überladenen Operatoren in C++ benötigt.


?
ja wie, soll die Programmiersprache sich selber zusammenreimen wie das * oder multiply definiert ist?
selbstverständlich muss das immer irgendwo definiert sein, was ist daran schlecht/ anders als beim Überladen?


----------



## Illuvatar (31. Mai 2008)

Ich wollte mich ja eigentlich raushalten, aber eine kleine Anmerkung wollte ich loswerden:

Wer einen Operator Apfel mal Apfel implementiert der wird auch stattdessen eine Methode Apfel#multiply(Apfel) einbauen. Und da kommt genauso Apfelquadrat raus


----------



## Guest (31. Mai 2008)

SlaterB hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...



Der überladene Operator in C++ ist ja im Prinzip eine gewöhnliche Methode wie jede andere auch, deswegen kann hier genauso debuggen und loggen.

[source]
const Vector3D operator + (const Vector3D &lhs, const Vector3D &rhs)
{
    return Vector3D(lhs.x + rhs.x, lhs.y + rhs.y, lhs.z + rhs.z);
}
[/source]


----------



## Guest (31. Mai 2008)

SlaterB hat gesagt.:
			
		

> was ist an einem multiply schlechter lesbar als an einem *?
> mehr Tipparbeit, ok, aber ein anderer Unterschied ist schlicht nicht vorhanden



Es ist "natürlicher". Stell dir vor, du würdest mit skalaren Werten dasselbe tun:

2 * (4 / (8 + 4))

entspricht dann:

2.multiply(4.divide(add(8, 4))); 

jetzt möchte ich aber gerne meine Formel umstellen, in dem ich die Klammerung der Addition weglasse:

2 * (4 / 8 + 4)

wird zu:

2.multiply(add(4.divide(8)));

Dieses Beispiel ist noch recht trivial, aber wenn die Formeln etwas größer sind, ist es mit überladenen Operatoren einfach schöner lesbar, schneller abzuändern (ich lass einfach nur die Klammerung weg) und dadurch weniger fehleranfällig, da auch gleichzeitig die Evaluierungsreihenfolge sichergestellt ist. 



			
				SlaterB hat gesagt.:
			
		

> ich schätze dabei auch die Vorteile von Operationen,
> etwa Logging/ Debugging in dieser Operation, Parameter prüfen/ Exceptions, Vererbung, einfache Definitions-Öffnung in einer IDE,
> könnte aber bei der Überladung auch alles vorhanden sein, keine Ahnung



Der überladene Operator in C++ ist ja im Prinzip eine gewöhnliche Methode wie jede andere auch, deswegen kann hier genauso debuggen und loggen.


```
const Vector3D operator + (const Vector3D &lhs, const Vector3D &rhs)
{
    return Vector3D(lhs.x + rhs.x, lhs.y + rhs.y, lhs.z + rhs.z);
}
```


----------



## SlaterB (31. Mai 2008)

jo, dann bleiben wir bei der Schreibweise,
ich stimme zu dass das + schicker aussieht

bringt keine 30 Zeilen Vorteil aber mehr Übersicht

wobei mir persönlich sowas noch nicht untergekommen ist und im Forum auch noch nicht,
wer sowas richtig braucht geht wohl gleich zu C


----------



## Gast (31. Mai 2008)

sobald man einmal code folgender art gesehen hat

```
pVec(node[*ix[n]](0,0), node[d+1])[*(++in)] + pVec(node[*ix[n]](0,1), node[d])[*(++in)];
```
hasst man operatorüberladung abgrundtief. da hab ich lieber 30 zeilen verständlichen code


----------



## SlaterB (31. Mai 2008)

dass man zuviel in eine Zeile schreibt wird durch kurze Operatoren vielleicht begünstigt,
ist aber im Grunde ein anderes Problem


----------



## AlArenal (31. Mai 2008)

Mich würde mal interessieren, wie man mit überladenen Operatoren praktisch arbeitet. Erkennen die IDEs beim  Tippen ob die verwendete Operation zulässig / vorhanden ist? Kann man z.B. per Shortcut das "+" anklicken und landet im Code, wo das Ding definiert wird? usw. usf.

Die meiste Zeit verbringt man damit Code zu warten, nicht neuen Code zu produzieren. Sobald man anfängt mit fremden Code zu arbeiten, muss man wohl oder übel mal Blicke in die Implementierung und Code-Doku werfen.


----------



## LordLuzifer (31. Mai 2008)

Hab das grad mal ausprobiert und zumindest Visual Studio zeigt mir beim Plus die passende Methode an, von daher entsteht also kein Problem.

Das Problem bei Operator-Überladungen ist das selbe wie überall: wenn man Leute einfach machen lässt, was sie wollen, und die Leute das ohne Nachdenken ausnutzen, kommt oft nichts Sinnvolles dabei heraus.

Viel schlimmer finde ich die Möglichkeit in C++ (in C vllt auch?), einparametrige (gibts das?) Konstruktoren zu verkürzen.
Eine Klasse mit zB dem Konstruktor Number(int i) kann dort auch so aufgerufen werden:


```
Number n = 2;
```

Der Compiler erkennt, dass dort eigentlich "new Number(2)" (oder etwas in der Art) steht, und setzt das ein ... Das kann zu viel größeren Verwirrungen führen, mMn.


----------



## Guest (1. Jun 2008)

Gast hat gesagt.:
			
		

> sobald man einmal code folgender art gesehen hat
> 
> ```
> pVec(node[*ix[n]](0,0), node[d+1])[*(++in)] + pVec(node[*ix[n]](0,1), node[d])[*(++in)];
> ...


Das soll C++ sein, ja? Du veränderst und liest die Variable in an zwei Stellen ohne einen trennenden Sequence Point, was zu Undefined Behavior führt. Setzen, sechs.


----------



## Guest (1. Jun 2008)

LordLuzifer hat gesagt.:
			
		

> ```
> Number n = 2;
> ```
> Der Compiler erkennt, dass dort eigentlich "new Number(2)" (oder etwas in der Art) steht


"new Number(2)" würde das Objekt auf dem Heap anlegen. Du meinst sicher

```
Number n(2);
```


----------



## Marco13 (1. Jun 2008)

Anonymous hat gesagt.:
			
		

> Gast hat gesagt.:
> 
> 
> 
> ...



Wer sagt denn, dass der Präfix-++-Operator so überladen ist, dass die Variable verändert wird?  :meld:   :bae:


----------



## Guest (1. Jun 2008)

Marco13 hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...



und genau deshalb mag ich das beispiel so


----------

