OOP vs PP compile size

asc

kellerassel schrieb:

c++ kompiliert einfach total langsam :p

Mag sein, ich kann aber mit Compilezeiten von 1-2 Minuten (nach Clean) für unser Projekt leben. Außerhalb der VM wäre es bei etwa 30 Sekunden. Größenordnung etwa etwas unter einer halben Million Codezeilen, verhältnismäßig wenige C++ Templates (Von etwas STL-Einsatz einmal abgesehen).

SeppJ

cooky451 schrieb:

asc schrieb:

Wobei man in C++ die Programmgröße durch Templates wohl aufblähen kann (Anderseits bekommt man dafür Typsicherheit).

Davon merkt man was nach dem Kompilieren? oO

Ja. Dafür ist es aber eventuell schneller, weil für jeden Typen eine optimierte Version erzeugt werden kann. Die void*-Technik in C stellt hingegen eine praktisch unüberwindliche Optimierungshürde dar, auch wenn dadurch natürlich die erzeugten Funktionen nur einmal erzeugt werden müssen.

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.

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.

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

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

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

knivil schrieb:

Auf welches Konto soll ich die 2 Cent ueberweisen?

ich bin doch nicht larry page :p

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

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.

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

dfgdfg schrieb:

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

..., wenn man kein forth kann

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.

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.