Co nás ph naučil 1: C a CLASS (diskuse)

[Bedňa]

Mimo tému, ale keď som si 0MQ pozeral, tak som narazil na CurveZMQ. V akom štádiu je posielaie zašifrovaných správ vlastne dnes. Nikdy som to neskúšal, len keď tu o ňom niečo padne preklikám si to a pozriem video.

[sad]

Já se snad to objektové programování naučím, i když vypadá úplně šíleně, ale zřejmě by ho měl běžný programátor ovládat. Ale raději začnu s nějakým skutečně objektovým jazykem, asi C++.

A nebyla to zbytečná práce přepisovat unixové knihovny z procedurálního stylu do objektového?

[Radovan]

"s nějakým skutečně objektovým jazykem, asi C++"

Tak tomuhle jsem se v sobotu po ránu opravdu dobře zasmál

Tohle znáš? O objektu, struktuře a gotu.

[kralyk z abclinuxu]

Tohle znáš? O objektu, struktuře a gotu.

Ehh, to je zas ptákovina. Zas se někdo potřebuje cítit na výši nad ostatními. Někteří k tomuto účelu využívají svou znalost dizajn paternů a entrprajs Javy, jiní zase zalost embedded přístupu. U někoho, kdo pracuje s embedded mě tenhle postoj trochu zamrzel, čekal bych u těhle lidí větší nadhled...

[Bystroushaak]

+1, taky jsem to chtěl napsat (autor se v tom doslova vyžívá i v ostatních článcích), ale pak se mi to nechtělo vysvětlovat.

[Radovan]

Už se ti někdy stalo že se ti nevešel program do Arduina?

[Michal Kubeček]

To, že se nevejde na zásobník, se člověku snadno stane i na x86_64.

[Radovan]

Ne proměnné, ale kód!

[Michal Kubeček]

Není to jedno? Vlastně není: když se nevejde program (binárka) do paměti, přijdu na to nejpozději při pokusu spustit ho; když se nevejde na zásobník, stane se to v nějakém pseudonáhodném okamžiku za běhu, což je horší.

[Bystroushaak]

Už se ti někdy stalo že se ti nevešel program do Arduina?

Stalo a nikdy za to nemohlo použití objektů. Jinak tohle je argument jako prase. Už se ti někdy stalo že se ti nevešel program do arduina? Tak bys měl používat všude assembler, i když píšeš na desktopu, protože všechno je zlo a všichni jsou neschopní, jen já vím jak na to.

[kralyk z abclinuxu]

Už se ti někdy stalo že se ti nevešel program do Arduina?

To, že někdo nerozumí objektům, resp. jak fungují pod kapotou, a v důsledku toho je nemůže úspěšně použít pro embedded, není úplně důvod, proč by na tom ostatní museli být nutně stejně.

[pavlix]

Bavíme se ještě pořád o místu v paměti pro uložení datové struktury nebo její části?

[hypvofxy]

Martin Maly je kapitola sama o sobe. Jaky je v realu netusim, ale ve svych postech ma tendence lidi kategorizovat a povysovat se nad ne. Ma docela siroky rozhled mezi obory, ale vesmes mi prijde, ze krome psani, programovani starych pocitacu a trochu webu, toho ani moc neumi a spis jen tak do kde koho rype. Sam o sobe tvrdi, ze neni programator, a dnesni programovani mu pripada zcela nezajimave, na coz si pak kladu otazku, jestli je to jeho neznalosti (a vlastne vubec nevi, co se v dnesnim programovani taky da resit), nebo celkovym nezajmem o obor jako takovy (protoze mezi konickem a praci samozrejme existuji znacne rozdily). Ty jeho caste zmeny zamestnani muzou na urcitou nestalost trochu poukazovat...

[vlk]

programujem jednocipy a niektore z mojich pravidiel su:
- pisem v c++11 (alebo novsie) a vsetko v objektoch
- ziadne globalne premenne (len vynimocne aby som sa dostal k objektu z preruseni)
- ziadny heap, aloc, free, new, delete (pripadne len vynimocne na prvotnu alokaciu objektov - bez nutnosti delete, alebo nad memory poolom)
- ziadne vynimky
- nepouzivam #define, #if, ..., nahrazujem ich templejtami, inline funkciami a static const
- prerusenia len v casovo kritickych situaciach, inak sa dotazujem v hlavnej smycke pripadne vyuzivam DMA
- vyhybam sa jednocipom, ktore neumoznuju nastavit stack cez celu RAM a nemaju spolocny adresny priestor cez RAM, FLASH a vsetky registre periferii, idealne ak maju 32bit zbernicu nad adresami aj datami, takze ziadne AVR to asi nebudu
.....

dalej, assembler je vhodny len na casovo kriticke operacie, pisat v assembleri cely program je na hlavu a hlavne takto napisany program bude podstane menej optimalny nez kod prelozeny z vyssieho jazyka.

[Michal Kubeček]

Ale raději začnu s nějakým skutečně objektovým jazykem, asi C++.

Chtěl jsem napsat, že jste si naběhl na vidle, protože za tohle vás místní vyznavači zásady "žádný jazyk, který používá víc než deset lidí, nemůže být dost cool" rozcupují na kousky. Ale jak vidím, už je pozdě. Tak příjemnou zábavu… :-)

[Bystroushaak]

Chtěl jsem napsat, že jste si naběhl na vidle, protože za tohle vás místní vyznavači zásady "žádný jazyk, který používá víc než deset lidí, nemůže být dost cool" rozcupují na kousky. Ale jak vidím, už je pozdě. Tak příjemnou zábavu…

Ono hlavně C++ není skutečně objektový jazyk ani omylem. Objekty jsou tam naroubované jak rakovina na C.

[Michal Kubeček]

A už je to tady…

[Michal Vyskočil]

"žádný jazyk, který používá víc než deset lidí, nemůže být dost cool"

Hlavně žádný jazyk není skutečně objektový . Možná tak Self, nebo Javascript*

* smajlík-vyjadřující-dobrovolné-naběhnutí-si-na-vidle

[Bystroushaak]

Smalltalk je afaik taky kompletně objektový.

Self potom určitě, ale tam to brzí implementace v C++ a momentálně miniaturní komunita, která postupuje šnečím tempem po desíti letech v podstatě nulového posunu. Kdyby se podařilo dopsat Klein (Self v Selfu), tak je to o dost dál.

Javascript mi přijde zprasený, sice se Selfem inspiroval, ale ten prototype based přístup převzali tak nějak úplně blbě. Například tam chybí parent sloty a teď to tak různě mutuje, že to skoro dospívá k nějakému class based OOP.

[Michal Vyskočil]

Nikdo nic nepřepisuje, czmq je naprosto nová knihovna Navíc tento pattern není nový, například libmagic, nebo libabc, nebo hormada dalšího kódu.

Ale raději začnu s nějakým skutečně objektovým jazykem, asi C++

C++ má svoje výhody, zejména práce s kolekcemi (až na odporné STL API). Na druhou stranu i spoustu nevýhod, jako komplexní pravidla (rule of five), pomalá kompilace, nutnost dávat implementaci do hlavičkových souborů, neexistující ABI, ... Obvykle je to tak, že než já vyšperkuju třídu v C++, tak v C už mám dávno implementaci hotovou

[Tomáš Bžatek]

Hele on zije

[Kvakor]

Pozorní čtenáři si jistě všimli zvláštní konstrukce strdup ("") v konstruktoru. Typický C programátor nechce zbytečně plýtvat cykly CPU, takže by napsal self->name = NULL. Což je možné, ale potom je potřeba to všech metod třídy naprogramovat kód pro obsluhu NULL. Použití strdup vede na jednodušší kód bez zbytečných podmínek. A jednodušší kód je lepší, než ten komplikovaný.

No, je pravda, že použít strdup("") na inicializace řetězce dělá věci jedodušší, nicméně osobně bych raději udělal nějaký chytrý wrapper (možná by stačilo i makro), který obsahuje test na NULL (něco jako realloc(), ale pro řetězce), protože mít na haldě spousty pidiřetězců velkých jeden byte mi případá jako velmi neelegantní řešení.

A i když test na NULL je podmínka a tudíž skok, ve výsledku se přeloži jako jedna instrukce, zatímco ten kód, který následuje při dealokaci objektu z haldy, bude určitě obsahovat mnohem více skoků (například kvůli implementaci scelování) a navíc sahání do paměti, která nemusí být zrovna nacachované.