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 23: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: 8636
Beitrag Gregor Moderator 16: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 00:44:01 16.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 12: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 14: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 14: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: 6751
Beitrag dot Mitglied 14: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 14:50:04 16.10.2016, insgesamt 1-mal bearbeitet
y0da
Unregistrierter




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

Begun teh flamewar haz. :cool:
Swordfish
Mitglied

Benutzerprofil
Anmeldungsdatum: 27.03.2005
Beiträge: 5627
Beitrag Swordfish Mitglied 20: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: 779
Beitrag swapper Mitglied 15: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 15: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: 779
Beitrag swapper Mitglied 16: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 18: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: 779
Beitrag swapper Mitglied 20: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 20:18:43 17.10.2016, insgesamt 1-mal bearbeitet
5cript
Mitglied

Benutzerprofil
Anmeldungsdatum: 14.03.2009
Beiträge: 1956
Beitrag 5cript Mitglied 12: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 13: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 13:17:49 18.10.2016, insgesamt 1-mal bearbeitet
5cript
Mitglied

Benutzerprofil
Anmeldungsdatum: 14.03.2009
Beiträge: 1956
Beitrag 5cript Mitglied 13: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 13: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: 200
Beitrag floorball Mitglied 11: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 11: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 11:44:33 23.10.2016, insgesamt 1-mal bearbeitet
Kenner der User
Unregistrierter




Beitrag Kenner der User Unregistrierter 12: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: 2021
Beitrag Andromeda Mitglied 13:32:38 24.10.2016   Titel:              Zitieren

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

Wieso ist das ein Problem?

_________________
My Browser User Agent String is Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.6) Gecko/20100101 Firefox/10.0.6
Unregistrierter





Beitrag Unregistrierter 13: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: 3070
Beitrag Zeus Mitglied 14: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 14:18:56 24.10.2016, insgesamt 3-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 14: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: 3070
Beitrag Zeus Mitglied 18: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 19: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: 3070
Beitrag Zeus Mitglied 19: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 19:36:33 24.10.2016   Titel:              Zitieren

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

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 10: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: 19.12.2009
Beiträge: 1203
Beitrag Jockelx Mitglied 12: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: 262
Beitrag HansKlaus Mitglied 13: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 13: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 14: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: 3070
Beitrag Zeus Mitglied 14: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: 262
Beitrag HansKlaus Mitglied 15: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 15: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: 3070
Beitrag Zeus Mitglied 15: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 15: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 15: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 15:55:46 25.10.2016, insgesamt 1-mal bearbeitet
swapper
Mitglied

Benutzerprofil
Anmeldungsdatum: 02.08.2016
Beiträge: 779
Beitrag swapper Mitglied 16: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 16: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: 779
Beitrag swapper Mitglied 16: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: 262
Beitrag HansKlaus Mitglied 20: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: 779
Beitrag swapper Mitglied 20: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 21: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 22: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 22: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: 3070
Beitrag Zeus Mitglied 22: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 22: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: 3070
Beitrag Zeus Mitglied 09: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 09:40:00 26.10.2016, insgesamt 2-mal bearbeitet
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 10: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 10:24:03 27.10.2016, insgesamt 1-mal bearbeitet
cpp_Jungspund
Mitglied

Benutzerprofil
Anmeldungsdatum: 10.06.2015
Beiträge: 163
Beitrag cpp_Jungspund Mitglied 09: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: 262
Beitrag HansKlaus Mitglied 14: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: 779
Beitrag swapper Mitglied 15: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 10: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: 779
Beitrag swapper Mitglied 19: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 21: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: 779
Beitrag swapper Mitglied 21: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 22:33:32 29.10.2016   Titel:              Zitieren

Ohne Beispiele bleiben das Behauptungen.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 22: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 23: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: 779
Beitrag swapper Mitglied 05: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 05:42:27 30.10.2016, insgesamt 1-mal bearbeitet
Unregistrierter





Beitrag Unregistrierter 09: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: 3070
Beitrag Zeus Mitglied 11: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 12: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: 262
Beitrag HansKlaus Mitglied 12:59:35 30.10.2016   Titel:              Zitieren

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




Beitrag cppvsjava Unregistrierter 12: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: 3070
Beitrag Zeus Mitglied 13: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 20: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: 3070
Beitrag Zeus Mitglied 22: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 22:38:48 30.10.2016, insgesamt 4-mal bearbeitet
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 22: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 23: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: 3070
Beitrag Zeus Mitglied 23: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 23: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: 3070
Beitrag Zeus Mitglied 23: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 23: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 19: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 12: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 15: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 18: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 18:25:06 05.01.2017, insgesamt 3-mal bearbeitet
Kritischer Geist
Unregistrierter




Beitrag Kritischer Geist Unregistrierter 06: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: 262
Beitrag HansKlaus Mitglied 20: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: 971
Beitrag Tobiking2 Mitglied 08: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 08: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: 3070
Beitrag Zeus Mitglied 10: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?
benchm
Unregistrierter




Beitrag benchm Unregistrierter 00:32:38 21.01.2017   Titel:              Zitieren

Kritischer Geist schrieb:
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*

https://benchmarksgame.al ....... p?lang=java&lang2=gpp
Kritischer Geist
Unregistrierter




Beitrag Kritischer Geist Unregistrierter 08:55:07 21.01.2017   Titel:              Zitieren

benchm schrieb:
Kritischer Geist schrieb:
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*

https://benchmarksgame.al ....... p?lang=java&lang2=gpp
Danke! Da schneidet ja C++ immer deutlich besser als Java ab. :)
Gregor
Moderator

Benutzerprofil
Anmeldungsdatum: 16.01.2002
Beiträge: 8636
Beitrag Gregor Moderator 20:00:42 22.01.2017   Titel:              Zitieren

Kritischer Geist schrieb:
benchm schrieb:
Kritischer Geist schrieb:
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*

https://benchmarksgame.al ....... p?lang=java&lang2=gpp
Danke! Da schneidet ja C++ immer deutlich besser als Java ab. :)

Es ist durchaus bekannt, dass C++ Programme etwas schneller als Javaprogramme laufen. Man nutzt Java aber auch nicht, wenn es einem darum geht, das performanteste Programm zu schreiben. Java nutzt man aus anderen Gründen, zum Beispiel könnte die Infrastruktur im Umfeld der Sprache relevant sein und das verfügbare Know-How diesbezüglich. In Sachen Performance reicht es für Java völlig aus, halbwegs in der gleichen Liga wie C++ zu spielen. Wenn Javaprogramme grundsätzlich >10 mal langsamer als C++ Programme wären, dann wäre das für Java wohl ein Problem. So ist es aber nicht.

_________________
"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
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 20:28:30 23.01.2017   Titel:              Zitieren

Kritischer Geist schrieb:
Danke! Da schneidet ja C++ immer deutlich besser als Java ab. :)


das ist jetzt nichts besonderes und eigentlich habe ich dir das ja auch so gesagt. prinzipiell schneidet C sogar noch ein bisschen besser ab, aber jeder, der mal eine grafische oberfläche mit der winapi erstellt hat, weiß diese vereinfachungen, wie java sie mit sich bringt, zu schätzen.
Gast3
Unregistrierter




Beitrag Gast3 Unregistrierter 09:21:52 30.01.2017   Titel:              Zitieren

Zitat:
prinzipiell schneidet C sogar noch ein bisschen besser


Das stimmt so leider gar nicht - wird aber gerne immer und immer und immer wieder angeführt

C++ erlaubt viel besseres inlining (z.B. mit templates) - selbst mit C Macros kommt man nicht auf das Niveau
und auch der schlimme Code-Bloat von denen viele erzählen ist Seemannsgarn das gerne und vielfach von unerfahrenen Entwicklern einfach weiter gesponnen wird
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 21:56:32 01.02.2017   Titel:              Zitieren

Naja es gibt schon Dinge, für die c besser geeignet ist, als c++,einfach weil c schneller ist.
Also ein c-programm ist natürlich ein c++-programm, wenn auch kein gutes, aber warum den c++-compiler mit c-code füttern, statt gleich den richtigen compiler zu nehmen?
dot
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.05.2004
Beiträge: 6751
Beitrag dot Mitglied 21:58:18 01.02.2017   Titel:              Zitieren

HansKlaus schrieb:
Naja es gibt schon Dinge, für die c besser geeignet ist, als c++,einfach weil c schneller ist.

Nope. Du kannst in C++ oft wesentlich schneller sein als in C, langsamer zu sein geht aber nur mit schlechtem Code...

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


Zuletzt bearbeitet von dot am 21:58:33 01.02.2017, insgesamt 1-mal bearbeitet
Gast3
Unregistrierter




Beitrag Gast3 Unregistrierter 08:56:32 02.02.2017   Titel:              Zitieren

Zitat:
für die c besser geeignet ist, als c++,einfach weil c schneller ist.


das ist aber eben definitiv falsch - C ist in keinem Fall schneller als C++ - an was denkst du denn bei solchen Aussagen? die Inline-Fähigkeit von C++ kann man in C nicht oder nur mit sehr viel Aufwand erreichen - du verbreitest schon wieder Geschwindigkeits-Mythen im Internet (das 1. mal hier https://www.c-plusplus.net/forum/p2507658)
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 12:11:04 02.02.2017   Titel:              Zitieren

Gast3 schrieb:
an was denkst du denn bei solchen Aussagen?


hmmm ablaufsteuerungen z.b.?
QSort
Unregistrierter




Beitrag QSort Unregistrierter 15:01:30 05.02.2017   Titel:              Zitieren

Ablaufsteuerungen? Was soll den der Käse?

Im Gegensatz zu C kennt C++ so einige Sprachelemente, die sich zur Kompilierzeit auflösen lassen und womit enorm viel Laufzeit gespart werden kann. Templates, constexpr... machts möglich.

So ist der C++ STL Quicksort sehr viel schneller als der der C Standard Bibliothek. Beides generische Varianten. Der Unterschied ist, dass der C++ Kompiler den Vergleich zweier Elemente einfach inlinen kann und sich pro Vergleich einen Funktionsaufruf spart.

http://www.geeksforgeeks.org/c-qsort-vs-c-sort/

Zitat:

STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function.

STL’s sort runs 20% to 50% faster than the hand-coded quicksort and 250% to 1000% faster than the C qsort library function.


Ein anderes Beispiel ist das Durchsuchen von Lookup Tabellen oder Berechnungen die zur Kompilierzeit ausgeführt werden können, wenn die Eingangsdaten zur Kompilierzeit bekannt sind.

C++:
constexpr int factorial(int n)
{
    return n <= 1? 1 : (n * factorial(n - 1));
}


Das hier rechnet dir der Kompiler zur Kompilierzeit aus, wenn n bekannt ist. Oder eben zur Laufzeit, wenn nicht. Kein extra code.

Und das hier ist nur die Spitze des Eisbergs. C++ ist wesentlich mächtiger als C und trotzdem genauso performant.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 16:17:54 05.02.2017   Titel:              Zitieren

QSort schrieb:

http://www.geeksforgeeks.org/c-qsort-vs-c-sort/

Zitat:

STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function.

STL’s sort runs 20% to 50% faster than the hand-coded quicksort and 250% to 1000% faster than the C qsort library function.




Irgendwelche ein Idiot in Internet postet Sache die mir gefallen.

Theoretisch gibst es kein Unterschied zu Optimierung von einfachen C-Funktionen oder C++ Template Funktion.

Praktisch liegt es an dem Implementierung(Compiler) und/oder am der Person, die die Implementierung benutzt.

Code aus URL (angepasst):
- include eingefügt
- N 100000

Visual Studio 2015
Einstellung Standard

Code:
C:\Users\zeus\Desktop\Project1\Debug>Project1.exe
Time taken by C qsort() - 0.052
Time taken by C++ sort() - 0.175
 
C:\Users\zeus\Desktop\Project1\Release>Project1.exe
Time taken by C qsort() - 0.015
Time taken by C++ sort() - 0.006


Ops C war einmal schneller :eek: :o)


Zuletzt bearbeitet von Zeus am 16:22:48 05.02.2017, insgesamt 1-mal bearbeitet
Th69
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.03.2008
Beiträge: 4396
Beitrag Th69 Mitglied 16:52:00 05.02.2017   Titel:              Zitieren

Naja, im Debug-Mode zu vergleichen ist ja auch völliger Käse - ist als ob du 2 Autos vergleichst, welche mit angezogener Handbremse fahren ;-)
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 17:28:55 05.02.2017   Titel:              Zitieren

also ich hab mir das jetzt eben mal kurz angesehen. wenn ich das richtig verstanden habe, werden da zwei verschiedene sortierverfahren (namentlich quicksort und introsort) gegenüber gestellt. :rolleyes:

außerdem hab ich mir hier mal sagen lassen, dass es nicht gut ist, wenn ich c-funktionen durch den c++-compiler schicke.
QSort
Unregistrierter




Beitrag QSort Unregistrierter 19:56:54 07.02.2017   Titel:              Zitieren

Zeus schrieb:

Irgendwelche ein Idiot in Internet postet Sache die mir gefallen.

Theoretisch gibst es kein Unterschied zu Optimierung von einfachen C-Funktionen oder C++ Template Funktion.

Für generischen Code eben schon.

Zeus schrieb:


Code:
C:\Users\zeus\Desktop\Project1\Debug>Project1.exe
Time taken by C qsort() - 0.052
Time taken by C++ sort() - 0.175
 
C:\Users\zeus\Desktop\Project1\Release>Project1.exe
Time taken by C qsort() - 0.015
Time taken by C++ sort() - 0.006


Ops C war einmal schneller :eek: :o)


Dazu wurde ja alles gesagt.

HansKlaus schrieb:
also ich hab mir das jetzt eben mal kurz angesehen. wenn ich das richtig verstanden habe, werden da zwei verschiedene sortierverfahren (namentlich quicksort und introsort) gegenüber gestellt. :rolleyes:

Nunja introsort ist quicksort, aber da hast du recht. Trotzdem kann die C++ den Vergleich inlinen, C nicht.

Das Einzige was C++ nicht kann aber C, sind restricted pointer. Hab ich aber noch nirgendwo gesehen. C++ hat dafür aber move semantics, (const) references und was mir gerade noch so nicht einfällt. Damit kann man sicher auch Laufzeit sparen.
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 20:49:58 07.02.2017   Titel:              Zitieren

Code:
C:\Users\zeus\Desktop\Project2\Win64\Release>Project1.exe
Time taken by C++ sort() - 0.016
Time taken by C qsort() - 0.031


Code:
C:\Users\zeus\Desktop\Project2\Win64\Release>Project1.exe
Time taken by C qsort() - 0.016


Ohne weitere Worte


Zuletzt bearbeitet von Zeus am 21:37:48 07.02.2017, insgesamt 4-mal bearbeitet
QSort
Unregistrierter




Beitrag QSort Unregistrierter 23:30:14 07.02.2017   Titel:              Zitieren

Echt toll, dass du die Zeit der C++ Version weglässt. Absicht?

Du weißt schon, dass bei jedem Programmdurchlauf andere Werte vorliegen und du deshalb Äpfel mit Birnen vergleichst?

Code:
$ g++ qsort.cpp -O2 -o qsort
$ ./qsort
Time taken by C qsort() - 0.167546
Time taken by C++ sort() - 0.063008
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 10:19:09 08.02.2017   Titel:              Zitieren

Ich vergleiche nix, genau du vergleichst Äpfel mit Birnen :D

Propo sind die Test die ich hier poste nur ein Teil was ich wirklichh poste... es ist nur idotisch von solche Microbrench überhaupt eine Aussage zu treffen.

Oder erkläre mir wieso die C Version auf einmal doppelt/dreimal so schnell wird, wenn man die C++ Version weglässt.

Unter der Prämisse das die Programme unter N mal beobachtet wurden.


Zuletzt bearbeitet von Zeus am 10:30:55 08.02.2017, insgesamt 5-mal bearbeitet
QSort
Unregistrierter




Beitrag QSort Unregistrierter 21:00:01 08.02.2017   Titel:              Zitieren

Zeus schrieb:
Ich vergleiche nix, genau du vergleichst Äpfel mit Birnen :D

Tipp: Wenn du ernst genommen werden willst, lasse andere nicht rätselraten.

Zitat:

Propo sind die Test die ich hier poste nur ein Teil was ich wirklichh poste... es ist nur idotisch von solche Microbrench überhaupt eine Aussage zu treffen.

Oder erkläre mir wieso die C Version auf einmal doppelt/dreimal so schnell wird, wenn man die C++ Version weglässt.

Unter der Prämisse das die Programme unter N mal beobachtet wurden.


Sicher dass du den richtigen Code gelöscht hast? Das Verhalten kann ich nicht nachvollziehen, bei mir bleiben die Laufzeiten stabil und die C Version langsamer (Visual Studio 2015 Release und ebenso mit GCC). Auch seltsam, bei dir dass die C Version auch noch exakt so lang braucht wie C++.

Code:
1
2
3
4
5
6
7
8
9
C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort.exe
Time taken by C qsort() - 0.193
Time taken by C++ sort() - 0.096
 
C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort.exe
Time taken by C qsort() - 0.195
 
C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort
Time taken by C++ sort() - 0.094


C Version
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// C++ program to demonstrate performance of
// C qsort and C++ sort() algorithm
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <ctime>
 
using namespace std;
 
// Number of elements to be sorted
#define N 1000000
 
// A comparator function used by qsort
int compare(const void * a, const void * b)
{
    return (*(int*)a - *(int*)b);
}
 
// Driver program to test above functions
int main()
{
    int arr[N], dupArr[N];
 
    // seed for random input
    srand(time(NULL));
 
    // to measure time taken by qsort and sort
    clock_t begin, end;
    double time_spent;
 
    // generate random input
    for (int i = 0; i < N; i++)
        dupArr[i] = arr[i] = rand() % 100000;
 
    begin = clock();
    qsort(arr, N, sizeof(int), compare);
    end = clock();
 
    // calculate time taken by C qsort function
    time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
 
    cout << "Time taken by C qsort() - "
        << time_spent << endl;
 
    return 0;
}


Warum die C Version ohne den unteren C++ Code plötzlich schneller sein soll, ist sowieso absolut unlogisch. Also keine Ahnung was du da kompiliert hast...
Zeus
Mitglied

Benutzerprofil
Anmeldungsdatum: 25.09.2003
Beiträge: 3070
Beitrag Zeus Mitglied 21:45:43 09.02.2017   Titel:              Zitieren

Sorry, wer diesen Artikel postet, ist nicht ernst zu nehmen!

Code:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <ctime>
 
using namespace std;
 
// Number of elements to be sorted
#define N 100000
 
// A comparator function used by qsort
int compare(const void * a, const void * b)
{
    return (*(int*)a - *(int*)b);
}
 
// Driver program to test above functions
int main()
{
    int arr[N], dupArr[N];
 
    // seed for random input
    srand(time(NULL));
 
    // to measure time taken by qsort and sort
    clock_t begin, end;
    double time_spent;
 
    // generate random input
    for (int i = 0; i < N; i++)
        dupArr[i] = arr[i] = rand() % 100000;
 
    begin = clock();
    qsort(arr, N, sizeof(int), compare);
    end = clock();
 
    // calculate time taken by C qsort function
    time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
 
    cout << "Time taken by C qsort() - "
        << time_spent << endl;
 
    time_spent = 0.0;
 
    begin = clock();
    sort(dupArr, dupArr + N);
    end = clock();
 
    // calculate time taken by C++ sort
    time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
 
    cout << "Time taken by C++ sort() - "
        << time_spent << endl;
 
    return 0;
}


Projectsettings:
Dynamic
- General/Whole Program Optimiziation = Use Link Time Code Generation
- C/C++/Optimization/Optimization = Maximize Speed (/O2)
- C/C++/Optimization/Inline Function Expansion = Default
- C/C++/Code Generation/Runtime Library = Multi-threaded DLL (/MD)
- Linker/Optimization/Link TIme Code Generation = Use Link Time Code Generation (/LTCG)

Static
- General/Whole Program Optimiziation = Use Link Time Code Generation
- C/C++/Optimization = Maximize Speed (/O2)
- C/C++/Optimization/Inline Function Expansion = Any Suitable (/Ob2)
- C/C++/Code Generation/Runtime Library = Multi-threaded (/MT)
- Linker/Optimization/Link TIme Code Generation = Use Link Time Code Generation (/LTCG)

:warning: Inline Function Expansion für Dynamic wurde so gewählt, dass es zu sehen ist, dass Compare aufgerufen wird - ein Nachteil war nicht festzustellen!

Runtime Output
Code:
C:\Users\patri_000\Desktop\Project1\x64\Release>Project1_static.exe
Time taken by C qsort() - 0.012
Time taken by C++ sort() - 0.007
 
C:\Users\patri_000\Desktop\Project1\x64\Release>Project1_dynamic.exe
Time taken by C qsort() - 0.013
Time taken by C++ sort() - 0.006


Profiler Result - Call Tree
Dynamic
1. Project1.exe (100%)
1.1. main (81.82%)
1.1.1. [external code] (59.09%)
1.1.1.1. compare (18.18%)
1.1.2. std::_Sort (22.73%)


Static
1. Project1.exe (100%)
1.1. main (84.21%)
1.1.1. qsort (47.37%)
1.1.2. std::_Sort (21.05%)
1.1.3. std::op < (5.26%)
1.1.4. rand (5.26%)

Conclusion:
- Ohne den Assemblercode zu untersuchen ist eine korrekte Aussage schwer zu treffen.
- der CallTree zeigt, dass die Inline der Compare-Funktion ein Speedup von ≈ 12% -+x beträgt
- die C++ Variante braucht aber knapp die Hälfte der Zeit zum Sortieren
=> die Sortierverfahren waren sowieso nicht vergleichbar um ein Inline-Speedup zu zeigen:
https://de.wikipedia.org/wiki/Introsort schrieb:
Introsort ist ein Sortieralgorithmus. Der Begriff ist eine Kurzform für „introspektives Sortieren“. Der Algorithmus ist eine Variation von Quicksort, welche in entarteten Fällen auf ein anderes Sortierverfahren mit Worst-Case-Laufzeit {\displaystyle {\mathcal {O}}(n\log n)} {\mathcal {O}}(n\log n) (zum Beispiel Heapsort) zurückfällt. Dazu wird zu Beginn jedes Rekursionsschrittes anhand einer Bewertungsfunktion entschieden, ob ein anderer Algorithmus für die Sortierung der Teilliste verwendet werden soll (zum Beispiel bei Erreichen einer bestimmten Rekursionstiefe).


Zuletzt bearbeitet von Zeus am 22:42:09 09.02.2017, insgesamt 6-mal bearbeitet
HansKlaus
Mitglied

Benutzerprofil
Anmeldungsdatum: 19.04.2016
Beiträge: 262
Beitrag HansKlaus Mitglied 21:28:42 15.02.2017   Titel:              Zitieren

QSort schrieb:
Trotzdem kann die C++ den Vergleich inlinen, C nicht.


ähm unter C kannst du den vergleich auch inlinen, indem du ihn einfach inline hinschreibst. also

C:
1
2
3
4
5
6
7
8
9
10
int main()
{
//inhalt von funktion 1
 
//inhalt von funktion 2
 
//...
 
//inhalt von funktion n
}


ist durchaus zulässig und in zeiten von festplattenspeicher im bereich von terabyte und hauptspeicher im bereich von mehreren gigabyte sehr wohl vertretbar.

wenn du dazu noch globale variablen verwendest, sparst du dir sogar noch das ständige push und pop bei den funktionsaufrufen. allerdings kann ich dir aus eigener erfahrung sagen, dass du da bei größeren programmen wahnsinnig bei wirst, sodass das mit vorsicht zu genießen ist.
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1218
Beitrag dachschaden Mitglied 22:28:58 15.02.2017   Titel:              Zitieren

HansKlaus schrieb:
ist durchaus zulässig und in zeiten von festplattenspeicher im bereich von terabyte und hauptspeicher im bereich von mehreren gigabyte sehr wohl vertretbar.


Und zerfickt dir den I-Cache.
Push und Pop auf gecachte Lines ist nicht so ultimativ teuer wie das ständige Nachladen von Instruktionen, weil alles inlined wurde und ständig Cache-Lines rausgeworfen werden, die eigentlich noch gebraucht werden. Wenn du 10.000-mal hintereinander eine Funktion aufrufst, hast du nur Push und Pop, und das braucht nicht mal teuer sein, und der Code ist bereits im I-Cache und muss nicht vom lahmen Hauptspeicher nachgeladen werden. Wenn du stattdessen die 10.000 Aufrufe inlinest, sind Push und Pop weg, aber der Code ist nicht mehr im I-Cache und muss ständig nachgeladen werden.

Ein Cache-Hit kostet (L1) unter 10 Cycles; ein Cache-Miss kann locker 200 Cycles kosten, wenn direkt vom Hauptspeicher geladen werden muss.

HansKlaus schrieb:
wenn du dazu noch globale variablen verwendest, sparst du dir sogar noch das ständige push und pop bei den funktionsaufrufen.


Und dann hast du noch das Problem eventueller TLB-Misses.
Du arbeitest gerade mit einem großen Datenset, aber alles passt noch gerade so in den Cache. Dann greifst du auf deine globale Variable zu, die in einer komplett anderen Page liegt. Der TLB kennt die nicht. Also muss er einen Page-Walk machen. Der ist wahrscheinlich auch direkt ungecacht. Da wünschst du dir die 200-Cycle-Latenz noch, da geht es eher in den 2000 - 4000er Bereich. Abgesehen davon evicted es dir noch dein Datenset. Deswegen willst du Daten in der Regel lokal halten.

Dadurch, dass Sachen gecacht werden, gelten Annahmen, die Anfänger treffen, einfach nicht. Einen Wert wieder und wieder zu berechnen kann schneller sein, als ihn im ungecachten Hauptspeicher zu halten. Meistens will man sich damit auch nicht rumschlagen. Dafür hat man Optimizer in Compilern, die anhand von Heuristiken entscheiden, ob bestimmte Funktionsaufrufe geinlined werden (können). Die sind manchmal nicht die Besten, nein. Aber Pi mal Daumen besser, als was viele Programmierer manuell hingekommen täten.

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute


Zuletzt bearbeitet von dachschaden am 22:30:43 15.02.2017, insgesamt 1-mal bearbeitet
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.