Nachteile von Java

[Marco13]

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]

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]

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]

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:

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]

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]

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

 

[tfa]

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]

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]

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]

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.

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

allerdings ist dort im Moment Ruby zu finden, Groovy nicht

 

[Felli]

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]

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]

[- 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

Wie kann man die fehlende Operatorüberladung als vorteil bezeichnen?

In C++ kann ich z.b. mit einem 3D-Vector ein folgendes Statement schreiben:

3DVector L, N, V;
float n, Kd, Ks;

Für eine typische mathematische Berechnung (wie hier im Beispiel zur Lichtberechnung) würde man in C++ das alles mit einer Zeile dank Operatorüberladung erschlagen:

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

 

[AlArenal]

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]

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:

*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]

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

 

[SlaterB]

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]

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

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]

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

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]

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

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]

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]

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

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?

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]

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.

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]

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]

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]

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

 

[AlArenal]

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]

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]

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

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]

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]

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

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.

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

 

[Guest]

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

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.

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

und genau deshalb mag ich das beispiel so