Olyan egyszerű C++ program, amit OOP-ben könnyebb megírni vagy gyorsabban fut le, mintha másképp lenne megírva?

Mármint? A C++ eleve OOP. Pontosan mire vágysz? Hogyan hasonlítanád össze? Milyen processzoron, operációs rendszeren?

Általában az OOP-t arra találták ki, hogy bonyolult programokat könnyebb legyen megírni mint pl. sima C-ben vagy más nyelven. Az OOP általában nem arról "híres", hogy takarékosan bánna a CPU-val meg a memóriával. Mégis az összköltsége alacsonyabb lesz, mert ma már a fejlesztés, tesztelés, módosítás költsége magasabb mint a hardveré. A volt főnököm végzett ezzel kapcsolatban méréseket, számításokat. És mutatta nekünk, hogy nem véletlen, hogy az OOP kitalálása után jó pár év(tized) eltelt az elterjedésig, ameddig a hardver nagyon drága volt, vagy nagyon korlátos volt (pl. amíg a PC memóriája 640kByte volt max. még bajosabb volt egy OOP-ben írt nagyobb program, a nagyobb memória igény miatt). A futásidő meg ma már nem csak a kódtól hanem a fordítótól (és oprendszertől is) függ, mennyire képes a fordító optimalizálni. Pl. régi tankönyvek sokat írnak az optimalizációról (pl. Knuth több helyen írja, hogy a nem megfelelően végzett optilamizáció ártalmasabb mintha nem is csinálnánk). Alapvetően továbbra is igaz: fejlesztés munkaigénye - memória használat - sebesség összefügg. Ha nagyon a sebességre törekszik valaki annak memória igénye és fejlesztés igénye nagyobb. Ha a memóriára optimalizálunk akkor is a fejleszét igény lesz nagyobb és lassabb lesz a program. Ma egyértelműen az a trend, hogy a hardver ára elenyésző a fejlesztés költségéhez, gazdaságosabb 3x gyorsabb procit betenni, akár 10x annyi memóriával, mint az, hogy még egy évig tartson egy fejlesztés.

Kettes, jót írsz, de a C++ nem OOP, hanem OOP is. Azaz, multiparadigmás nyelv.

Azzal még kiegészíteném, hogy az OOP mint paradigma, jellemzően csak nagyobb szoftverrendszerek esetén gazdaságos, mert kisebb programok és bizonyos speciális programok esetén gazdaságosabb a procedurális fejlesztés, vagy éppen nem is opció az OOP.

4: Feltehetően nem voltam egyértelmű amikor azt írtam: "Általában az OOP-t arra találták ki, hogy bonyolult programokat könnyebb legyen megírni mint pl. sima C-ben vagy más nyelven."

Az, hogy ma már egy "Hello world!" programot OOP-ben írnak meg (ld. pl. python) és lefordítva 45Mbyte az picit "erős". De ha leszűkítem a C++-ra akkor igazad van.

Én felpontozom, most áll 61 %-on és a válaszom elküldése után nyomok egy zöldet. Bár ilyen válaszolókkal lenne tele a GYK.

A kérdező feltett korábban egy kérdést, az alatt én válaszoltam neki de egy kérdését válasdz nélkül hagytam, annak szeretett volna itt nekifutni, legalábbis úgy sejtem.

Ami kiegészítést tettem, azt nem annyira neked, inkább más itt megfordulóknak szántam.

Nem csak azt.

Az OOP egy olyan struktúrát ad az egész rendszernek, amit később is könnyű variálni, átdolgozni, tovább építeni.

Ezért cserébe elég sokat harap a RAM-ból is és a CPU időből is.

Az OOP alapvetően hosszabb kódot eredményez, ami több munka, tehát a kisebb programok esetében nem nagyon éri meg, mert azok így is átláthatók, nem igényelnek olyan komoly tervezést. Nem térül meg az OOP-s megvalósítás.

A driverek sem OOP-ben íródnak és úgy általában a HW közeli dolgok sem.

Arra a kérdésedre nem lehet egyértelmű, egzakt választ adni, hogy mit éri meg OOP-ben és mit procedurálisan vagy funkcionálisan leprogramozni.

A funkcionális és az oop között nincs jelentős hw igény eltérés. Mindkettő módszerrel lehet optimalizált kódot írni. És direkt optimalizáltat írtam, mivel az, hogy "gyors", meg "sokat harap a memóriából / cpu -ból" erősen szubjektív és kinek mi a sok.

Alapvetően egy program, ami különböző matematikai feladatokat számol ki (terület, kerület, térfogat) akár funkcionálisan akár oop írod meg, mindenképpen közel hasonló lesz az erőforrás igénye, mert az erőforrás jelentős része így is úgy is a számításokra fog elmenni, és ez lényegében az összes programra igaz.

A minimális különbséget pedig az okozza, hogy a funkcionális programozásban nagyon sok feltételed lesz, amit ki kell értékeljen a processzor, és sok olyan változót kell létrehoznia, amelyeket a memóriában kell tárolnia. Az oop esetén ugyan nem lesz sok feltételed, ott inkább az egyes objektumok betöltése lesz az, ami erőforrást fog igényelni. De mint írtam ez nem jelentős különbség.

Az oop előnye a fejlesztés területén jelentkezik, mivel rendkívül költséghatékony. A kód újrafelhasználható lesz (lásd library-k), e miatt az újabb projektekre kevesebb fejlesztési időt kell fordítani, amit munkabérre fordítva máris költséget spórol. A kódod tud csatlakozni 3rd party programokhoz vagy akár a tied is lehet olyan, ami csatlakozik másokéhoz 3rd party-ként (pluginok). Ezen kívül jelentősen kisebb a költsége a bővíthetőségnek, karbantarthatóságnak, tesztelhetőségnek.

És a költségek nem csak ott jelentkeznek, hogy milyen a kód, hanem ott is, hogy mennyien tudnak rajta dolgozni. Egy funkcionálisan fejlesztett programon maximum 2, nagyon jó kommunikáció esetén 3 ember tudna dolgozni. Nah, egy átlagos AAA játékot 100+ programozó fejleszt és így is évekbe telik a fejlesztési idő. Akkor ezt számold át max 3 emberre. De ne túlozzunk ennyire, legyen olyan sofware amit 20 ember fejleszt. Funkcionális programozással az is teljes kudarc lenne.

Ha nem lenne oop a legtöbb program, akkor nem tudnál az operációs rendszeredre programokat telepíteni, mivel nem lenne megfelelő kapcsolódási pont. Csak abba gondolj bele, hogy sok "multiplatformos" program létezik. Megy windowson, macen, linuxon. Azt ne hidd, hogy mondjuk egy Adobe a 20+ fő softwarét 2 külön operációs rendszerre fejleszti (windows, macos) és tartja karban, meg updateli stb. A program önmagában ugyan az mindkét oprendszeren, csak van a teljes kód felett egy réteg, amivel csatlakozik az adott oprendszerre. OOP nélkül ezt nem lehetne megvalósítani.

A HW közeli programozás más tészta, mivel ott technikai okok miatt nincsen lehetőség az oop megvalósítására + ott nem is cél, hiszen hw specifikusan kódolnak le valamit, és nem cél hogy az a kód újrafelhasználható legyen vagy bővíthatő vagy csatlakozzon más programokhoz. De még ott is írnak fölé egy oop layert, amivel majd más programok tudnak rácsatlakozni, hogy használni tudják a HW-t, ezt hívjuk drivernek. A driver, ha nem lenne oop, akkor teljesen használhatatlan lenne. Ezen kívül a low level miatt van az a fő probléma, hogy minden oprendszerre egyedi drivert kell fejleszteni, mert mindegyik másképp kezeli a hw-t, ezt hívjuk KERNEL -nek. E miatt van az, hogy egyes HW gyártók bizonyos oprendszereket favorizálnak, ugye ebből a szempontból a windows a nyerő, Apple ezt úgy oldotta meg, hogy saját specifikus hw-t gyárt, és így nem kell más oprendszerrel foglalkoznia, a linux meg azzal dolgozik amit a community lefejleszt (sajnos mára már inkább csak elavult régi driverek vannak forkolva meg tákolva).

9:(2021.06.12. 11:27). Nagyon nincs igazad. OOP esetén az optimalizáció jelentős részét a fordító program csinálja vagy jól vagy kevésbé jól. De pont az objektumok tulajdonságai és a C-ben "alap" érték szerinti függvény hívások miatt (és a C++-ban is láthatunk olyat,hogy egész nagy objektumokat "dobál" érték szerint) eleve nő a memória igény.

HW közeli programozás:

Miért ne lenne lehetőség ott az OOP-re? Mi tiltja? Sajnos semmi, egyre több helyen látunk OOP-vel hibásan megírt HW közeli dolgokat, amik aztán a rengeteg "feleslegesen mozgatott" adat miatt sok memóriát eszik és lassú. Vannak még nagyon időkritikus alkalmazások ott még mindig célszerűbb sok esetben az assembly (pl. egycsipes mikrogépek, mikrokontrollerek stb. esetén) de már azoknál is egyre kisebb kódrészleteket írnak "hagyományos" módon (pl. egy interupt rutin, ahol lényeg, hogy a lehető elggyorsabb legyen).

“HW közeli programozás:

Miért ne lenne lehetőség ott az OOP-re? ”

Nálunk is az megy. Arm-re épül a rendszer, és speckó linux fut rajta, a bázis nagy részét objektumorientáltan készítik.