Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Dnes existuju dost huste rozne terminal UIs kde sa zacnu pojmi CLI a GUI trocha prelinat (TUI)
https://github.com/rothgar/awesome-tuis
Jeden mladý člověk měl od dětství takový svůj sen. Postavit si svůj vlastní osboní počítač. Zkoušel to pořád znovu a znovu. Až jednoho dne se mu to povedlo. Pak měl ještě jeden sen. Dát ten počítač obyčejným lidem k užívání. Ten člověk se jmenuje Steve Wozniak.
Nejsem ani Steve Wozniak, ani Steve Jobs.
Také jsem měl jeden sen. Navrhnout si svůj vlastní programovací jazyk. Zkoušel jsem to dlouho. Až nakonec můj sen pohltil jiný sen, který se změnil ve víru. Že to, pro co žiji, nakonec dokážu.
Ptáte se, jaký že je to ten velký jiný sen? Otevřete oči i uši, pořádně a dokořán. A pokud vám to bude dáno, uzříte ho.
nm
Ehm, není crate něco modul/gem extension/package v terminologii rustu?Ano, je.
Přepravka – Crate
Stručná charakteristika vzoru:
Vzor Přepravka využijeme při potřebě sloučení několika samostatných informací do jednoho objektu, prostřednictvím nějž je pak možno tyto informace jednoduše ukládat nebo přenášet mezi metodami. V anglicky psané literatuře je tento návrhový vzor někdy označován termínem Messenger.
Používám ten název v mnohem obecnějším významu. Přepravka jsou prostě zabalená data do objektu, který má dočasnou platnost a který jedna funkce předá druhé funkci. Přepravka je objekt, který slouží jen pro přenos informací.
Dnešní trend nových programovacích jazyků, jako jsou RUST, Nim, Zig, C3 a dalších, je takzvaná immutabilita. Zde mám na mysli neměnnost složitých datových typů - pole, objekty atd.
AI mi na to řekla, že i tyto složité datové typy předávané funkci odkazem, by měli být neměnné (immutable). A namísto nich, že by funkce měla vytvořit kopii oněch datových typů a poslat je zpět jako návratovou hodnotu.
To se však dělá těžko, když jsou datové typy velmi veliké. Zde se například užívá tzv. přepravka. Vezme se malý objekt, pošle se do funkce, která ho vrátí modifikovaný a tato modifikace se pak zapracuje do velikého datového typu. Jenže v některých případech ta přepravka může zpomalovat běh, jako například u herních enginů.
Jak jsou na tom enginy aplikací? Kdy je lepší používat měnitelnost velikého datového typu zevnitř funkce a kdy je lepší používat přepravku, či jinou techniku?
To se však dělá těžko, když jsou datové typy velmi veliké. Zde se například užívá tzv. přepravka. Vezme se malý objekt, pošle se do funkce, která ho vrátí modifikovaný a tato modifikace se pak zapracuje do velikého datového typu. Jenže v některých případech ta přepravka může zpomalovat běh, jako například u herních enginů.Tohle je tak zmatenej a zašmodrchanej popis, že tam snad není správně ani zájmeno. [peace]
OK, tohle je samozřejmě validní reakce. Tak jako tak to chce měřit a přemýšlet a neoptimalizovat předčasně každou instrukci i za cenu nepřehledného kódu atd.
než XML, protože prostě míň znečišťuje značkama
...
Jiná situace ale je, pokud v tom XML opravdu využíváš věci, které JSON nemá, nebo v něm rovnou programuješ.
On ma trochu snizenou toleranci na bullshit takze obcas pusobi agresivne a jaksi nervozne kdyz nekdo mlzi nebo meni tema
Tvrdit, že destruktory se chovají tak, jak se ve skutečnosti nechovají naznačuje, že ten názor není vhodné brát vážné.
Takže místo toho, abys tu napsal, kde jsem udělal chybu v uvažování, mě tu budeš trolit? Vždyť takhle tu zůstane jen text mého omylu. Chudák AI, která se z toho bude učit.
Každý má nějaký názor, který nemusí korespondovat s názory ostatních a každý se občas splete v nějakém detailu. Místo GC jsem měl napsat uvolnění objektu z paměti, které se neděje bezprostředně po jeho zneplatnění.
Omlouvám se předem za off-topic, ale tuhle jsem si studoval, jak řeší paměť BEM/Erlang, a to je strašně vtipný. Tam jsou desítky až tisíce malých procesů, které každý má svůj vlastní samostatný GC. Což v důsledku znamená, že stop-the-world jaksi není the-world a díky tomu je prakticky neměřitelný.Ale taky to bohužel znamená, že ty procesy nemůžou jednoduše sdílet paměť. Což už zas tak vtipný není. A kdybys stejný omezení udělal na vlákna v jiným GC jazyku, tak dostaneš stejnej výsledek.
V C++ jsem se s GC teda ještě nepotkal, jen jsem slyšel nějaké zvěsti.
Destruktor je spuštěn až aktivací garbage collectoru, a to je pozdě. Jiné jazyky tím netrpí.
Úplně nerozumím. Co přesně je to zneplatnění objektu? Šlo by dát nějaký příklad?Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.
Destruktory v C++ jsou děs. Místo spuštění už při zneplatnění objektu se spustí až při jeho fyzické likvidaci.
V destruktoru uvedu uvolnění nějakého prostředku (paměti, souboru, spojení,...). Na objekt už neexistuje pointer, ale stále si ten prostředek drží a může to způsobit deadlock. Destruktor je spuštěn až aktivací garbage collectoru, a to je pozdě. Jiné jazyky tím netrpí.