OOP pre mikrokontrolér.

[niki31]

Zdravím všetkých a mám otázočku ohľadne OOP pre mikrokontrolér. Zaujíma ma, aká je spotreba pamäti pri vytváraní inštancie nejakej triedy. Povedzme že vytvorím triedu s grafickým ovládačom pre displej. Potom budem vytvárať grafické prvky ako samostatné triedy a v každej potrebujem vytvoriť inštanciu grafického ovládača aby mohol byť prvok vykreslený na obrazovku. Po vykreslení inštanciu objektu zrušiť alebo držať v pamäti, pre ďalšie prekreslenie prvku?

Neviem či je to správny prístup, nikdy som oop pre jednočip nepoužil. Napadlo ma že by mohli byť metody v graf. ovládači statické ale to poruší zapuzdrenie triedy. Potom vyvstáva otázka či má taký prístup vôbec zmysel.

Pohrávam sa s doskou nucleo STM32H7, RAM 512 kB, FLASH 2MB.

[budvar10]

OOP je pre MCU vhodné, úplne bez problémov. Spotreba pamäte nie je závislá od toho, či ide o OOP.
To či objekt budeš mazať je len na probléme, ktorý sa rieši, ale ak sa používa dokolečka dokola a pri MCU je to skoro vždy, nemá to význam.

[peterple]

Čo ja si pamätám tak OOP v C++ na PC prišlo okolo roku 1990 pod MSDOS. A tam bolo max 640kB RAM. Ty máš 2M FLASH + 512KB RAM a máš obavy. Kludne používaj ako len chceš. V inštancii objektu máš navyše len ukazatele na virtuálne funkcie (okrem dát ktoré by tam boli tak či tak). Ostatné veci sú riešené cez vtable triedy a teda sú tam len raz pre všetky objekty.

Zábava začne keď je RAM veľká 2kB Ale aj to sa dá keď sa pozrieš na Arduino.

Druhá vec je vytváranie a rušenie objektov. Jasné je že keď nejaký objekt potrebujem "furt", tak si ho tam nechám "furt".

[niki31]

No, v podstate ste mi potvrdili to čo som si už myslel. Vďaka.

[peterple]

Istý malý háčik tu vidím v tejto vete.

Potom budem vytvárať grafické prvky ako samostatné triedy a v každej potrebujem vytvoriť inštanciu grafického ovládača aby mohol byť prvok vykreslený na obrazovku.

Dúfamže to nemyslíš vážne že v každom grafickom objekte ktorých môže byť tisíce si vytvoríš nanovo inštanciu grafického ovládača.
Grafika je jedna. Ovládač je jeden. Objektom stačí iba ukazateľ na ovládač a nie vždy vytvoriť nový objekt.
To by sa tá RAMka mohla rýchle minúť.

Kolega v práci riešil taký problém že si v cykle vytvoril miliony objektov ktoré potom zrušil. Za cyklom dostal chybu že nie je dosť pamäte. Dosť sa tomu čudoval kedže objekty boli už zničené. Tu je ale treba vidieť trochu aj dovnútra toho jazyka. Išlo o to že to bol C#, objekty sa vytvárali na halde a o uvolňovanie sa pre programátorove pohodlie stará garbage collector. Nuž a ten upratuje ako uzná za vhodné. To isté platí pre JAVA a ďalšie jazyky s GC. Ak sa bavíme o C++ tak tam je to málinko lepšie ale aj tam sa to dá napísať z neznalosti tak že je to neefektívne až hrúza a v PC to zachraňuje iba to že ich výkon je dnes brutálny, čo ale neplatí o malom MCU, kde treba programovať efektívne - teda s rozumom.

[pocitujlasku]

veru, aj mna to prekvapilo. vacsinou sa to robi tak, ze sa mu len da referencia na uz vytvoreny hlavny objekt, teda ten graficky ovladac.
vyhoda je hlavne efektivita, lebo nemusi ho cely inicializovat, co trva urcity cas a nemas v pamati zbytocne kopie.
dalej, co moze byt problem, ze ak pristupuje k hw, tak to ma len jedna instancia a nie niekolko zaroven.

[Tribec Zacks]

niki31,

ovladac urob bud staticky, alebo ak to musi byt class, tak nech to je singleton co moze byt instancovany len raz (mas len jednu grafiku / akcelerator). potom objekty vytvaraj dynamicky ako potreba a posielaj ovladacu. eg. new square.., render(square)...

oop na 32bitoch je uplne v pohode co sa tyka pamate a vykonu. zle je ak nasupes do kodu hlava-nehlava templaty, lambdy, virt. funkcie atd a bude treba debug na low level urovni...
ak budes umierneny s cpp ficurami a vyuzijes cpp skor na organizaciu kodu a v tvojom pripade na veci typu class na text, stvorec, kruh... co maju nejake svoje parametre, tak ti to dost ulahci robotu pri vytvarani rovnakych objektov s inymi parametrami...

[pocitujlasku]

a hlavne vyuzivaj dedicnost. teda class tvar a napr. stvorec bude zdedeny z tvar.
do tvar daj vsetko spolocne, napr. to odoslanie na render, nejake tie pomocne veci...
dost to skrati kod.

[niki31]

Urobil som tu triedu ako statickú pretože vytvoriť odkaz na ovládač v OOP C++, znamená vytvoriť inštanciu.
Práve preto som sa na to pýtal. Toto nieje programovanie vo "Visual studiu". Gcc kompilátor nepozná statickú triedu iba statické metódy a potom vznikajú problémy s prístupom k premenným a členom triedy. A poruší sa aj zapuzdrenie triedy. Toto porušenie zapuzdrenia budem musieť v tomto prípade asi tolerovať.

I

[maskrtnik01]

Tak tomuto príspevku načisto nerozumiem. Vytvoriť pointer na objekt triedy, a inštanciu sú predsa dva rozdielne veci. Tak ako 100 int* môže odkazovať na jednu int premennú, to isté vie aj trieda.

[peterple]

pretože vytvoriť odkaz na ovládač v OOP C++, znamená vytvoriť inštanciu.

S týmto tvrdením prudko nesúhlasím. Ovládač bude inštancia nejakej triedy. Odkaz na ovládač v inom objekte sa dá uchovávať ako ukazateľ, alebo ako referencia (čo je v podstate taký trochu vykastrovaný ukazateľ). Niekde silno tlačia používať iba referencie (Arduino ekosystém) a to z toho dôvodu že si málokto z dnešných kopírovačov kódu vie predstaviť čo to ukazateľ je a ako to funguje a ako ho bezpečne používať.
A ako už bolo uvedené ide to aj opačne. Grafický objekt nemusí mať odkaz na ovládač ale ovládaču sa predhadzujú jednotlivé grafické objekty. Aké si to urobíš také to máš.

(Nieviem či hovoríme tým istým jazykom, v poslednej dobe sa mi často stáva že mladá generácia nerozumie čo hovorím nakoľko si pod odbornými termínmi predstavujú úplne niečo iné ako si predstavujem ja)

[niki31]

No vidíš prudko nesúhlasíš a hneď v druhej a tretej vete píšeš to isté čo som napísal ja.

Viacmenej si ma nepriamo priviedol k náprave. Pôvodne som skúšal vytvoriť jednu inštanciu triedy ako globálnu a tú použiť v celom projekte. Kompilátor mi ale vyhadzoval chyby a nechcel mi to vziať. Problém bol nakoniec v tom že STMCubeIDE generuje projekt ako c. Ja aj keď som kompiloval projekt ako C++, linker mi bral na pozadí main ako c súbor. No a pretože C nepozná triedy nešlo mi vytvoriť ani referenciu na inštanciu triedy. Pridal som teda podmienený preklad ako c++ a už je to v poriadku.

Teraz už referenciu vytvoriť môžem a je viditeľná zo všetkých tried. No a či je OOP vhodná voľba pre môj program, to sa ešte ukáže.

Vďaka za podnety,.

[peterple]

Fakt píšem to isté čo ty? Tak ešte raz, aby to bolo jasné. Ak by platilo čo si napísal tak každý odkaz na objekt by ukazoval na novú inštanciu a teda na nový objekt v pamäti. Tak to ale nefunguje. Vytvorenie odkazu a vytvorenie objektu (jeho inštancie) sú dve nezávislé veci. To znamená že na jeden objekt (jeho jednu konkrétnu inštanciu) môže odkazovať ľubovolný počet odkazov.

[maskrtnik01]

niki31: Odporúčam doštudovať pointery. Akýkoľvek pointer, či je to void, int, enum, struct, class,.. vždy len ukazuje na miesto v pamäti. Takže keď deklarujem pointer na triedu, jediné čo sa alokuje v pamäti sú tie 4/8 bajty pre adresu, žiaden nový objekt triedy.

[Mishung]

Memory management je téma v C++ všeobecne. Keď poserieš memory management tak ti nepostačí ani 32GB RAM.

V tvojom prípade odporúčam naštudovať si smart pointery. Venuješ tomu síce pár večerov ale ušetríš v budúcnosti nepomerné množstvo času ktoré by si strávil naháňaním memory leakov, dangling pointerov atď.

Hovorí sa, že C++ ti dá do rúk celé lano na ktorom sa neskôr môžeš obesiť. Smart pointery ti to lano trochu skrátia.