Příspěvky

1

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

« kdy: 04. 08. 2022, 18:18:21 »

"Slysel jste nekdy o YAGNI? A kdybych mel vzdycky delat jen to, co se po mne chce, asi bych byl porad jeste junior... "
No nevím, pocit že jsi chytřejší než ostatní je často dosti příznačné pro ... doplň si sám. Jak se říká: "Never trust a programmer who says he knows C++" 

Omg, ja se na to, na co odpovidal vubec neptal. Jestli neznate C++ nebo se bojite, ze vam nekdo dokope pointery a vy si to neumite pohlidat, pak bezte programovat v Jave a neplette se do diskuzi o C++.

Jasně, takže junior 

Jestli pak konecne opustite tuhle diskuzi, pak ano, klidne si to myslete...

2

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

« kdy: 04. 08. 2022, 07:02:44 »

"Slysel jste nekdy o YAGNI? A kdybych mel vzdycky delat jen to, co se po mne chce, asi bych byl porad jeste junior... "
No nevím, pocit že jsi chytřejší než ostatní je často dosti příznačné pro ... doplň si sám. Jak se říká: "Never trust a programmer who says he knows C++" 

Omg, ja se na to, na co odpovidal vubec neptal. Jestli neznate C++ nebo se bojite, ze vam nekdo dokope pointery a vy si to neumite pohlidat, pak bezte programovat v Jave a neplette se do diskuzi o C++.

3

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

« kdy: 03. 08. 2022, 13:09:32 »

Ma nejaky smysl, aby objekty uvnitr (Http klient a DB databaze) byly std::shared_ptr a ne proste staticky alokovane membery nebo alespon std::unique_ptr?

Chce se po mne, abych predaval vsechny reference na Http a DB pomoci kopirovani shared pointeru kvuli tomu, aby "nahodou" napr Http nebyl automaticky dealokovan drive nez ho neco pouzije.

Má to přesně ten smysl uvedený v dalším odstavci. Zadavatel/nadřízený si nejspíš uvědomuje, že kód má tendeci se vyvíjet a měnit, ten pointer nemusí být navždy unikátní a raw-pointer dříve nebo později někdo dokope. Nezáleží na tom, že zrovna teď zrovna v tomhle případě není nutný. Ničemu nevadí a předchází problému. Když se to po tobě takhle chce, tak to takhle udělej.

Slysel jste nekdy o YAGNI? A kdybych mel vzdycky delat jen to, co se po mne chce, asi bych byl porad jeste junior...

Ale abych se vratil k otazce.

Trochu to prezenu, abych zduraznil absurditu Je mozne pristoupit k objektu na heap po korektnim zniceni cele heap v bezicim procesu? Tj. dobehnou vlakna, znici se heap a TED je ten okamzik Muze v tomto bode jeste napriklad bezet detached vlakno?

Jo, zničit heap v běžícím procesu samozřejmě jde. Ale já teda nepotkal platformu, kde by se při ukončování likvidoval normální heap. Vždycky to zůstalo viset a tu paměť pak poklidil OS. Spousta programů nechává viset objekty, které nepotřebujou volat destruktory. Takže příčetné runtimy se úklidem heapu na konci neobtěžují. Akorát Valgrind a spol. v takovém případě kvičí.

Moment moment, jde tohle udelat pomoci standardniho C++ runtimu? (tj. NE volanim noveho processu z C kodu). Predpokladam, ze to bude nejaky unixovy system call, ne?

4

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

« kdy: 02. 08. 2022, 17:36:55 »

Dekuji vsem za odpovedi.

Par poznamek:

1) Kdyby bylo po mem, staticky (tj. na stacku) bych naalokoval vse v mainu, predaval referenci v konstruktoru (umoznuje dependency injection) a zajistil graceful shutdown. Po mem ale bohuzel neni, ponevadz manazer lpi na globalni promenne (kvuli egu a protoze C++ nerozumi). Ja bych delal spoustu veci jinak.

2) Inicializace statickych, block-scoped promennych je skutecne thread-safe. Vygooglete si nasledujici vetu v C++ standardu:

Kód: [Vybrat]

If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initializationTenhle singleton taktez nese jmeno Scotta Meyerse: https://laristra.github.io/flecsi/src/developer-guide/patterns/meyers_singleton.html. Soudim tedy, ze je to safe.

3) Rozumim-li spravne postu o kompilacnim flagu, pak je to nejspis toto:

Kód: [Vybrat]

-fno-threadsafe-statics
Do not emit the extra code to use the routines specified in the C++ ABI for thread-safe initialization of local statics. You can use this option to reduce code size slightly in code that doesn’t need to be thread-safe.Z toho mi plyne, ze tento flag vypina thread-safety, tudiz defaultne je to safe.

Ale abych se vratil k otazce.

Trochu to prezenu, abych zduraznil absurditu Je mozne pristoupit k objektu na heap po korektnim zniceni cele heap v bezicim procesu? Tj. dobehnou vlakna, znici se heap a TED je ten okamzik Muze v tomto bode jeste napriklad bezet detached vlakno?

Lze to same udelat s korektne - na konci programu - dealokovanou statickou promennou?

Pokud nikoliv, vubec neni potreba tridu Sluzby dynamicky alokovat a uz vubec managovat ji nebo jeji membery pomoci std::shared_ptr.

A sem se snazim celou dobu dostat. Respektive, chci vedet, jestli neco neopomijim.

5

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

« kdy: 01. 08. 2022, 11:33:39 »

Ano, o designu si taky myslim svoje, chci ho zmenit zpusobem jaky navrhuji. Nejde o performance, ale o korektnost a jednoduchost.

Pokud muze byt

Kód: [Vybrat]

Sluzby *sluzbyGlobal = new Sluzby;

dealokovano drive nez skonci kterekoliv vlakno a ja mam napriklad tridu, ktera drzi pointer/referenci na Sluzby:

Kód: [Vybrat]

class MujObjekt
{
   Sluzby& sluzby;

   void foo() { sluzby.klient->post(); }
};

(ano, bohuzel, takhle to v nasi code base je).

tak me std::shared_ptr<Http> nezachrani, protoze uz byl davno dealokovan s celou tridou Sluzby.

Proto se ptam znovu, muze byt globalni/staticka promenna nebo pamet na heap dealokovana drive nez skonci (i detached) vlakna?

Pokud ano, std::shared_ptr<Http> nas nezachrani, pokud ne, nema std::shared_ptr<Http> v tomhle pripade cenu.

6

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

« kdy: 01. 08. 2022, 10:29:38 »

Ahoj,

resim ted jeden problem. Mame objekt tridy, rekneme Sluzby:

Kód: [Vybrat]

class Sluzby
{
   std::shared_ptr<Http> klient;
   std::shared_ptr<DB> databaze;
};

Tento objekt musi zit po celou dobu behu aplikace a musi byt prave jeden. Pristupuje se k objektu tedy takto:

Kód: [Vybrat]

Sluzby *sluzbyGlobal = new Sluzby;

tj. je to globalni promenna, na kterou se nikdy nevola delete. Tj. umre az na uplnem konci s celou heap.

Ma nejaky smysl, aby objekty uvnitr (Http klient a DB databaze) byly std::shared_ptr a ne proste staticky alokovane membery nebo alespon std::unique_ptr?

Chce se po mne, abych predaval vsechny reference na Http a DB pomoci kopirovani shared pointeru kvuli tomu, aby "nahodou" napr Http nebyl automaticky dealokovan drive nez ho neco pouzije.

Ja argumentuju tim, ze neexistuje situace, kdy by takto alokovany objekt mohl byt dealokovan drive nez skonci jakekoliv vlakno v cele aplikaci (i detached). Tudiz, prijde mi efektivnejsi predavat vsude proste Http& klient namisto pomalejsiho std::shared_ptr<Http>.

Pokud vim, kdyz se vyskytne neopravitelna chyba (vyjimka pri zpracovani vyjimky, SIGABRT), program okamzite skonci a neceka se na nejake uvolnovani pameti nebo kdesi cosi.

Dale, nemyslim si, ze by se vlakno mohlo nejakou vzacnou chybou stat detached. Pokud jsou vsechny vlakna non-detached, s koncem programu se nasilne takova vlakna ukonci, ze? Tj. drive pred uvolnenim heap/static objektu.

Tj. proc proste nemit tohle:

Kód: [Vybrat]

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

?

7

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

« kdy: 20. 02. 2022, 15:02:56 »

pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++

Copak asi zjistili pro přepsání do C++ Že je to pomalé a musí to přepsat do Rustu?

Jakoze Rust je rychlejsi nez C++ Rekl vam nekdo, ze oba jazyky se kompiluji do stejneho strojoveho kodu, dokonce Rust backend je - stejne jako Clang - v LLVM, tudiz nektere vysledne binarky mohou byt ~totozne?

a) Rust neni a ani nema byt ambici "byt rychlejsi nez C++". Chce byt "alespon stejne rychly, pri vetsich compile-time zarukach".
b) Benchmarky sice existuji, ale jsou dost vyrovnane - benchmarky, ktere jsou takto blizke nemaji vyznam. Dulezite jsou pouze pokud ukazuji radove (řádové) rozdily.

8

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

« kdy: 19. 02. 2022, 21:22:13 »

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

Co vlatně porovnáváte? Iteraci přes pole v C vs zobrazovaní obrázků v prohlížeči?

Ne, vy se tu snazite manipulativne tvrdit, jak v JavaScriptu musite resit kazdou instrukci bytekodu, aby vas kod byl rychly. A ja to vyvracim tim, ze kdyz udelate spravne vsechno ostatni, profiler vas nezajima.

9

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

« kdy: 19. 02. 2022, 21:20:21 »

Boze muj, chapete rozdil mezi tim, kdyz mate program ve forme vstupniho jazyka (napriklad JavaScript) nebo ve zkompilovane binarni forme??

10

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

« kdy: 19. 02. 2022, 21:09:50 »

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Co se týče UI tak browser technologie (JS VM, HTML, CSS) jsou teď srovnatelné s .NET a JVM, ne li lepší a to hlavně v rychlosti. Podle špatně napsaných aplikací nebo knihoven nemůžete posuzovat celou platformu. Napsat dobře aplikaci v browseru může být stejně složité jako ji napsat dobře v libovolném jiném jazyce.

WebAssembly pomůže jen v ojedinělých případech, má také svůj overhead.

Vy ale hrubym zpusobem mijite moji pointu. Ja zde nerozlisuji JavaScript vs JVM atd., nybrz interpretovany vs. kompilovany jazyk - v tom by WebAssembly pomohlo hodne, ale "it is not there yet" samozrejme...

A i kdyz bude vas JavaScript stokrat rychlejsi nez C++, stejne vykon vasich webovek bude stat a padat s kvalitou obrazku, poctem stazenych stylesheetu, knihoven, neefektivnim renderovanim atd. atd.

11

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

« kdy: 19. 02. 2022, 20:59:02 »

Nesmim se vyjadrovat k nicemu, co neni moje domena? Vy se taky nevyjadrujete k politice, politice, ekonomii... mezi kamarady u piva (tady je uroven podobna)? Evidentne to take neni vase domena. Dle toho, co pisete, neni vase domena ani cokoliv na backendu. Proc jste se k tomu tedy - dle vasi logiky - vyjadroval?

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Onehda jsem mel hovor s jednim rekruterem, nabidka byla celkem zajimava (detaily zminovat samozrejme nebudu), ale pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++. Tot k te optimalizaci na mikrosekundy...

Pokud cerpate znalosti z rozhovoru s recruitery, ani se nedivim, ze placate nesmysly. Alespon jste se naucil buzzwordy.

Javascript neni pomaly, pomale jsou manipulace s DOMem, webassembly mozna pomuze jen u canvas aplikaci a her, urcite ne u klasickych aplikaci s DOM ui. Mozna byste to zjistil, kdybyste obcas otevrel profiler.

Ano, presne tak, jeste taky cerpam informace od vseznalku z rootu

Abyste mohl rict, ze neco "neni pomale", musite ale rict, co resite nebo to s necim srovnat. Ano, pokud resite DOM traversing, tak na to zrejme JavaScript je "dost" rychly. Pokud uz chcete JavaScript s necim srovnat, pak ano, zrejme je rychlejsi nez vase babicka, ale mezi jazyky, ktere resi skutecne problemy (v kterych je mimo jine i ten vas JavaScript napsan) se radit neda...

Samozrejme, ze WebAssembly s DOMem nyni nepomuze, protoze (pokud vim) ho nativne ani zatim neumi. Nevim, jestli jste cetl (nebo pochopil), co jsem psal. Ja mluvil o requestech, ktere vubec ten vas JavaScript musi do prohlizece dopravit a kdyz uz tam je, tak ho musi prohlizec naparsovat a zkontrolovat syntaxi. WebAssembly je binarni.

Proc mi nutite profiler? Profilery jsou dneska na kazdy nesmysl. Ja vam rikam, ze kdyz udelate spravne vse vubec pred pouzitim JavaScriptu a toho JavaScriptu budete mit minimum (ano, jde to), nemusite resit profilery, protoze - pokud jste to nevedel - browser musi udelat spoustu dalsich operaci (je napsany v C++, vite?) predtim nez se vubec prokouse k vasemu JS.

Ano, samozrejme, pokud spustite 10000x smycku, jejiz body trva 100ms, tak jste prave zabil UI. Ale potrebujete na tohle skutecne profiler? Bezny uzivatel webovek skutecne nemeri vykonnost na milisekundy, ten vam jen rekne "je to pomale" vs. "je to rychle"

Vy uz jste se davno odkopal tim, ze nemate ahnung, co se deje na backendu, vase formulace "u frontendu musite myslet na rychlost mnohem casteji nez u backendu" to dokazuje. Mozna si tim jen snazite dokazat, ze vase remeslo je nejdulezitejsi na svete - ale neni

Tohle neni ani tak pro vas, vy uz svoji pravdu mate, spis pro ostatni, co se tak na webu meri: https://www.keycdn.com/blog/website-performance-metrics...

12

Studium a uplatnění / Re:MatFyz UK vs. FIT ČVUT

« kdy: 19. 02. 2022, 20:13:54 »

Naprosto nesouhlasím s výkřiky "MFF ti dá jen teorii" a "chodí tam jen nerdi"...

Samozřejmě, MFF je o dost teoretičtější (projděte si studijní plány), ale musíte si zodpovědět, co chcete dělat... Jestliže chcete mastit eshopy (vizte vedlejší vlákno...) nebo linux-adminovat pár serverů a teď nic neumíte, ano, udělejte si Bc. na FITu.

Chcete-li se věnovat něčemu složitějšímu, pak se rozhodování dále větví...

FIT vás naučí programovat, pokud to ještě neumíte + vám dá navíc něco teorie.

Pokud už umíte dobře programovat a ještě navíc vám jde matika, MFF vás naučí nad problémy jinak přemýšlet a programování pro vás bude spíš nástroj, jak ty problémy řešit - ale nedá vám tolik praxe jako FIT.

V každém případě ale nikdo nemůže počítat s tím, že dokončí Mgr. na MFF nebo Ing. na FITu a bude z něj mistr světa. Úspěšná kariéra samozřejmě vyžaduje spoustu dalšího sebevzdělávání a praxe.

Já mám zkušenosti s obojím.

Na FITu je matika spíš opravdu jen takový základ pro programovací/teoretické předměty, naopak - když člověk aspoň trochu chce - může se tam naučit slušně programovat.

Na MFF je naopak brutální matematika, větší důraz na různé grafy, efektivní algoritmy apod., ale programování samo o sobě je tam prostředek pro "zkoušení" těchto problémů. Jsou tam také obory/předměty, kde se člověk naučí dobře programovat, ale IMO je v nich větší volnost než na FITu.

13

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

« kdy: 19. 02. 2022, 20:01:04 »

Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...

pokud implementujete vlastni DB server.

Co to povidate? Myslite si, ze databaze programuji roboti? Databaze programuji lide, velmi casto je pisi v C++ a presne tam resi vykonnost proto, aby na rootu mohli rozumbradove psat, ze "vykon backendu neresi"...

Projdete si nabidky na LinkedInu, pomerne nedavno jsem tam videl i nejakou zajimavou nabidku na C++ job pro nejakou firmu, co programuje databaze. A ano, tam se vas rozhodne na algoritmy ptat budou...

to si nemyslim, mozna je to vase domena? Proc se potom vyjadrujete k webovemu frontendu?

Nesmim se vyjadrovat k nicemu, co neni moje domena? Vy se taky nevyjadrujete k politice, politice, ekonomii... mezi kamarady u piva (tady je uroven podobna)? Evidentne to take neni vase domena. Dle toho, co pisete, neni vase domena ani cokoliv na backendu. Proc jste se k tomu tedy - dle vasi logiky - vyjadroval?

Musi byt webovy frontend moje domena, abych vedel, ze JavaScript je ukrutne pomaly, latence na webovem frontendu je zpusobena requesty, resourcy, parsovanim HTML, CSS, JS (uz aby se rozsirilo WebAssembly), prebujelymi JS knihovnami a cpanim JS tam, kde by stacilo plain CSS?

Onehda jsem mel hovor s jednim rekruterem, nabidka byla celkem zajimava (detaily zminovat samozrejme nebudu), ale pry ten svuj uzasny produkt napsali v TypeScriptu, ale zjistili, ze je to prilis pomale a museli to zacit prepisovat do C++. Tot k te optimalizaci na mikrosekundy...

14

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

« kdy: 19. 02. 2022, 19:13:36 »

Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...

pokud implementujete vlastni DB server.

Co to povidate? Myslite si, ze databaze programuji roboti? Databaze programuji lide, velmi casto je pisi v C++ a presne tam resi vykonnost proto, aby na rootu mohli rozumbradove psat, ze "vykon backendu neresi"...

Projdete si nabidky na LinkedInu, pomerne nedavno jsem tam videl i nejakou zajimavou nabidku na C++ job pro nejakou firmu, co programuje databaze. A ano, tam se vas rozhodne na algoritmy ptat budou...

15

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

« kdy: 19. 02. 2022, 18:32:37 »

neni zdaleka pravda, u frontendu musite myslet na rychlost (pripadne spotrebu baterie) mnohem casteji nez u backendu. V JS pouzivam profiler celkem casto.

A ted tu o Karkulce... Pokud nemate ve vasich webovkach svitive barvy, netahate megabajty obrazku, resourcu, libek (coz je ale hloupost i u ne-mobilni aplikace), nemate tam tunu zbytecnych requestu, vezte, ze nejake to iterovani pres pole ma vyznam 0.0. Pokud pisete hry v JS pro mobilni prohlizece, dejme tomu - ale to uz jsme daleko od bouchani eshopu a stejne bude jeste hodne zalezet na tom, jak ten prohlizec JS interpretuje...

99% vykonostnich problemu webovych aplikaci jsou bud na strane DB serveru nebo frontendu. Na strane backendoveho aplikacniho kodu neni problem temer nikdy, tam staci dodrzovat jednoduchou zasadu neselektovat z DB vic dat nez hodlate zobrazovat. Potom muzete klidne zamenovat std::vektor a std::unordered map, dat nikdy neni tolik, aby se to vykonostne projevilo.

"Mnohem casteji nez u backendu"? Tak jestli vas backend je par selectu z databaze... Pokud pisete webove aplikace, kde neresite vykon backendu, zrejme byste si mel rozsirit obzory...

Navic, ja ani tak nemluvil o "webovych backendech", spise obecne o cemkoliv slozitejsim nez placani webovek v JavaScriptu. Budete se divit, ale ta vase DB na backendu setsakramentsky resi, jestli bude pouzivat std::vector nebo std::unordered_map...