Hypercell ein ] Hypercell aus ] Zeige Navigation ] Verstecke Navigation ]
c++.net  
   

Die mobilen Seiten von c++.net:
https://m.c-plusplus.net

  
C++ Forum :: Java ::  Java vs. C++     Zeige alle Beiträge auf einer Seite Auf Beitrag antworten
Autor Nachricht
cppvsjava
Unregistrierter




Beitrag cppvsjava Unregistrierter 22:11:38 14.10.2016   Titel:   Java vs. C++            Zitieren

Hallo,

ich komme aus der C++-Welt, doch es geht mir gerade um Java.

Ich hab seit Jahren C++ gemacht, weil ich war mal ein Jüngerle, wollte Spiele programmieren, und stieß auf C++.

Jetzt schreibe und (ein bisschen) lese ich C++ seit ungefähr 6 bis 8 Jahren.

Dann dacht ich mir, ein guter Programmierer, der kann mehr als nur eine Sprache.

Und dann habe ich Java gemacht.

Und ich hab immer total viele Flamewars über Java und C++ gelesen und habe nicht so gerafft warum das so ist.

Und da ich ein paar Wochen Java gelernt habe, wollte ich mal fragen, was denn so Kacke im Vergleich von beiden ist?

Ich habe da drei Sachen auszusetzen:

C++ ist besser, weil...

[list][*]Mehr Typsicherheit irgendwie. Java Generics find ich im Gegensatz zu C++-Templates echt kacke! Ich hatte sogar schon Probleme bei nem simplen Factorial!
[*]Operatorüberladung
[*]Explizite throw-Angabe in der Funktionssignatur.

Also, wie gesagt, ich häng bei C++. Java konnte ich nicht mal weiterlernen, da ich durch Arbeit und so gerade mehr neuerdings mit Python beschäftigt bin.

Das schwierigste daran, eine neue Sprache zu lernen, ist, ohne in einer Referenz nachschauen zu müssen, was was ist. Findet ihr nicht? In C++ muss ich garnet mehr inner Referenz nachschauen. Einfach drauf losprogrammieren, fast komplettes <algorithm> im Kopf.

Tja, so ist das halt, wenn man Jahre nur auf einer einzigen Sprache hängt.

So isses!
Gregor
Moderator

Benutzerprofil
Anmeldungsdatum: 16.01.2002
Beiträge: 8607
Beitrag Gregor Moderator 15:09:45 15.10.2016   Titel:   Re: Java vs. C++            Zitieren

cppvsjava schrieb:

Und da ich ein paar Wochen Java gelernt habe, wollte ich mal fragen, was denn so Kacke im Vergleich von beiden ist?

Jenseits dieser Frage habe ich keine andere in Deinem Beitrag entdeckt. Zur Antwort: Java ist zu Recht eine der beliebtesten Programmiersprachen. Es gibt natürlich Unterschiede zu anderen Sprachen und selbstverständlich kann man diese Unterschiede aus mehreren Blickwinkeln betrachten. Was die einen positiv bewerten, bewerten andere negativ. Flamewars über "Java vs. C++" gibt es, weil sich die Anwendungsbereiche der beiden Sprachen teilweise überschneiden.

_________________
"Die Mathematiker sind eine Art Franzosen: Redet man zu ihnen, so übersetzen sie es in ihre Sprache, und dann ist es alsobald ganz etwas anderes." - Johann Wolfgang von Goethe
proundcontract
Unregistrierter




Beitrag proundcontract Unregistrierter 23:44:01 15.10.2016   Titel:              Zitieren

Java ist gut fürs Money Making also beruflich proggen. In allen anderen Bereich ist C++ besser.
Gast3
Unregistrierter




Beitrag Gast3 Unregistrierter 11:32:56 16.10.2016   Titel:              Zitieren

Zitat:
Java ist gut fürs Money Making also beruflich proggen. In allen anderen Bereich ist C++ besser.


du weißt aber schon das mehr Geld mit C/C++ Entwicklung verdient wird - oder?
proundcontract
Unregistrierter




Beitrag proundcontract Unregistrierter 13:16:04 16.10.2016   Titel:              Zitieren

Kann sein, dass der Stundenlohn für C++ höher ist, es gibt aber viel mehr Stellenangebote für Proggen mit Java. :(
Gast3
Unregistrierter




Beitrag Gast3 Unregistrierter 13:33:33 16.10.2016   Titel:              Zitieren

Zitat:
Kann sein, dass der Stundenlohn für C++ höher ist, es gibt aber viel mehr Stellenangebote für Proggen mit Java.


.Net, Java und viele anderen halten sich doch eher die Waage - dein Post klang aber so als wenn man nur mit Java Geld verdienen kann - und das ist eben mehr als nur falsch
dot
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.05.2004
Beiträge: 6740
Beitrag dot Mitglied 13:49:52 16.10.2016   Titel:   Re: Java vs. C++            Zitieren

cppvsjava schrieb:
Und da ich ein paar Wochen Java gelernt habe, wollte ich mal fragen, was denn so Kacke im Vergleich von beiden ist?

Ist ganz einfach: Garbage Collection

_________________
one point of view will never reveal the entire scene.


Zuletzt bearbeitet von dot am 13:50:04 16.10.2016, insgesamt 1-mal bearbeitet
y0da
Unregistrierter




Beitrag y0da Unregistrierter 18:55:32 16.10.2016   Titel:              Zitieren

Begun teh flamewar haz. :cool:
Swordfish
Mitglied

Benutzerprofil
Anmeldungsdatum: 27.03.2005
Beiträge: 5586
Beitrag Swordfish Mitglied 19:14:00 16.10.2016   Titel:              Zitieren

If Java had true garbage collection, most programs would delete themselves upon execution.

_________________
To the journey! And to those of us who aren't here to celebrate it with us.
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 14:42:03 17.10.2016   Titel:   Re: Java vs. C++            Zitieren

Gregor schrieb:

Flamewars über "Java vs. C++" gibt es, weil sich die Anwendungsbereiche der beiden Sprachen teilweise überschneiden.

im bereich der schnittmenge ist man mit java besser bedient als mit c++. und für alles darunter ist man mit c besser bedient als mit c++. kurz gesagt: c++ ist irgendwie obsolet. nur etwas für liebhaber aber ohne praktischen vorteil.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Unregistrierter





Beitrag Unregistrierter 14:56:44 17.10.2016   Titel:              Zitieren

Von wegen C++ und typsicher!

C++:
int x = 2;
 
if (x = 1) {
    std::out << "Na klaro!" << std::endl;
}
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 15:32:18 17.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Von wegen C++ und typsicher!

C++:
int x = 2;
 
if (x = 1) {
    std::out << "Na klaro!" << std::endl;
}


deswegen z.b. sind die macher von java bis heute sehr stolz auf ihre sprache.
boolean ist da eben keine teilmenge von int. ;)

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Kenner des C++
Unregistrierter




Beitrag Kenner des C++ Unregistrierter 17:32:50 17.10.2016   Titel:   Re: Java vs. C++            Zitieren

swapper schrieb:
Gregor schrieb:

Flamewars über "Java vs. C++" gibt es, weil sich die Anwendungsbereiche der beiden Sprachen teilweise überschneiden.

im bereich der schnittmenge ist man mit java besser bedient als mit c++. und für alles darunter ist man mit c besser bedient als mit c++. kurz gesagt: c++ ist irgendwie obsolet. nur etwas für liebhaber aber ohne praktischen vorteil.

[ ] Du hast Ahnung.
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 19:18:18 17.10.2016   Titel:   Re: Java vs. C++            Zitieren

Kenner des C++ schrieb:
swapper schrieb:
Gregor schrieb:

Flamewars über "Java vs. C++" gibt es, weil sich die Anwendungsbereiche der beiden Sprachen teilweise überschneiden.

im bereich der schnittmenge ist man mit java besser bedient als mit c++. und für alles darunter ist man mit c besser bedient als mit c++. kurz gesagt: c++ ist irgendwie obsolet. nur etwas für liebhaber aber ohne praktischen vorteil.

[ ] Du hast Ahnung.


naja, etwas. wie die meisten hier. :)

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump


Zuletzt bearbeitet von swapper am 19:18:43 17.10.2016, insgesamt 1-mal bearbeitet
5cript
Mitglied

Benutzerprofil
Anmeldungsdatum: 14.03.2009
Beiträge: 1929
Beitrag 5cript Mitglied 11:15:10 18.10.2016   Titel:              Zitieren

Eigentlich will ich diese leidige Thema nicht befeuern, aber von Java -> C++ fehlt mir nur richtige Introspektion und die extrem einfache Testbarkeit. Andersrum fehlt mit ne riesige Tonne Features.
Und die extrem strikte Objektorientierung und das Fehlen von Features vernichtet hunderte coole Software Designs und Abstraktionen.
Ich schreibe lieber C++, wegen der Freiheit die mir die Sprache bietet.
Dafür muss ich nicht immer wieder die gleichen ausgelutschten Argumente bedienen.
C++ kann so viele Programmierparadigmen bedienen, da erscheint mit der Vergleich schon fast wie ein Vergleich zwischen einem roten Apfel (Java) und einem ganzen Fruchtkorb.

_________________
http://assets.amuniversal ....... 067f90134cb84005056a9545d
Unregistrierter





Beitrag Unregistrierter 12:10:33 18.10.2016   Titel:              Zitieren

5cript schrieb:
Eigentlich will ich diese leidige Thema nicht befeuern, aber von Java -> C++ fehlt mir nur richtige Introspektion und die extrem einfache Testbarkeit. Andersrum fehlt mit ne riesige Tonne Features.
Und die extrem strikte Objektorientierung und das Fehlen von Features vernichtet hunderte coole Software Designs und Abstraktionen.
Ich schreibe lieber C++, wegen der Freiheit die mir die Sprache bietet.
Dafür muss ich nicht immer wieder die gleichen ausgelutschten Argumente bedienen.
C++ kann so viele Programmierparadigmen bedienen, da erscheint mit der Vergleich schon fast wie ein Vergleich zwischen einem roten Apfel (Java) und einem ganzen Fruchtkorb.

C++ hindert mich sicher zu programmieren. In Java kann ich z. B. alle Membervariablen als final deklarieren, solange ich sie im Konstruktor initialisiere. Geht zwar auch mit C++, aber sobald ich das Objekt z. B. in eine QList stecke, fängt der Visual C++ Compiler an zu meckern, dass der Copy Konstruktor fehlt. Geht komischerweise wunderbar unter Linux, weil dort die Zuweisung evtl. durch memcopy realisiert ist (ich weiß es ehrlich gesagt nicht).

Ganz ähnlich, wenn ich einen Standard-Konstruktor vermeiden will und stattdessen einen mit mehreren Argumenten wähle, um sicherzustellen, dass alle Membervariablen vom Benutzer sinnvoll initialisiert werden: QList braucht einen Default-Konstruktor, dadurch kann dann der Benutzer das Objekt mit einem Default-Konstruktor instanziieren und ein paar Member-Variablen setzen und den Rest uninitialisiert lassen. – Die Sicherheit ist dadurch verloren gegangen. Das sind alles Probleme, die ich erst seit C++ kenne und die andere moderne Sprachen nicht haben.


Zuletzt bearbeitet von Unregistrierter am 12:17:49 18.10.2016, insgesamt 1-mal bearbeitet
5cript
Mitglied

Benutzerprofil
Anmeldungsdatum: 14.03.2009
Beiträge: 1929
Beitrag 5cript Mitglied 12:34:40 18.10.2016   Titel:              Zitieren

ShadowClone schrieb:
C++ hindert mich sicher zu programmieren. In Java kann ich z. B. alle Membervariablen als final deklarieren, solange ich sie im Konstruktor initialisiere. Geht zwar auch mit C++, aber sobald ich das Objekt z. B. in eine QList stecke, fängt der Visual C++ Compiler an zu meckern, dass der Copy Konstruktor fehlt. Geht komischerweise wunderbar unter Linux, weil dort die Zuweisung evtl. durch memcopy realisiert ist (ich weiß es ehrlich gesagt nicht).

Ganz ähnlich, wenn ich einen Standard-Konstruktor vermeiden will und stattdessen einen mit mehreren Argumenten wähle, um sicherzustellen, dass alle Membervariablen vom Benutzer sinnvoll initialisiert werden: QList braucht einen Default-Konstruktor, dadurch kann dann der Benutzer das Objekt mit einem Default-Konstruktor instanziieren und ein paar Member-Variablen setzen und den Rest uninitialisiert lassen. – Die Sicherheit ist dadurch verloren gegangen. Das sind alles Probleme, die ich erst seit C++ kenne und die andere moderne Sprachen nicht haben.


Dann kann man Java auch emulieren und mit referenzen / zeigern arbeiten. Wenn das Objekt default-Konstruierbar sein muss: wrappen (unique_ptr, for instance).
Sonst soweit auch erstmal ein Problem mit Qt...

_________________
http://assets.amuniversal ....... 067f90134cb84005056a9545d
Unregistrierter





Beitrag Unregistrierter 12:42:12 18.10.2016   Titel:              Zitieren

Java hat das Problem, dass final nicht const ist. Das stimmt. Insgesamt halte ich es aber für sicherer.

Zum Wrappen: Das habe ich später auch im Internet gelesen, aber dass ich dann Objekte auf dem Heap anlegen muss, ist auch nicht das Gelbe vom Ei.

Zu Qt: Ja, mag ein Problem von Qt sein, aber Qt macht C++ erst interessant. Crossplattform-Entwicklung macht man bei C++ mit Qt. Die Konkurrenz deckt bestenfalls eine Teilmenge von Qt ab. Qt bietet wirklich alle Standard-Techniken in einem Guss an.
floorball
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.04.2012
Beiträge: 198
Beitrag floorball Mitglied 10:36:54 23.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Zum Wrappen: Das habe ich später auch im Internet gelesen, aber dass ich dann Objekte auf dem Heap anlegen muss, ist auch nicht das Gelbe vom Ei.

Demnach besteht Java nur aus Eiweiß.
Unregistrierter





Beitrag Unregistrierter 10:43:52 23.10.2016   Titel:              Zitieren

floorball schrieb:
ShadowClone schrieb:
Zum Wrappen: Das habe ich später auch im Internet gelesen, aber dass ich dann Objekte auf dem Heap anlegen muss, ist auch nicht das Gelbe vom Ei.

Demnach besteht Java nur aus Eiweiß.

Größtenteils, ja. Und dank Qt, wird C++ auch zu einem Eiweiß-Klumpen, wenn man so vorgehen will, wie ich es oben beschrieben habe.


Zuletzt bearbeitet von Unregistrierter am 10:44:33 23.10.2016, insgesamt 1-mal bearbeitet
Kenner der User
Unregistrierter




Beitrag Kenner der User Unregistrierter 11:47:14 24.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Zu Qt: Ja, mag ein Problem von Qt sein, aber Qt macht C++ erst interessant. Crossplattform-Entwicklung macht man bei C++ mit Qt. Die Konkurrenz deckt bestenfalls eine Teilmenge von Qt ab. Qt bietet wirklich alle Standard-Techniken in einem Guss an.
Meine Güte, wenn ich nur schon den Benutzernamen ShadowClone lese, dann weiß ich schon, dass da irgendein Stuss zu Qt kommt. Selbiges hier, genau so sehr fehl am Platz: https://www.c-plusplus.net/forum/p2512288#2512288
Was kommt als nächstes? LLVM, Root und Caffe sollte man von C++ komplett nach Java umschreiben, weil es für C++ kein Argument gibt, da diese Bibliotheken kein Qt benutzen?
Andromeda
Mitglied

Benutzerprofil
Anmeldungsdatum: 09.12.2006
Beiträge: 1705
Beitrag Andromeda Mitglied 12:32:38 24.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Java hat das Problem, dass final nicht const ist.

Wieso ist das ein Problem?

_________________
Phuck Donald Trump! https://www.youtube.com/watch?v=0s1dDerMe5o
Unregistrierter





Beitrag Unregistrierter 12:41:09 24.10.2016   Titel:              Zitieren

Andromeda schrieb:
ShadowClone schrieb:
Java hat das Problem, dass final nicht const ist.

Wieso ist das ein Problem?

Weil sich das final bei Objekten nur auf die Referenz/Pointer bezieht und du die Member der Objekten immer noch manipulieren kannst. Das ist bei Klassen, die immutabel sein sollen bspw. ein Problem, da du nicht drum rumkommst ein Deep Copy zu machen, wenn du Parameter entgegen nimmst bzw. Member-Instanzen zurückgibst.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 13:18:38 24.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Andromeda schrieb:
ShadowClone schrieb:
Java hat das Problem, dass final nicht const ist.

Wieso ist das ein Problem?

Weil sich das final bei Objekten nur auf die Referenz/Pointer bezieht und du die Member der Objekten immer noch manipulieren kannst. Das ist bei Klassen, die immutabel sein sollen bspw. ein Problem, da du nicht drum rumkommst ein Deep Copy zu machen, wenn du Parameter entgegen nimmst bzw. Member-Instanzen zurückgibst.


Wenn eine Class immutabel sein soll, nennt man das final vor dem Schlüsselwort class!


Zuletzt bearbeitet von Zeus am 13:18:56 24.10.2016, insgesamt 3-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 13:56:54 24.10.2016   Titel:              Zitieren

Zeus schrieb:
ShadowClone schrieb:
Andromeda schrieb:
ShadowClone schrieb:
Java hat das Problem, dass final nicht const ist.

Wieso ist das ein Problem?

Weil sich das final bei Objekten nur auf die Referenz/Pointer bezieht und du die Member der Objekten immer noch manipulieren kannst. Das ist bei Klassen, die immutabel sein sollen bspw. ein Problem, da du nicht drum rumkommst ein Deep Copy zu machen, wenn du Parameter entgegen nimmst bzw. Member-Instanzen zurückgibst.

Wenn eine Class immutabel sein soll, nennt man das final vor dem Schlüsselwort class!


Ist in Java nicht so einfach.

https://docs.oracle.com/j ....... /concurrency/imstrat.html
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 17:25:58 24.10.2016   Titel:              Zitieren

Doch sehr einfach! Das Pattern ist so einfach zu verstehen wie C++ Const nicht transitiv ist.
Unregistrierter





Beitrag Unregistrierter 18:16:00 24.10.2016   Titel:              Zitieren

Es ist aber nicht damit getan die Klasse final zu machen, wie von dir eingangs behauptet.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 18:18:26 24.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Es ist aber nicht damit getan die Klasse final zu machen, wie von dir eingangs behauptet.


Nein hab ich nie behauptet wo steht das?
Unregistrierter





Beitrag Unregistrierter 18:36:33 24.10.2016   Titel:              Zitieren

Das ist mir jetzt echt zu doof. ;)
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 09:37:17 25.10.2016   Titel:              Zitieren

eigentlich ist es ziemlich egal, welche programmiersprache du im endeffekt nimmst und es gibt auch kein besser. die "java-menschen" reden nur so schlecht über c++, weil sie eben zuerst java gelernt haben, und umgekehrt reden die "c++-menschen" so schlecht über über java, weil sie zuerst c++ gelernt haben, und beide haben dann so ihre gewohnheiten.

aber wie gesagt: im endeffekt ist es egal.
Jockelx
Mitglied

Benutzerprofil
Anmeldungsdatum: 18.12.2009
Beiträge: 1154
Beitrag Jockelx Mitglied 11:01:41 25.10.2016   Titel:              Zitieren

Quark. Ich hab zuerst C64-Basic gelernt und das werde ich hier sicher nicht als gut anpreisen.
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 12:16:03 25.10.2016   Titel:              Zitieren

und ich hab zuerst c gelernt und wollte es jetzt mal mit common lisp probieren, sofern ich die zeit dafür finde. :rolleyes:

aber trotzdem bleibe ich dabei, dass zwischen c++ und java kein wirklich gravierender unterschied besteht, die leute aber wegen irgendwelcher, mehr oder weniger sinnfreier, sprachbestandteile und entsprechender gewohnheiten der meinung sind, dass die jeweils andere sprache schlechter ist. :D
Unregistrierter





Beitrag Unregistrierter 12:45:34 25.10.2016   Titel:              Zitieren

HansKlaus schrieb:
aber trotzdem bleibe ich dabei, dass zwischen c++ und java kein wirklich gravierender unterschied besteht, die leute aber wegen irgendwelcher, mehr oder weniger sinnfreier, sprachbestandteile und entsprechender gewohnheiten der meinung sind, dass die jeweils andere sprache schlechter ist. :D

Das ist Quatsch. Die Syntax ist vll. ähnlich, aber Java kommt für verschiedene Anwendungsgebiete erst gar nicht in Betracht. Z. B. Treiber-, OS-Programmierung, Embedded auch eher ungeeignet, Real-Time, alles, was niedrigen Speicherverbrauch und wenig Latenz haben soll.
Auskenner
Unregistrierter




Beitrag Auskenner Unregistrierter 13:09:13 25.10.2016   Titel:              Zitieren

HansKlaus schrieb:
eigentlich ist es ziemlich egal, welche programmiersprache du im endeffekt nimmst und es gibt auch kein besser.
HansKlaus schrieb:
aber trotzdem bleibe ich dabei, dass zwischen c++ und java kein wirklich gravierender unterschied besteht, die leute aber wegen irgendwelcher, mehr oder weniger sinnfreier, sprachbestandteile und entsprechender gewohnheiten der meinung sind, dass die jeweils andere sprache schlechter ist. :D

Ach du lieber Himmel, du hast ja mal gar keine Ahnung.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 13:10:31 25.10.2016   Titel:              Zitieren

Ja-Ne, deswegen gibt es auch JavaOS (https://en.wikipedia.org/wiki/JavaOS) und Java Embedded (http://www.oracle.com/technetwork/java/embedded/overview/index.html).
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 14:21:52 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:
HansKlaus schrieb:
aber trotzdem bleibe ich dabei, dass zwischen c++ und java kein wirklich gravierender unterschied besteht, die leute aber wegen irgendwelcher, mehr oder weniger sinnfreier, sprachbestandteile und entsprechender gewohnheiten der meinung sind, dass die jeweils andere sprache schlechter ist. :D

Das ist Quatsch. Die Syntax ist vll. ähnlich, aber Java kommt für verschiedene Anwendungsgebiete erst gar nicht in Betracht. Z. B. Treiber-, OS-Programmierung, Embedded auch eher ungeeignet, Real-Time, alles, was niedrigen Speicherverbrauch und wenig Latenz haben soll.


Dafür würde ich spontan C verwenden und nicht C++
Unregistrierter





Beitrag Unregistrierter 14:31:45 25.10.2016   Titel:              Zitieren

Zeus schrieb:
Ja-Ne, deswegen gibt es auch JavaOS (https://en.wikipedia.org/wiki/JavaOS) und Java Embedded (http://www.oracle.com/technetwork/java/embedded/overview/index.html).

Du kommst mir zunehmend vor wie ein Troll. Gehen tut vieles – gut, ist wieder eine andere Frage.
Ich kann auch ein Spiel 100% in Python schreiben, einen Browser auch – geht. :rolleyes:
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 14:41:57 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Zeus schrieb:
Ja-Ne, deswegen gibt es auch JavaOS (https://en.wikipedia.org/wiki/JavaOS) und Java Embedded (http://www.oracle.com/technetwork/java/embedded/overview/index.html).

Du kommst mir zunehmend vor wie ein Troll. Gehen tut vieles – gut, ist wieder eine andere Frage.
Ich kann auch ein Spiel 100% in Python schreiben, einen Browser auch – geht. :rolleyes:


Eine Gegenfrage wie oft schreibst du Embedded Code mit welche Sprache für welches Systeme?
Unregistrierter





Beitrag Unregistrierter 14:47:45 25.10.2016   Titel:              Zitieren

HansKlaus schrieb:
ShadowClone schrieb:
Das ist Quatsch. Die Syntax ist vll. ähnlich, aber Java kommt für verschiedene Anwendungsgebiete erst gar nicht in Betracht. Z. B. Treiber-, OS-Programmierung, Embedded auch eher ungeeignet, Real-Time, alles, was niedrigen Speicherverbrauch und wenig Latenz haben soll.

Dafür würde ich spontan C verwenden und nicht C++

Keine Ahnung wie du zu diesem Schluss kommst. Jedenfalls zeigt das doch, dass nicht alle Programmiersprachen alle "gleich gut" (O-Ton) sind. "Gut", ist immer auf das Anwendungsgebiet bezogen. – Ok, dann gibt es Sprachen, die tendenziell obsolet sind. Wie C z. B. :p
Unregistrierter





Beitrag Unregistrierter 14:54:14 25.10.2016   Titel:              Zitieren

Zeus schrieb:
ShadowClone schrieb:
Zeus schrieb:
Ja-Ne, deswegen gibt es auch JavaOS (https://en.wikipedia.org/wiki/JavaOS) und Java Embedded (http://www.oracle.com/technetwork/java/embedded/overview/index.html).

Du kommst mir zunehmend vor wie ein Troll. Gehen tut vieles – gut, ist wieder eine andere Frage.
Ich kann auch ein Spiel 100% in Python schreiben, einen Browser auch – geht. :rolleyes:

Eine Gegenfrage wie oft schreibst du Embedded Code mit welche Sprache für welches Systeme?

Ich bin mal ganz kurz auf diesen Gleis aufgesprungen und hab ein Praktikum bei einem Automobilzulieferer gemacht. Dort wurde C/C++ verwendet. Die Mikrokontroller hatten RAM im kilobyte-Bereich. Stell dir vor, jemand drückt auf die Bremse und es springt erst mal der GC an.
Java wird in Embedded nie und nimmer so intensiv verwendet wie C/C++.
Was ich momentan mache, ist als Werkstudent bei einem Anlagenbauer für Inspektionssysteme zu arbeiten. Und obwohl die Rechner dort ordentlich Power haben, wird dort ebenfalls C++ verwendet. Ok – zugegeben tatsächlich auch Python, aber diese Python-Libs greifen wiederum auf C- und Fortran-Libs zu. Sind also eher Python-Wrapper und wie gesagt haben die Rechner auch ordentlich Power.


Zuletzt bearbeitet von Unregistrierter am 14:55:46 25.10.2016, insgesamt 1-mal bearbeitet
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 15:07:13 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:

Stell dir vor, jemand drückt auf die Bremse und es springt erst mal der GC an.
Java wird in Embedded nie und nimmer so intensiv verwendet wie C/C++.


kannste nicht wissen. es gibt auch realtime-java: https://www.jcp.org/en/jsr/detail?id=282
und preisgünstige und energieeffiziente mcu's mit viel ram und rechenleistung (arm) gibt es auch immer mehr.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Unregistrierter





Beitrag Unregistrierter 15:13:04 25.10.2016   Titel:              Zitieren

swapper schrieb:
kannste nicht wissen. es gibt auch realtime-java: https://www.jcp.org/en/jsr/detail?id=282
und preisgünstige und energieeffiziente mcu's mit viel ram und rechenleistung (arm) gibt es auch immer mehr.

Realtime heißt nicht, dass es dieselbe kurze Latenz hat wie C/C++.
Dann ist das auch eine Kostenfrage:
- Muss ich Lizenzgebühren bezahlen?
- Wie viel mehr muss ich für die Aufstockung der Hardware zahlen?

Wenn ich mehrere Millionen Einheiten pro Jahr verkaufe, dann sind das alles keine irrelevanten Faktoren.

Andere, wichtige Faktoren:
- An welche Plattformen binde ich mich überhaupt, wenn ich Java verwende?
- Wie robust ist überhaupt die Laufzeitumgebung?
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 15:21:49 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:

Wenn ich mehrere Millionen Einheiten pro Jahr verkaufe, dann sind das alles keine irrelevanten Faktoren.

so ist es. dann kann schon ein passives bauteil zum entscheidenden kostenfaktor werden. das führt sogar soweit, dass man versucht, mit irgendwelchen software-tricks hardware zu sparen.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 19:19:14 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:

Keine Ahnung wie du zu diesem Schluss kommst.

C ist - meiner Meinung nach - eine schlanke und schnelle Programmiersprache und - ebenfalls meiner Meinung nach - bestens dafür geeignet, solche Abläufe zu programmieren. mit C++ kann man das zwar auch alles schön machen, aber eben nur, weil C (naja oder sowas ähnliches) da immer schön mitgeschleppt wird.

Zitat:

Jedenfalls zeigt das doch, dass nicht alle Programmiersprachen alle "gleich gut" (O-Ton) sind. "Gut", ist immer auf das Anwendungsgebiet bezogen.

naja und wofür verwendet man c++ und java hauptsächlich? mir fallen da spontan erst einmal computerspiele und irgendwelche "endanwendersoftware" (emailclients, terminplaner usw) ein und das kann man beides super mit c++ und java programmieren.

Zitat:

– Ok, dann gibt es Sprachen, die tendenziell obsolet sind. Wie C z. B. :p

also c++ wird ja scheinbar zunehmend durch java ersetzt. :D zumindest bei mir an der fh wird jedenfalls java zur einführung in die programmierung verwendet, damit die informatiker lernen, in oop zu denken, weil das ja so super wichtig ist und c++ ja nur eine hybridsprache darstellt und die armen leutchen mit dem ganzen gefährlichen zeugs, das c++ so bietet, ja alle überfordert werden. dieses gefühl verstärkt sich sogar noch, wenn ich hier lese, dass die meisten stellenangebote java verlangen und nicht c++.

aber die e-ingenieure verwenden eigentlich nur c, daher halte ich "c ist obsolet" für eine sehr gefährliche aussage. :rolleyes:
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 19:48:22 25.10.2016   Titel:              Zitieren

HansKlaus schrieb:

aber die e-ingenieure verwenden eigentlich nur c, daher halte ich "c ist obsolet" für eine sehr gefährliche aussage. :rolleyes:

der spruch dass c veraltet ist, kommt doch nur von ahnungsosen c++ fanboys.
c ist zwar alt, aber unsterblich.
--> http://beza1e1.tuxen.de/articles/spirit_of_c.html

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
cppvsjava
Unregistrierter




Beitrag cppvsjava Unregistrierter 20:10:44 25.10.2016   Titel:              Zitieren

Zitat:

C ist - meiner Meinung nach - eine schlanke und schnelle Programmiersprache und - ebenfalls meiner Meinung nach - bestens dafür geeignet, solche Abläufe zu programmieren. mit C++ kann man das zwar auch alles schön machen, aber eben nur, weil C (naja oder sowas ähnliches) da immer schön mitgeschleppt wird.

Egalwat, da wird absolut gar nichts mitgeschleppt. So manches reines C kompiliert nicht mit einem C++-Compiler. C++ ist eine Sprache die auf ihren eigenen Füßen steht, ihre eigene Features bereitstellt und mit der man aufs Auge genau so performanten Code rausbekommt als mit C. Wenn nicht sogar noch besseren, weil es vorgefertigte Musterlösungen im Standard gibt, die einem das Leben vereinfachen und es ja schlussendlich nur auf den Programmierer drauf ankommt, wie gut er sein Ding implementiert.
Unregistrierter





Beitrag Unregistrierter 21:21:22 25.10.2016   Titel:              Zitieren

Irgendjemand hier, hat diesen Vortrag verlinkt:

https://www.youtube.com/watch?v=zBkNBP00wJE

Hier wird C++ (17) verwendet, um ein Spiel für einen 35 Jahre alten Computer zu programmieren. Der Vortragende zeigt Beispiele, wie C++ Abstraktion mit null Overhead in Assembler kompiliert wird.

Kurz gesagt: C++ kann ebenfalls schlank und effizient sein und das bei besserer Sicherheit und besserer Wartbarkeit als C.

Btw: Kenne ich nur ein Spiel, das in Java programmiert ist und das ist Minecraft. Für so ne grottige Grafik soll es laut Aussagen von Kollegen trotzdem leistungshungrig sein.
Unregistrierter





Beitrag Unregistrierter 21:41:03 25.10.2016   Titel:              Zitieren

Auch sehr interessant:
Zitat:
CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 21:47:10 25.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Auch sehr interessant:
Zitat:
CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU


Sehr interessant C++ im Abwärtstrend im Embeddedbereich.
Unregistrierter





Beitrag Unregistrierter 21:51:53 25.10.2016   Titel:              Zitieren

Zeus schrieb:
ShadowClone schrieb:
Auch sehr interessant:
Zitat:
CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU


Sehr interessant C++ im Abwärtstrend im Embeddedbereich.

Und Java im einstelligen Bereich. :D
Das mit C++ ist aber wirklich nicht gerechtfertigt.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 08:39:44 26.10.2016   Titel:              Zitieren

ShadowClone schrieb:

Und Java im einstelligen Bereich. :D
Das mit C++ ist aber wirklich nicht gerechtfertigt.


Das Jukt mich echt nicht! Eher solche Leute die allgemeine Halbwissen wie du verbreitest.


Zuletzt bearbeitet von Zeus am 08:40:00 26.10.2016, insgesamt 2-mal bearbeitet
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 09:22:57 27.10.2016   Titel:              Zitieren

cppvsjava schrieb:

Egalwat, da wird absolut gar nichts mitgeschleppt. So manches reines C kompiliert nicht mit einem C++-Compiler. C++ ist eine Sprache die auf ihren eigenen Füßen steht, ihre eigene Features bereitstellt und mit der man aufs Auge genau so performanten Code rausbekommt als mit C. Wenn nicht sogar noch besseren, weil es vorgefertigte Musterlösungen im Standard gibt, die einem das Leben vereinfachen und es ja schlussendlich nur auf den Programmierer drauf ankommt, wie gut er sein Ding implementiert.


also ich finde, dass c einfacher zu programmieren ist, als c++. irgendwo ist es doch auch "performant", wenn das programm schneller geschrieben werden kann, oder nicht? also c++ muss ja nicht unbedingt oo programmiert werden, aber irgendwie ist das alles komisch und hat unnötig viele funktionen.

andererseits sollen wir grad an der fh im rahmen von mixed reality irgendwelche fußballroboter über ein spielfeld schieben. das ist alles komplett in java geschrieben, funktioniert alles wunderbar und ist trotzdem schnell.


Zuletzt bearbeitet von HansKlaus am 09:24:03 27.10.2016, insgesamt 1-mal bearbeitet
cpp_Jungspund
Mitglied

Benutzerprofil
Anmeldungsdatum: 10.06.2015
Beiträge: 163
Beitrag cpp_Jungspund Mitglied 08:00:38 28.10.2016   Titel:              Zitieren

Einen Roboter anzusteuern ist auch nichts rechenintensives. Lass dein Programm mal vier Millionen Matrixmultiplikationen oder Eigenwerte von 10000x10000 Matrizen berechnen und vergleiche dann die Performance Unterschiede.
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 13:59:41 28.10.2016   Titel:              Zitieren

da würde ich dann glaub ich auch wieder c verwenden. angeblich kann man sogar c-Programme in Java einfügen. :rolleyes:

also dass Java ziemlich langsam ist, ist mir sehr wohl bekannt. aber c++ soll auch nicht immer an c rankommen. ;)
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 14:37:44 28.10.2016   Titel:              Zitieren

HansKlaus schrieb:

da würde ich dann glaub ich auch wieder c verwenden. angeblich kann man sogar c-Programme in Java einfügen. :rolleyes:


diese schnittstelle nennt sich jni (java native interface).
und in der tat: java und c in kombination lassen keine wünsche mehr offen. :)

das java auf android-geräten hat sogar einen eingebauten c-dialekt für besonders rechenintensive aufgaben: https://developer.android ....... renderscript/compute.html

wer braucht noch c++?
c++ wurde mal gehyped wie xml. dadurch kam es groß raus, wovon es noch bis heute zehrt. aber richtig gut war c++ nie.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Unregistrierter





Beitrag Unregistrierter 09:49:53 29.10.2016   Titel:              Zitieren

Leute, was ist denn an C besser? Die verlinkten Videos zeigen doch, dass C++ mind. so schnell ist wie C. In manchen Fällen sogar noch schneller. Dafür habe ich oben drauf noch mehr Sicherheit und kann im Schnitt den Code besser pflegen.
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 18:30:27 29.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Leute, was ist denn an C besser?

c++ ist mit features überladen. c++ programme tendieren zur überkomplexität. ein guter c++ coder muss nicht nur ein erfahrener fachmann sein, sondern auch extrem diszipliniert vorgehen. c++ hat viel-viel mehr fallstricke als c. c ist dagegen recht pimitiv und leicht zu lernen. das trifft auf c++ leider nicht zu.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Unregistrierter





Beitrag Unregistrierter 20:33:10 29.10.2016   Titel:              Zitieren

Allein durch RAI und die bessere Typisierung fallen viele Fallstricke von C weg.
Die STL ist außerdem sehr sinnvoll und performant. Bspw. ist std::copy im Gegensatz zu memcpy nicht nur typsicher, sondern tendenziell auch etwas performanter!

http://stackoverflow.com/ ....... y-in-terms-to-performance
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 20:49:58 29.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Allein durch RAI und die bessere Typisierung fallen viele Fallstricke von C weg.


die problemchen von c, die c++ zu beiseitigen versucht, werden üblicherweise gegen einen ganzen sack voll eigener probleme getauscht.

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump
Unregistrierter





Beitrag Unregistrierter 21:33:32 29.10.2016   Titel:              Zitieren

Ohne Beispiele bleiben das Behauptungen.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 21:57:26 29.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Allein durch RAI und die bessere Typisierung fallen viele Fallstricke von C weg.
Die STL ist außerdem sehr sinnvoll und performant. Bspw. ist std::copy im Gegensatz zu memcpy nicht nur typsicher, sondern tendenziell auch etwas performanter!

http://stackoverflow.com/ ....... y-in-terms-to-performance


Ach du love!
Ist nicht dein Ernst?


Hast du dir dein Source Code angeschaut?
Weißt du, dass das vor 5 Jahren war?
Außerdem Speedtest mit einem Compiler?

OMG!
Unregistrierter





Beitrag Unregistrierter 22:29:16 29.10.2016   Titel:              Zitieren

Kannst du drehen und wenden wie du willst. Die verlinkten Videos kommen zum selben Schluss: C++ ist mind. genau so schnell wie C und dies bei mehr Sicherheit und Wartbarkeit.
Die C++ Leute liefern wenigsten und räumen mit Mythen auf. Leute wie du kommen nur mit Behauptungen und nörgeln rum.
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 771
Beitrag swapper Mitglied 04:20:04 30.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Ohne Beispiele bleiben das Behauptungen.


das netz ist voller beispiele: http://horstmann.com/cpp/pitfalls.html

sogar aktuell hier im forum: https://www.c-plusplus.net/forum/340285

_________________
“It’s freezing and snowing in New York. We need global warming!” -- Donald J. Trump


Zuletzt bearbeitet von swapper am 04:42:27 30.10.2016, insgesamt 1-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 08:21:55 30.10.2016   Titel:              Zitieren

Mal davon abgesehen, dass C diese auch hat und diese gewiss nicht schön sind: Compilerwarnungen sind mittlerweile eine große Hilfe.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 10:46:26 30.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Kannst du drehen und wenden wie du willst. Die verlinkten Videos kommen zum selben Schluss: C++ ist mind. genau so schnell wie C und dies bei mehr Sicherheit und Wartbarkeit.
Die C++ Leute liefern wenigsten und räumen mit Mythen auf. Leute wie du kommen nur mit Behauptungen und nörgeln rum.


An wem ist das Adressiert?
Ich persönlich bin Software Engineer. Ich brauch kein Language War. Außerdem hab ich das Recht eine andere Meinung als irgendwer im Netz zu sein. Copy vs Memcopy ist ja so lächlich weil der Compiler und deren Runtime Implementieren lebendige Software ist, was ist wenn die heutige gcc 5% mehr raushaut? C Compiler und C++ beu GNU sind mindesten zwei verschiedenen Branches unter Umständen von zwei verschiedenen Entwicklergruppe gepflegt und du willst mir weiß machen das irgendein Beitrag der mit eine Version testet, sein Beitrag zum Fakt wird? Ich bitte dich. Außerdem benutzt dein Video nicht zero cost abstraction. Sowas gibst nicht in C++, Bjarne Stroustrup redet von
B. Stroustrup schrieb:
zero-overhead principle: What you don't use, you don't pay for
in The Design and Evolution of C++. Addison Wesley, ISBN 0-201-54330-3.
March 1994.

In C++ musst du
- für Objektorientierung zahlen
- für Template Mechanismen zahlen

Aber umsonst ist nix, die Frage ist ob es effizienter ist, aber das wiederum ist die Implementierung!
Unregistrierter





Beitrag Unregistrierter 11:50:16 30.10.2016   Titel:              Zitieren

Zeus schrieb:

In C++ musst du
- für Objektorientierung zahlen
- für Template Mechanismen zahlen

Für die anderen, die diesen Quatsch tatsächlich glauben:

Klassen haben nicht per se Overhead. Den hat man nur, wenn du virtuelle Funktionen benutzt.

Templates: Der Code wird komplett zur Compilezeit erstellt. Den einzigen "Overhead" den man hat, ist, dass der Code für jeden Datentyp dupliziert wird. Das wirkt sich jedoch meist positiv auf die Laufzeit aus (deswegen hat man es ja gemacht). Der einzige Umstand, wo es sich negativ auswirkt, ist, wenn der Code nicht mehr in den CPU-Cache passt. Aber auch hier gilt: Niemand zwingt einen das zu benutzen. Allein durch Klassen, RAI und bessere Typsicherheit, ist viel gewonnen.

Mit dir Zeus, ist jegliche Diskussion beendet.
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 11:59:35 30.10.2016   Titel:              Zitieren

Aber Klassen und schöne Fehlervermeidung habe ich bei Java doch auch.
cppvsjava
Unregistrierter




Beitrag cppvsjava Unregistrierter 11:59:50 30.10.2016   Titel:              Zitieren

Zitat:
- für Template Mechanismen zahlen

Ich nehme mal an du sprichst über den Kompiliervorgang. Dann ja, manchmal muss ich mich echt am Kopf fassen, wenn ich irgendwas von Boost kompiliere.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 12:13:29 30.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Zeus schrieb:

In C++ musst du
- für Objektorientierung zahlen
- für Template Mechanismen zahlen

Für die anderen, die diesen Quatsch tatsächlich glauben:

Klassen haben nicht per se Overhead. Den hat man nur, wenn du virtuelle Funktionen benutzt.

Templates: Der Code wird komplett zur Compilezeit erstellt. Den einzigen "Overhead" den man hat, ist, dass der Code für jeden Datentyp dupliziert wird. Das wirkt sich jedoch meist positiv auf die Laufzeit aus (deswegen hat man es ja gemacht). Der einzige Umstand, wo es sich negativ auswirkt, ist, wenn der Code nicht mehr in den CPU-Cache passt. Aber auch hier gilt: Niemand zwingt einen das zu benutzen. Allein durch Klassen, RAI und bessere Typsicherheit, ist viel gewonnen.

Mit dir Zeus, ist jegliche Diskussion beendet.


Du hast ja nix wiederlegen können? Also wo ist der Quatsch? Was ist der Blödsinn was ich sagte?

Wie willst du objektorientierte Pattern verwenden ohne dynamischen Dispatcher zu benutzen? Es geht nicht oder du nimmst Substitionstechniken! Außerdem hab ich nie von Overhead geredet. Im Kern kannst du meine Aussage nicht wiederlegen. Du musst bezahlen. Egal wie du es machst.
Halsabschneider
Unregistrierter




Beitrag Halsabschneider Unregistrierter 19:30:02 30.10.2016   Titel:              Zitieren

Zeus schrieb:
In C++ musst du für Objektorientierung zahlen
In C++ lässt sich auch statischer Polymorphismus implementieren, der absolut keine Indirektionen zur Folge hat. Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.
Außerdem ist dein Argument von Grund auf invalide, denn für Funktionszeiger in C oder für call/jmp zahlt man genauso. Die Abstraktion, die C++ hierbei bietet, beläuft sich lediglich darauf, dass man sich nicht mehr selbst um die Funktionszeigern kümmern muss, wie man es in C müsste. Diese Abstraktion ist in der Tat ohne zusätzliche Kosten; im Gegenteil, sie erlaubt sogar noch besseren Code dank den aufgezählten Optimierungen.
Zeus schrieb:
In C++ musst du für Template Mechanismen zahlen
Ganz klar falsch. "Template-Mechanismen" evaluieren während der Compile-Zeit zu gewöhnlichem C++-Code und werden, wie alles andere, zu nativem Code kompiliert. Ferner erlauben sie Techniken wie Expression Tempaltes oder Spezialisierung, die zu noch performanterem Zielcode führen.
Zeus schrieb:
wiederlegen
Zeus schrieb:
An wem ist das Adressiert?
Ich persönlich bin Software Engineer. Ich brauch kein Language War. Außerdem hab ich das Recht eine andere Meinung als irgendwer im Netz zu sein. Copy vs Memcopy ist ja so lächlich weil der Compiler und deren Runtime Implementieren lebendige Software ist, was ist wenn die heutige gcc 5% mehr raushaut?
Lern zuerst Deutsch, du Analphabet, bevor du hier dein jämmerliches Halbwissen zu Programmiersprachen äußerst.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 21:06:04 30.10.2016   Titel:              Zitieren

Halsabschneider schrieb:
Zeus schrieb:
In C++ musst du für Objektorientierung zahlen
In C++ lässt sich auch statischer Polymorphismus implementieren, der absolut keine Indirektionen zur Folge hat. Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.
Außerdem ist dein Argument von Grund auf invalide, denn für Funktionszeiger in C oder für call/jmp zahlt man genauso. Die Abstraktion, die C++ hierbei bietet, beläuft sich lediglich darauf, dass man sich nicht mehr selbst um die Funktionszeigern kümmern muss, wie man es in C müsste. Diese Abstraktion ist in der Tat ohne zusätzliche Kosten; im Gegenteil, sie erlaubt sogar noch besseren Code dank den aufgezählten Optimierungen.


Woher kommen die Berechnungen zu devirtualisierung her, holt sie dein C++ Compiler aus eine andere Dimension, damit die keine Kosten haben?

Halsabschneider schrieb:

Zeus schrieb:
In C++ musst du für Template Mechanismen zahlen
Ganz klar falsch. "Template-Mechanismen" evaluieren während der Compile-Zeit zu gewöhnlichem C++-Code und werden, wie alles andere, zu nativem Code kompiliert. Ferner erlauben sie Techniken wie Expression Tempaltes oder Spezialisierung, die zu noch performanterem Zielcode führen.


Ja genau der Compiler musst während des Compilezeit Typeinstanziierung von Template berechnen, Instanziierung ausführen und das Ergebnis zurückschreiben - Holt sich der Compiler diese Berechnungen aus eine andere Dimension damit sie nix kosten?


Zuletzt bearbeitet von Zeus am 21:38:48 30.10.2016, insgesamt 4-mal bearbeitet
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 21:25:23 30.10.2016   Titel:              Zitieren

Halsabschneider schrieb:
Moderne C++-Compiler beherrschen außerdem Devirtualization. In C++ zahlt man also unter dem Strich deutlich weniger für Objektorientierung als in anderen OO-Sprachen.


DO ist im LLVM implementierung und kann von jeden Compilerentwickler für seine Programmiersprache verwenden. Es ist nicht C++ exclusiv!
Unregistrierter





Beitrag Unregistrierter 22:15:19 30.10.2016   Titel:              Zitieren

Da klammert sich jemand an die letzten Grashalme. Da sagt er, dass da (zur Compilezeit) sehr wohl Kosten entstehen, um dann danach zu sagen, dass diese Kosten bei C auch entstehen können.
Mal davon abgesehen, dass man lieber Compiletime-Kosten in Kauf nimmt als Runtime-Kosten (ein Release-Build macht man sowieso viel seltener). Da vermischt jemand ganz gehörig Dinge bzw. tut das absichtlich um auf Teufel komm raus recht behalten zu wollen. Wirklich armselig...
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 22:36:31 30.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Da klammert sich jemand an die letzten Grashalme. Da sagt er, dass da (zur Compilezeit) sehr wohl Kosten entstehen, um dann danach zu sagen, dass diese Kosten bei C auch entstehen können.
Mal davon abgesehen, dass man lieber Compiletime-Kosten in Kauf nimmt als Runtime-Kosten (ein Release-Build macht man sowieso viel seltener). Da vermischt jemand ganz gehörig Dinge bzw. tut das absichtlich um auf Teufel komm raus recht behalten zu wollen. Wirklich armselig...


Erstens, wolltest du die Diskussion nicht mit mir beenden? Warum meldest du dich überhaupt?

Vorallen, kannst du überhaupt denken? Du schießt dich so sehr ein auf 'kosten'. Das du total vergießt, dass man sich darüber noch über Struktur und Wertigkeit (im Vergleich) reden könnten.

Außerdem bist du doch gar nicht an eine sinnvolle Diskussion interessiert. Du hast dich schon mit deine ersten Provokation disqualifiziert
ShadowClone schrieb:
Von wegen C++ und typsicher!
C++:
int x = 2;
if (x = 1) {
    std::out << "Na klaro!" << std::endl;
}


Also Mr.Cpp-Papst, predige C++ weil es eine Ingenieursprache ist :D, aber bitte meide es objektive sich darüber auszutauschen.
Unregistrierter





Beitrag Unregistrierter 22:45:46 30.10.2016   Titel:              Zitieren

Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 22:51:52 30.10.2016   Titel:              Zitieren

ShadowClone schrieb:
Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!


D.h. implizite Typkonvertierung schwächen C++ typensicherheit?
wenn ja, dann passt dein Post,
wenn nein, dann ist dein Post unsinn.

Meine Meinung ist nein.
Unregistrierter





Beitrag Unregistrierter 22:53:17 30.10.2016   Titel:              Zitieren

Zeus schrieb:
ShadowClone schrieb:
Verdreh keine Dinge. Der Eingangspost hat Java mit C++ verglichen und es hieß, dass C++ typsicherer als Java sei. In diesem Kontext konnte ich nicht zustimmen, aber ich kann darin zustimmen, dass C++ typsicherer als C ist! – Hat alles Hand und Fuß!


D.h. implizite Typkonvertierung schwächen C++ typensicherheit?

Ja.
zufallswert
Unregistrierter




Beitrag zufallswert Unregistrierter 18:16:38 31.10.2016   Titel:   Re: Java vs. C++            Zitieren

cppvsjava schrieb:

Jetzt schreibe und (ein bisschen) lese ich C++ seit ungefähr 6 bis 8 Jahren. Dann dacht ich mir, ein guter Programmierer, der kann mehr als nur eine Sprache.

Kann er ja auch. Mit C++ kannst Du eine blockstrukturierte Sprache (C), eine objektorientierte Sprache, eine generische Sprache, eine funktionale Sprache (Template Meta). 4 für einen Preis, ein echtes Schnäppchen.
cppvsjava schrieb:

Und dann habe ich Java gemacht.

Ach Du warst das ?! :eek:
cpp_Jungspund
Mitglied

Benutzerprofil
Anmeldungsdatum: 10.06.2015
Beiträge: 163
Beitrag cpp_Jungspund Mitglied 11:29:28 01.11.2016   Titel:              Zitieren

Vielleicht sollten sich die Gemüter zu dem Thema etwas entspannen und einen Film ansehen :) https://www.youtube.com/watch?v=RnqAXuLZlaE
wie bitte?
Unregistrierter




Beitrag wie bitte? Unregistrierter 14:09:40 19.11.2016   Titel:              Zitieren

C++ ist langsamer als C, wenn man Objektorientierung benutzt (Konstruktoren, Destruktoren, mehr Daten...). Ansonsten ist das doch C, welches mit einem C++-Compiler compiliert wurde.
JulianH
Mitglied

Benutzerprofil
Anmeldungsdatum: 05.11.2012
Beiträge: 167
Beitrag JulianH Mitglied 17:19:31 05.01.2017   Titel:              Zitieren

Eines der größten Probleme wird wohl bleiben, dass die meisten Leute überhaupt nicht in der Lage sind entscheiden zu können, welche Sprache die Richtige für ihr Problem ist.

MMn. trifft es dieser Spruch am besten:
"C++ ist eine der meist genutzten Sprache, obwohl diese so scheiße schwer und kompliziert ist."
Java hingegen ist nur einfach.


Zuletzt bearbeitet von JulianH am 17:25:06 05.01.2017, insgesamt 3-mal bearbeitet
Kritischer Geist
Unregistrierter




Beitrag Kritischer Geist Unregistrierter 05:22:16 06.01.2017   Titel:              Zitieren

Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 228
Beitrag HansKlaus Mitglied 19:37:24 16.01.2017   Titel:              Zitieren

grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

da brauchst du keine benchmarks für.
Tobiking2
Mitglied

Benutzerprofil
Anmeldungsdatum: 12.04.2009
Beiträge: 962
Beitrag Tobiking2 Mitglied 07:00:58 17.01.2017   Titel:              Zitieren

HansKlaus schrieb:
grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

Die JVM hat auch einen JIT Compiler aus dem Opcodes rauspurzeln. Die Begründung passt also nicht.
Kritischer Geist
Unregistrierter




Beitrag Kritischer Geist Unregistrierter 07:27:11 17.01.2017   Titel:              Zitieren

Kritischer Geist schrieb:
Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?
*push*
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3042
Beitrag Zeus Mitglied 09:32:50 17.01.2017   Titel:              Zitieren

Tobiking2 schrieb:
HansKlaus schrieb:
grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

Die JVM hat auch einen JIT Compiler aus dem Opcodes rauspurzeln. Die Begründung passt also nicht.


C++:
class jvm
{
stack<call_frame> callStack;
stream<byte_code> byteCode;
mapped_file<native_code> nativeCode;
map<byte_code*, native_code*> codeCache;
}


Ach wieso nicht? Nur weil Opcodes generiert wird?
C++ Forum :: Java ::  Java vs. C++   Auf Beitrag antworten

Zeige alle Beiträge auf einer Seite




Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht mitmachen.

Powered by phpBB © 2001, 2002 phpBB Group :: FI Theme

c++.net ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de Werbekostenerstattung verdient werden kann.

Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info und www.c-plusplus.net enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt (vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden. Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.