malloc/free

[Jaroslav Buchta]

Podle me se hodi tyto funkce v MCU na tyto ucely.
- alokace objektu u kterych predem (pri prkladu) neni znama delka a 
ktere uz budou "nafurt"
- alokace docasnych objektu (buffery pro sprintf, komunikaci...) s velmi 
kratkou zivotnosti, treba jen behem jedne funkce
Za techto okolnosti nevznika problem s plytvanim pameti.
A pak mame C++, treba arduino knihovny, kde se dynamicky alokuje jak o 
zivot kazda blbost a taky to funguje.
Ja bych to uplne nezatracoval. IMHO je dobre, aby se trvale existujici 
objekty alokovaly pri startu aplikace a pak se pokud mozno nemenily a ty 
ostatni aby zas nebyly nikdy trvaleho charakteru a hlavne, aby se to 
nemichalo a nevznikaly tak diry.

Dne 03.11.2016 v 2:48 Jan Waclawek napsal(a):
> Suhlasim s Tvojim nesuhlasom tak ako si ho sformuloval ;-)
>
> Ale ak povodnu otazku mierne preformulujeme na "existuje sposob ktorym sa
> dosiahne upratanost pamate aj za cenu zmeny pointrov", tak odpoved je
> znova "to zavisi od kniznice"; a ak je otazka "moze existovat [to iste]"
> tak odpoved je "ano, preco by nemohlo".
>
> Samozrejme sa ta zmena pointrov neudeje poza chrbat uzivatela, ale na jeho
> explicitnu poziadavku (v ktorej sa tie pointre musia odovzdavat kniznici a
> tie zmenene naspat aplikacii). V podstate realloc je taky prototyp
> takehoto niecoho - a ak by vadila ta klauzula o lifetime, tak aj ten nas
> mechanizmus mozeme nazvat tak, ze ide o funkciu/funkcionalitu (lebo to
> moze byt trebars sada funkcii s nejakym predpisanym postupom pouzitia),
> ktora dealokuje stare a naalokuje nove polia pri zachovani relevantnej
> casti obsahu.
>
> Samozrejme sa jedna o rozsirenie mimo standard, ale take rozsirenia su
> nielen bezne ale pre pouzitelnost celeho tohto mechanizmu takmer
> nevyhnutne, napr. uz len kvoli poziadavke "univerzalneho zarovnania" ktore
> bude ocividne neoptimalne, a v praxi znamena, ze konformny malloc() moze
> byt na nejakej exotickejsej platforme neimplementovatelny (pretoze nikde v
> norme nie je poziadavka ze musi existovat mechanizmus na univerzalne
> zarovnanie objektov a univerzalnu konvertibilitu void*, prave naopak)...
>
> Akurat som sa povodne nechcel rozpisovat - vo svetle toho, ze v drvivej
> vacsine pripadov je to pre mcu neuzitocne a pre tu drvivu mensinu je
> obvykle v(y)hodnejsie si napisat vlastny alokator. Dynamicka alokacia
> najma s pouzitim kniznicnych funkcii v mcu az prilis casto poukazuje skor
> na nekompetentnost programatora...
>
> wek
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list