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.


Příspěvky - Ink

Stran: 1 ... 4 5 [6] 7 8 ... 43
76
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 04. 12. 2022, 14:29:45 »
Citace
Tohle v různých obdobách existuje dávno. Očividně se to zase tolik neosvědčilo a proto "svět" vymyslel třeba Rust, kde udělat program unsafe je možné, ale má to svoje pravidla a obecně se to nedoporučuje.

Muzete mi dat priklad toho rozsireni C o memory safe reseni ?

C++ obsahuje prvky memory safety, C++ je přece rozšířené C. A podobných jazyků je víc.

77
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 04. 12. 2022, 12:27:52 »
Neni. Ne ze by mne nezajimala psychologie za tim co se deje okolo Rustu, ale toho se zde asi nedobereme.

To je stejná psychologie, jako když jsi půl života musel tahat kamení za sebou na kárce a pak jsi dostal náklaďák.

Citace
Take mi neni uplne jasne, proc svet nesel jen rozsirenim jazyka C o vlastnosti, ktere by resily problem memory unsafe jazyka (tzn. stale by to bylo na programatorovi, zda pouzije cisty pointer a tim udela memory unsafe program).

Tohle v různých obdobách existuje dávno. Očividně se to zase tolik neosvědčilo a proto "svět" vymyslel třeba Rust, kde udělat program unsafe je možné, ale má to svoje pravidla a obecně se to nedoporučuje.

78
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 03. 12. 2022, 08:38:44 »
Domnívám se, že hodně schází nějaký projekt, který by porovnával řešení mezi jazyky. Občas zkouším použít RosettaCode, ale je to dost zakopaný. Představoval bych si něco předžvejkanějšího. Něco, co bude demonstrovat, že HKT, nebo AGDT vám umožní toto a toto, což se v tomto jazyce bez AGDT dělá takto, a má to tato omezení, a proto je AGDT lepší. 1)



1) provokativně očekávám, že se nyní strhne lavina příspěvků, že jsem úplnej debil, ať se kouknu na tuhle a tuhle stránku, že to už přece dávno je :-)

Co třeba tyhle, pro začátek?

https://gist.github.com/CMCDragonkai/a5638f50c87d49f815b8
https://www.reddit.com/r/rust/comments/6seaf8/why_are_higher_kinded_types_requested_in_rust/
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html

79
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 01. 12. 2022, 14:24:23 »
hloubkové pochopení typového systému a dalších aspektů Rustu přesahuje mentální obzor poměrně velké skupiny programátorů (nechme stranou debaty, jestli by se neměli raději živit něčím jiným).
Typový systém Rustu je primitivní, podstatně jednodušší než v případě již zmíněného OCamlu, Scaly nebo Haskellu (raději pomiňme Agdu, Coq a spol.). Nevím, jak se ten “mentální obzor” měří, ale co to je za vývojáře, kteří nepochopí ani typy Rustu?

Ty jsi dobrý necromancer. Ano, pomiň Agdu, Coq, Scalu, OCaml a Rust a začneš se blížit realitě "normálního" programátora.

80
Hardware / Re:Výběr klávesnice pro pracovní účely
« kdy: 25. 11. 2022, 22:37:24 »
Ta klávesnice Genesis Thor s Brown spínači je na tom s hlasitostí docela doře - je relativné tichá, děti mi nevzbudí. Kroužky jsem si nainstaloval, ale pocitově nepoznám rozdíl, zdá se mi to stejné...

Přemýšlím, že si pořídím nějakou další klávesnici, byl jsem zvyklý na Cherry MX Brown, ale tohoto "Outemu" se bojím (na CZC byly ty recenze dost špatné)...

81
Vývoj / Re:Načtení 2D pole v C
« kdy: 25. 11. 2022, 08:31:52 »
@mr.rubik: Moje znalosti C jsou dost neaktuální, takže k tvýmu kódu mám hloupej dotaz - proč funkce freeMatrix a freeMatrixRow žerou const pointery? Myslel jsem, že const značí, že se s parametrem pracuje v podstatě "read-only", což dealokace jeho části úplně není? Díky za osvětlení

Bezna implementace free() nic s daty na ktera pointer ukazuje nedela, obycejne existuje nekde v pameti seznam vsech alokovanych chunku pameti, a v tomto seznamu se odstrani zaznam o alokovane pameti na niz posilame pointer jako parametr funkce free(). Timpadem si alokator tento chunk pameti "oznaci jako znovu pouzitelny" a to je cele. Z tohoto pohledu spada dealokace do kategorie read-only.

Muze existovat nejaka bezpecnostni verze, ktera napriklad pri dealokaci vsechno prepise nulami, ale neni to bezne. Data tam zustanou dokud je nekdo jiny neprepise. Dealokaci se vsak programator zavazuje, ze s nimi jiz nebude nakladat.

Nikdo rozumný ale už nemůže předpokládat, že tam ten uvolněný objekt pořád je a o to jde. Z pohledu programové logiky a ne nějaké technické nahodilosti.

82
Studium a uplatnění / Re:Neochota firmy zvednout plat
« kdy: 22. 11. 2022, 16:49:31 »
A Ty máš touhu programovat ve "specifickém PL, který se nikde jinde nepoužívá", nebo se bojíš, že se programováním v nějakém normálním PL neuživíš? Už jenom kvůli tomuhle bych se jim na to vybodnul.

83
Server / Re:Nefungující HTTP
« kdy: 22. 11. 2022, 09:29:11 »
Ahoj, už delší dobu pozoruju, že mi občas nefungujou weby, které nemají zabezpečené spojení resp ty, které nejsou https. Např. včera to pravděpodobně nešlo během dne a dneska už to zase jde. Může jít o chybu u mě, nebo je to nějakej globální šotek? Někde jsem slyšel názor, že DNS googlu údajně může blokovat nezabezpečené spojení, ale to se mi nějak nepovedlo potvrdit, protože mi tu kolega zkusil jinej DNS server a nešlo to také. Dík za případnou reakci.

Používám DNS od Google a tohle nepozoruju. Bylo by to divné, DNS nemá co řešit "nezabezpečené spojení". A obecně ani nemůže. Zkusil bych zaměřit se na ty konkrétní weby - jsou služby, které dostupnost monitorují.

84
Vývoj / Re:Načtení 2D pole v C
« kdy: 21. 11. 2022, 22:22:58 »
Je to super, jak z toho školního příkladu chcete udělat skoro produkční kód.
Je v pořádku, že je ve školním projektu undefined behavior na třech místech? S tím, že jsou to kritické bezpečnostní chyby?

Souhlasím s tím, co jsi psal výše, tedy že C je jazyk nevhodný pro začátečníky (plný pastí, dodávám).

Mimochodem, co jsou ty tři chyby?
  • Buffer overflow na počet řádků.
  • Buffer overflow na počet sloupců.
  • Neinicializovaná matrix. Prakticky celou neinicializovanou matrix je možné vypsat, to je hodně dat. Tím to ale nekončí. V kombinaci s buffer overflow je možné vypsat úplně všechno, co je na zásobníku. Celý zásobník procesu, ke kterému se útočník snadno dostane. To může být fakt hodně potenciálně citlivých dat. Jako chápu, že to většina lidí neřeší, ale kritická bezpečnostní chyba to prostě je.

Jasně, dík.

85
Vývoj / Re:Načtení 2D pole v C
« kdy: 21. 11. 2022, 21:08:04 »
Toto su malicherne nedostatky, ktore sa daju lahko osetrit.
Asi máme jiný názor na to, co jsou malicherné nedostatky. Já vidím tři kritické bezpečnostní chyby.

Keby si mal nejaku sebareflexiu, tak by si namiesto kritiky radsej postol vlastny funkcny kod, co sa ale nestalo.
Kdybys měl nějakou sebereflexi, poděkoval bys za kostruktivní code review.

Je to super, jak z toho školního příkladu chcete udělat skoro produkční kód. Docela by mě zajímalo, co na to původní tazatel. Začal dost bezradně a tohle je jiný level. Mimochodem, co jsou ty tři chyby? Já tam vidím přetečení řádku nebo sloupce a pokud dobře rozumím, co se děje s inicializací toho pole, tak pokud není deklarováno jako static (nebo není vynulováno něčím jako int matrix[MAX_ROWS][MAX_COLS] = {0};), je v případě, že tam ta čísla v některých řádcích chybí (řídká matice?), v některých pozicích nedefinovaná hodnota. Jinak ale přidat dynamickou alokaci podle potřeby, umět načíst dlouhé řádky a je to?

86
Vývoj / Re:Načtení 2D pole v C
« kdy: 21. 11. 2022, 07:01:11 »
kdyz chce nekdo proniknout do veci, tak si i ty cihly muze sam udelat a vyzkouset si to.
pak kdyz zjisti jak to funguje, nasledne muze prejit na cihly co uz jsou k dispozici.

Na youtubu jsem viděl pár videí několika lidí, kteří to skutečně tak udělali. V reálném životě neznám nikoho. Tedy vulgo: ano, máte pravdu, ale ta vaše pravda je k ničemu.

A co jiného je výuka C, než základní pochopení, jak program funguje na mikroúrovni?

87
Vývoj / Re:Načtení 2D pole v C
« kdy: 21. 11. 2022, 06:58:40 »
Používám tuto konstrukci, čte celý řádek a pak řádek parsuje daným separátorem.

char *separator = " \t";
FILE *file = fopen( "jmeno_souboru.txt", "rt" );

fscanf( file, "%[^\n]s", line ); fgetc( file );

int index = atoi( strtok( line, separator ) );
double koef = atof( strtok( NULL, separator ) );

Tokenizace + zpracování po řádcích? To vypadá jako plán.

88
Vývoj / Re:Načtení 2D pole v C
« kdy: 20. 11. 2022, 19:34:08 »
A vubec, vse vyse zminene je naprosto nepodstatne, protoze zvolit "napsat si to sam" i kdyz je k dispozici standardni funkce je vzdy spatna volba (pokud nepotrebujete vyzdimat kazdou mikrosekundu) - a to z mnoha duvodu: kazdy, kdo to vezme po vas, si tu funkci bude muset precist, protoze nevi, co dela, pokud najde chybu, vy budete kopat okolo, ze "jste to tak myslel" - namisto "aha, scanf, ok, ten znam...".

Kdybych to měl řešit "po svém", pravděpodobně bych nepoužil C, kdybych musel použít C, je otázka, zda bych měl k dispozici jenom tyhle "standardní" funkce apod.

To, co jsem napsal plati pro produkcni kod, ale dost hrubym zpusobem to miji pointu tohoto vlakna. Tazatel je zacatecnik, chce nacist matici, dostal zadani udelat to v C a scanf je v tom jazyce standardni funkce...

OK, v pohodě. Zadání jsem neviděl - buďto tu není nebo jsem ho přehlédl. Přesto mi nepřijde to řešení s konečným automatem v takovémto případě špatné - vyřeší celkem jednoduše řádkování atd. Znaménko, whitespace apod. jsou úplně v pohodě, ošetřit "správně" invalidní znak je triviální, poskládání integeru z dekadického zápisu je triviální. Řešit hexa číslo je zvláštní, že se int nevejde do mezí typu je sice možné, ale co na tom vyřeší scanf()? Co když někdo napíše do vstupu stočíslicovou hodnotu?

89
Vývoj / Re:Načtení 2D pole v C
« kdy: 20. 11. 2022, 17:10:58 »
Otázka zní, zda vůbec používat funkci scanf() a zda by nebylo lepší udělat si vlastní konečný automat a načítat si ta čísla po znacích. Je to dost triviální.

To by teda nebylo lepší :) Je to dost citlivá funkce, protože načítá vstup, udělat to správně a bez chyb není vůbec triviální. A to se bavíme jen o integerech, floaty jsou úplně jiná liga. A navíc je to úplně mimo mísu pro začátečníka...

Ano, bavíme se o integerech. Jaké hrozné problémy tam jsou? V čem je lepší používat obskurní funkce typu scanf()?.

90
Vývoj / Re:Alternativa za Excel Visual Basic?
« kdy: 20. 11. 2022, 14:47:54 »
Proč myslíš, že by sis s LibreOffice Calc nepomohl a "s tím od Google" ano?

Stran: 1 ... 4 5 [6] 7 8 ... 43