Příspěvky

16

Vývoj / Re:Lifetime static/global/heap-allocated objektu v C++

« kdy: 02. 08. 2022, 13:30:56 »

Ja vedel ze C++ je slepa cesta jen si hezky onanujte, vy uber-programatori.

Na vse ostatni staci takovy jednodychy on-demand generator:

typ *single() {
  static typ *instance;
  if (!instance) instance = &new typ();
  return instance;
}

To céčku je naozaj nutné kontrolovať, či statická premenná vo funkcii bola inicializovaná?

V C++ nie je, jednoducho to prebehne iba pri prvom volaní a platí to aj pre tú alokáciu pamäte.

A od C+11 je to aj thread-safe...

Pokud je ta statická proměnná ukazatel na dynamicky alokovaný objekt, tak je to nutné kontrolovat. V C++11 je thread safe tahle verze :

typ *single() {
  static typ instance;
  return &instance;
}

Protože thread safe je jen ta samotná inicializace statické proměnné.

Spíš jde o to tu proměnnou "lazy" zinicializovat až když je opravdu potřeba, statická inicializace v C++ je tak trochu nepředvídatelná a spoláhat se na ni je cesta do pekel - proto bych vyhodil všechny globals a měl jen jeden - nějaký DI context nebo aplikační kontext, atd... popřípadě nemít ani ten a předávat ten kontext. Asi záleží na tom jak je kód na kterém tazatel děla starý - obvykle starší code-base má hodně globálních proměnných a něco s tím udělat by bylo na roky práce...

Globální proměnné jsou problematické, ale statická proměnná uvnitř funkce je v pohodě. Ta se zinicializuje ve chvíli, kdy se ta funkce poprvé zavolá.

17

Vývoj / Re:Lifetime static/global/heap-allocated objektu v C++

« kdy: 02. 08. 2022, 09:58:56 »

Ja vedel ze C++ je slepa cesta jen si hezky onanujte, vy uber-programatori.

Na vse ostatni staci takovy jednodychy on-demand generator:

typ *single() {
  static typ *instance;
  if (!instance) instance = &new typ();
  return instance;
}

Supr, tak sis kopl a navíc taky neodpověděl na to, na co se tazatel ptal.

Mimochodem, ten jednoduchý on demand generátor na všechno rozhodně nestačí. Minimálně proto, že není thread-safe. A tazatel se ptal na thready, takže mu to nejspíš vadit bude.

18

Vývoj / Re:Lifetime static/global/heap-allocated objektu v C++

« kdy: 02. 08. 2022, 09:24:37 »

jednoduchy priklad, ze i objekt na stacku muze byt "singleton".
sice jde vytvorit mnoho techto objektu, ale funkcni je jen ten prvni vytvoreny pomoci sid=0.
metody jsou ohnute, ze neco delaji jen kdyz je my_id objektu 0, takze jen prvni instance
funguje spravne.

Bacha, singleton pattern má i další věci. Třeba že existuje nějaký globální přístupový bod k tomu jedinečnému objektu. A to ten váš příklad nesplňuje.

Tomu, že si nějaký jeden objekt vytvořím ručně a rozstrkám ho dál třeba přes dependency injection, se obvykle Singleton neříká. A stejně tak bych od něčeho nazvaného singleton nečekal, že půjde jednoduše vytvořit víc instancí, které se akorát budou jinak chovat.

Neni pristupovy bod ta globalni instance? Pokud nepotrebuje lazy inicializaci, nevidim problem.

Ale alex nepsal o žádné globální instanci. V tom jeho příkladu byl "globální" akorát couter na základě kterého mohl ten nesingleton poznat, že je první. K těm samotným objektům na stacku žádný globální přístup nebyl.

19

Vývoj / Re:Lifetime static/global/heap-allocated objektu v C++

« kdy: 01. 08. 2022, 14:44:57 »

jednoduchy priklad, ze i objekt na stacku muze byt "singleton".
sice jde vytvorit mnoho techto objektu, ale funkcni je jen ten prvni vytvoreny pomoci sid=0.
metody jsou ohnute, ze neco delaji jen kdyz je my_id objektu 0, takze jen prvni instance
funguje spravne.

Bacha, singleton pattern má i další věci. Třeba že existuje nějaký globální přístupový bod k tomu jedinečnému objektu. A to ten váš příklad nesplňuje.

Tomu, že si nějaký jeden objekt vytvořím ručně a rozstrkám ho dál třeba přes dependency injection, se obvykle Singleton neříká. A stejně tak bych od něčeho nazvaného singleton nečekal, že půjde jednoduše vytvořit víc instancí, které se akorát budou jinak chovat.

20

Vývoj / Re:Lifetime static/global/heap-allocated objektu v C++

« kdy: 01. 08. 2022, 14:23:09 »

Tohle řešení:

Kód: [Vybrat]

class Sluzby
{
   Http klient;
   DB databaze;
   static Sluzby& Get()
   {
      static Sluzby instance;
      return instance;
   }
};

není ekvivalentní vytvoření instance Sluzby na heapu, protože C++ nedefinuje pořadí inicializace statických proměnných v různých kompilačních jednotkách. Pokud něco z instance Sluzby bude používat (konstantní) statickou proměnnou z jiné kompilační jednotky, je to undefined behavior. Ono to tam nemusí být teď, ale možná to tam někdo přidá v budoucnu... Osobně nejsem přiznivcem takového řešení, vytvoření instance Sluzby na heapu tímto problémem netrpí.

Tohle není úplně pravda. U globálních objektů není specifikované pořadí mezi jednotlivými .cpp.
Ale tahle instance se vytvoří při prvním zavolání Get a úklid takových objektů je v opačném pořadí než vznikly.

MujObjekt je asi cajk, protože ta reference se dá nasměrovat na později vzniklý objekt jen divokým prasením. Ale dal bych si bacha na věci, co mají na ty Sluzby ukazatel.

Jinak co se týče vláken, tak c++ vlákna by měla skončit před destrukcí statických a globálních objektů. Ale pokud jde o jiné thready, tak bych byl hodně opatrný až paranoidní. Třeba holé winapi s c++ runtime spolupracuje špatně.

21

Studium a uplatnění / Re:atmoskop.cz - žaloba za podvodne jednání

« kdy: 22. 06. 2022, 12:39:54 »

... myslím že obrázek mluví za vše:

A co ten obrázek teda podle Vás říká?

22

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 25. 03. 2022, 13:40:08 »

Kdyz firma nedokaze jasne zadat ukol ani pri pohovoru, asi bych pro ne pracovat nechtel. V praci chci programovat, ne se dohadovat o zadani. Uchazec by mel predvest schopnost resit ukoly, firma by mela predvest schopnost ukoly zadavat.

Jasně zadat úkol je občas hodně těžký problém. Bohatě stačí, když bude firma spolupracovat při doplňování toho zadání.

Alex6bbc ve mně zanechal dojem člověka, který napřed podřízeného zjebe že je to přece úplně jasné a pak ho zjebe znova že dostal něco jiného než chtěl. Pracovat bych pro něj fakt nechtěl.

23

Studium a uplatnění / Re:Obsese algoritmických otázek na pohovoru

« kdy: 25. 03. 2022, 11:04:17 »

testovaci ukol znel jasne, reverznout soubor. tyhlety chytre otazky jsou dobre, kdyz se resi opravdovy ukol.
ale kdyz nekomu reknu vypis soubor pozpatku, a on se me zepta na tyhle veci, tak si reknu, ze to je magor,
ktery bude delat z jednoducheho ukolu elektrarnu :-(

Sorry, ale zadání "reverznout soubor" je silně nejednoznačné. Tady záleží třeba na míře programátorské deformace. Poloprogramátor či neprogramátor si pod tím určitě nepředstaví reverznutí po bytech, protože na takové úrovni abstrakce ani nepřemýšlí. Takový člověk spíš přemýšlí na úrovni grapheme clusterů i když ten pojem nejspíš vůbec nezná.

Zkušený vývojář bude mít určitě hromadu zážitků, kdy na první pohled jasný úkol vlastně vůbec jasný nebyl. A kdybych na pohovoru položil nějaké doplňující otázky a reakce byla že to zbytečně komplikuju, tak pravděpodobně hledám práci jinde.

BTW Opravdu vás při pohovoru nezajímá, jak se bude kandidát chovat až dostane ten "opravdový úkol"?

24

Studium a uplatnění / Re:Tipy a triky na zlepšení logického myšlení u pohovorů

« kdy: 15. 02. 2022, 13:33:08 »

Kód: [Vybrat]

[a,b]=[b,a]

Kód je často očekáván jako správné řešení, ale opět je nesprávné. Interně totiž proběhne alokace hned 4 registrů, počet instrukcí ani nezmiňuji.

Hele, o počtu registrů nemá cenu ani uvažovat pokud neznáme přesně jazyk, cílovou instrukční sadu a možná i verzi překladače. A to se ten kód musí aspoň JITovat, jinak se o registrech nedá uvažovat vůbec.

Tohle je buď test, jak zareaguješ na WTF situaci, nebo prefabrikovaná otázka na kterou očekávají prefabrikovanou odpověď.

25

Studium a uplatnění / Re:Tipy a triky na zlepšení logického myšlení u pohovorů

« kdy: 15. 02. 2022, 08:07:42 »

a += b
b = a - b
a  -= b

Pekne ale nepouzitelne ak hrozi pretecenie...

Proto se to dělá xorem.

Tady bych tě opravil - nedělá se to! Je extrémně nepravděpodobné, že by se tazatel někdy dostal do situace, kdy takovýhle swap dává smysl.

Rozumný překladač tenhle kód zoptimalizuje na normální swap. Respektive zoptimalizoval by, kdyby nemusel zachovat jednu hnusnou past, kdy ten kód neprohazuje, ale nuluje. Naprosto typická zkratka - je to pomalejší ale zase to nefunguje vždycky.

26

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 12. 02. 2022, 13:54:57 »

A skoro mám chuť slovíčkařit a zeptat se, co přesně je ta "opravdová dědičnost".

To je otázka do pranice Dědičností je hodně. Dědičnost rozhraní má kde co, třeba ObjC, Go nebo Rust (všechny tři dokonce vícenásobnou). U konkrétních typů se pak rozlišuje datová a konceptuální, kteréžto jdou v teorii (typů) tak trochu proti sobě. Která je “opravdová”? U multimetod se to komplikuje ještě více. To je jako ptát se, která barva je opravdová, červená, zelená nebo modrá?

No právě proto Sice bych nevysypal ani polovinu těchhle příkladů, ale stejně mě to praštilo do očí.

Ale možná to bude ta, co nosí kilt a jí haggis

Jo, ale jejich prostorová distribuce je dost nevyvážená

No ale to, že všechny pravé závorky přijdou na jedno místo, přece výrazně zjednodušuje programátorovi přemýšlení, ne?

27

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 11:05:39 »

Aha, už myslím začínám tušit, kde se naše pohledy liší. Já na to koukám jako čtenář kódu. A že tam zrovna není nic, co by to přede mnou _opravdu_ schovalo. Jo, kdyby to querier bylo jen rozhraní a padalo ven z nějakého blackboxu, tak bych ten blackbox za továrnu považoval.

Querier nemuze byt rozhrani, protoze rozhrani nemuzou byt typove parametrizovana, pokud se nepletu.

Ale může to být "něco" do čeho nevidím a na co můžu zavolat All nebo Filter. Což bych považoval za rozhraní, aspoň v obecném smyslu, ne jako klíčové slovo nějakého jazyka.

Já vidím struct, který se přes tečkovou notaci předává jako první parametr nějaké sadě funkcí. To prostě vypadá a kváká jako C++/C#/Java třída. A mám pocit, že je i cílem aby to tak co nejvíc kvákalo, ať to není matoucí.

Vypada to tak jenom syntakticky, jinak se to ve spouste veci lisi.

Napr. mechanismus tzv. "embedded structs" sice pripomina dedicnost, ale pri predavani "predka" se predava jenom skutecne ten embedded struct, takze se pomoci toho opravdova dedicnost udelat neda. Jednou jsem na to napsal explicitni priklad, ale ted ho nemuzu najit

To i v tom C++ nebo Javě. Ty jsou si taky jen podobné. A skoro mám chuť slovíčkařit a zeptat se, co přesně je ta "opravdová dědičnost". Ale jen skoro

28

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 10:09:16 »

Co potkávám továrny, tak obvykle neprodukují nějaké konkrétní objekty, ale "něco" co má nějaké rozhraní. Takže ta továrna je mezivrstva, díky které nevím, co vlastně přesně dostanu.

Jo, to jsem zapomnel zminit, to tady ale taky plati. V tom prikladu https://rakyll.org/generics-facilititators/ muze byt struktura Querier kldne neexportovana.

Aha, už myslím začínám tušit, kde se naše pohledy liší. Já na to koukám jako čtenář kódu. A že tam zrovna není nic, co by to přede mnou _opravdu_ schovalo. Jo, kdyby to querier bylo jen rozhraní a padalo ven z nějakého blackboxu, tak bych ten blackbox za továrnu považoval. Jo blackboxem nemyslím že se opravdu nemůžu podívat dovnitř, ale že nevidím dovnitř při lokálním uvažování třeba v rámci souboru.
Ale tímhle způsobem se dá taky upravit skoro všechno. Takže to, že by to tak mohlo být, tak nějak neřeším. To znamená že ze všeho se dá udělat továrna, ne že všechno je továrna.

Ty facilitátory ani nepadají z nějaké továrny - vznikají jako instance nějaké konkrétní generické třídy. A ani z nich nemusí padat nějaké výsledky - může to být třeba zapisovač řádků do databázové tabulky.

Go nema "tridy". A to NewQuerier je sice semanticky konstruktor, ale na urovni jazyka je to libovolna typove parametrizovana funkce, ktera typ zafixuje do structu. Volajici vubec nemusi vedet, co ten struct, ktery dostane, obsahuje. Vi jenom, ze jsou na nem nadefinovane nejake metody.

Já vidím struct, který se přes tečkovou notaci předává jako první parametr nějaké sadě funkcí. To prostě vypadá a kváká jako C++/C#/Java třída. A mám pocit, že je i cílem aby to tak co nejvíc kvákalo, ať to není matoucí.

29

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 09:16:48 »

Třeba první na co jsem narazil byl "querier" - dotazovač do databáze. Pokud je tohle továrna, tak už je továrna všechno co má nejaký výstup.

Já se patternama nezabývám (vědomě, záměrně), takže říkám "factory" všemu, co produkuje nějakého "dělače" na základě nějakých parametrů. Což na ten facilitátor přesně sedí.

U kanonického chápání factory jsou ještě nějaká další omezení?

Tak já si netroufám tvrdit, že mám nějaké kanonické nebo správné chápání návrhových vzorů.

Co potkávám továrny, tak obvykle neprodukují nějaké konkrétní objekty, ale "něco" co má nějaké rozhraní. Takže ta továrna je mezivrstva, díky které nevím, co vlastně přesně dostanu.

Ty facilitátory ani nepadají z nějaké továrny - vznikají jako instance nějaké konkrétní generické třídy. A ani z nich nemusí padat nějaké výsledky - může to být třeba zapisovač řádků do databázové tabulky.

30

Vývoj / Re:Kterým směrem se vydat od C

« kdy: 11. 02. 2022, 08:55:22 »

A i ty příklady facilitátorů, na které jsem narazil, byli jiní dělači než továrny.

V čem?

Třeba první na co jsem narazil byl "querier" - dotazovač do databáze. Pokud je tohle továrna, tak už je továrna všechno co má nejaký výstup.