Příspěvky

16

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

« kdy: 02. 08. 2022, 15:23:59 »

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á.

Jo, a kdy se zničí ta statická proměnná? Jediná možnost v tomto případě je udělat leak a alokovat ji na heapu a nikdy ji nezničit (takže mít static pointer).

Statické proměnné se ničí při ukončování programu a to v opačném pořadí než vznikly. Trochu jako by se hned po tom vytvoření zavolal atexit.
Takže abyste se na tu proměnnou dostal po jejím zničení, musel byste na ni lézt z nějakého objektu, který existoval už předtím. To je poměrně obskurní použití, takže to moc nehrozí. Pokud nějaký sigleton potřebuje jiné singletony, pak stačí aby si o ně řekl už v konstruktoru a je za vodou.
Všechny implementace singletonů mají své pasti a tahle je na tom ještě docela v pohodě.

Jinak thread safe inicialization má compile flag - pokud někdo kompiluje bez tak tyto hrátky se statickýma proměnnýma nejsou ani thread safe.

Přes compile flagy se dá nastavit spousta dalších věcí - výjimky, RTTI, přesnost floatů, ... Pokud někdo vrtá do tohohle, tak holt musí vědět moc dobře, co dělá.

17

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

« kdy: 02. 08. 2022, 15:09:41 »

Pokud pisu zdrojak, pisu ho tak, abych nemusel poskytovat out-of-band informaci, jakou verzi standardu se na to ma prekladac divat.

Mám to chápat tak, že píšete v c++98 abyste ke všem těm out-of-band informacím jako jsou cesty ke knihovnám, úrovně optimalizací a další nastavení prostředí nemusel přidat jeden další parametr?

Všiml jste si, že všechny běžně používané jazyky přicházejí s novýma verzema, kde se (obvykle úspěšně) snaží programátorům ulehčit práci? A každý příčetný programátor tu out-of-band informaci rád poskytne aby nemusel používat prehistorickou verzi 0.666 z hlubin pekelných, pokud to není nezbytně nutné.

18

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á.

19

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.

20

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.

21

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.

22

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ě.

23

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á?

24

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.

25

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"?

26

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ěď.

27

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.

28

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?

29

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

30

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í.