Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: MaLaMuT 31. 10. 2017, 17:45:23
-
Ahoj,
Cčko se chová trochu jinak, než bych čekal.
Mám pole znaků (A to začne dělat problémy...):
unsigned char myfield[32];
Vynuluji ho:
memset(myfield, 0, 32);
Vytvořím si proměnnou, která by se neměla měnit:
char vstupniSoubor[] ="in.tx";
A teď začnu zapisovat do toho pole, resp. nastavovat prvky na pozici 0.
Na pozici 0 zapíšu hodnotu 0-255:
myfield[0]=(unsigned char)255;
printf("%s\n",vstupniSoubor);
myfield[0]=(unsigned char)0;
printf("%s\n",vstupniSoubor);
myfield[0]=(unsigned char)127;
printf("%s\n",vstupniSoubor);
myfield[0]=(unsigned char)255;
No a tohle mi velice rychle rozmrcasí tu proměnnou vstupniSoubor :-(
(https://images2.imgbox.com/9e/7b/2ji5mzai_o.png)
Když to nechám běžet dostatečně dlouho, rozbije to okno terminálu a nakonec to položí celý stroj.
Samotná hodnota myfield je naprosto v pořádku.
Pokud měním jiný prvek než nultý, tak se problém neprojevuje (možná to dělá paseku mimo tu proměnnou, kterou zobrazuji).
Jednak nechápu, proč by to mělo přetékat mimo pole.
Tj. kdyby se hodnota 0-255 nevešla do charu, což by se vejít měla, tak by to mělo ovlivnit sousední prvek.
Nakopněte mě, co je na tomhle špatně:
myfield[0]=(unsigned char)255;
Tato varianta se chová úplně stejně:
myfield[0]=255;
Co je špatně? :-\
-
verze kompileru?
cely zdrojovy kod?
mi to nic spatneho nedela.
vypis:
in.tx
in.tx
in.tx
-
Překladač: gcc version 6.3.0 20170516 (Debian 6.3.0-18)
Používám syntaxi C99, protože jedu jednořádkové komentáře
Jádro: 4.9.0-3-amd64
Parametry překladu:
gcc -Wall -o jentest jentest.c +knihovny, které ale nevolám
Celý zdroják nemůžu postnout :-( Něco s tím zkusím udělat, ale bojím se, že když ten kód budu upravovat, odmazávat proměnné, že se změna začne dít jinde v paměti a už to nepůjde ukázat.
-
Zkompilovat s address sanitizerem!!!
Jinak to vypadá, jako kdyby na konci vstupniSoubor nebyl znak \0.
[queue]Něco s tím zkusím udělat, ale bojím se, že když ten kód budu upravovat, odmazávat proměnné, že se změna začne dít jinde v paměti a už to nepůjde ukázat.[/queue]
A během toho asi zjistíš, kde je chyba.
-
Co zkusit char *vstupnisoubor="file.txt"; ?
-
Jenda, ač je obvykle totáč mimo, mi vyřešil problém :P
Nakoplo mě sprosté -fsanitize=address
Ona nepřetékalo to pole do té proměnné - na což jsem se soustředil, ale proměnná vstupniSoubor[] do pole :P
Jendo, VELMI TI DĚKUJI!
Já na to koukal jako vrána, zkoušel psí kusy a přitom taková blbost ::)
-
Zkus si vyprintit adresy těch promennnejch.
-
Hele já to nechápu. Jak se ti podařilo, aby překladač vyrobil ty proměnný aliasnuty? Nehledě na to, že literály bývají v jiném segmentu a ne na stacku.
-
napadlo tě někdy použít MS Visual Studio ? nebo Eclipse ?
-
Nj, chybu jsem udělal, když jsem si tady vyrobil moc malé pole: char vstupniSoubor[] ="in.tx";
Jeho poslední prvek zjevně přesahoval do prvního prvku toho druhého pole.
Nevšiml jsem si toho... ::)
Nebýt Jendy, tak na to koukám jako vrána i teď...
napadlo tě někdy použít MS Visual Studio ? nebo Eclipse ?
Dělám v C# a Visual Studio znám celkem dobře, ale ne pro čistý Cčko.
Moc jsem se soustředil na to, že je problém v tom poli ::)
@Jenda ještě jednou dík!
-
Nj, chybu jsem udělal, když jsem si tady vyrobil moc malé pole: char vstupniSoubor[] ="in.tx";
Jeho poslední prvek zjevně přesahoval do prvního prvku toho druhého pole.
Nevšiml jsem si toho... ::)
Nebýt Jendy, tak na to koukám jako vrána i teď...
Co to je za blbost? :D Pokud tvrdíš, že vstupniSoubor se nebude měnit, tak ti překladač vyrobí pole přesně tak velké, aby se do něho daný řetězcový literál vešel, včetně ukončovací nuly, a žádnou jinou proměnnou nealokuje tak, že by s tímto polem mohla při korektním zacházení kolidovat. Pokud bys to pole deklaroval s modifikátorem const, tak by nejspíš ta proměnná ukazovala někam do oblasti rodata, tedy úplně jinam než se nachází to druhé pole, jak už tu správně poznamenal předřečník.
Neboli chyba tam někde evidentně je, ale rozhodně nemůže být v tom, co píšeš, protože to pole pro tebe vyrábí překladač a ten se při určování jeho velikosti, narozdíl od lidí, neplete.
-
nechybi ti tam jenom v tom "retezci" na konci \0 ?
-
Co to je za blbost? :D Pokud tvrdíš, že vstupniSoubor se nebude měnit
No já ten řetězec modifikoval (strcp), tím vznikl přesah a proto se měnil při změnách pole...
Díky Jendově radě jsem si toho všiml hned.
-
nechybi ti tam jenom v tom "retezci" na konci \0 ?
urcite ne, sizeof(vstupniSoubor) mu vrati 6, tam se nula pridava automaticky, navic je to v jinem segmentu
taky by me zajimaly adresy tech promennych, muzes je pls. vypsat pres %p? Trosku to vypada, jako by neco z toho byla lokalni promenna mimo svou platnost :)
-
Tak abychom si to ujasnili. Ve všech případech uvažuji lokální deklarace.
char *s = "bla";
V .data nebo .rodata se alokují 4B s nulou terminovaným literárem. Proměnná s je pointer na stacku a je inicializována adresou toho literálu z příslušné sekce. I přes chybějící const je modifikace takového řetězce undefined a záleží na kompilatoru, zda taková operace skončí pádem aplikace.
char s[] = "bla";
Na stacku se alokuje 4prvkové pole, které je inicializováno příslušnými hodnotami (dost možná též z .rodata segmentu, dle implementace). Je v pořádku takový string měnit.
Ale nic z toho nevysvětluje ten alias; leda by OP deklaroval pole s explicitní délkou kratší, než je délka inicializačního řetězce s nulou.
-
Co to je za blbost? :D Pokud tvrdíš, že vstupniSoubor se nebude měnit
No já ten řetězec modifikoval (strcp), tím vznikl přesah a proto se měnil při změnách pole...
To by nevadilo, ze jsi lama. Ale vadi, ze v dotazu pises vyrazne jinej kod, nez kterej zpusobuje chybu a jeste zamerne tvrdis opak, nez delas (ze se nebude menit). Takhle se s cennym casem lidi jako Jenda nebo Tisnik nepracuje.
-
No já to nechtěl na sebe prášit, ale udělal jsem tuhle chybu a nevšiml si toho.
char vstupniSoubor[] ="in.tx";
strcat(vstupniSoubor, argv[1]);
To způsobilo, že se ty dvě proměnné překryly.
Taková blbá chyba no ::)
Njn. C# není Cčko, musím víc přemýšlet a míň prasit.
Díky za objasnění.
-
No já to nechtěl na sebe prášit, ale udělal jsem tuhle chybu a nevšiml si toho.
char vstupniSoubor[] ="in.tx";
strcat(vstupniSoubor, argv[1]);
To způsobilo, že se ty dvě proměnné překryly.
Taková blbá chyba no ::)
Njn. C# není Cčko, musím víc přemýšlet a míň prasit.
Díky za objasnění.
Šiš. Vždyť je to úplně něco jinýho.
-
ze v dotazu pises vyrazne jinej kod
A jednak to bylo v úplně jiné části, než kde jsem tu chybu hledal.
Myslel jsem, že ta chyba vzniká v kódu, který modifikuje to první pole.
Tam jsem tu chybu celou dobu honil.
Nenapadlo mě, že jsem si jí vyrobil o sto řádků předtím.
Můj čas je také drahý, lidem radím s jinými problémy, takže to dobro posílám dál.
Ale jinak Jendo díky a Robertotrone:
(http://www.rouming.cz/archived/sorry_jako.jpg)
-
Šiš. Vždyť je to úplně něco jinýho.
Je, ale je to o sto řádků výš.
Chyba se neprojevila, dokud jsem nezačal manipulovat s prvky toho druhého pole.
Chybně jsem identifikoval zdroj problému.
Jenda mě nakop ;)
-
Je to proste, char vstupniSoubor[] ="in.tx" je ekvivalentni char vstupniSoubor[5] ={'i', 'n', '.', 't', 'x'}; , tedy bez koncoveho '\0'.
Pro konstantni string je nejjednodusi char *vstupniSoubor="in.tx" (jak jsem psal vyse), resp. pro promeny string bud char vstupniSoubor[] ="in.tx\0", nebo char vstupniSoubor[6] ="in.tx\0", fungovat by melo i vstupniSoubor[6] ="in.tx".
-
Je to proste, char vstupniSoubor[] ="in.tx" je ekvivalentni char vstupniSoubor[5] ={'i', 'n', '.', 't', 'x'}; , tedy bez koncoveho '\0'.
Pro konstantni string je nejjednodusi char *vstupniSoubor="in.tx" (jak jsem psal vyse), resp. pro promeny string bud char vstupniSoubor[] ="in.tx\0", nebo char vstupniSoubor[6] ="in.tx\0", fungovat by melo i vstupniSoubor[6] ="in.tx".
nee prosím - http://www.tutorialspoint.com/cprogramming/c_strings.htm
cituji "Actually, you do not place the null character at the end of a string constant. The C compiler automatically places the '\0' at the end of the string when it initializes the array."
-
nee prosím - http://www.tutorialspoint.com/cprogramming/c_strings.htm
cituji "Actually, you do not place the null character at the end of a string constant. The C compiler automatically places the '\0' at the end of the string when it initializes the array."
Nemam tu knihu momentalne k disposici ale jestli si to pamatuji spravne, tak "Herout, Ucebnice jazyka C" uvadi to, co jsem psal ja...
-
Je to proste, char vstupniSoubor[] ="in.tx" je ekvivalentni char vstupniSoubor[5] ={'i', 'n', '.', 't', 'x'}; , tedy bez koncoveho '\0'.
Pro konstantni string je nejjednodusi char *vstupniSoubor="in.tx" (jak jsem psal vyse), resp. pro promeny string bud char vstupniSoubor[] ="in.tx\0", nebo char vstupniSoubor[6] ="in.tx\0", fungovat by melo i vstupniSoubor[6] ="in.tx".
Nikoli!
char s[] = "in.tx";
je ekvivalentem
char s[6] = {'i', 'n', '.', 't', 'x', '\0'};
a
char *s = "in.tx";
je ekvivalentem
char __unnamed[] = "in.tx";
char *s = __unnamed;
-
Lidi naučte se C++ a přestanete řešit voloviny
-
Njn. C# není Cčko, musím víc přemýšlet a míň prasit.
Ve srovnání s C# je programování v C jako procházka minovým polem. Občas pomohou přepínače, které bohužel nebývají defaultně zapnuty kvůli zpětné kompatibilitě.
-
nee prosím - http://www.tutorialspoint.com/cprogramming/c_strings.htm
cituji "Actually, you do not place the null character at the end of a string constant. The C compiler automatically places the '\0' at the end of the string when it initializes the array."
Nemam tu knihu momentalne k disposici ale jestli si to pamatuji spravne, tak "Herout, Ucebnice jazyka C" uvadi to, co jsem psal ja...
Na rozdíl od Zemana si nic přesně nepamatuju :-), tak jsem "Herouta" zkoukl a je to na straně 196, poznámka vlevo nahoře (třetí upravené vydání, v dalších vydáních to možná bude o kousek dál).
-
nee prosím - http://www.tutorialspoint.com/cprogramming/c_strings.htm
cituji "Actually, you do not place the null character at the end of a string constant. The C compiler automatically places the '\0' at the end of the string when it initializes the array."
Nemam tu knihu momentalne k disposici ale jestli si to pamatuji spravne, tak "Herout, Ucebnice jazyka C" uvadi to, co jsem psal ja...
Spíš bych tipoval, že si to správně nepamatuješ. Takovou blbost by snad Herout nenapsal.
Lidi naučte se C++ a přestanete řešit voloviny
C je jednoduchý a s určitou praxí a cvikem příjemný nízkoúrovňový jazyk. Kdežto C++ je... raději no comment, nerad užívám sprostých slov. Ale když chce někdo objektově programovat, měl by použít objektový jazyk a ne C++.
Njn. C# není Cčko, musím víc přemýšlet a míň prasit.
Ve srovnání s C# je programování v C jako procházka minovým polem. Občas pomohou přepínače, které bohužel nebývají defaultně zapnuty kvůli zpětné kompatibilitě.
Je to jazyk z přelomu 60. a 70. let. Tenkrát se ještě nepočítalo s tím, že ho budou používat lidé mentálně předurčení spíše k manuálním činnostem, jak je tomu v IT dnes ;)
-
Lidi naučte se C++ a přestanete řešit voloviny
C je jednoduchý a s určitou praxí a cvikem příjemný nízkoúrovňový jazyk. Kdežto C++ je... raději no comment, nerad užívám sprostých slov. Ale když chce někdo objektově programovat, měl by použít objektový jazyk a ne C++.
Nejde o objekty, ale třeba kdyby použil std::string, tak se vyhne většině bezpečnostních problémů a další drtivé většina běžných začátečnických problémů. Mimochodem, práce s řetězci je z pravidla příčinou různých chyb typu buffer overrun, což je i tenhle případ, jako demonstrace postačí.
-
Ve srovnání s C# je programování v C jako procházka minovým polem.
Přesně tak, běžně jedu v C# a jen některé věci jedu v čistém Cčku (výpočty).
Nepoužívám C++, protože na OOP mám C#
Kdežto C++
C++ je překonaný jazyk, byl překonán Javou a C#.
Multithreading v C++ je opruz, C# má poměrně velkou paletu nástrojů a to nejen pro tohle.
Z mého pohledu je kombinace C99 a C# 7 ideální.
Tady jsem udělal chybu, protože si hlídám čísla a přitom jsem si nepohlídal jednu hloupou proměnnou.
-
C++ je překonaný jazyk, byl překonán Javou a C#.
Multithreading v C++ je opruz, C# má poměrně velkou paletu nástrojů a to nejen pro tohle.
Kdy jste naposledy viděl C++. Já jen že už od verze z roku 2011 je multithreading naprostá pohoda.
Co se jmenovaných jazyků týče, tak C# = otrok Microsoftu, Java = otrok Oracle, C++ = svoboda.
-
Z mého pohledu je kombinace C99 a C# 7 ideální.
Zkusil sis někdy jazyk D? Měl by spojovat výhody obou zmíněných jazyků.
-
Co se jmenovaných jazyků týče, tak C# = otrok Microsoftu, Java = otrok Oracle, C++ = svoboda.
Když už se bavíme o Javě, tak GCJ je také svobodný.
-
Zkusil sis někdy jazyk D? Měl by spojovat výhody obou zmíněných jazyků.
Mně osobně to D hodně láká, ale jeho rozšíření je zatím dost malé a tuším, že dělali nějaký brikule, kdy se jazyk vyvíjel a trochu se měnily datové typy. Připouštím, že to bude dobře pět let, takže to mohlo dozrát.
-
Zkusil sis někdy jazyk D? Měl by spojovat výhody obou zmíněných jazyků.
Mně osobně to D hodně láká, ale jeho rozšíření je zatím dost malé a tuším, že dělali nějaký brikule, kdy se jazyk vyvíjel a trochu se měnily datové typy. Připouštím, že to bude dobře pět let, takže to mohlo dozrát.
Dlang by měl být začleněn do kompilátoru GCC podobně jako mnoho dalších jazyků. Teprve pak to bude ta správná paráda.
-
Uz tu diskuzi nerozmelnujte.
Autore se poucil, ze dotaz je treba spravne zadat.
A zatajovani co dela v kodu jen zhorsuje situaci.
-
Co se jmenovaných jazyků týče, tak C# = otrok Microsoftu, Java = otrok Oracle, C++ = svoboda.
Nevím, jestli má Oracle výhradní práva na Javu, ale na ní mi vadí jiné věci: absence RAII, šablon a neznaménkových typů. Šablony v Javě jsou parodie na šablony.
-
Autorovi doporucuju projet si zakladni tutorial GO, to je dnesni opravdova nahrada C.
Pak si na nejake C ani nevzpomene.
Zvlast pokud je rec o pouziti na vypocty a dnesnich multicore procesorech. V GO za pomoci goroutines a buffered channels s prstem v nose. V C programatorske peklo silne nachylne na chyby.
-
Autorovi doporucuju projet si zakladni tutorial GO, to je dnesni opravdova nahrada C.
Pak si na nejake C ani nevzpomene.
Zvlast pokud je rec o pouziti na vypocty a dnesnich multicore procesorech. V GO za pomoci goroutines a buffered channels s prstem v nose. V C programatorske peklo silne nachylne na chyby.
S Go si moc nepomůže, má tam pořád garbage collector a výkon Go oproti C taky nic moc. Místo C bych doporučitl spíš Rust, to je opravdová náhrada C, pak si na nějaké Go nebo C už ani nevzpomene :).
-
Autorovi doporucuju projet si zakladni tutorial GO, to je dnesni opravdova nahrada C.
Pak si na nejake C ani nevzpomene.
Zvlast pokud je rec o pouziti na vypocty a dnesnich multicore procesorech. V GO za pomoci goroutines a buffered channels s prstem v nose. V C programatorske peklo silne nachylne na chyby.
S Go si moc nepomůže, má tam pořád garbage collector a výkon Go oproti C taky nic moc. Místo C bych doporučitl spíš Rust, to je opravdová náhrada C, pak si na nějaké Go nebo C už ani nevzpomene :).
A vůbec nejlepší by bylo si pořádně procvičit to C. Pak se obejde bez Rustu i bez Go, které mi připadají jako pomocná kolečka přimontovaná na motorku. :) Však si každý může vybrat, zda chce motorku, tříkolku nebo auto. Každé má svá pro i proti. Když se budu potřebovat rychle někam dostat něčím malým, tak zvolím motorku. Když na dovolenou s rodinou, tak asi auto. Ale hanět motorku kvůli tomu, že by si na ní průměrný plechovkář rozmlátil hubu, je nesmyslné. To není nedostatek motorky.
-
Zkusil sis někdy jazyk D? Měl by spojovat výhody obou zmíněných jazyků.
Mně osobně to D hodně láká, ale jeho rozšíření je zatím dost malé a tuším, že dělali nějaký brikule, kdy se jazyk vyvíjel a trochu se měnily datové typy. Připouštím, že to bude dobře pět let, takže to mohlo dozrát.
Tak ho zkus. Mohu vřele doporučit. Používám jej už asi něco přes 5 let a jsem s jazykem D velmi spokojen. Jinak o tom že by se vyloženě měnily datové typy nic nevím (záleží co přesně máš namysli). Jinak za posledních pět let tento jazyk hodně dozrál. Zejména je vidět snaha celkově jazyk stabilizovat. Tím nemám namysli že už by se dál nevyvíjel a nepřidával nové vlastnosti (ba naopak), ale je vidět snaha nic při tom nerozbít a zachovat zpětnou kompatibilitu co možná nejvíce co to jde.
Jinak ať se vyhnem offtopic tématu. Pokud máš zájem o více info o jazyku D, tak mi klidně napiš na mail kozzi11 zavinac gmail tecka com
-
A vůbec nejlepší by bylo si pořádně procvičit to C. Pak se obejde bez Rustu i bez Go, které mi připadají jako pomocná kolečka přimontovaná na motorku. :) Však si každý může vybrat, zda chce motorku, tříkolku nebo auto. Každé má svá pro i proti. Když se budu potřebovat rychle někam dostat něčím malým, tak zvolím motorku. Když na dovolenou s rodinou, tak asi auto. Ale hanět motorku kvůli tomu, že by si na ní průměrný plechovkář rozmlátil hubu, je nesmyslné. To není nedostatek motorky.
Ehm, říkat o Rustu, že je motorka s pomocnýma kolečkama, to je úplné nepochopení toto, co Rust nabízí. Rust je oproti C navíc memory safe a data race safe, což je kontrolované už během kompilace. V Rustu nejde program, který není paměťově bezpečný nebo je v něm data race, vůbec zkompilovat. To všechno při rychlosti srovnatelné s C. Obojí je velký nedostatek C, stále se vyskytují nové a nové kritické bezpečností chyby v profesionálním software psaným profesionály, protože někdo zapomněl, jak má velké pole nebo kam mu zrovna ukazuje pointer. Lidé prostě dělají chyby. Překladač Rustu chybu neudělá, odmítne to přeložit.
-
A vůbec nejlepší by bylo si pořádně procvičit to C. Pak se obejde bez Rustu i bez Go, které mi připadají jako pomocná kolečka přimontovaná na motorku. :) Však si každý může vybrat, zda chce motorku, tříkolku nebo auto. Každé má svá pro i proti. Když se budu potřebovat rychle někam dostat něčím malým, tak zvolím motorku. Když na dovolenou s rodinou, tak asi auto. Ale hanět motorku kvůli tomu, že by si na ní průměrný plechovkář rozmlátil hubu, je nesmyslné. To není nedostatek motorky.
Ehm, říkat o Rustu, že je motorka s pomocnýma kolečkama, to je úplné nepochopení toto, co Rust nabízí. Rust je oproti C navíc memory safe a data race safe, což je kontrolované už během kompilace. V Rustu nejde program, který není paměťově bezpečný nebo je v něm data race, vůbec zkompilovat. To všechno při rychlosti srovnatelné s C. Obojí je velký nedostatek C, stále se vyskytují nové a nové kritické bezpečností chyby v profesionálním software psaným profesionály, protože někdo zapomněl, jak má velké pole nebo kam mu zrovna ukazuje pointer. Lidé prostě dělají chyby. Překladač Rustu chybu neudělá, odmítne to přeložit.
To je ale přesně co říkám. Na motorce se oproti autu taky snadno vysekáš, stačí štěrk v zatáčce nebo prudce puštěná spojka a už letíš. To se ti v autu (nebo pokud máš pomocná kolečka) nestane. Ne že by se nešlo v autě vybourat. Jde to, ale je třeba vyvinout trochu víc úsilí než jen zprudka pustit spojku. To ale není důvod snažit se zavrhnout motorku nebo ji znásilňovat pomocnými kolečky. Tak jako se mi už dávno nestává, že bych měl na motorce ty výše zmíněné problémy, tak ani v C se mi nestane, co se stává vám s pamětí. Už po těch letech máte vyvinutý určitý podvědomý cvik, jak s takovými objekty zacházet, člověk už ví, že dělá něco potenciálně nebezpečného a podle toho k tomu přistupuje. Ale to je otázka cviku, letité praxe. To se prostě musí zažít. Stejně jako na té motorce. Pokud vám to nejde, není to chyba motorky ani C. Prostě nemáte praxi nebo vám k tomu chybějí vlohy. Můžete furt dobře řídit to auto, ale jsou prostě chvíle, kdy ta motorka je efektivnější a když ji nezvládáte, musíte vzít za vděk méně efektivním řešením.
-
A vůbec nejlepší by bylo si pořádně procvičit to C. Pak se obejde bez Rustu i bez Go, které mi připadají jako pomocná kolečka přimontovaná na motorku. :) Však si každý může vybrat, zda chce motorku, tříkolku nebo auto. Každé má svá pro i proti. Když se budu potřebovat rychle někam dostat něčím malým, tak zvolím motorku. Když na dovolenou s rodinou, tak asi auto. Ale hanět motorku kvůli tomu, že by si na ní průměrný plechovkář rozmlátil hubu, je nesmyslné. To není nedostatek motorky.
Ehm, říkat o Rustu, že je motorka s pomocnýma kolečkama, to je úplné nepochopení toto, co Rust nabízí. Rust je oproti C navíc memory safe a data race safe, což je kontrolované už během kompilace. V Rustu nejde program, který není paměťově bezpečný nebo je v něm data race, vůbec zkompilovat. To všechno při rychlosti srovnatelné s C. Obojí je velký nedostatek C, stále se vyskytují nové a nové kritické bezpečností chyby v profesionálním software psaným profesionály, protože někdo zapomněl, jak má velké pole nebo kam mu zrovna ukazuje pointer. Lidé prostě dělají chyby. Překladač Rustu chybu neudělá, odmítne to přeložit.
To je ale přesně co říkám. Na motorce se oproti autu taky snadno vysekáš, stačí štěrk v zatáčce nebo prudce puštěná spojka a už letíš. To se ti v autu (nebo pokud máš pomocná kolečka) nestane. Ne že by se nešlo v autě vybourat. Jde to, ale je třeba vyvinout trochu víc úsilí než jen zprudka pustit spojku. To ale není důvod snažit se zavrhnout motorku nebo ji znásilňovat pomocnými kolečky. Tak jako se mi už dávno nestává, že bych měl na motorce ty výše zmíněné problémy, tak ani v C se mi nestane, co se stává vám s pamětí. Už po těch letech máte vyvinutý určitý podvědomý cvik, jak s takovými objekty zacházet, člověk už ví, že dělá něco potenciálně nebezpečného a podle toho k tomu přistupuje. Ale to je otázka cviku, letité praxe. To se prostě musí zažít. Stejně jako na té motorce. Pokud vám to nejde, není to chyba motorky ani C. Prostě nemáte praxi nebo vám k tomu chybějí vlohy. Můžete furt dobře řídit to auto, ale jsou prostě chvíle, kdy ta motorka je efektivnější a když ji nezvládáte, musíte vzít za vděk méně efektivním řešením.
Problem je, ze hromada lidi poiziva motorku na miste, kde je potreba pasovy buldozer.
Navic i pokud za cenu hrozneho usili si pohlidam, aby muj C kod byl flawless, dosahnu leda toho, ze chyby dodal autor prilinkovane knihovny, treba OpenSSL.
Nahore jsem navrhoval GO. GO bude mit occa 30% slabsi singlecore vykon nez hole C. Pomoci goroutines a channeled buffers to s prstem v nose rozprostres na 8 cores - pojede jak z praku.
Veskery business kod mnohem bezpecnejsi a prehlednejsi, stringy, arrays, jsou bezpecne, HashMap v C vubec neni.
GO muze bez problemu embeddovat C kod, neni nejmensi problem udelat si ten jeden horky time critical forloop v C, veskery okolostojicny business kod v bezpecnem a pohodlnem GO.
Navic GO ma obrovskou vyhodu v ekosystemu. Pristupuje ke GITHubu ve stylu mavenu pro chude.
Potrebuju v GO programu nejaky message bus.
V commadlajne napisu: "go get github.com/nats-io/gnatsd" - a mam luxusni NATS message bus k obecnemu pouziti, samo se to stahne a nainstalu je do GO environmentu.
Navic GO ma luxusni standard library, je v ni treba i HTTP server na microservices.
-
To je ale přesně co říkám. Na motorce se oproti autu taky snadno vysekáš, stačí štěrk v zatáčce nebo prudce puštěná spojka a už letíš. To se ti v autu (nebo pokud máš pomocná kolečka) nestane. Ne že by se nešlo v autě vybourat. Jde to, ale je třeba vyvinout trochu víc úsilí než jen zprudka pustit spojku. To ale není důvod snažit se zavrhnout motorku nebo ji znásilňovat pomocnými kolečky. Tak jako se mi už dávno nestává, že bych měl na motorce ty výše zmíněné problémy, tak ani v C se mi nestane, co se stává vám s pamětí. Už po těch letech máte vyvinutý určitý podvědomý cvik, jak s takovými objekty zacházet, člověk už ví, že dělá něco potenciálně nebezpečného a podle toho k tomu přistupuje. Ale to je otázka cviku, letité praxe. To se prostě musí zažít. Stejně jako na té motorce. Pokud vám to nejde, není to chyba motorky ani C. Prostě nemáte praxi nebo vám k tomu chybějí vlohy. Můžete furt dobře řídit to auto, ale jsou prostě chvíle, kdy ta motorka je efektivnější a když ji nezvládáte, musíte vzít za vděk méně efektivním řešením.
No já mám v C nacouváno možná víc, než co máš ty odježděno dopředu :). Jenomže narozdíl od tebe znám i Rust. Oproti C nabízí mnohem vyšší míru abstrakce a bezpečnosti při srovnatelném výkonu. Nemá smysl začínat nový projekt v C, když místo C můžeš použít Rust.
Jakmile někdo začně stylem "já nemám v C problém, jenom patlalům se stávají segfaulty", tak je mi jasné, že nemá žádnou zkušenost s větším projektem v C/C++. Chybám při práci s pamětí nejde v C zabránit, už jenom kvůli tomu, že na projektu pracuje více lidí a stačí, aby se nedomluvili nebo nepochopili. Děje se to bohužel úplně běžně v každém projektu jenom trochu složitějším než Hello World.
-
Nahore jsem navrhoval GO. GO bude mit occa 30% slabsi singlecore vykon nez hole C.
Bohužel je to víc než 30%, Go bude průměrně tak 3x pomalejší než čisté C (záleží samozřejmě na typu úlohy). Nějaké srovnání zde: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc
Když srovnáš Go s Rustem, tak je výtěz myslím celkem jasný: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go
Rust navíc garantuje, že v programu nebude žádný data race, tohle v Go garantované nemáš a data races si musíš hlídat sám.
Nicméně nechci aby to vyznělo tak, že je Go špatné, není. Go je výborná volba hlavně na microservices a podobné úlohy, gorutiny jsou fakt dobré. Ale když někdo řeší, kam od C utéct, tak je první volba Rust, protože je C mnohem blíže a nabízí vyšší výkon než Go.
-
Jakmile někdo začně stylem "já nemám v C problém, jenom patlalům se stávají segfaulty", tak je mi jasné, že nemá žádnou zkušenost s větším projektem v C/C++. Chybám při práci s pamětí nejde v C zabránit, už jenom kvůli tomu, že na projektu pracuje více lidí a stačí, aby se nedomluvili nebo nepochopili. Děje se to bohužel úplně běžně v každém projektu jenom trochu složitějším než Hello World.
V C++ se ten problém redukuje už kvůli tomu, že tam se dá projekt rozdělit na objekty, které se z principu každý stará o svůj svět. Pokud je každý objekt odladěn a otestován, problémy známe z C se v C++ prostě projevit nemohou.
Jo a samozřejmě, lidi nechtěji používat C++ protože ho neumí. A neumí ho proto, že se C++ u nás, ale i kdekoliv na světe blbe vyučuje
https://www.youtube.com/watch?v=YnWhqhNdYyk
-
V C++ se ten problém redukuje už kvůli tomu, že tam se dá projekt rozdělit na objekty, které se z principu každý stará o svůj svět. Pokud je každý objekt odladěn a otestován, problémy známe z C se v C++ prostě projevit nemohou.
Ale mohou se objevit a objevují se. C++ nabízí vyšší míru abstrakce a odstiňuje od low level správy paměti, ale negarantuje navíc vůbec nic. V C++ se dá střelit do nohy stejně snadno jako v C (dokonce k tomu je více příležitostí). C++ nehlídá žádné chyby přístupu do paměti, všechno musí programátor pohlídat ručně. No a lidi dělají chyby. Pokud něco lze zkontrolovat strojově, je to lepší nechat zkontrolovat stojově. Překladač Rustu chybu neudělá, neunaví se, protože dělá na projektu, který je ve skluzu už 10 hodin v kuse a všichni se ho ptají, jakto že to ještě nemá hotové.
-
Nahore jsem navrhoval GO. GO bude mit occa 30% slabsi singlecore vykon nez hole C.
Bohužel je to víc než 30%, Go bude průměrně tak 3x pomalejší než čisté C (záleží samozřejmě na typu úlohy). Nějaké srovnání zde: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc
Když srovnáš Go s Rustem, tak je výtěz myslím celkem jasný: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go
Rust navíc garantuje, že v programu nebude žádný data race, tohle v Go garantované nemáš a data races si musíš hlídat sám.
Nicméně nechci aby to vyznělo tak, že je Go špatné, není. Go je výborná volba hlavně na microservices a podobné úlohy, gorutiny jsou fakt dobré. Ale když někdo řeší, kam od C utéct, tak je první volba Rust, protože je C mnohem blíže a nabízí vyšší výkon než Go.
Go jsem zminoval hlavne proto, ze bezny program obsahuje bajvoko 90% business kodu, kde na rychlosti nesejde a cca 10% horkeho kodu, ktery ma smysl optimalizovat. A na tythle kousky jde v GO bezproblemove embeddovat C.
GO ma i prvky z vyssich jazyku, je to takova Java pro chude, pak mas k dispozici vic moznosti. Rust je jenom nahrada C.
-
Ale mohou se objevit a objevují se. C++ nabízí vyšší míru abstrakce a odstiňuje od low level správy paměti, ale negarantuje navíc vůbec nic. V C++ se dá střelit do nohy stejně snadno jako v C (dokonce k tomu je více příležitostí). C++ nehlídá žádné chyby přístupu do paměti, všechno musí programátor pohlídat ručně. No a lidi dělají chyby. Pokud něco lze zkontrolovat strojově, je to lepší nechat zkontrolovat stojově. Překladač Rustu chybu neudělá, neunaví se, protože dělá na projektu, který je ve skluzu už 10 hodin v kuse a všichni se ho ptají, jakto že to ještě nemá hotové.
No protože to nejsou C++ programátoři. Protože současná generace programátorů umí z C základy a používá k tomu C++ syntaxi a nazývají se C++ programátoři. Spoléhat se, že nějaký stroj udělá code review nejde. Vždycky to bude něco za něco. Jazyky s GC za programátora řeší správu paměti, jejich nevýhodou je, že správu paměti už nemůže dělat programátor a navíc ta správa paměti není 100%. Totéž v Rustu. Něco za Vás Rust hlída, ale zároveň omezuje. A když dojde na lámání chleba, začnu Rust obcházet a vymýšlet prasárny.
-
Go jsem zminoval hlavne proto, ze bezny program obsahuje bajvoko 90% business kodu, kde na rychlosti nesejde a cca 10% horkeho kodu, ktery ma smysl optimalizovat. A na tythle kousky jde v GO bezproblemove embeddovat C.
GO ma i prvky z vyssich jazyku, je to takova Java pro chude, pak mas k dispozici vic moznosti. Rust je jenom nahrada C.
Rust fakt není náhrada C, Rust nabízí vyšší míru abstrakce než C i Go. Chceš generika? V Rustu není problém, v Go si o tom můžeš nechat akorát tak zdát...
-
No protože to nejsou C++ programátoři. Protože současná generace programátorů umí z C základy a používá k tomu C++ syntaxi a nazývají se C++ programátoři. Spoléhat se, že nějaký stroj udělá code review nejde. Vždycky to bude něco za něco. Jazyky s GC za programátora řeší správu paměti, jejich nevýhodou je, že správu paměti už nemůže dělat programátor a navíc ta správa paměti není 100%. Totéž v Rustu. Něco za Vás Rust hlída, ale zároveň omezuje. A když dojde na lámání chleba, začnu Rust obcházet a vymýšlet prasárny.
Lámání chleba je co? Nějaká hardcore optimalizace něčeho? To se dělá obvykle v assembleru, nebo pokud bych fakt chtěl, tak je v Rustu unsafe, ale nikdy jsem ale neměl potřebu unsafe přímo použít. C++ je oproti tomu unsafe by default, nelze si vybrat, že teď to chci safe. C++ safe režim jaksi neumí...
-
Střelné zbraně, zápalky a překladač C nepatří do rukou amatérů 8)
-
Ale mohou se objevit a objevují se. C++ nabízí vyšší míru abstrakce a odstiňuje od low level správy paměti, ale negarantuje navíc vůbec nic. V C++ se dá střelit do nohy stejně snadno jako v C (dokonce k tomu je více příležitostí). C++ nehlídá žádné chyby přístupu do paměti, všechno musí programátor pohlídat ručně. No a lidi dělají chyby. Pokud něco lze zkontrolovat strojově, je to lepší nechat zkontrolovat stojově. Překladač Rustu chybu neudělá, neunaví se, protože dělá na projektu, který je ve skluzu už 10 hodin v kuse a všichni se ho ptají, jakto že to ještě nemá hotové.
No protože to nejsou C++ programátoři. Protože současná generace programátorů umí z C základy a používá k tomu C++ syntaxi a nazývají se C++ programátoři.
A to je prave ono. Jelikoz sehnat (a zaplatit) kvalitni C++ programatori, kteri si vse ohlidaji, nedava dnes casto smysl. A je mnohem lepsi to nechat to na prekladaci a programatory at se venuji tomu za co jsou placeni :P.
-
Lámání chleba je co? Nějaká hardcore optimalizace něčeho? To se dělá obvykle v assembleru, nebo pokud bych fakt chtěl, tak je v Rustu unsafe, ale nikdy jsem ale neměl potřebu unsafe přímo použít. C++ je oproti tomu unsafe by default, nelze si vybrat, že teď to chci safe. C++ safe režim jaksi neumí...
Která konkrétní část C++ je unsafe? To že můžete použít věci z C? Že to nemusím uvozovat nějakým klíčovým slovem? Je to problém? Analyzátory C++ kódu existují a umí docela dobře upozornit na unsafe techniky v C++ kódu. To že si něco vynucuje syntaxe je jen syntax sugar.
Co se runtime týče, jakákoliv bezpečí hlídající technika jde proti výkonu. V tomto místě chci mít svobodu, jestli zajištění bezpečnosti nebo výkon.
-
Která konkrétní část C++ je unsafe? To že můžete použít věci z C? Že to nemusím uvozovat nějakým klíčovým slovem? Je to problém? Analyzátory C++ kódu existují a umí docela dobře upozornit na unsafe techniky v C++ kódu. To že si něco vynucuje syntaxe je jen syntax sugar.
Co se runtime týče, jakákoliv bezpečí hlídající technika jde proti výkonu. V tomto místě chci mít svobodu, jestli zajištění bezpečnosti nebo výkon.
Unsafe je v C++ prakticky všechno např.:
*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();
Rust v runtime navíc oproti C hlídá jen velikost pole při náhodném přístupu přes index. To musí dělat, toho se nejde zbavit. Při sekvenčním přistupu není třeba index hlídat, stačí porovnat s mezí pole, tam není žádná výkonová penalizace.
Výkonově je Rust a C++ prakticky nastejno: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp
Rust navíc dává garanci, že v programu není žádný data race, tohle v C++ zaručit nelze.
-
Co se runtime týče, jakákoliv bezpečí hlídající technika jde proti výkonu. V tomto místě chci mít svobodu, jestli zajištění bezpečnosti nebo výkon.
Tyto techniky hlídající bezpečí by měly být defaultně zapnuté. Kdo chce výkon, může si je po odladění vypnout.
-
Lámání chleba je co? Nějaká hardcore optimalizace něčeho? To se dělá obvykle v assembleru, nebo pokud bych fakt chtěl, tak je v Rustu unsafe, ale nikdy jsem ale neměl potřebu unsafe přímo použít. C++ je oproti tomu unsafe by default, nelze si vybrat, že teď to chci safe. C++ safe režim jaksi neumí...
Která konkrétní část C++ je unsafe? To že můžete použít věci z C? Že to nemusím uvozovat nějakým klíčovým slovem? Je to problém? Analyzátory C++ kódu existují a umí docela dobře upozornit na unsafe techniky v C++ kódu. To že si něco vynucuje syntaxe je jen syntax sugar.
Co se runtime týče, jakákoliv bezpečí hlídající technika jde proti výkonu. V tomto místě chci mít svobodu, jestli zajištění bezpečnosti nebo výkon.
to už vám bylo vyvráceno v této diskuzi
https://www.root.cz/clanky/ukazatele-v-rustu-aneb-temna-strana-sily/nazory/
-
Unsafe je v C++ prakticky všechno např.:
*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();
Krása, ale chtěl jsem C++. Ne C.
Rust navíc dává garanci, že v programu není žádný data race, tohle v C++ zaručit nelze.
Rust si hlavně pomáhá tím, že má všechno imutabilní. Já taky v programech mám většinu věcí imutabulní právě proto, abych co nejméně řešil data races. C++ vám nebrání mít imutabilní objekty. To není vlastnost jazyka. A pokud v runtime automaticky zamyká přístup k neimutabilním objektům, ... tak pak je to o tom výkonu ... rozhodně to nebude žádný modrý přízrak.
-
Unsafe je v C++ prakticky všechno např.:
*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();
Krása, ale chtěl jsem C++. Ne C.
Aha, takže v C++ se nepřistupuje do pole nebo se nevolají metody objektu? To už je opravdu velká demagogie. Znovu opakuji, v C++ není safe prakticky nic, protože C++ neřeší životnost objektů.
Rust si hlavně pomáhá tím, že má všechno imutabilní. Já taky v programech mám většinu věcí imutabulní právě proto, abych co nejméně řešil data races. C++ vám nebrání mít imutabilní objekty. To není vlastnost jazyka. A pokud v runtime automaticky zamyká přístup k neimutabilním objektům, ... tak pak je to o tom výkonu ... rozhodně to nebude žádný modrý přízrak.
Garance v Rustu jsou založené na tom, že může být buď libobolný počet imutabilních objektů, nebo pouze jeden objekt mutabilní. V runtime Rust nic nezamyká, řeší se to během kompilace. Prosím nepište nesmysly, když o tom nic nevíte. Jediný runtime overhead navíc v Rustu je při kontrole mezí polí při náhodném přístupu. Proto je taky rychlost Rustu a C++ srovnatelná. Rust nemá žádný runtime overhead navíc a přitom garantuje, že v programu není data race. Zjistí to už během kompilace.
-
Rust si hlavně pomáhá tím, že má všechno imutabilní.
To není pravda.
Já taky v programech mám většinu věcí imutabulní právě proto, abych co nejméně řešil data races.
ve vašem příkladu mutable counteru z jiné diskuze jste musel používat zámky. Kdybyste v tom udělal chybu, tak to překladač narozdíl od Rustu přeloží.
-
Unsafe je v C++ prakticky všechno např.:
*pointer;
pointer += neco; *pointer;
pole[index];
*iterator;
iterator += neco; *iterator;
if (pointer) *pointer; // pointer neni null, ale objekt uz neexistuje
objekt->metoda();
Krása, ale chtěl jsem C++. Ne C.
Aha, takže v C++ se nepřistupuje do pole nebo se nevolají metody objektu? To už je opravdu velká demagogie. Znovu opakuji, v C++ není safe prakticky nic, protože C++ neřeší životnost objektů.
V C++ nejsou pole! V C++ máte std::vector<>! Že můžete v C++ udělat pole je proto, že C++ sebou taha C. Ale při code review pokud někdo někde vytváří pole, tak kód letí na přepsání, pokud to nemá nějaký závažný výkonostní důvod. To se pozná na první pohled
Jak C++ neřeší životnost objektu? C++ má RAII!!! A opět, pokud míníte pointery, tak zase už nejste v C++. C++ má přece std::shared_ptr nebo std::unique_ptr!
Mám ještě demonstrovat že o C++ nevíte vůbec nic?
[/quote]
Garance v Rustu jsou založené na tom, že může být buď libobolný počet imutabilních objektů, nebo pouze jeden objekt mutabilní.
Vím jak fungují imutabilní objekty. Mám na tomhle principu postavenou celou knihovnu.
https://github.com/ondra-novak/imtjson
. Rust nemá žádný runtime overhead navíc a přitom garantuje, že v programu není data race. Zjistí to už během kompilace.
No jasně, stačí jen ověřit imutabilitu. Najít race v systémech, kde se sdílí stav, třeba taková sdílená mapa s nutností do ní zapisovat, to už taková sranda není. A není to věc jazyka.
Jste naivní a zaslepený svou vírou.
-
ve vašem příkladu mutable counteru z jiné diskuze jste musel používat zámky. Kdybyste v tom udělal chybu, tak to překladač narozdíl od Rustu přeloží.
No ono se to jinak implementovat nedá! V žádném jazyce.
(ach ta slepá víra ve své božstvo)
A právě z jiné diskuze se ukázalo, že na jednom místě všichni hlásili chybějící zámek, ale po promyšlení se ukázalo, že tam chybí správně (že je zbytečný). Rust by asi řval (zbytečně)
-
ve vašem příkladu mutable counteru z jiné diskuze jste musel používat zámky. Kdybyste v tom udělal chybu, tak to překladač narozdíl od Rustu přeloží.
No ono se to jinak implementovat nedá! V žádném jazyce.
(ach ta slepá víra ve své božstvo)
A právě z jiné diskuze se ukázalo, že na jednom místě všichni hlásili chybějící zámek, ale po promyšlení se ukázalo, že tam chybí správně (že je zbytečný). Rust by asi řval (zbytečně)
Já jsem nepsal, že jste tam měl chybu. Měl jsem na mysli zamykání při inkrementac/dekrementaci.
-
V C++ nejsou pole! V C++ máte std::vector<>! Že můžete v C++ udělat pole je proto, že C++ sebou taha C. Ale při code review pokud někdo někde vytváří pole, tak kód letí na přepsání, pokud to nemá nějaký závažný výkonostní důvod. To se pozná na první pohled
vector nic neřeší, všechno je unsafe:
std::vector<int> v(10);
std::cout << *(v.begin() + 11);
Jak C++ neřeší životnost objektu? C++ má RAII!!! A opět, pokud míníte pointery, tak zase už nejste v C++. C++ má přece std::shared_ptr nebo std::unique_ptr!
smart pointery nic neřeší, překladač nemá informaci o životnosti objektu, všechno je unsafe:
auto ptr = std::make_unique<Objekt>();
ptr->metoda();
ptr.reset();
ptr->metoda();
Mám ještě demonstrovat že o C++ nevíte vůbec nic?
Vy už jste dostatečně demonstroval, že nemáte vůbec ponění, co znamená bezpečný kód jak jdou věci dělat lépe než v C++.
Vím jak fungují imutabilní objekty. Mám na tomhle principu postavenou celou knihovnu.
https://github.com/ondra-novak/imtjson
No to je hezké, ale ta knihovna nic negarantuje. Když v ní budete mít chybu nebo ji blbě použiju, tak to v lepším případě segfaulne. V horším se to bude chovat naprosto nedefinovaně.
No jasně, stačí jen ověřit imutabilitu. Najít race v systémech, kde se sdílí stav, třeba taková sdílená mapa s nutností do ní zapisovat, to už taková sranda není. A není to věc jazyka.
Tak znovu. V Rustu nejde data race vyrobit. Chytí to překladač během kompilace. Není co hledat. Data race nejsou.
Jste naivní a zaslepený svou vírou.
Jste beznadějně uzavřený ve světě C++ bez dostatečného rozhledu jinam. Vaše chyba.
-
A právě z jiné diskuze se ukázalo, že na jednom místě všichni hlásili chybějící zámek, ale po promyšlení se ukázalo, že tam chybí správně (že je zbytečný). Rust by asi řval (zbytečně)
Ten zámek tam chybí. Je to public metoda, která vytváří data race. Takový prasokód by nepřešel přes code review. Sorry.
-
Pani, uplne zbytocne hadky, C treba pouzit na to, na co je urcene, a to na systemove a embedded programovanie.
-
Pani, uplne zbytocne hadky, C treba pouzit na to, na co je urcene, a to na systemove a embedded programovanie.
Na což lze stejně dobře použít i Rust s mnoha výhodami ;). V embedded teda Rust ještě moc rozšířený není, protože je příliš nový a svět embedded dost konzervativní, nicméně potenciál má velký, v embedded se bezpečnost řeší hodně.
-
Lámání chleba je co? Nějaká hardcore optimalizace něčeho? To se dělá obvykle v assembleru, nebo pokud bych fakt chtěl, tak je v Rustu unsafe, ale nikdy jsem ale neměl potřebu unsafe přímo použít. C++ je oproti tomu unsafe by default, nelze si vybrat, že teď to chci safe. C++ safe režim jaksi neumí...
Safe rezim jako co? staci pouzivat shared/unique pointry a pamet mate osefovanou. RAII a mate osefovane i jine resourcy. Dokonce vite kdy presne se co bude uvolnovat, narozdil od GC-backed jazyku, coz je hlavne extremni problem u javy a opravdu velkych projektu - stravite 10x vice casu na ladeni GC a "world stop", nez ladeni celeho c++.
Chtel bych videt, jak budete rucne v asembleru optimalizovat psat ty vektorizovane zpracovani dat. google -> compiler explorer -> vybrat -O2/-O3 u kompilatoru a uvidice, co vam dneska zvladnou kompilatory zoptimalizovat.
-
Aha, takže v C++ se nepřistupuje do pole nebo se nevolají metody objektu? To už je opravdu velká demagogie. Znovu opakuji, v C++ není safe prakticky nic, protože C++ neřeší životnost objektů.
C++ naopak zivotnost objetku resi a zivotnost objektu je take narozdil od Javy a jinych GC-backed jazyku presne definovana.
-
To je ale přesně co říkám. Na motorce se oproti autu taky snadno vysekáš, stačí štěrk v zatáčce nebo prudce puštěná spojka a už letíš. To se ti v autu (nebo pokud máš pomocná kolečka) nestane. Ne že by se nešlo v autě vybourat. Jde to, ale je třeba vyvinout trochu víc úsilí než jen zprudka pustit spojku. To ale není důvod snažit se zavrhnout motorku nebo ji znásilňovat pomocnými kolečky. Tak jako se mi už dávno nestává, že bych měl na motorce ty výše zmíněné problémy, tak ani v C se mi nestane, co se stává vám s pamětí. Už po těch letech máte vyvinutý určitý podvědomý cvik, jak s takovými objekty zacházet, člověk už ví, že dělá něco potenciálně nebezpečného a podle toho k tomu přistupuje. Ale to je otázka cviku, letité praxe. To se prostě musí zažít. Stejně jako na té motorce. Pokud vám to nejde, není to chyba motorky ani C. Prostě nemáte praxi nebo vám k tomu chybějí vlohy. Můžete furt dobře řídit to auto, ale jsou prostě chvíle, kdy ta motorka je efektivnější a když ji nezvládáte, musíte vzít za vděk méně efektivním řešením.
No já mám v C nacouváno možná víc, než co máš ty odježděno dopředu :). Jenomže narozdíl od tebe znám i Rust. Oproti C nabízí mnohem vyšší míru abstrakce a bezpečnosti při srovnatelném výkonu. Nemá smysl začínat nový projekt v C, když místo C můžeš použít Rust.
Jakmile někdo začně stylem "já nemám v C problém, jenom patlalům se stávají segfaulty", tak je mi jasné, že nemá žádnou zkušenost s větším projektem v C/C++. Chybám při práci s pamětí nejde v C zabránit, už jenom kvůli tomu, že na projektu pracuje více lidí a stačí, aby se nedomluvili nebo nepochopili. Děje se to bohužel úplně běžně v každém projektu jenom trochu složitějším než Hello World.
Chyby dělá každý. Liší se v tom, jaké chyby kdo dělá. Ale chyby, na něž tu narážíte vy, jsem v C dělal někdy tak před 25 lety, když jsem s C začínal. Dnes dělám úplně jiný typ chyb. Použiju tedy jiný příměr - je to podobné, jako byste mi vyzdvihovali nějaký textový editor, který za mě opravuje pravopisné chyby. To je nejspíš užitečná vlastnost pro ty, kdo dělají pravopisné chyby. A protože je to velmi častý jev, tak spousta lidí nejspíš usoudí, že s pravopisem má problém každý. Ale tak tomu není. S pravopisem dávno problémy nemám, spíše udělám nějakou chybu ve větné vazbě nebo v nějaké nešikovnosti typu nadměrného užití nějakého slova v krátkém rozsahu textu. Ale od toho mi žádný editor s opravou pravopisu nepomůže.
Mimochodem, PC mě nijak zvlášť nezajímá, zabývám se většinu života embedded oblastí, zejména systémařinou a low-level vývojem. Nechci žádnou vyšší míru abstrakce! Ta, co nabízí C, je pro dané věci přesně akorát. Srovnatelné by byly snad jedině PL/M či Oberon, popř. Forth. Tak nevím, proč mi cpeš Rust nebo dokonce Go. K čemu? Když náhodou potřebuji vyšší míru abstrakce na PC, sáhnu např. po Pythonu. Jazyky typu Rust řadím do kategorie ani ryba, ani rak. Pro low-level příliš náročné, pro high-level nedostatečné.
-
Safe rezim jako co? staci pouzivat shared/unique pointry a pamet mate osefovanou.
Ne to opravdu nestačí. Jeden příklad už jsem dával, tak přidám i další pro ty, kteří to stále nepochopili. Tento kód nefunguje a je úplně bez pointerů:
std::vector<int> v(1);
auto& a = v.front();
v.push_back(0);
std::cout << a;
-
C++ naopak zivotnost objetku resi a zivotnost objektu je take narozdil od Javy a jinych GC-backed jazyku presne definovana.
Překladač C++ neví nic o tom, jestli pointer ukazuje na validní objekt, nebo ne. Kdyby věděl, tak by takovou prasárnu nepřeložil:
auto ptr = std::make_unique<Objekt>();
ptr.reset();
ptr->foo();
-
Chyby dělá každý. Liší se v tom, jaké chyby kdo dělá. Ale chyby, na něž tu narážíte vy, jsem v C dělal někdy tak před 25 lety, když jsem s C začínal.
V pořádku, beru na vědomí, že jsi superman a chyby při práci s pamětí v C už vůbec neděláš. Může být. Ale na projektu nepracují jen samí supermani, pracuje na něm dalších 50 lidí. A ti bohužel chyby dělají. Proto potřebují něco, co za ně bude chyby hlídat.
Mimochodem, PC mě nijak zvlášť nezajímá, zabývám se většinu života embedded oblastí, zejména systémařinou a low-level vývojem. Nechci žádnou vyšší míru abstrakce! Ta, co nabízí C, je pro dané věci přesně akorát. Srovnatelné by byly snad jedině PL/M či Oberon, popř. Forth. Tak nevím, proč mi cpeš Rust nebo dokonce Go. K čemu? Když náhodou potřebuji vyšší míru abstrakce na PC, sáhnu např. po Pythonu. Jazyky typu Rust řadím do kategorie ani ryba, ani rak. Pro low-level příliš náročné, pro high-level nedostatečné.
Tak tady se obrovsky mýlíš, Rust je na embedded mnohem lepší než C. Malá ochutnávka: http://blog.japaric.io/quickstart/
Podívej se na ten výsledný assembler, z bezpečného high level kódu v Rustu se vygeneruje prakticky optimální kód bez žádných režií navíc.
-
Tak tady se obrovsky mýlíš, Rust je na embedded mnohem lepší než C. Malá ochutnávka: http://blog.japaric.io/quickstart/
Podívej se na ten výsledný assembler, z bezpečného high level kódu v Rustu se vygeneruje prakticky optimální kód bez žádných režií navíc.
Dík za odkaz, mrknu se na to. Na první pohled to vypadá slibně.
-
Tak tady se obrovsky mýlíš, Rust je na embedded mnohem lepší než C. Malá ochutnávka: http://blog.japaric.io/quickstart/
Podívej se na ten výsledný assembler, z bezpečného high level kódu v Rustu se vygeneruje prakticky optimální kód bez žádných režií navíc.
Ano, to je hezké ale má to podstatnou chybu. Zatím jsem na webu nenašel příklad pro embedded, který by byl napsán v rustu a něco rozumného dělal. Chybí mi především obsluha přerušení. Až to někdo vyřeší, pak dejte vědět. Do té doby je pro mne rust sice zajímavý a dobře vymyšlený nástroj, nicméně pro embedded nepoužitelný. Věřím, že se v tom dá psát efektivní, bezpečný a hezký kód, ale jen pokud pod tím běží operační systém, který vám poskytne potřebné služby.
-
Ano, to je hezké ale má to podstatnou chybu. Zatím jsem na webu nenašel příklad pro embedded, který by byl napsán v rustu a něco rozumného dělal. Chybí mi především obsluha přerušení. Až to někdo vyřeší, pak dejte vědět.
No tak se podívej třeba sem: http://blog.japaric.io/fearless-concurrency/
-
No tak se podívej třeba sem: http://blog.japaric.io/fearless-concurrency/
Dík, to jsem přehlédl. Kdysi jsem to zkoumal a narazil jsem jen na zinc.rs a ten mi připadá dost mrtvý. Zkusím to prozkoumat, ale připadá mi to dost komplikované. Je to ale pohled C-čkaře, v C/C++ si v podstatě můžete dělat co chcete, takže vaše postupy nemusí být rigorózní, přesto však fungují, pokud alespoň trochu víte co děláte.
-
Dík, to jsem přehlédl. Kdysi jsem to zkoumal a narazil jsem jen na zinc.rs a ten mi připadá dost mrtvý. Zkusím to prozkoumat, ale připadá mi to dost komplikované. Je to ale pohled C-čkaře, v C/C++ si v podstatě můžete dělat co chcete, takže vaše postupy nemusí být rigorózní, přesto však fungují, pokud alespoň trochu víte co děláte.
Ono to vypadá komplikovaně jenom na první pohled, ve skutečnosti je to docela jednoduché, v podstatě stačí psát tasky. A nabízí to opravdu zajímavé vlastnosti:
- tasky spouštěné událostí (přerušením)
- preemptivní multitasking podle priority tasků
- celé je to memory safe, unsafe se nikde nepoužívá
- žádné data races (kontrolováno během překladu)
- žádné deadlocky (kontrolováno během překladu)
- prakticky žádný runtime overhead
Je to docela nové, na produkční nasazení je ještě asi brzo, nicméně už teď to má vlasnosti, o kterých se může C nebo C++ jenom zdát.
-
smart pointery nic neřeší, překladač nemá informaci o životnosti objektu, všechno je unsafe:
auto ptr = std::make_unique<Objekt>();
ptr->metoda();
ptr.reset();
ptr->metoda();
Kdyby jsi použil const, tak tento problém ani nevznikne:
const auto ptr = std::make_unique<Objekt>();
ptr->metoda();
ptr.reset(); // error pri kompilaci: ptr je const, zatimco reset() je non-const
ptr->metoda();
Takže souhlasím s Ondřejem Novákem, kompilátor tohle pohlídá, je ale potřeba použít správné jazykové prostředky.
-
Takže souhlasím s Ondřejem Novákem, kompilátor tohle pohlídá, je ale potřeba použít správné jazykové prostředky.
Hele experte, bezpečnost nemůže být založena na tom, že někde nezapomenu napsat const. Bezpečné to musí být stále, ať tam ten const napíšu, nebo ne. Rust to splňuje, C++ ne. Nehledě na to, že s const ti přestane fungovat třeba swap, takže jsi tak jako tak v pasti.
-
Je to docela nové, na produkční nasazení je ještě asi brzo, nicméně už teď to má vlasnosti, o kterých se může C nebo C++ jenom zdát.
Velké nadšení to ve mně nebudí. Přeložit to neumím, natolik jsem do rustu ještě nepronikl. Japaric má na githubu několik příkladů, které přeložit jdou, ale třeba zápis jednoho znaku na usart bez přerušení v release verzi sežere 10KiB flash. Ono je to zřejmě tím, že nejsou ošetřeny všechny výjimky (třeba dělení 0 při výpočtu baudrate) a tohle s sebou táhne spoustu balastu, ale i na tom je zřejmé, že programování přímo na železo má svá specifika. Možná se to časem nějak uladí, ale zatím bych rust na nový projekt nenasadil. Bylo by to moc práce s velmi nejistým výsledkem. Na akademické půdě ať si s tím hrají, proč ne, ale v praxi potřebujete předvídatelný výsledek a to zatím rust nedává. Ono na něj (nebo něco podobného) dojde i v tom embedded, tak jak roste kapacita použitelných pamětí a rychlost procesorů, roste i složitost aplikací, ale zatím je ještě brzy. Dáme tomu ještě nějaký ten rok, třeba umře sám od sebe a objeví se něco lepšího. Ale dost o tom pochybuji, počítám, že C/C++ se ještě nějakou tu dobu udrží. Mně osobně vyhovuje C++, ale spousta lidí v oboru zůstává u čistého C, které je přece jen jednodušší. Hodně lidí, co dělají s jednočipy začínali jako návrháři hardware a v oblasti software jsou v podstatě samouci. Problémy, které jsme řešili doposud také nevyžadovaly nějakou velkou teorii, byly jednoduché, protože nic složitého se do čipu prostě nevešlo.
-
Je to docela nové, na produkční nasazení je ještě asi brzo, nicméně už teď to má vlasnosti, o kterých se může C nebo C++ jenom zdát.
Velké nadšení to ve mně nebudí. Přeložit to neumím, natolik jsem do rustu ještě nepronikl. Japaric má na githubu několik příkladů, které přeložit jdou, ale třeba zápis jednoho znaku na usart bez přerušení v release verzi sežere 10KiB flash. Ono je to zřejmě tím, že nejsou ošetřeny všechny výjimky (třeba dělení 0 při výpočtu baudrate) a tohle s sebou táhne spoustu balastu, ale i na tom je zřejmé, že programování přímo na železo má svá specifika. Možná se to časem nějak uladí, ale zatím bych rust na nový projekt nenasadil. Bylo by to moc práce s velmi nejistým výsledkem. Na akademické půdě ať si s tím hrají, proč ne, ale v praxi potřebujete předvídatelný výsledek a to zatím rust nedává. Ono na něj (nebo něco podobného) dojde i v tom embedded, tak jak roste kapacita použitelných pamětí a rychlost procesorů, roste i složitost aplikací, ale zatím je ještě brzy. Dáme tomu ještě nějaký ten rok, třeba umře sám od sebe a objeví se něco lepšího. Ale dost o tom pochybuji, počítám, že C/C++ se ještě nějakou tu dobu udrží. Mně osobně vyhovuje C++, ale spousta lidí v oboru zůstává u čistého C, které je přece jen jednodušší. Hodně lidí, co dělají s jednočipy začínali jako návrháři hardware a v oblasti software jsou v podstatě samouci. Problémy, které jsme řešili doposud také nevyžadovaly nějakou velkou teorii, byly jednoduché, protože nic složitého se do čipu prostě nevešlo.
Taky z toho nijak odvařený teda nejsem. Nic, co by mě motivovalo k ústupu od C.
-
Taky z toho nijak odvařený teda nejsem. Nic, co by mě motivovalo k ústupu od C.
Ještě to není dostatečně dobré pro produkční nasazení, ale dřív nebo později na Rust (nebo něco podobného) v embedded dojde, protože je hodně oblastí, kde se bezbečnost opravdu řeší (automotive, aerospace, medicine...). Co by tě mohlo motivovat už jsem psal:
- paměťová bezpečnost
- žádné data races
- vysoká míra abstrakce (generika, closures...)
- prakticky žádný runtime overhead
Pořád nic? Starého psa novým kouskům nenaučíš ;)
-
Pořád nic? Starého psa novým kouskům nenaučíš ;)
O co ti jde? Koukl na to a vyjádřil se, že ho to nepřesvědčilo. Ty pak sám uznáš, že na nasazení to teď není, pak napíšeš tohle? Jestli chceš starého psa učit novým kouskům, tak by ty nové kousky neměly být horší (momentálně "nenasaditelné") než ty, které už umí. To není o tom, kdo je a není starý pes, ale o vhodnosti volených technologií.
-
O co ti jde?
O nic, jen ztrácím čas v diskuzích na rootu.
Koukl na to a vyjádřil se, že ho to nepřesvědčilo.
Že ho to nepřesvědčilo, beru. Ale vyjádřil se, že nevidí nic, co by ho motivovalo k ústupu od C. To neberu. Motivací k ústupu od C je hodně, hlavně v oblastech, kde jde o bezpečnost (automotive, aerospace...). Tam se C(++) používá spíše z historických důvodů, protože nic lepšího nebylo. Nějakou dobu to tak ještě zůstane, ale tlaky ústup od C(++) jsou silné. Z pohledu vhodnosti technologie je C(++) na tyto účely naprosto nevhodné.
-
Lopata ma samoztejme pravdu.
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Tady je spis smutne (celkove na rootu) kolik lidi tu namyslene a sebevedome placa rozumy.
-
Taky z toho nijak odvařený teda nejsem. Nic, co by mě motivovalo k ústupu od C.
Ještě to není dostatečně dobré pro produkční nasazení, ale dřív nebo později na Rust (nebo něco podobného) v embedded dojde, protože je hodně oblastí, kde se bezbečnost opravdu řeší (automotive, aerospace, medicine...). Co by tě mohlo motivovat už jsem psal:
- paměťová bezpečnost
- žádné data races
- vysoká míra abstrakce (generika, closures...)
- prakticky žádný runtime overhead
Pořád nic? Starého psa novým kouskům nenaučíš ;)
Starý pes už se v branži pohybuje dost dlouho na to, aby pamatoval hromadu podobných "nových kousků", které skončily v zapomenutí. Ale když se v embedded nechytla Ada, tak tohle se neuchytí zcela určitě. Mimochodem, dost pochybuji, že se to nějak výrazněji prosadí na PC.
Celý ten jazyk je jak dort Pejska a Kočičky - totálně přeplácaný, komplikovaný, neortogonální, write-only. Oproti C++ nepřináší žádnou killer-feature, v podstatě na vše, co chce Rust řešit jazykovými prostředky, dnes v C++ existuje nějaká knihovna.
Rust údajně vznikl jako frustrace autorů webového prohlížeče z C++. To naprosto chápu, protože nechápu, jak dnes někomu může připadat normální, když má webový prohlížeč 18 milionů LOC.
Lidi dnes prostě místo přemýšlení plodí kód, to je celý problém. Ostatně hned v prvních 10 minutách to mnohem pregnantněji vyjádřil mnohem povolanější:
https://www.youtube.com/watch?v=ubaX1Smg6pY
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
-
Celý ten jazyk je jak dort Pejska a Kočičky - totálně přeplácaný, komplikovaný, neortogonální, write-only. Oproti C++ nepřináší žádnou killer-feature, v podstatě na vše, co chce Rust řešit jazykovými prostředky, dnes v C++ existuje nějaká knihovna.
Po pravdě, názor člověka, který zná C, ale nezná Rust, není moc relevantní. Já znám obojí, v C mám odprogramováno hodně, dělal jsem i embedded a výhody Rustu jasně vidím. Říct o Rustu, že je write only, to chce hodně velkou dávku ignorace, zvlášť v kontextu porovnání s C(++). Rust už podruhé vyhrál na stack overflow jako most loved language. To je anketa mezi vývojáři, kteří danou technologii opravdu používají prakticky: https://users.rust-lang.org/t/stackoverflow-developer-survey-result-2017/10038
Pokud nepovažuješ bezpečný kód za killer feature, potom nemá další diskuze žádný smysl
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
Vidí to přesně jak jsem napsal. Je třeba posuzovat dopady selhání a jejich pravděpodobnost a podle toho volit vhodné nástroje.
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
Vidí to přesně jak jsem napsal. Je třeba posuzovat dopady selhání a jejich pravděpodobnost a podle toho volit vhodné nástroje.
třeba jazyk podle žádané SIL, to co tu píšete vyznívá jako, že na jazyku nezáleží, stačí coding guidelines
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
Vidí to přesně jak jsem napsal. Je třeba posuzovat dopady selhání a jejich pravděpodobnost a podle toho volit vhodné nástroje.
třeba jazyk podle žádané SIL, to co tu píšete vyznívá jako, že na jazyku nezáleží, stačí coding guidelines
Na jazyku ale opravdu z hlediska těchto standardů a doporučení záleží pramálo. Těžko by taky prošel nějaký konkrétní jazyk. Klidně vám to řeknu, jak to funguje, protože už jsme dodávali více safety-critical software.
Zákazník si stanoví podmínky, obvykle "dle ISO...", "dle DO-178" apod. Tyhle standardy ale nespecifikují žádný konkrétní jazyk. My jen v protokolech pro audit musíme vypsat, jak jsme se vypořádali se všemi požadavky, jež jsou těmito standardy na nás kladeny, pokud jde o vývojový cyklus, o testování, o coding guidelines/policies. Ovšem ani tady to není úplně striktní, požaduje-li něco např. MISRA, stále můžeme zadavateli navrhnout odchýlení se, protože v daném případě nám daný požadavek připadá jako kontraproduktivní, nebo specifikovat jiné požadavky (zákaz podmíněného operátoru, povinnost inicializovat alespoň na neplatnou hodnotu hned při deklaraci, maximální/průměrná cyklomatická složitost...)
Obecně platí, že nejzásadnější je mít k dispozici certifikované produkty třetích stran, tj. překladač a knihovny. Takové najdete pro C, pro C++, Adu, Pascal, Fortran, COBOL, Javu, ale bude mít i Rust a s ním používané knihovny potřebný certifikát dle zadavatelova standardu? Protože pokud ne, tak i kdyby v daném jazyku nebylo možné se ani křivě podívat na zdroják, stejně bude z tohoto hlediska nepoužitelný. Překladač s knihovnami certifikovaný na všechny ty možné standardy najdete snad jen u Ady a - kdo by to řekl - u C/C++.
Jinými slovy - ano, i ten nejkritičtější software je možné psát - a taky se píše - v C, potažmo v C++, a to i přesto, že tu s námi už dávno jsou jazyky, které jsou považovány za blbuvzdornější než tyto dva výše jmenované.
Mimochodem - víte o nějaké statistice, která by dokládala, že software napsaný v nějakém tom "bezpečnějším" jazyce je opravdu spolehlivější a jeho vývoj a údržba stály méně peněz v porovnání s "nebezpečným" jazykem? Mám obavy, že americké ministerstvo obrany postupně ustupuje od Ady právě kvůli tomu, že žádný takový závěr se jim nepodařilo prokázat. Ostatně ani Erlang se v Ericssonu ani zdaleka nestal hlavním vývojovým nástrojem, jak se původně plánovalo - hardware tam dnes programují v C/C++ (snad jsem teď nevyzradil nějaké jejich korporátní tajemství) a Erlang tam spíše jen dožívá na starších projektech.
Praxe zkrátka ukazuje, že ty inherentní bezpečnostní prvky některých jazyků nejsou zas takovou evoluční výhodou, jak by se na první pohled mohlo zdát.
-
Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
Vidí to přesně jak jsem napsal. Je třeba posuzovat dopady selhání a jejich pravděpodobnost a podle toho volit vhodné nástroje.
třeba jazyk podle žádané SIL, to co tu píšete vyznívá jako, že na jazyku nezáleží, stačí coding guidelines
Na jazyku ale opravdu z hlediska těchto standardů a doporučení záleží pramálo. Těžko by taky prošel nějaký konkrétní jazyk. Klidně vám to řeknu, jak to funguje, protože už jsme dodávali více safety-critical software.
Zákazník si stanoví podmínky, obvykle "dle ISO...", "dle DO-178" apod. Tyhle standardy ale nespecifikují žádný konkrétní jazyk. My jen v protokolech pro audit musíme vypsat, jak jsme se vypořádali se všemi požadavky, jež jsou těmito standardy na nás kladeny, pokud jde o vývojový cyklus, o testování, o coding guidelines/policies. Ovšem ani tady to není úplně striktní, požaduje-li něco např. MISRA, stále můžeme zadavateli navrhnout odchýlení se, protože v daném případě nám daný požadavek připadá jako kontraproduktivní, nebo specifikovat jiné požadavky (zákaz podmíněného operátoru, povinnost inicializovat alespoň na neplatnou hodnotu hned při deklaraci, maximální/průměrná cyklomatická složitost...)
Obecně platí, že nejzásadnější je mít k dispozici certifikované produkty třetích stran, tj. překladač a knihovny. Takové najdete pro C, pro C++, Adu, Pascal, Fortran, COBOL, Javu, ale bude mít i Rust a s ním používané knihovny potřebný certifikát dle zadavatelova standardu? Protože pokud ne, tak i kdyby v daném jazyku nebylo možné se ani křivě podívat na zdroják, stejně bude z tohoto hlediska nepoužitelný. Překladač s knihovnami certifikovaný na všechny ty možné standardy najdete snad jen u Ady a - kdo by to řekl - u C/C++.
Jinými slovy - ano, i ten nejkritičtější software je možné psát - a taky se píše - v C, potažmo v C++, a to i přesto, že tu s námi už dávno jsou jazyky, které jsou považovány za blbuvzdornější než tyto dva výše jmenované.
Mimochodem - víte o nějaké statistice, která by dokládala, že software napsaný v nějakém tom "bezpečnějším" jazyce je opravdu spolehlivější a jeho vývoj a údržba stály méně peněz v porovnání s "nebezpečným" jazykem? Mám obavy, že americké ministerstvo obrany postupně ustupuje od Ady právě kvůli tomu, že žádný takový závěr se jim nepodařilo prokázat. Ostatně ani Erlang se v Ericssonu ani zdaleka nestal hlavním vývojovým nástrojem, jak se původně plánovalo - hardware tam dnes programují v C/C++ (snad jsem teď nevyzradil nějaké jejich korporátní tajemství) a Erlang tam spíše jen dožívá na starších projektech.
Praxe zkrátka ukazuje, že ty inherentní bezpečnostní prvky některých jazyků nejsou zas takovou evoluční výhodou, jak by se na první pohled mohlo zdát.
IMHO kdyby na jazyku nezáleželo tak by v 61508 nebyla tabulka s doporučenými jazyky pro jednotlivé SIL
s tím zbytkem celkem souhlasím
-
Ono to vypadá komplikovaně jenom na první pohled, ve skutečnosti je to docela jednoduché, v podstatě stačí psát tasky. A nabízí to opravdu zajímavé vlastnosti:
- tasky spouštěné událostí (přerušením)
- preemptivní multitasking podle priority tasků
- celé je to memory safe, unsafe se nikde nepoužívá
- žádné data races (kontrolováno během překladu)
- žádné deadlocky (kontrolováno během překladu)
- prakticky žádný runtime overhead
Je to docela nové, na produkční nasazení je ještě asi brzo, nicméně už teď to má vlasnosti, o kterých se může C nebo C++ jenom zdát.
Hele, tak se mi to podařilo zprovoznit. Opravdu je to něco, po čem moderní manažer půjde jak slepice po flusu. Jeden kolega se k tomu vyjádřil velice trefně takto (https://www.youtube.com/watch?v=JBVWkvMuh_k). Ano, obsluhu přerušení lze nazvat preemptivním multitaskingem, data races nejsou, protože žádná data mezi úlohami neputují, ale úsporné to opravdu je. Dokonce je neuvěřitelné, kolik je toho potřeba ve zdrojácích, aby to vygenerovalo cca 1KiB kódu. Ale ty nástroje jsou propracované, celé to budí dojem velmi promyšleného postupu, buzzwordy jsou už vymyšleny, to se asi ujme. I když takový forth kdysi sliboval taky úžasné nové možnosti, dokonce se kvůli tomu začaly vyrábět i speciální zásobníkové procesory (které dodnes létají v kosmu) a kdo to dneska používá, že.
Oni si to lidi přeberou podle své mentality, já stejně jako kolega Kiwi zatím zůstávám u C/C++. Dává mi větší volnost. Teď půjdu do lesa na procházku a helmu si nevezmu i když jsem si vědom, že padají žaludy. Prostě to risknu s tím, že dubinám je lépe se vyhnout. I když může spadnout i smrková šiška.
-
buzzwordy jsou už vymyšleny, to se asi ujme.
;D ;D ;D
I když takový forth kdysi sliboval taky úžasné nové možnosti, dokonce se kvůli tomu začaly vyrábět i speciální zásobníkové procesory (které dodnes létají v kosmu) a kdo to dneska používá, že.
Například my, prosím. :) Ale spíš jen jako takový shell a pískoviště na cílových zařízení. Na Forthu je úžasná jeho minimalističnost a nenáročnost, než že by nabízel nějaké úžasné nové možnosti (na ARMech s Thumb sadou ani ne 4 KB flash a něco přes 0,5 KB RAM). Filosofie s ním spojená, pokud jde o bezpečnost, je založena na tom, že celková pravděpodobnost selhání je úměrná počtu součástí násobeného pravděpodobností, že zrovna tato součást selže, takže zmenšením počtu součástí vzroste celková spolehlivost. A je pravda, že když člověk něco programuje ve Forthu, tak sice musí trochu víc přemýšlet, ale jednoduchostí a elegancí toho, co nakonec stvoří, bývá překvapen i on sám. Navíc ty procesory specializované pro něj jsou taky jednoduché jak kafemlejnek.
-
Na Forthu je úžasná jeho minimalističnost a nenáročnost, než že by nabízel nějaké úžasné nové možnosti (na ARMech s Thumb sadou ani ne 4 KB flash a něco přes 0,5 KB RAM). Filosofie s ním spojená, pokud jde o bezpečnost, je založena na tom, že celková pravděpodobnost selhání je úměrná počtu součástí násobeného pravděpodobností, že zrovna tato součást selže, takže zmenšením počtu součástí vzroste celková spolehlivost. A je pravda, že když člověk něco programuje ve Forthu, tak sice musí trochu víc přemýšlet, ale jednoduchostí a elegancí toho, co nakonec stvoří, bývá překvapen i on sám. Navíc ty procesory specializované pro něj jsou taky jednoduché jak kafemlejnek.
Ve Forthu si také občas něco zkouším a z hlediska návrhu mi připadá velmi sympatický. Procesory specializované na Forth bývají konstrukčně ještě jednodušší, než standardní procesory, protože si vystačí s chudší instrukční sadou.
-
Například my, prosím. :)
Proč ne, když to pro daný účel vyhovuje. Určitě bude pro nějaký účel vyhovovat dobře i ten rust. Já jsem tím chtěl jen říct, že se jednou za čas objeví nějaký "univerzální všelék", který podle autorů vyřeší všechny problémy. Obvykle však tomu tak není. Nějaké problémy to vyřeší, jiné zase přinese. Nevíme co přinese budoucnost. Možná přijde éra kvantových výpočtů a tyhle problémy nám za pár let přijdou směšné.
A abych jen nekritizoval - ten rust vymýšleli zjevně chytří lidé, lze se z něj dost poučit. Například mě to utvrdilo v tom, že psát v C(++) ten otravný modifikátor const všude, kde je to jen trochu možné vůbec není od věci. A v Cortex-M3,4 jsem našel mechanizmus ldrex/strex pro vytváření zámků, který mi připadá hezčí než obvyklé cpsid/cpsie převzaté z osmibitů.
-
A v Cortex-M3,4 jsem našel mechanizmus ldrex/strex pro vytváření zámků, který mi připadá hezčí než obvyklé cpsid/cpsie převzaté z osmibitů.
... a clrex ;) Vždyť přesně kvůli tomu tam ty instrukce také jsou. :) Ale není to žádný armí vynález, podobné instrukce měla myslím už IBM 360 ze 60. let.
-
... a clrex ;) Vždyť přesně kvůli tomu tam ty instrukce také jsou. :) Ale není to žádný armí vynález, podobné instrukce měla myslím už IBM 360 ze 60. let.
No jo, ale musíte o nich vědět. A když přecházíte na ARM z osmibitu, tak použijete to, co znáte a obvykle nepátráte po všech tajích architektury. Ale přiznávám, jsou i tací. Co si budeme povídat, většina lidí tady kolem používá STM32 protože jsou na to klikací nástroje, "knihovny" a mohutná marketingová kampaň. Co se děje uvnitř, lidi až tak moc nezajímá. Alespoň do doby než to přestane fungovat. Nebo, když už je někdo hodně velký šťoura, když mu přijde divné, že to naklikané blikátko sežere půlku flešky, když se to dá dostat do nějakých 50. bytů.
-
Proč ne, když to pro daný účel vyhovuje. Určitě bude pro nějaký účel vyhovovat dobře i ten rust. Já jsem tím chtěl jen říct, že se jednou za čas objeví nějaký "univerzální všelék", který podle autorů vyřeší všechny problémy. Obvykle však tomu tak není. Nějaké problémy to vyřeší, jiné zase přinese. Nevíme co přinese budoucnost. Možná přijde éra kvantových výpočtů a tyhle problémy nám za pár let přijdou směšné.
Tohle je teda ulet. Sam sis zvyraznil, co sis taky sam vymyslel a nekomu jinemu sam podsunul. Gratulki.