OOP vs PP compile size

[hustbaer]

@Le Fox
Ein Programm ist sowohl in C als auch in C++ ziemlich genau so gross und so schnell wie du es machst.

In C++ ist es bloss viel einfacher unabsichtlich etwas zu machen was dazu führt dass das Programm viel grösser oder etwas langsamer wird als es sein müsste.

Dafür ist C++ halt auch die wesentlich angenehmere Sprache.

[kellerassel]

SeppJ schrieb:

Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.

ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem. zumindest wenn der code als src vorliegt. warum das nicht gemacht wird, ist mir sowieso schleierhaft

das würde einen großteil der c vs c++ benchmarks umwerfen

[kellerassel]

kellerassel schrieb:

warum das nicht gemacht wird, ist mir sowieso schleierhaft

btw. der richtige c progger braucht das eh nicht, der behilft sich einfach mit einem #define qsort :p

[dot]

kellerassel schrieb:

SeppJ schrieb:

Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.

ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem.

Wie genau soll ein Compiler das deiner Meinung nach anstellen? Ich kenn zumindest keinen, der das tut...

kellerassel schrieb:

das würde einen großteil der c vs c++ benchmarks umwerfen

Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...

[kellerassel]

dot schrieb:

kellerassel schrieb:

SeppJ schrieb:

Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.

ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem.

Wie genau soll ein Compiler das deiner Meinung nach anstellen? Ich kenn zumindest keinen, der das tut...

ich auch nicht, aber hab ja schon geschieben, dass ich das feature nicht brauch

dot schrieb:

kellerassel schrieb:

das würde einen großteil der c vs c++ benchmarks umwerfen

Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...

wir waren gerade an dem punkt, wo templates eine stdlib funktion outperformen was aber faktisch ein äpfel/birnen vergleich ist.

und wenn wir die diskussion noch weiterführen, kommen wir sicher iwann zu dem punkt, wo du mir erzählen willst, dass c++ einen 2x+ schnelleren algo implementiert hat, der sich in c nicht umsetzen lässt, weil das die sprache nicht hergibt

[dot]

kellerassel schrieb:

dot schrieb:

kellerassel schrieb:

das würde einen großteil der c vs c++ benchmarks umwerfen

Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...

wir waren gerade an dem punkt, wo templates eine stdlib funktion outperformen was aber faktisch ein äpfel/birnen vergleich ist.

Stimmt, natürlich kann man nicht direkt Features zweier Sprachen vergleichen, wenn eine der beiden Sprachen kein vergleichbares Feature hat. Man kann aber dennoch feststellen, dass eine der beiden Sprachen kein vergleichbares Feature bietet und daher gewisse Dinge in dieser Sprache einfach nicht möglich sind bzw. gewisse Dinge in der anderen Sprache viel besser gehen...

[kellerassel]

ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen. damit ist das thema für mich durch

wenn du mir nicht glaubst dass es die gibt, und es dir das wert ist, mir meinen stundenlohn zu zahlen bekommst eins

[knivil]

Auf welches Konto soll ich die 2 Cent ueberweisen?

[dot]

kellerassel schrieb:

ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen.

Wäre das nicht Äpfel mit Birnen vergleichen?

Btw: Das coole an C++ ist, dass dort sowohl Äpfel als auch Birnen wachsen können...

[kellerassel]

knivil schrieb:

Auf welches Konto soll ich die 2 Cent ueberweisen?

ich bin doch nicht larry page :p

[kellerassel]

dot schrieb:

kellerassel schrieb:

ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen.

Wäre das nicht Äpfel mit Birnen vergleichen?

Btw: Das coole an C++ ist, dass dort sowohl Äpfel als auch Birnen wachsen können...

das einzig coole was ich der sprache abringen kann, ist, dass sie vielen lowlevel entwicklern nicht taugt, was dazu führt, dass ich damit bei meinen highlevel programmen nicht oft in kontakt komm. DAS ist

[kellerassel]

aber hey, wir sind doch freie entwickler und jeder kann verwenden was er will und wie bei weibern hat jeder einen anderen geschmack, so kommt man sich zumindest nicht in die quere

[Bitte ein Bit]

das einzig coole was ich der sprache abringen kann, ist, dass sie vielen lowlevel entwicklern nicht taugt,

Och, mann kann auch sehr C lastig in C++ programmieren.

was dazu führt, dass ich damit bei meinen highlevel programmen nicht oft in kontakt komm. DAS ist

aufwendig, da C++ doch einiges mehr an syntaktischen Zucker hat ?

Übrigens: Man munkelt das im Embedded Bereich Java immer mehr Einzug in die Mikrokontroller-Wert hält.

[kellerassel]

Bitte ein Bit schrieb:

das einzig coole was ich der sprache abringen kann, ist, dass sie vielen lowlevel entwicklern nicht taugt,

Och, mann kann auch sehr C lastig in C++ programmieren.

ein furchtbares kauderwelsch, da sind wir uns doch hoffentlich einig.

Bitte ein Bit schrieb:

was dazu führt, dass ich damit bei meinen highlevel programmen nicht oft in kontakt komm. DAS ist

aufwendig, da C++ doch einiges mehr an syntaktischen Zucker hat ?

mag sein.

Bitte ein Bit schrieb:

Übrigens: Man munkelt das im Embedded Bereich Java immer mehr Einzug in die Mikrokontroller-Wert hält.

was soll mir das jetzt sagen? die seite an der ich zzt bastel wird mein letztes projekt und ich denke nicht, dass die programmiersprache ieinen einfluss am misserfolg hat. in zukunft investier ich mein geld lieber in reisen mit koks und nutten, dann hab ich zumindest was davon

[buchstaben]

dfgdfg schrieb:

Noch ein Nachtrag: Schnell und klein schließt sich häufig gegenseitig aus.

..., wenn man kein forth kann

[ich bins]

std::sort ist ein Algorithmus aus der C++ Standardlibrary. Hier wird nach OOP vs PP gefragt. std::sort ist aber kein OOP, auch wenn es aus der C++ Standardlibrary kommt. Gerade in der C++ Standardlibrary ist vieles eher (aus guten Grund) prozedural gelöst. Das schöne an C++ ist, dass man die Wahl hat.

Und zur eigentlichen Frage: im Prinzip ist es für die Codegrösse egal, ob man objektorientiert oder prozedural denkt, plant und programmiert. Es ist nur viel einfacher in C++ komplexere Sachen zu machen.

[asc]

ich bins schrieb:

std::sort ist aber kein OOP, auch wenn es aus der C++ Standardlibrary kommt. Gerade in der C++ Standardlibrary ist vieles eher (aus guten Grund) prozedural gelöst.

Korregiere mich, aber soviel ich weiß ist std::sort ist generisch, und verwendet ggf. auch andere Implementierungen (Templatespezialisierung) die dann nicht zwangsweise prozedural sein müssen.

[ich bins]

Es geht doch darum, dass std::sort einfach eine Funktion ist. Dass eine Funktion auch eine Liste von Objekten sortieren kann, macht aus der Funktion kein Element der objektorientierten Programmierung. Ein objektorientiertes Sort wäre so etwas wie:

somecontainer.sort();

Da wird ein sort als Member eines Continerobjektes aufgerufen. In C++ geht das aber so:

std::sort(somecontainer.begin(), somecontainer.end());

Häufig denkt man, dass objektorientiert besser ist als Prozedural, aber das ist ein Beispiel, wo die prozedurale Schreibweise flexibler ist. In C++ hat man halt die Wahl. Man kann je nach Situation das passendste Instrument wählen. Oft kommt dann so eine Mischung aus objektorientiert und prozedural. Und das ist auch gut so.

Es gibt Sprachen, die unterstützen nur objektorientierte Programmierung. Dann kommt so was komisches raus wie

Math.sin(1.2)

Da muss dann eine Funktion in ein Objekt gepackt werden, auch wenn es eigentlich nur eine Funktion ist.

[Zeus]

ich bins schrieb:

Es gibt Sprachen, die unterstützen nur objektorientierte Programmierung. Dann kommt so was komisches raus wie

Math.sin(1.2)

Da muss dann eine Funktion in ein Objekt gepackt werden, auch wenn es eigentlich nur eine Funktion ist.

Von Java ist also nicht die Rede, obwohl das sehr wohl ein Java Beispiel ist.

[Nexus]

ich bins schrieb:

Ein objektorientiertes Sort wäre so etwas wie:

somecontainer.sort();

Da wird ein sort als Member eines Continerobjektes aufgerufen.

Das ist die typisch engstirnige Sichtweise von Objektorientierung: Alles in einer Klasse ist OOP, alles ausserhalb nicht.

Es spricht nichts dafür, dass object.function() objektorientierter ist als function(object) − das ist nur Syntax. Programmierparadigmen sind mehr als das.