OOP vs PP compile size

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.

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.

Shade Of Mine

Nexus schrieb:

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.

Da mag ich Python:

class OOP:
  def bin_ich_oo(self):
    pass

obj=OOP()
obj.bin_ich_oo() #OOP
OOP.bin_ich_oo(obj) #keine OOP

Nexus schrieb:

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.

Da hast Du sicher recht. Ich kann ja auch in C objektorientiert programmieren, wie ich ja auch in Java oder selbst in Python prozedural programmieren kann. Dennoch verleitet die objekt.member-Notation eher dazu, objektorientiert zu denken. Daher ist die Notation durchaus relevant.

Aber da sind wir schon fast wieder bei der Ausgangsfrage. Sie geht ja davon aus, dass man in C prozedural und in C++ objektorientiert programmiert. Im Prinzip ist das keine Frage der Sprache, sondern was man daraus macht.

Bei C++ wird man in der Regel aufwändigere Lösungen implementieren, da es doch so einfach ist. Mal schnell eine verkettete Liste macht man in C++ mit std::list. In C müsste man die erst mal programmieren und überlegt sich, ob ein einfaches array es nicht auch tun. Daher sind C-Programme in der Regel einfacher und kompakter als C++-Programme.

dot

ich bins schrieb:

Sie geht ja davon aus, dass man in C prozedural und in C++ objektorientiert programmiert.

Das ist aber leider eine falsche Prämisse, denn in C++ programmiert man eben nicht einfach nur objektorientiert. Auch wenn OOP in C++ sicherlich eine große Rolle spielt, so ist das Mischen verschiedenster Stile in C++ fundamental und der Regelfall...

Tachyon

ich bins schrieb:

Bei C++ wird man in der Regel aufwändigere Lösungen implementieren, da es doch so einfach ist. Mal schnell eine verkettete Liste macht man in C++ mit std::list. In C müsste man die erst mal programmieren und überlegt sich, ob ein einfaches array es nicht auch tun. Daher sind C-Programme in der Regel einfacher und kompakter als C++-Programme.

Eine Liste benutzt man dann, wenn man eine Liste wirklich braucht. Das ist in C++ nicht anders wie in C. In C muss ich allerdings für jeden Typen, den ich in einer Liste halten will, neuen Code schreiben oder übleste Macros benutzen. In C++ programmiere ich einmal ein Klassentemplate dafür und benutze es dann immer wieder. Ich persönlich finde ja Letzteres einfacher.

Tachyon schrieb:

In C muss ich allerdings für jeden Typen, den ich in einer Liste halten will, neuen Code schreiben oder übleste Macros benutzen.

das stimmt doch überhaupt nicht

auch wenn ich ein studium anerkenne, so hab ich langsam das gefühl, da wird man so schnell durchgetrieben, dass man mit dem nächsten anfängt, wenn man das alte noch nicht richtig verstanden hat.