Windowsprogramm mit C++ oder Java?

[Gregor]

pale dog schrieb:

es wundert mich auch immer wieder, warum geht's immer Java gegen c++?
Java vs. C# wäre ja noch zu verstehen, weil sie sich sehr ähnlich sind,
aber warum C++?

Java ist in der Wirtschaft und Industrie sehr erfolgreich. C++ hat technisch hingegen einiges zu bieten, was Java so nicht kann. C++ ist somit im Allgemeinen ausdrucksstärker. Beide Sprachen haben also etwas, was die andere gerne hätte. ...C# hat hingegen gar nichts.

[pale dog]

Gregor schrieb:

C++ hat technisch hingegen einiges zu bieten, was Java so nicht kann.

naja, aber sind das nicht alles dinge, die in Java absichtlich weggelassen wurden, wie pointer, präprozessor, überladene operatoren und mehrfachvererbung, weil sie zu fehlerträchtigem und schwer lesbarem code führen?
bis auf templates vielleicht, die würden Java auch gut stehen.

[lolz]

pale dog schrieb:

Gregor schrieb:

C++ hat technisch hingegen einiges zu bieten, was Java so nicht kann.

naja, aber sind das nicht alles dinge, die in Java absichtlich weggelassen wurden, wie pointer, präprozessor, überladene operatoren und mehrfachvererbung, weil sie zu fehlerträchtigem und schwer lesbarem code führen?
bis auf templates vielleicht, die würden Java auch gut stehen.

Darüber lässt sich streiten. Mehrfachvererbung wird in Java durch andere Features ersetzt. Es wird also nicht benötigt (wie es in C++ der Fall ist). Den Präprozessor braucht C++ auch, aber Java hat ein anderes Modul-System wodurch es keinen benötigt (falls man Textersetzungen braucht, oder bedingte Kompilation kann man jederzeit einen Präprozessor vorschalten).
Über Pointer lässt sich definitiv nur streiten, weshalb ich die außen vor lasse.

Überladene Operatoren finde ich sehr sinnvoll, da sie das Lesen von Code deutlich vereinfachen können, da man mehrere Methodenaufrufe leserlich hintereinander hängen kann.

a1 = a2 + a3 + a4 + a5 + a6;

//vs

a1.assign( a2.add( a3.add( a4.add( a5.add( a6 ) ) ) ) );

Genauso wie hinter dem + oder = Operator etwas ganz anderes stecken könnte, als man erwartet kann ich Methoden mit den Namen assign oder add benutzen die etwas völlig anderes machen.
Daher ist dieses Argument imho quatsch.

Ebenso das Argument, dass komplexe Operationen sich nicht hinter einfach aussehenden Dingen verstecken sollten.

vector v1, v2; //v2 hat viele tausend elemente

v1 = v2; //aufwendige kopieroperation hinter op=

//vs

v1.assign( v2 );  //aufwendinge Kopieroperation hinter assign

Ein vector ist jetzt nicht gerade das Hammerbeispiel, aber ich hoffe euch wird klar was ich meine.

Als (gesunder) Programmierer gehe ich davon aus, dass eine Zuweisung eines großen (komplexen) Objekts aufwändiger ist als das Zuweisen eines ints. Ob da jetzt op= oder assign steht ändert nichts daran, dass ich in die Doku schauen muss um zu sehen wie das Kopieren genau aussieht.

[pale dog]

@lolz,
schon klar, der eine findet das gut, der andere jenes. es gibt keine universelle wahrheit und wenn wir damit weitermachen, haben wir genau diesen C++ vs. Java flamewar wieder hervorgekramt.
ich finde jedenfalls, dass Java und C++ sich sehr fremd sind (bis auf die C-style syntax ist doch vieles extrem anders), deshalb wundert es mich eben, weshalb so oft Java mit C++ verglichen wird.

[Apollon]

Simon2 schrieb:

Apollon schrieb:

Simon2 schrieb:

Schon erstaunlich, wie lange man über sowas streiten kann.

Nein. Erstaunlich wie Du ueber sowas streiten kannst.

Muss ich nicht verstehen, oder ?
Versuchst Du jetzt, mich irgendwie zu provozieren, damit Du weiter was zum Streiten hast ?
Mein statement zu dem Thema kannst Du oben nachlesen.
Mag sein, dass Dir langweilig isr, mir nicht - ich genieße jetzt Samstag, Sonne und Erdeeren mit meiner Frau.

Schönen Tag noch,

Simon2.

Nein. Um Gottes Willen! Ich kann mich nur gut erinnern, dass Du damals ordentlich mitgemischt hast. Das ist alles. Ich geniesse jetzt den Abend mit meinen Freunden beim Grillen

Wuensche dir ebenso einen schoenen Tag!

-- Waldemar

[DEvent]

Genauso wie hinter dem + oder = Operator etwas ganz anderes stecken könnte, als man erwartet kann ich Methoden mit den Namen assign oder add benutzen die etwas völlig anderes machen.
Daher ist dieses Argument imho quatsch.

Das erinnert mich an das was ich eben über C# und Delegates gelesen habe.

A: Quick, can you spot the inefficiency in this code? public void Calc(int[] foo)
{
Sum = 0;
for (int i = 0; i < foo.Length; i++)
Sum += foo[i];
}

What you may have missed is that every += involves two function calls. The only indication of this fact is the uppercase 'S' in Sum (which by the way is a convention that is frequently not followed), so the inefficiency is not easy to spot

Bei C++ und C# muss man halt bei jedem Operator bangen das er überladen wurde und das hinter einem simplem + sich etliche Methodenaufrufe verstecken könnten.

[Gast]

Und das muss man bei einer Methode foo nicht?

[DEvent]

Tim schrieb:

Und das muss man bei einer Methode foo nicht?

Wenn eine Methode explizit aufgerufen wird, dann weis ich zu 100% das da nichts nativ sein kann. Bei einem Operator muss ich raten (in die Doku schauen oder in den Code).
Auch recht lustig:

Test 2
How many function calls can be hiding in the following statement?

x.y += a[b];

Klar hat man mit Operatorüberladungen eben die Möglichkeit mathematische Ausdrücke leicht verständlich im Code abzubilden. Das man diese Möglichkeit zu 99% sowieso nicht benötigt wird eben in Java Rechnung getragen.

[lolz]

DEvent schrieb:

Tim schrieb:

Und das muss man bei einer Methode foo nicht?

Wenn eine Methode explizit aufgerufen wird, dann weis ich zu 100% das da nichts nativ sein kann. Bei einem Operator muss ich raten (in die Doku schauen oder in den Code).

Das Argument ist aber nicht sehr stark.
Ich nehme mal an, dass du ein Gegner der ungarischen Notation (im Sinne von Typen in Variablennamen einzubauen) bist und du das u.a. damit begründest, dass man Dank Intelli-Sense sowieso jederzeit weiß was für ein Typ ein Objekt hat.
Es gibt nur eine Hand voll von built-in Typen, somit lässt sich dank Intelli-Sense sehr leicht feststellen ob das Objekt ein built-in Typ ist oder ob es sich um ein Methodenaufruf handelt.

Die Template-Diskussion die meist mit der Operatorüberladung einher geht ist (leider) immer auf C++ beschränkt, da es Templates so nirgends sonst gibt.
Aber die Templates sind ein Paradebeispiel dafür, dass es nötig ist mit Objekten so operieren zu können wie mit built-in Typen um wirklich allgemein gültigen Template-Code zu schreiben.
Die Möglichkeit Objekte wie Funktionen zu behandeln durch ein Überladen von dem ()-Operator ermöglicht es in Templates nicht nur Funktionen als Parameter sondern auch Objekte zu verwenden.

Ich vertrete die Meinung, dass man mit jeder Sprache unwartbaren Code schreiben kann (sieht man täglich auf www.worsethanfailure.com) und dagegen ist kein Kraut gewachsen.
Für den "gesunden" Programmierer jedoch ist die Operatorüberladung jedoch ein sehr mächtiges Werkzeug (und es steht einem frei diese zu Nutzen oder es sein zu lassen).

[rüdiger]

DEvent schrieb:

Tim schrieb:

Und das muss man bei einer Methode foo nicht?

Wenn eine Methode explizit aufgerufen wird, dann weis ich zu 100% das da nichts nativ sein kann. Bei einem Operator muss ich raten (in die Doku schauen oder in den Code).

Was meinst du nun genau?

* Wie man etwas mit einer Klasse erreicht muss man in jedem Fall wissen. Das kannst du also nicht meinen.

* Ob der Operator+ überladen ist oder builtin kann einem ja auch egal sein, solange er das macht was er machen soll (Und für Objekte kann der eben nicht builtin sein...)

Ich finde Operator-Überladung sehr wichtig, da es die Ausdrucksweise des Codes stärkt. Unter a + b kann ich mir etwas vorstellen. Sicher gibt es Leute die dazu tendieren die Operator-Überladung zu missbrauchen und Operatoren für allen scheiß zu überladen. Aber deswegen ist Operator-Überladung nicht schlecht. Wie gesagt, es soll ein mittel sein um die Ausdrucksstärke (und damit die Lesbarkeit) des Codes zu erhöhen.

[Simon2]

Apollon schrieb:

...
Wuensche dir ebenso einen schoenen Tag!

-- Waldemar

Danke - hatte ich ! Du hoffentlich auch.
Ja - ich habe damals mitgemischt, aber eben seit diesem Thread weiß ich, worin IMO die Ursache für diese Diskussion liegt (unterschiedliche Definitionen desselben Begriffs).
Und diese Erkenntnis wollte ich hier reinschmeissen, um evtl. das erneute Aufflaker abzumildern....

Auf jeden Fall will ich hier nicht weiterstreiten, weil es IMO nichts mehr zu streiten gibt.

Einen gute Nacht,

Simon2.

[lolololol]

IntelliSense

[superlexx]

DEvent schrieb:

What you may have missed is that every += involves two function calls.

Wer's glaubt...

public void Calc(int[] foo)
        {
            Sum = 0;
00000000  push        edi  
00000001  push        esi  
00000002  xor         eax,eax 
00000004  mov         dword ptr [ecx+4],eax 
            for (int i = 0; i < foo.Length; i++)
00000007  xor         esi,esi 
00000009  mov         edi,dword ptr [edx+4] 
0000000c  test        edi,edi 
0000000e  jle         0000001F 
                Sum += foo[i];
00000010  mov         eax,dword ptr [ecx+4] 
00000013  add         eax,dword ptr [edx+esi*4+8] 
00000017  mov         dword ptr [ecx+4],eax 
            for (int i = 0; i < foo.Length; i++)
0000001a  inc         esi  
0000001b  cmp         edi,esi 
0000001d  jg          00000010 
0000001f  pop         esi  
        }
00000020  pop         edi  
00000021  ret

Es sind also genau 0 Funktionsaufrufe. So wenig Ahnung bei so viel Java-Evangelismus ist schon bisschen peinlich

[lol eh ^ 2]

dir ist anscheinend entgangen dass das beispiel da oben
1. nicht smit java zu tun hat => hääää????
2. sondern es um c# nich c(++) ging
3. das ein zitat war
4. dass in c# bei dem beispiel da oben in der tat so stimmt wie es dort steht, aber vermutlich hast du dir die seite nichmal vollständig durchgelesen

[lol eh ^ 2]

rofl was hab ich gerade für ein müll geschrieben??

[nich schlecht]

herr rüder

[ähhhh]

rüdiger

[DEvent]

Ich finde Operator-Überladung sehr wichtig, da es die Ausdrucksweise des Codes stärkt. Unter a + b kann ich mir etwas vorstellen. Sicher gibt es Leute die dazu tendieren die Operator-Überladung zu missbrauchen und Operatoren für allen scheiß zu überladen. Aber deswegen ist Operator-Überladung nicht schlecht. Wie gesagt, es soll ein mittel sein um die Ausdrucksstärke (und damit die Lesbarkeit) des Codes zu erhöhen.

Ich habe nie behauptet das ich Operatorüberladung schlecht finde. Ich habe nur gesagt das man zu 99% Operatorüberladung nicht benötigt und man damit viel Misst machen kann. Das wird eben in Java Rechnung getragen und das finde ich gut.

Das Argument ist aber nicht sehr stark.
Ich nehme mal an, dass du ein Gegner der ungarischen Notation (im Sinne von Typen in Variablennamen einzubauen) bist und du das u.a. damit begründest, dass man Dank Intelli-Sense sowieso jederzeit weiß was für ein Typ ein Objekt hat.
Es gibt nur eine Hand voll von built-in Typen, somit lässt sich dank Intelli-Sense sehr leicht feststellen ob das Objekt ein built-in Typ ist oder ob es sich um ein Methodenaufruf handelt.

Ich bin tatsächlich ein Gegner der UN, aber aus dem einfachen Grund das man nicht zwischen einem Typ zu unterscheiden braucht. Ob etwas eine Realzahl, eine Klasse oder Bool ist, ist vollkommen egal und sollte aus dem Contex ersichtlich sein.

Die Möglichkeit Objekte wie Funktionen zu behandeln durch ein Überladen von dem ()-Operator ermöglicht es in Templates nicht nur Funktionen als Parameter sondern auch Objekte zu verwenden.

In einer OO-Sprache benötigt man eigentlich nur Objekte und würde mit Interfaces oder mit abstrakten Klassen hantieren. Also wenn man Funktionen aus der Sprache weglässt, ist der Operator() unnötig. So gesehen ist die Möglichkeit den Operator() zu überladen in C++ einfach nötig für die Brücke OOP und prozedurale Programmierung.

Oder mit den Worten aus dem Openbook: http://www.galileocomputing.de/openbook/csharp/kap25.htm

Es ist nicht möglich, Operatoren für den Mitgliedszugriff, für den Mitgliedsaufruf (Funktionsaufruf) oder die Operatoren +, &&, ||, ?: oder new zu überladen. Dies geschieht im Namen der Einfachheit. Obwohl mit der Überladung lustige Dinge angestellt werden können, wird die Verständlichkeit des Codes doch erheblich herabgesetzt, da der Programmierer stets daran denken muss, dass der Mitgliedsaufruf (beispielsweise) zu besonderen Operationen führen kann1 . Der Operator new kann nicht überladen werden, da die .NET-Laufzeitumgebung für die Speicherverwaltung zuständig ist, und im C#-Dialekt bedeutet new »Gib mir eine neue Instanz von«.

Es ist darüber hinaus nicht möglich, die zusammengesetzten Zuweisungsoperatoren +=, *= usw. zu überladen, da diese immer in die einfache Operation und eine Zuordnung erweitert werden. Auf diese Weise wird vermieden, dass nur einer der Operatoren definiert wird oder (schauder) dass die Operatoren mit unterschiedlichen Bedeutungen definiert werden.

Das letztere kann man übrigens in C++ ohne weiteres machen.

[Simon2]

[****&/%&$")(/@*** !!!! Gerade ausführlich geschrieben und dann per short cut direkt Fenster geschlossen !!]

Hi DEvent,

ich will keinen Krieg vom Zaun brechen, aber Dir trotzdem sanft widersprechen (im Sinne eines hilfreichen Gedankenaustauschs)

DEvent schrieb:

...man damit viel Misst machen kann. Das wird eben in Java Rechnung getragen und das finde ich gut....

Ersteres sehe ich auch so, Zweiteres nicht.
Ich selbst habe am Anfang viel mit Operatorüberladung falsch gemacht ... aber wenn ich mir reale Software ansehe, muss ich schon sagen, dass das (bei wirklich für Wiederverwendung ausgelegter Software) ziemlich selten ist.
Hier hat man IMO "das Kind mit dem ade ausgeschüttet" und wegen eher schwacher Nachteile ernstzunehmende Vorteile bzgl Lesbarkeit (z.B. bei eigenen "Zahlklassen") und Generizität über Bord geworfen, z.B.:

DEvent schrieb:

...das man nicht zwischen einem Typ zu unterscheiden braucht. Ob etwas eine Realzahl, eine Klasse oder Bool ist, ist vollkommen egal .......

Dem stimme ich zu ... und gerade deswegen bedauere ich die Streichung der Operatorüberladung, weil sie diesem Grundsatz widerspricht; schließlich kann man in Java primitive Typen nur, Klassen hingegen NIE mit Operatoren "bearbeiten". Ich muss also zumindestens zwischen diesen immer unterscheiden.
(Damit will ich nicht der UN das Wort reden - die lehne ich aus demselben Grund ab wie Du)

DEvent schrieb:

...In einer OO-Sprache benötigt man eigentlich nur Objekte ...

Eine Sprache, die diesen Grundsatz umsetzt, zwingt aber allen Programmierern in bestimmten Situationen ein unpassendes/ungeschicktes Design oder eingeschränkte Wiederverwendbarkeit (z.B. indem man Sortieralgorithmus an den Container oder den Datentyp koppelt) auf. Es gibt in der Realität einfach Zusammenhänge, die besser prozedural abgebildet werden (z.B. alles, was in Algorithmen formuliert wird; Sortieren, Suchen, krytographische Operationen, ...).
Ich kann verstehen, dass der Bann von Funktionen damals Teil des "didaktischen Konzepts zu Stärkung der OO-Denke" war - aber letztlich ist es IMO eine Verarmung der Sprache und eine Begünstigung schlechten Designs in bestimmten Zusammenhängen (Nach Java-Denke also eigentlich auszumerzen - schließlich ist schlechtes Design viel öfter Ursache für schlechte Programme als Operatorenoverloading .... .... ich weiß, dass ich das hier überstrapaziere - ist nicht wirklich erst gemeint).

Übrigens: Den Java-Ansatz "Was zuviel Probleme/Verwirrung/Fehler/... verursacht, kommt nicht in die Sprache", finde ich gut und in vielen Bereichen von Java ach gut umgesetzt ... aber eben bei "Operatorenüberladung" und "Funktionenrausschmiss" eben nicht.

Gruß,

Simon2.

[Zeus]

Im JDK 7 gibst Operatorüberladung wenigstens für die Klasse BigDecimal.

btw Mir ist ne Möglichkeit die ich nicht nutze lieber als ne Möglichkeit die ich brauche.