abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 06:00 | Pozvánky

Srpnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 22. 8. 2019 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tématem bude jako obvykle svobodný software a hardware. A pokud vás zajímá bezpečnost bezdrátových klávesnic a myší (útok MouseJack a spol.) a nějaké takové zařízení máte, vezměte ho sebou – trochu ho potrápíme o ověříme jeho bezpečnost.

xkucf03 | Komentářů: 0
včera 16:33 | Nová verze

David Heinemeier Hansson oznámil vydání nové major verze 6.0 frameworku pro vývoj webových aplikací Ruby on Rails (Wikipedie). Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Přispělo 801 vývojářů.

Ladislav Hagara | Komentářů: 2
17.8. 18:11 | Nová verze

Byla vydána verze 2.23.0 distribuovaného systému správy verzí Git. Přispělo 77 vývojářů, z toho 26 nových. Přehled novinek v poznámkách k vydání nebo v příspěvku na blogu GitHubu.

Ladislav Hagara | Komentářů: 7
17.8. 13:33 | Komunita

Nadace Raspberry Pi na svém blogu informuje o vydání Scratch 3 Desktopu pro Raspbian na Raspberry Pi. Verze 3 výukového vizuálního programovacího jazyka Scratch byla vydána v lednu letošního roku. Offline Scratch Desktop byl ale dosud dostupný pouze pro Windows a macOS.

Ladislav Hagara | Komentářů: 0
15.8. 19:44 | Bezpečnostní upozornění

Byly zveřejněny informace o 8 bezpečnostních chybách v implementacích protokolu HTTP/2. Chyby CVE-2019-9511 až CVE-2019-9518 lze zneužít k odepření služeb (DoS). Přehled softwarových produktů a v nich obsažených chyb v tabulce na stránce CERT/CC.

Ladislav Hagara | Komentářů: 16
15.8. 17:55 | Nová verze

Byla vydána verze 1.37.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 100
15.8. 15:11 | Nová verze

Byla vydána nová verze 19.08.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Videoukázka nových vlastností na YouTube nebo na PeerTube.

Ladislav Hagara | Komentářů: 5
15.8. 14:44 | Zajímavý projekt

CutiePi je open source tablet postavený na Raspberry Pi, konkrétně na Compute Module. K dispozici by měl být koncem roku. Cena zatím nebyla stanovena. Vývojový tým zjišťuje zájem [Hacker News].

Ladislav Hagara | Komentářů: 8
14.8. 21:33 | Zajímavý článek

Greg Kroah-Hartman v příspěvku na svém blogu popisuje svou práci na linuxovém jádře. Popis prokládá videoukázkami ve formátu asciinema. Dnes používá především poštovního klienta Mutt. V plánu má přejít na poštovního klienta aerc, pokud do něj budou přidány v popisu zmíněné vlastnosti.

Ladislav Hagara | Komentářů: 0
14.8. 21:11 | Nová verze

Bylo oznámeno, že EPEL (Extra Packages for Enterprise Linux) ve verzi 8.0 je připraven k vydání. Vedle x86_64, ppc64le a aarch64 je nově podporována také platforma s390x.

Ladislav Hagara | Komentářů: 0
Používáte ještě 32bitový software na PC?
 (20%)
 (15%)
 (17%)
 (43%)
 (6%)
 (29%)
Celkem 428 hlasů
 Komentářů: 36, poslední včera 21:46
Rozcestník

Rust 1.37.0

Byla vydána verze 1.37.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

15.8. 17:55 | Ladislav Hagara | Nová verze


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

15.8. 20:00 Pavel
Rozbalit Rozbalit vše Re: Rust 1.37.0
Muze mi nekdo vysvetlit, proc Rust jeste nevytlacil C?
15.8. 21:48 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
To je velice jednoduché:

1) Protože Rust není tak dobrý, a nemá dostatečně dobré vlastnosti, aby dokázal nahradit C/C++.

2) Protože Rust není seriózní programovací jazyk na rozdíl od C/C++ (nemá nezávislý standard, nectí zpětnou kompatibilitu, ...).

3) Rust nemá definováno přesné chování v řadě situací - bez čehož se Rust může jít klouzat.

4) Protože C je mnohem přenositelnější a univerzálnější jazyk než Rust.

5) Protože C má konzistentní a stabilní ABI, což umožňuje velice mnoho věcí.

6) Protože Rust přišel o pár desetiletí později než C/C++.

15.8. 21:59 _
Rozbalit Rozbalit vše Re: Rust 1.37.0
1-5 jsou zjevné lži
15.8. 22:13 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Komentář nade mnou je zjevná totální lež.
15.8. 23:52 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
nectí zpětnou kompatibilitu
Ale ctí, resp. nějaké nekompatibilní změny byly, ale typicky pouze v corner-casech nebo případně v kódu, který nebyl korektní...

Jinak bod 1. je otázka názoru, 3. a 5. nechápu - C standard žádné ABI nespecifikuje.

Jako relevantní mi přijdou body 4. a 6., upřesnil bych to ještě tím, že Rust má pouze (realisticky) jednu implementaci, která je postavená nad LLVM, což je problém.
16.8. 02:22 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ad 1) říká: Když máte namísto C používat méně univerzální Rust, tak stejně budete muset na některé úlohy (které nezvládne Rust) použít to C. Ergo kladívko Rust nemůže nahradit a vykopnout C, ani kdyby se Rust rozkrájel.

Ad 2) "Nějaké nekompatibilní změny byly" - to je vše. Já mohu vzít 30 let staré zdrojové kódy v C, přeložit je na jakékoli platformě, a dělají přesně to samé co před 30 lety. Samozřejmě pokud si vystačím se standardem.

Ad 5) Standard C/C++ ABI nedefinuje. Ale protože je C/C++ základní a univerzální jazyk, tak obvykle každá platforma definuje nějaké ABI pro C. A na ní se můžete mnoha jazyky napojit.
16.8. 12:25 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ad 1) říká: Když máte namísto C používat méně univerzální Rust, tak stejně budete muset na některé úlohy (které nezvládne Rust) použít to C. Ergo kladívko Rust nemůže nahradit a vykopnout C, ani kdyby se Rust rozkrájel.
Rust je méně univerzální v tom, že podporuje méně platforem než C. Pokud ale danou platformu podporuje, moc nevidim, v čem je méně univerzální.

Jinak celkem souhlasim, že Rust pravděpodobně nikdy úplně nenahradí C/C++, a vlastně ani nevim, proč by měl. Za mě úplně postačí, když bude existovat jako použitelná alternativa k C/C++ a bude mít nějaké slušné procento. Což si myslim, že je docela realistické...

Nahradit veškerý C/C++ kód Rustem chtějí jen přiblblí fanatici nebo trollové, kteří typicky s nim ani nemají moc zkušeností...
"Nějaké nekompatibilní změny byly" - to je vše. Já mohu vzít 30 let staré zdrojové kódy v C, přeložit je na jakékoli platformě, a dělají přesně to samé co před 30 lety. Samozřejmě pokud si vystačím se standardem.
Malá část reálně existujícího kódu si vystačí jen se standardem a/nebo je skutečně dobře napsaná podle standardu.
Ad 5) Standard C/C++ ABI nedefinuje. Ale protože je C/C++ základní a univerzální jazyk, tak obvykle každá platforma definuje nějaké ABI pro C. A na ní se můžete mnoha jazyky napojit.
Tady nevidim žádnou pointu. V Rustu můžeš udělat to samé, co v C++ - exponovat C-kompatibilní API/ABI.

xkucf03 avatar 16.8. 12:56 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0
Jinak celkem souhlasim, že Rust pravděpodobně nikdy úplně nenahradí C/C++, a vlastně ani nevim, proč by měl. Za mě úplně postačí, když bude existovat jako použitelná alternativa k C/C++ a bude mít nějaké slušné procento.

Nevím, jestli je dobré mluvit o C a C++ jako o jednom jazyku (tzn. psát C/C++). Pokud se na C++ budeme dívat jako na vysokoúrovňový jazyk určený k psaní složitějších aplikací, tak by ho Rust (nebo třeba D) nahradit mohl, ne?

Problém je akorát v tom, že při psaní C++ aplikace můžeš kdykoli plynule přejít do C a používat přímo céčkové knihovny. Což je vlastnost, kterou prakticky žádný jiný jazyk nemá (snad leda D).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 13:16 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Perl jde míchat s C.
xkucf03 avatar 16.8. 13:31 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Jak se to liší od nativních funkcí (případně JNA) v Javě?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 23:22 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Je to možné oběma směry, tzn části Perlu jde naopak includovat do kódu v C a mělo by to být oficiálně podporováno.
xkucf03 avatar 16.8. 23:32 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Ano a z C nebo C++ můžu volat kód psaný v Javě. Nicméně v obou těch směrech je to diametrálně odlišné od toho, jak se integruje C a C++, protože tam je to naprosto bezešvé, je to jeden jazyk (C jako podmnožina C++). Částečně se tomu blíží D, ale jinak nevím o jiném jazyku, který by se tak dobře integroval s C nebo dokonce C++.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 23:41 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
> Ano a z C nebo C++ můžu volat kód psaný v Javě.

Ne.

V C udělám #include <perl.h> a používám Perl. Bez syntaxe Perlu, ale Perl.

> je to jeden jazyk (C jako podmnožina C++).

C není podmnožina C++.
16.8. 14:09 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Nevím, jestli je dobré mluvit o C a C++ jako o jednom jazyku (tzn. psát C/C++). Pokud se na C++ budeme dívat jako na vysokoúrovňový jazyk určený k psaní složitějších aplikací, tak by ho Rust (nebo třeba D) nahradit mohl, ne?
Jj, když píšu C/C++, myslim tím spíš C, C++; jsou to dva dost různé jazyky. Rust, D, atd. by C++ teoreticky nahradit mohly, v praxi v C++ je napsáno obrovské množství kódu, takže to by trvalo dlouho, jestli se to vůbec někdy stane (IMO spíš ne).

Taky se může stát, že C++ nebo D přidaj borrow-checker a pak by to mohlo vypadat jinak. Walter Bright už trochu vyměkl a možná něco takového přidá. (Osobně ale moc nevěřim v úspěch D kvůli fragmentaci. Potřebovali by to spíš nějak defragmentovat :-D)
Problém je akorát v tom, že při psaní C++ aplikace můžeš kdykoli plynule přejít do C a používat přímo céčkové knihovny. Což je vlastnost, kterou prakticky žádný jiný jazyk nemá (snad leda D).
V kontextu Rustu by tohle nebyla moc výhra, což je asi taky důvod, proč pro to není moc přímá podpora. Udělat binding pro C ve smyslu Rustového ekvivalentu header file je snadné a skoro úplně automatizovatelné, nicméně to gro těch bindingů je ve vytvoření idiomatického a hlanvě bezpečnost-zachovávajícího API, což je něco, co se obecně moc automatizovat nedá. (Ale na druhou stranu lidi to motivuje k tvorbě takových bindingů a existuje jich překvapivě relativně dost.)
16.8. 16:23 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Nevím, jestli je dobré mluvit o C a C++ jako o jednom jazyku (tzn. psát C/C++).
Ale on to v zásadě jeden jazyk je. Dobře napsaný C kód je zároveň přeložitelným C++ kódem. Klidně se dá C++ považovat za vyšší verzi C.

---
Pokud se na C++ budeme dívat jako na vysokoúrovňový jazyk určený k psaní složitějších aplikací, tak by ho Rust (nebo třeba D) nahradit mohl, ne?
Nemohl. Protože D i Rustu chybí v první řadě serióznost.

a) C++ má vlastní standard, množství nezávislých kompilátorů.

b) C++ má tu vlastnost, že C++ je stejně univerzální jako C, tj. napíšete v něm třeba operační systém, ovladače hw, můžete v něm psát kódy pro mikrokontrolery, atd. atd. atd.

Aby mohl nějaký jazyk převálcovat C/C++, musí umět to samé plus ještě mnohem více, být stejně univerzální, mít seriózní standard. A hlavně: Musí mít nějakou killer feature, která způsobí, že se vyplatí opustil C/C++ a přejít na ten nový super jazyk, který je převálcuje.

---
Jj, když píšu C/C++, myslim tím spíš C, C++; jsou to dva dost různé jazyky. Rust, D, atd. by C++ teoreticky nahradit mohly, v praxi v C++ je napsáno obrovské množství kódu, takže to by trvalo dlouho, jestli se to vůbec někdy stane (IMO spíš ne).
Ale C/C++ je v zásadě stejný jazyk. Mají stejnou syntaxi, stejnou knihovnu, ... Jen C++ toho má trochu více.

C++ je jediný jazyk, který má našlápnuto na to smést C z povrchu zemského. Žádný jiný dnešní programovací jazyk C nenahradí.

---
Taky se může stát, že C++ nebo D přidaj borrow-checker a pak by to mohlo vypadat jinak. ... Osobně ale moc nevěřim v úspěch D kvůli fragmentaci. Potřebovali by to spíš nějak defragmentovat.
D má mnohem více problémů než jen defragmentaci. Je zvláštní, že tvůrci jazyků podceňují právě ty drobnosti, co rozhodují nejvíce o úspěchu jazyka: serióznost, dobře psaný standard, žádné licenční problémy, kompatibilita s kódem jiných jazyků, atd.

Právě proto neuspěje ani D ani Rust.

---
Problém je akorát v tom, že při psaní C++ aplikace můžeš kdykoli plynule přejít do C a používat přímo céčkové knihovny. Což je vlastnost, kterou prakticky žádný jiný jazyk nemá (snad leda D).
Což je velice silná vlastnost C++, a jiný jazyk by ji musel přebít něčím sakra silným.
16.8. 17:20 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Nemohl. Protože D i Rustu chybí v první řadě serióznost.
Myslimže v Rustu už je na serióznost napsán pull request, prochází to review. Měli by to mergnout do další verze. Jestli si dobře pamatuju roadmapu, od verze 1.41 by měl být dodáván s kompilátorem i monokl a cylindr.
tj. napíšete v něm třeba operační systém, ovladače hw, můžete v něm psát kódy pro mikrokontrolery, atd. atd. atd.
Ditto Rust.

Ad. mikrokontrolery viz třeba tady, AFAIK můžeš taky už dnes napsat modul do Linuxu... Problém je když už tak nedostatek kompilátorů/toolchainů (příp. knihoven, abstrakcí) - což si všimni, že je nevýhoda, ve které jsem s tebou zcela souhlasil - nikoli na úrovni jazyka.
Aby mohl nějaký jazyk převálcovat C/C++ ... C++ je jediný jazyk, který má našlápnuto na to smést C z povrchu zemského. Žádný jiný dnešní programovací jazyk C nenahradí.
Jak už jsem napsal, mně je nějaké převálcování C nebo C++ dost u zadku. Nevidim, proč by měl Rust něco převálcovat, stejně jako nevidim důvod, proč by C++ mělo převálcovat C (což se stejně nestane).
Což je velice silná vlastnost C++, a jiný jazyk by ji musel přebít něčím sakra silným.
Naposledy, když jsem se rozhodl používat C knihovnu z C++, jsem si na to stejně napsal v C++ wrapper. Takže v podstatě stejný scénář, jaký by nastal v Rustu...

Rust se v tomhle liší v podstatě jenom tím, že používání holého C API je o trochu větší opruz než v C++ (musíš používat unsafe atd.) a málo se to dělá, protože lidi nechtějí pokudmožno mít kód zamořený unsafe bloky/funkcemi (což je IMO dobře).
xkucf03 avatar 16.8. 17:28 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Nemohl. Protože D i Rustu chybí v první řadě serióznost.

a) C++ má vlastní standard, množství nezávislých kompilátorů.

S tímhle souhlasím. Oddělit specifikaci a implementaci je dobré a je to znakem vyspělosti, stability a serióznosti.

C++ má tu vlastnost, že C++ je stejně univerzální jako C, tj. napíšete v něm třeba operační systém, ovladače hw, můžete v něm psát kódy pro mikrokontrolery, atd. atd. atd.

Tohle může nabídnout jakýkoli jazyk z něhož po kompilaci vypadne strojový kód / assembler. Ty jazyky jsou vlastně jen prostředkem pro převod lidsky čitelného zápisu na kód, kterému rozumí počítač. A klidně to může být tak univerzální, že to půjde přeložit pro různé architektury včetně nějakých jednočipů.

Takže tady jde spíš o ten ekosystém kolem a o to, že nikdo nepřepíše všechny ty knihovny do nového jazyka, než o to, že by to v principu nešlo.

C++ je jediný jazyk, který má našlápnuto na to smést C z povrchu zemského. Žádný jiný dnešní programovací jazyk C nenahradí.

Vzhledem k tomu, že C++ je nadmnožina1 C, tak C++ nahradit C nemůže, protože C++ vždy v sobě to C bude obsahovat.

Což je velice silná vlastnost C++, a jiný jazyk by ji musel přebít něčím sakra silným.

Silná vlastnost to je, ale zároveň je to i slabina, protože C++ programy můžou obsahovat hodně nízkoúrovňového bordelu a nebezpečného kódu. A to jsou fakt věci, na které bych v aplikačním kódu nerad narážel. Tohle je vlastně klasický spor o to, zda je lepší mít víc možností i za cenu toho, že je programátor zneužije nebo bude dělat chyby. Řešilo se to tu celkem nedávno v souvislosti s vlákny. Někdo by programátorům tuhle možnost sebral, aby nedělali chyby, někdo by ji tam nechal… myslím, že tohle nemá jednoduché řešení.

[1] víceméně, ať mě tu zase někdo nechytá za slovo

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 17:47 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Tohle může nabídnout jakýkoli jazyk z něhož po kompilaci vypadne strojový kód / assembler.
Hnidopišská poznámka: To tak úplně neplatí. Třeba Go kompiluje do strojového kódu (žádný bytecode), ale ten kód má přibalený a je závislý na poměrně komplexním runtime obsahujícím GC, custom stack alokace atd. V tom asi driver psát nechceš ;-)
xkucf03 avatar 16.8. 17:58 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Nechci. Ale u céčka se tam taky přibalí nějaký kód/instrukce, které jsi nenapsal, ne? Takže to není nějaké černobílé buď a nebo, ale spíš plynulá škála toho, jak moc kódu navíc tam kompilátor různých jazyků přidává.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 18:22 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Je to černobílé. U C/C++ je velice snadné psát kód, který nepřibalí nic navíc, žádnou knihovnu. Který bude obsahovat čistě jen váš kód.
16.8. 18:35 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
Rust splňuje.
xkucf03 avatar 16.8. 21:51 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

z výpisu ldd:

        linux-vdso.so.1 (0x00007fffbbb83000)
        libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 (0x00007f86d5640000)
        libhidapi-hidraw.so.0 => /usr/lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007f86d5438000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f86d50a8000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f86d4e90000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f86d4a98000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f86d4890000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f86d4688000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f86d4468000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f86d40c8000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f86d3ea8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f86d6820000)

nic z toho jsem nenapsal a ni explicitně neuvedl jako závislost (jedinou – explicitní a chtěnou – závislost tam mám to USB HID API + ASAN). Ne, že by mě to nějak trápilo, ale nepřijde mi správné říkat, že program v C++ neobsahuje nic navíc, než co napsal jeho autor.

Stejně tak z GraalVM vypadne nativní binárka, která má přibaleno jen trochu kódu navíc.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 23:26 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Já jsem se ale vyjádřil naprosto přesně: Je snadné psát v C/C++ programy, které neobsahují nic kromě napsaného kódu.

17.8. 00:07 Poky74
Rozbalit Rozbalit vše Re: Rust 1.37.0
nepřijde mi správné říkat, že program v C++ neobsahuje nic navíc, než co napsal jeho autor.
A někomu něco podsouvat ti správné přijde?
17.8. 03:01 qwe
Rozbalit Rozbalit vše Re: Rust 1.37.0
myslím, že nechápeš, co je freestanding C++.
jsou kernely napsané v C++, myslíš že linkují k libstdc++? lol
xkucf03 avatar 17.8. 08:21 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Pak je ale část toho kódu, který je zde ve sdílených knihovnách, zakompilovaná do tvého programu, ne?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Josef Kufner avatar 17.8. 10:46 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ne. Pokud nepoužiješ žádné knihovny, tak se program napsaný v C či C++ zkompiluje jen na hromádku instrukcí (a dat), které odpovídají tebou napsanému kódu. Opravdu tam pak není nic navíc, pokud nepočítáme optimalizace provedené překladačem a metadata spustitelné binárky.
Hello world ! Segmentation fault (core dumped)
17.8. 13:38 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Pak je ale část toho kódu, který je zde ve sdílených knihovnách, zakompilovaná do tvého programu, ne?
Záleží. Když nalinkuješ staticky standardní knihovnu, tak ano. Ale můžeš taky napsat program zcela bez jakýchkoli knihoven, včetně standardní.

Takhle kompiluje programy třeba Go - vůbec nepoužívají libc a binárky, který z toho padaj, jsou zcela nedynamický. Řešej si sami syscally na každý platformě. Přijde mi to jako trochu prasárna, ale whatever.

Ad. téma vlákna: V C je tohle velmi snadné, vzhledem např. k tomu, že alokace se dělá voláním funkce, nejsou výjimky (ignorujme stejmp) atd. V C++ to už je o trochu méně snadné a je to IMO zhruba stejné jako v Rustu: Je potřeba řešit nějak výjimky (resp. paniky v případě Rustu) a např. alokaci, tzn. v C++ buď přetížit de/alkoační operátory nebo je nepoužívat vůbec, podobně v Rustu (buď nahradit globální alokátor, nebo ho nepoužívat). V obou případech může (ale nemusí) být obvyklý komfort jazyka snížen, záleží, jak moc se ho bude člověk snažit zachovat.
včera 21:33 qwe
Rozbalit Rozbalit vše Re: Rust 1.37.0
ne
16.8. 18:14 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Tohle může nabídnout jakýkoli jazyk z něhož po kompilaci vypadne strojový kód / assembler. Ty jazyky jsou vlastně jen prostředkem pro převod lidsky čitelného zápisu na kód, kterému rozumí počítač. A klidně to může být tak univerzální, že to půjde přeložit pro různé architektury včetně nějakých jednočipů.
Bohužel nemůže. Jazyk si sebou nese i runtime knihovnu a další věci, které nutně potřebuje pro běh kódu. U naprosté většiny jazyků je právě toto neslučitelné s většinou low level použití typu operační systém nebo mikrokontroller.

---
Silná vlastnost to je, ale zároveň je to i slabina, protože C++ programy můžou obsahovat hodně nízkoúrovňového bordelu a nebezpečného kódu. A to jsou fakt věci, na které bych v aplikačním kódu nerad narážel.
Pak ale nemá smysl mluvit o tom, že by Rust nahradil C. Protože C a jeho aplikace míří právě na ten nízkoúrovňový bordel. C/C++ vám dává výhodu naprosté kontroly toho co děláte, a jako vedlejší efekt to samozřejmě můžete také potentovat. Žádný jazyk, který neumožní totéž nemůže být konkurentem C/C++.
16.8. 18:49 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Bohužel nemůže. Jazyk si sebou nese i runtime knihovnu a další věci, které nutně potřebuje pro běh kódu.
V Rustu je to zhruba podobné jako v C/C++, by default se linkuje standardní knihovna, runtime atd., ale můžeš psát kód i bez toho, použít vlastní alokátor atd.
Pak ale nemá smysl mluvit o tom, že by Rust nahradil C. Protože C a jeho aplikace míří právě na ten nízkoúrovňový bordel.
Rust pro to má explicitní podporu, říká tomu unsafe kód. Proč jsi nenapsal rovnou na úvod, že o Rustu vlastně nic moc nevíš?
16.8. 19:29 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ad 1) V Rustu není vždy jasné, co zavolá a v kódu vede na vnitřní volání funkce.

Ad 2) Takže budeme používat Rust s miliardou unsafe bloků?
16.8. 19:40 Spike | skóre: 30 | blog: Communicator | Praha
Rozbalit Rozbalit vše Re: Rust 1.37.0

Ad ad 2) Na unsafe není nic inherentně špatného a ne™.

Přijde mi, že se projevujete trochu jako fachidiot, který se před 30 lety zvládl naučit jeden programovací jazyk, potažmo dostal do ruky kladivo, takže teď celý svět vypadá jako hřebík.

16.8. 19:59 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Na žádné věci na světě není nic špatného. Jen to nemusí být efektivní.

K vašemu pokusu o útok ad hominem bych dodal, že téma zní - čehož jste si patrně neráčil zatím všimnout: Proč Rust nenahradil C? Je to pro vás možná překvapivé, ale když téma zní Rust a C, tak se mluví o programovacích jazycích C a Rust.

Problém těch odkazů je, že nejsou objektivní.

Například: "Může Rust pracovat na mikrokontrolerech?" A odpověď: "Není teoretický důvod proč ne." To je argumentace jak noha.

Samozřejmě, že Rust (a řada dalších jazyků) lze ohnout na ledacos. Stačí když k tomu vynecháte část jazyka a jeho možností, a když jste do toho nadšenec. Pokud půjdete pragmaticky, tak Rust pro embedded prostě používat nebudete, protože jsou mnohem lepší nástroje a mnohem lepší jazyky.

---

STM32 procesory a jejich vývojové kity jsou mimochodem geniální. Mají v sobě moc moc moc ROM paměti, takže unesou i neefektivní jazyk s neefektivními knohovnami a HAL vrstvou. Na to jsem už také přišel, a pokusničím s nimi mnoho let. To je skoro jako když to běží na PC, jen to má málo RAM.

A to je celý princip. Máte jazyk, který potřebuje relativně obludný a silný hw, aby běžel. Představte si, že jsou mnohem slabší a méně vybavené mikrokontrolery, a prodá se jich obludné množství každý rok po celém světě. A ty jsou úhelným kamenem.

xkucf03 avatar 16.8. 21:56 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0
Žádný jazyk, který neumožní totéž nemůže být konkurentem C/C++.

Univerzálnost C++ mě na jednu stranu fascinuje, ale na druhou stranu nevím, jestli je takhle široké rozpětí ideální. Na jednu stranu je skvělé, že stačí umět jeden jazyk a můžu v něm psát všechno od firmwaru do jednočipů, ovladačů a operačního systému až po účetní programy nebo hry, ale na druhou stranu to klade poměrně vysoké nároky na programátory a štábní kulturu. Což je asi důvod, proč jsou dost oblíbené i méně univerzální jazyky.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 22:52 Miloslav Ponkrác
Rozbalit Rozbalit vše Univerzálnost C/C++
Já si spíše myslím, že C/C++ jsou dost nešťastně navržené jazyky. Nicméně jsou univerzální. Neměl by být až tak velký problém je překonat, ale k mému údivu každý moderní jazyk namísto toho aby byl dobrým programovacím jazykem se shlédne v nějaké ideologii - a tu zanese. Moderní programovací jazyky jsou pak jako sekty, nikoli reálně dobré jazyky.

Univerzálnost není problém.
16.8. 18:19 Miloslav Ponkrác
Rozbalit Rozbalit vše Bezpečnost x Štábní kultura
Tohle je vlastně klasický spor o to, zda je lepší mít víc možností i za cenu toho, že je programátor zneužije nebo bude dělat chyby.
To s prominutím pletete dohromady dvě věci:

1) Bezpečnost výsledného kódu.

2) Dodržování štábní kultury.

Udělat programovací jazyk stejně rychlý, schopný a efektivní jako C/C++ s tím, že navíc by byl mnohem bezpečnější - není problém. Takové jazyky existovaly a existují. Jen jsou ukecanější než C/C++, protože kompilátor potřebuje více informací, aby mohl více věcí kontrolovat. Mainstreamoví programátoři je nepoužívají, protože dávají přednost jazykům, kde lze něco napsat výrazem o 2 znaky kratším.

Na druhé straně z ekonomických důvodů firmy chtějí ušetřit na programátorech, a tak zaměstnávají většinou různé nekňuby a nemehla - a ty nemají IQ ani zkušenosti na dodržování štábní kultury. Proto potřebují co nejblbější jazyk s co nejméně možnostmi, aby nemohli dělat co nemají. Takovým typickým jazykem pro neschopné je Java, která se snažila být ideálem pro tyto lidi.
16.8. 19:41 Spike | skóre: 30 | blog: Communicator | Praha
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Mainstreamoví programátoři je nepoužívají, protože dávají přednost jazykům, kde lze něco napsat výrazem o 2 znaky kratším.
Dojmologie.
Na druhé straně z ekonomických důvodů firmy chtějí ušetřit na programátorech, a tak zaměstnávají většinou různé nekňuby a nemehla - a ty nemají IQ ani zkušenosti na dodržování štábní kultury. Proto potřebují co nejblbější jazyk s co nejméně možnostmi, aby nemohli dělat co nemají. Takovým typickým jazykem pro neschopné je Java, která se snažila být ideálem pro tyto lidi.
Dojmologie.
16.8. 20:02 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Až napíšete nějaký věcný argument (najdete ve slovníku cizích slov), bude možné na vás nějak reagovat.
xkucf03 avatar 16.8. 22:13 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Udělat programovací jazyk stejně rychlý, schopný a efektivní jako C/C++ s tím, že navíc by byl mnohem bezpečnější - není problém. Takové jazyky existovaly a existují. Jen jsou ukecanější než C/C++, protože kompilátor potřebuje více informací, aby mohl více věcí kontrolovat. Mainstreamoví programátoři je nepoužívají, protože dávají přednost jazykům, kde lze něco napsat výrazem o 2 znaky kratším.

Nemyslím si, že by lepší jazyk musel být nutně ukecanější. C++ má místy hnusnou/složitou syntaxi a ještě hnusnější standardní knihovnu. Kvůli zpětné kompatibilitě to nejde, ale kdyby to šlo: tak zahozením standardní knihovny a jejím čistým a promyšleným přepsáním by se z toho stal mnohem lepší jazyk.

Na druhé straně z ekonomických důvodů firmy chtějí ušetřit na programátorech, a tak zaměstnávají většinou různé nekňuby a nemehla - a ty nemají IQ ani zkušenosti na dodržování štábní kultury.

Nějak jsem si nevšiml, že by schopní programátoři nemohli sehnat práci, protože jsou drazí. Ti schopní jsou rozebraní a dobře placení. A co pak má dělat firma, která potřebuje programátory? Prostě musí brát ty průměrné a podprůměrné. Tohle je realita, současný stav – ne něco, co by si ty firmy vymyslely, aby ušetřily.

A Java je jazyk, který tuhle realitu dobře reflektuje a trefil správný poměr jednoduchosti a možností jazyka. Proto se ve firmách tolik používá. Na druhé straně jsou jazyky pro geniální samotáře, kteří budou onanovat nad vlastní genialitou a teoretickou dokonalostí svého jazyka. Ale pro týmovou spolupráci je takový člověk a jeho výtvor nepoužitelný a zatáhnout si něco takového do firmy je neštěstí, protože ta většina průměrných programátorů si s tím nebude vědět rady. C++ je někde mezi tím, je na jednu stranu hodně složité a záludné, ale na druhou stranu je to praktický jazyk s dlouhou historií, zralým ekosystémem a je v něm napsaná spousta softwaru, takže jen tak nezmizí (a tím pádem ani nevymřou C++ programátoři).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 23:20 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Nemyslím si, že by lepší jazyk musel být nutně ukecanější. C++ má místy hnusnou/složitou syntaxi a ještě hnusnější standardní knihovnu. Kvůli zpětné kompatibilitě to nejde, ale kdyby to šlo: tak zahozením standardní knihovny a jejím čistým a promyšleným přepsáním by se z toho stal mnohem lepší jazyk.
Bezpečnější jazyk je obvykle ukecanější. Protože potřebuje mít nějaké informace ve zdrojovém kódu.

C/C++ je prostě hnusné po syntaktické stránce i po stránce standardní knihovny. Hlavní důvod proč se prosadilo C je, že se svezlo s unixem. Hlavní důvod, proč se prosadilo C++ je, že to bylo C, které všichni známe.

---
A Java je jazyk, který tuhle realitu dobře reflektuje a trefil správný poměr jednoduchosti a možností jazyka. Proto se ve firmách tolik používá.
S tím bych ostře nesouhlasil. Java se prosadila a používá proto, a jen proto, že firma Sun do prosazení Javy narvala astronomické miliardy dolarů. Sun financoval prosazení Javy tak mocně, až sám zkrachoval, a přestal existovat. Protože namísto kšeftu se Sun věnoval prosazení Javy.

Když nalejete tolik peněz do prosazení i totálně blbého jazyka, jako nalil Sun do Javy, tak se ten jazyk prostě používat aspoň trochu bude.

---
Na druhé straně jsou jazyky pro geniální samotáře, kteří budou onanovat nad vlastní genialitou a teoretickou dokonalostí svého jazyka. Ale pro týmovou spolupráci je takový člověk a jeho výtvor nepoužitelný a zatáhnout si něco takového do firmy je neštěstí, protože ta většina průměrných programátorů si s tím nebude vědět rady.
Já jsem tedy asi žil celý život v bludu. Celý život jsem měl zato, že nástroje pro práci mají sloužit tomu, co se dělá. Programovací jazyk není nic jiného než nástroj, asi tak jako kladivo, šroubovák, pila, apod. Dělat z programovací nástroje účel a cíl snažení je zaměňovat prostředky a cíl snažení.

Každý programovací jazyk dneška je v zásadě jednoduchoučký jako pro mentální retardy. Neznám žádný programovací jazyk, kde by člověk potřeboval doktorát. Nevím proto moc o čem mluvíte.

Já naopak trpím tím, že většina moderních programovacích jazyků si zbožští jako zlaté tele pokládané na oltář bohu nějakou teoretickou věc, a tím vznikne nepraktický programovací jazyk. Byl bych první, kdo by jásal, kdyby někdo tvořil praktický programovací jazyk - jako nástroj.

Java si zbožštila OOP. Rust si zbožštil bezpečnost pointerů. C++ si zbožštilo šablony, generické programování.

---
C++ je někde mezi tím, je na jednu stranu hodně složité a záludné, ale na druhou stranu je to praktický jazyk s dlouhou historií, zralým ekosystémem a je v něm napsaná spousta softwaru, takže jen tak nezmizí (a tím pádem ani nevymřou C++ programátoři).
C++ právě záludné není. C++ se chová dosti logicky. Jeho složitost je jenom zdánlivá, C++ je postaveno na několika málo principech, které se všude opakují.
17.8. 00:12 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Bezpečnější jazyk je obvykle ukecanější. Protože potřebuje mít nějaké informace ve zdrojovém kódu.
Jaké informace máš na mysli? Rust moc informací navícv tomhle ohledu typicky neobsahuje. Občas nějaké ty lifetimes, to ano, ale toho obvykle moc není. Celkově mi přijde spíš méně ukecaný než C++, ačkoli záleží jak v čem.
C++ právě záludné není.
C++ zcela určitě záludné je, mj. v tom, že obsahuje velké množství implicitního chování. Různé typy se implicitně konvertují jeden na druhý, volání funkce může implicitně končit všude možně (overload resolution je směšně složitý), vytvoření reference je implicitní, u kontejnerů stdlib se provádí implicitně hluboké kopie, atd.

Celé je to prošpikováno nepěkným množstvím složitého implicitního chování. Zajímavé je, že i přes spoustu toho implicitního chování je C++ stále dost ukecaný jazyk.
17.8. 01:23 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
C++ zcela určitě záludné je, mj. v tom, že obsahuje velké množství implicitního chování. Různé typy se implicitně konvertují jeden na druhý, volání funkce může implicitně končit všude možně, vytvoření reference je implicitní, u kontejnerů stdlib se provádí implicitně hluboké kopie, atd. Celé je to prošpikováno nepěkným množstvím složitého implicitního chování. Zajímavé je, že i přes spoustu toho implicitního chování je C++ stále dost ukecaný jazyk.
Já jsem čekal, že vyjmenujete úplně jiné záludnosti C++. A ne tento čajíček. :-)

Nicméně C++ se chová logicky. Ve své podstatě se dají i neznámé části a chování C++ odhadnout, pokud máte trochu selského rozumu.

Já bych za hlavní chybu C/C++ považoval, že je až fanaticky příliš postavena na pointerech. A až příliš mnoho věcí je "emulated by poiter". Z toho vyšly hlavní chyby a problémy C/C++.

Dál je třeba říci, že standardní knihovny C/C++ se nepovedly, a je to seno, odpad, a žumpa. U používání C/C++ je poměrně nutné používat nějakou vlastní univerzální knihovnu.

Co se STL, tedy standardní knihovny C++, týká, tak kontejnery považuji za něco, co bych tvůrcům omlátil o hlavu. Jsou špatně, ale hlavně nebezpečně navržené. Rezignovalo se tam jak na OOP hierarchii, tak na jakoukoli kontrolu správnosti operace. Až příliš, přespříliš mnoho situací končí "nedefinovaným chováním". Myslím, že ideální taktika je napsat si vlastní kontejnery, které se budou chovat trochu rozumněji.
BWPOW avatar 17.8. 02:33 BWPOW | skóre: 21 | Kosice
Rozbalit Rozbalit vše Re: Bezpečnost x Štábní kultura
Tie kontajnery budu v C++20 uz trochu pod kontrolou vdaka konceptom. Ale suhlasim s tym, ze je v tom trochu bordel. Prakticky vsetko, co vzniklo pred C++11 je trochu bordel.
Prisiel som, videl som, hmm ... bwpow.eu
17.8. 03:07 Miloslav Ponkrác
Rozbalit Rozbalit vše C++
Velkou devizou C++ jazyka je, že je to vnitřně logický a konzistentní jazyk, což je spíše velice vzácná výjimka v programovacích jazycích.

Ohledně STL si myslím, že nikdy nebude dobrá. Pamatuji doby, kdy standardizační komise nechtěla zaručit vůbec nic. Jak obrovskou práci dalo komisi přesvědčit, že vyhozená výjimka v kontejneru by neměla skončit "nedefinovaných chováním", ale ta výjimka by se normálně měla šířit dál. Protože objekt v kontejneru může vyhodit cokoli, a mělo by se to dále šířit.

Můj názor je napsat si své vlastní kontejnery a nad STL zmlámat hůl. Ten čas na napsání vlastních kontejnerů se vám miliónkrát vrátí, až někde omylem sáhnete do kontejneru mimo. Namísto třídenní hledání chyby v STL kontejneru prostě dostanete výjimku z vlastního kontejneru a za okamžik je opraveno.

---

Standardizační komise se také bojí třeba sáhnout nad RTTI. Musela by si přiznat, že neřešila nekonzistenci typového systému. Totiž že C++ řeší typy nezávisle pro každý modul, ale jiné features, třeba dynamic_cast nebo rtti nebo přetypování proměnných z jiných modulů - je nedořešená věc jako Brno.

---

A tak bych mohl psát dále a dále. Prohlásil jsem to kdysi a řeknu to i teď. Až standardizační komise C++ včetně Stroustrupa dostane rozum, pozná se to tak, že v C++ bude klíčové slovo finally. Pak teprve lze očekávat prakticky vyřešené kontejnery v C++ a mnoho dalších základních věcí.
17.8. 14:07 linuxák
Rozbalit Rozbalit vše Re: C++
Můj názor je napsat si své vlastní kontejnery a nad STL zmlámat hůl. Ten čas na napsání vlastních kontejnerů se vám miliónkrát vrátí, až někde omylem sáhnete do kontejneru mimo. Namísto třídenní hledání chyby v STL kontejneru prostě dostanete výjimku z vlastního kontejneru a za okamžik je opraveno.

---

Takže si v C++ napíšeš vlastní kontejnery, proč ne. A teď si vem, že bys třeba místo C++ použil Rust. Sáhneš do kontejneru mimo a stane se co? V Rustu dostaneš panic ze standardního kontajneru a za minutu je opraveno. Jako bonus jsi ušetřil měsíc psaní vlastních kontejnerů, ve kterých stejně nasekáš mraky chyb a budou mnohem hůř odladěné, než ty ve standardní knihovně.

17.8. 19:27 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: C++
Proč by měly být v jednoduchých kontejnerech mraky chyb?
včera 07:15 linuxák
Rozbalit Rozbalit vše Re: C++
Protože ty kontejnery nejsou vůbec jednoduché. Musíš řešit mimo jiné move sémantiku, in-place konstrukci, vlastní alokátory a podobné chuťovky. Jestli si myslíš, že na koleně spíchneš vlastní kontejnery, které budou srovnatelné s knihovní implementací co do kvality a výkonu, tak jsi hodně naivní, protože jen v kontajnerech v C++ standardní knihovně jsou člověkoroky práce.
včera 12:44 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: C++
Musíš řešit mimo jiné move sémantiku, in-place konstrukci, vlastní alokátory a podobné chuťovky.
Tipuju, že tohle on vůbec neřeší...

Jinak v tomhle je zajímavé, jak má Rust úplně opačný default: Datové struktury by-default nejsou kopírovací, naopak by default jsou přesouvací (movable). Takže člověk pro typy ani nemusí implementovat move semantics - funguje to out of the box. A to mnohem lépe než v C++, protože se neporušuje RAII. V C++ jsou move semantics dost zprasené, je to spíš glorifikovaný swap. Jsem z toho popravdě dost zklamaný. Taky mi přijde mnohem lepší, když je kopírování explicitní, ne implicitní jako v C++, kde když si člověk nedá pozor, zkopíruje se mu věcí, že se nestačí divit.

Na druhou stranu Rust má nevýhodu, že move je někdy potřeba explicitně zakázat (pin API, mam z něj zatím trochu smíšené pocity) a taky nepodporuje emplacing (byla pro to jednu dobu experimentální podpora v nightly, ale odstranili to, protože to nefungovalo dobře, a čeká se teď na nový, lepší návrh). Tož tak.
xkucf03 avatar 17.8. 14:16 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: C++
Můj názor je napsat si své vlastní kontejnery a nad STL zmlámat hůl.

Jenže jak potom kombinovat kód od různých autorů? Co když budu psát knihovnu pro ostatní nebo naopak používat cizí knihovnu a ty metody budou mít na vstupu nebo výstupu více hodnot (tzn. nějakou kolekci, pole, seznam…)? Pro srovnání: v Javě by ta metoda přijímala nebo vracela Collection, což je jednoduché rozhraní definované ve standardní knihovně, které může kdokoli implementovat (a pravděpodobně si i vystačí s implementacemi ze standardní knihovny).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
17.8. 19:42 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: C++
V C++ není problém vytvořit vlastní kontejnery stejného názvu jako jsou v STL standardní knihovně C++. Vzhledem k tomu, že C++ kontejnery jsou stejně jenom hlavičkové soubory se šablonami, není vůbec žádný problém je nahradit vlastní implementací. Mnohem lepší než je ve standardu.

Takže není problém napsat a používat (a vnutit libovolnému projektu/knihovně/etc.) vlastní hlavičkový soubor "list", "vector", atd., který bude implementovat šablony s vlastní implementací std::list, std::vector, ...

Mimochodem, divil byste se, jak chybové a plné problémů jsou cizí knihovny, hlavně open source. Když je napojím na svou implementaci kontejnerů, tak to začnou padat chyby z knihoven jako kanonáda.

C++ má prostě mizerně nevržené knihovny, přičemž kontejnery jsou ta nejhorší část. Ani další verze standardu C++ na příšernosti STL nic nezměnily. V případě C++ je to ale opravitelná chyba. Nahradit knihovny vlastními je velice jednoduché.

Mimochodem, třeba Microsoft ve svém kompilátoru pochopil šílenost STL, a doplnil STL alespoň houfem assertů, které upozorňují na špatné použití kontejnerů. GCC ovšem nechává programátory na holičkách, chybné použití STL prostě jen někdy naboří paměť, a pak se to náhodně někde sekne či zboří. I to mluví o kvalitách kompilátorů.
včera 07:21 linuxák
Rozbalit Rozbalit vše Re: C++
Vytvořit alternativní implementaci kontejnerů se stejným názvem jako v STL knihovně, je obecně velmi špatný nápad. Není to totiž binárně kompatibilní, což znamená, že všechny knihovny, které mají v interface kontejner, musíš také překládat s tvým projektem. Nemůžeš použít žádnou dev knihovnu, která je součástí distribuce. To je docela opruz hlídat a všechny závislosti si znovu překládat, u většího projektu spousta zbytečné práce navíc.

A mimochodem GCC má debug verzi kontejnerů taky: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
16.8. 16:07 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Tady nevidim žádnou pointu. V Rustu můžeš udělat to samé, co v C++ - exponovat C-kompatibilní API/ABI.
Ta pointa je v tom, že každá platforma definuje C ABI, nikoli Rust ABI.
16.8. 01:24 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Rust 1.37.0
1) Protože Rust není tak dobrý, a nemá dostatečně dobré vlastnosti, aby dokázal nahradit C/C++.
Rust neni vselek, ale v rade scenaru muze byt lepsi volba. Go taky neni top jazyk co do vlastnosti, ale presto rada programatoru po nem sahne, protoze resi nektere veci mnohem elegantneji nez C/C++.
2) Protože Rust není seriózní programovací jazyk na rozdíl od C/C++ (nemá nezávislý standard, nectí zpětnou kompatibilitu, ...).
To asi malokoho trapi. I C++ dlouho dobu nemelo standard a rozsirilo se. A i kdyz standard melo, tak prekladace byly proslule tim, ze nepodporovaly vsechno a poradne, takze kolem prelomu tisicileti bylo zvykem, ze soucasti guidelines projektu bylo i to, ktere vlastnosti jazyka se muzou pouzivat, aby to slo prelozit na ruznych prekladacich a platformach.
3) Rust nemá definováno přesné chování v řadě situac
Vytahovat nedefinovane chovani pri srovnavani s jazykem C je dost chucpe.
4) Protože C je mnohem přenositelnější a univerzálnější jazyk než Rust.
Otazka vkusu. Slusi se dodat, ze ta univerzalita je vykoupena tim, ze programatorovi je umozneno udelat vyrazne vic chyb.
5) Protože C má konzistentní a stabilní ABI, což umožňuje velice mnoho věcí.
IIRC, to nikde ve standardu neni napsane a s rozsirenim jazyka to moc nesouvisi. ABI C++ budiz prikladem.
6) Protože Rust přišel o pár desetiletí později než C/C++.
To je tak jedine, s cim se da souhlasit.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
16.8. 02:14 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ad 1) Jenomže C/C++ má své typické pole použití: Univerzální jazyk, kde potřebujete maximální rychlost, rychlý vývoj a totální kontrolu. Jazyk, který vám umožní skoro cokoli - a minimalizuje použití jiného jazyka (zejména assembleru). Jazyků, které by zde mohli s C/C++ soupeřit moc není - já neznám osobně ani jeden moderní jazyk, který by se o to úspěšně mohl pokusit.

Ad 2) Tak si to myslete dál, že nikoho netrápí, že má před sebou indiferentní nedefinovaný jazyk, od kterého nemůže přesně vědět, co může čekat dnes či za rok - ale pak pěkně prosím nedávejte prosím takové blbé otázky jako "proč Rust nenahradil C".

Všechny jazyky, které nebyly jen štěkem, a jsou dlouhodobou stálicí, mají - jasný standard a zpětnou kompatibilitu.

Ad 3) Zřejmě víte o C něco, co nevím já.

Ad 4) Já znám jazyky, které umožňují stejnou univerzalitu jako C, a přitom jsou daleko bezpečnější než Rust. Třeba i ta stará herka Ada to zvládla velice dobře. Rust to nezvládl.

Nicméně jak už jsem psal výše. Jsou plné pytle jazyků pseudonáhrad C/C++, ale neschopných univerzálnosti C/C++. Jinak řečeno, nejsou náhradou C/C++. Ani Rust ne. Proto nikdy Rust C/C++ nenahradí.

Ad 5) A proto snad každý programovací jazyk má nějakou formu, jak zavolat funkci v C ABI. :-)

včera 23:08 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Rust 1.37.0
Jenomže C/C++ má své typické pole použití: Univerzální jazyk, kde ...
Pouziti slov "univerzalni jazyk", pricemz nasleduje omezujici vycet, je takove mile.

Vylozene manipulativni je pak davat jazyky C a C++ dohromady a vlastnosti jednoho spojovat s obema. C opravdu nevynika rychlosti vyvoje, v C++ zase clovek ztraci tu zminovanou totalni kontrolu...
Ad 2) Tak si to myslete dál, že nikoho netrápí, že má před sebou indiferentní nedefinovaný jazyk, od kterého nemůže přesně vědět, co může čekat dnes či za rok - ale pak pěkně prosím nedávejte prosím takové blbé otázky jako "proč Rust nenahradil C".

Všechny jazyky, které nebyly jen štěkem, a jsou dlouhodobou stálicí, mají - jasný standard a zpětnou kompatibilitu.
Treba takovy Python nebo PHP...
Ad 4) Já znám jazyky, které umožňují stejnou univerzalitu jako C, a přitom jsou daleko bezpečnější než Rust. Třeba i ta stará herka Ada to zvládla velice dobře. Rust to nezvládl.
Tak sem s nima. Otazka je, jestli opravdu ta bezbreha univerzalita je to, co programatori realne chteji/potrebuji. Ada sice nektere veci resi lip, ale programovat v ni je tezce PITA, vedle toho Rust si programatori voli dobrovolne, protoze prekvapive se jim v tom dobre programuje a resi to nektere situace, ktere generuji caste chyby. Za me duraz implicitni duraz na immutabilitu je krok velmi dobrym smerem.
Ad 5) A proto snad každý programovací jazyk má nějakou formu, jak zavolat funkci v C ABI. :-)
Jak uz jsem psal v predchozim prispevku, C++ ma priserne ABI a jeho rozsireni to neni nijak nebrani, nevim, proc by to melo branit Rustu. Volani funkci z C je ciste otazkou rozhrani a u rady jazyku se to resi nejakou formou FFI, coz s jazykem nemusi souviset vubec.

Fakt, ze vetsina jazyku ma out-of-the-box rozhrani pro C neni dano nejakou jeho uzasnosti toho rozhrani, ale proste tim, ze temer kazdy programovaci jazyk potrebuje pristup k rozhranim OS, resp. k standardnim knihovnam, ktere jsou v drtive vetsine psany v C, takze je to jen takova znouzectnost.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
včera 11:15 jdsulin2
Rozbalit Rozbalit vše Re: Rust 1.37.0
5) Protože C má konzistentní a stabilní ABI, což umožňuje velice mnoho věcí.
Ale pro C je to pravda, vsichni to dodrzuji, narozdil od toho C++, kde to prinasi spoustu problemu a mnohdy knihovny uvnitr napsane v C++ (protoze je v tom jednodussi spoustu veci naprogramovat) maji interface v C prave z tohoto duvodu. C knihovnu nahrajes v podstate v jakemkoliv jazyku, dokonce i dynamicky (dlsym, GetProcAddress), coz taky vsechny vyssi jazyky delaji, kdyz potrebuji C knihovnu.
16.8. 13:23 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
6/ Je správně.

Dnes je tolik jazyků, a tak mnoho legacy kódu, že aby se nový jazyk prosadil, tak to prostě bude trvat dost dlouho. A vzhledem k tomu, že naučit se Rust je přeci jen náročnější než třeba Javu, nebo C#, nebo Javascript, tak to tomu taky nepomáhá.
16.8. 16:36 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Hlavně je potřeba přesvědčit tisíce výrobců různých mikrokontrollerů a procesorů, že nový jazyk je lepší než C.

A abyste donutili ty tisíce firem přejít z C na Rust, tak potřebujete:

1) Standard jazyka.

2) Puntičkářské dodržování zpětné kompatibility.

Firmy nebudou utrácet dolary na to, že se jim neustále mění jazyk pod rukama, na to se vám zvysoka vykašlají. Nebudou utrácet velké peníze za neustálé změny kompilátorů. A vývojáři nebudou utrácet prachy za neustálé přepisy zdrojáků.

3) Public domain licenci jazyka. Tak jak to má třeba C/C++. V okamžiku kdy si najdu na webu Rustu, že Rust je licencován buď jako Apache nebo MIT licence, tak to je polibek smrti pro programovací jazyk.

4) Záruku budoucího vývoje. Tedy aby Rust byl spravován nějakou seriózní organizací.

5) A pak samozřejmě Rust by musel být stejně univerzální a stejně efektivní jako C. Plus nějaké killer feature navíc, kterou nelze realizovat knihovnami či extenzemi C.
16.8. 17:44 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
2) Puntičkářské dodržování zpětné kompatibility.
Blah. C++ taky občas udělá nekompatibilní změny (C++11, C++14, C++17).

Co se týče "puntíčkářského" dodržování zpětné kompatibility v C, zkus si následující kód zkompilovat s C90 a C99:

int main() {
    const int i = 2 //**/ 2
        ;
    return i;
}
16.8. 18:03 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Každý jazyk dělá nekompatibilní změny. Ale C/C++ je dělá velice nerado, s obrovským rozmyslem, a musí to být sakra zdůvodněné. Jinak řečeno, politikou C/C++ je nedělat nekompatibilní změny.

Upřímně řečeno, žádná firma ani vývojář nechce trávit čas přepisem projektu o miliónu(ech) řádcích zdrojového kódu jen proto, že autor programovacího jazyka je debil a není schopen udržet v maximální míře zpětnou kompatibilitu.

Programuji už cca 30 let. Všechny C/C++ zdrojové kódy přeložím bez jakýchkoli problémů úprav i pod nejnovějšími standardy C/C++. Všechen kód za 30 let. To je něco, co se mi s nějakým Go, Rustem, apod. nemůže nikdy stát. Kód v Rustu, který napíši dnes, s největší pravděpobností pohoří za rok, dva nebo tři - při těch změnách jazyka.
16.8. 18:42 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
To je něco, co se mi s nějakým Go, Rustem, apod. nemůže nikdy stát. Kód v Rustu, který napíši dnes, s největší pravděpobností pohoří za rok, dva nebo tři - při těch změnách jazyka.
Vytáhl jsem si projekt z konce 2016 a aktuální Rust to normálně přeloží včetně všech dependencí. Rust má kvůli zpětné kompatibilitě mj. edice (víceméně něco jako různé verze standardů v C/C++). Souhlasim, že jsou méně kozervativní než C/C++ a šance na problém je asi o něco větší, nicméně zpětnou kompatibilitu berou také docela vážně. Veškeré nové featury v edici 2018 nijak neovlivnily schopnost kopmilátoru kompilovat kód z 2015.

Go je na tom se zpětnou kompatibilitou pravděpodobně lépe než Rust co se týče jazyka jako takového, bude na tom ale hůř v oblasti dependencí, protože semver specifikace dependencí podporuje teprve nedávno. Rust je má od začátku. C/C++ ti v oblasti dependencí ukáže velký vztyčený prostředníček.
16.8. 20:16 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Rust vydává různé verze standardů zvaných edice. Ale nemá ani jeden psaný normativní standard. To mi přijde takové zvláštní.

Já přeji Rustu ať se mu daří. Má před sebou ještě mnoho práce.
xkucf03 avatar 16.8. 21:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0
C/C++ ti v oblasti dependencí ukáže velký vztyčený prostředníček.

To přece není až tak věc C/C++ jako spíš distribucí, jednotlivých knihoven a sestavovacích nástrojů. U C/C++ je snaha používat sdílené knihovny – což je ta těžší cesta, ale podle mého správnější. Oproti tomu jiné jazyky resp. jejich ekosystémy na tohle kašlou a zjednodušují si to tím, že všechny závislosti přibalí k programu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 23:51 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
To přece není až tak věc C/C++ jako spíš distribucí, jednotlivých knihoven a sestavovacích nástrojů.
Tam je to špatně celé ze shora až dolů. Jistá naděje jsou moduly v C++20, ale nevim no, uvidíme...
U C/C++ je snaha používat sdílené knihovny – což je ta těžší cesta, ale podle mého správnější.
Já ti nevim. Taky jsem býval fanoušek sdílených knihoven v distribučních balíčcích, poslední dobou už moc ne. Funguje to dobře pro takové ty hodně rozšířené fundamentální věci jako různé kodeky základních široce používaných formátů (komprese, obrázky, apod.), systémové GUI toolkity a takovéhle věci. Pro ostatní věci až tak ne, mi přijde. Nedávno jsem si instaloval maličký prográmek v Hakellu a balíčkovací systém mi kvůli tomu natahal několik desítek balíčků haskellovských závislostí. Být to sestaveno více staticky, nejspíš by to mělo zlomek tý velikosti a bylo v jednom nebo několika málo balíčcích. Když se mi pak s každou aktualizací systému stahovala půlka haskell ekosystému, tak jsem to celé odstranil.

Nehledě k tomu, že proces mapování dependencí na balíčky nějaké konkrétní distribuce je nespolehlivý, nepredikovatelný opruz.
xkucf03 avatar 17.8. 00:10 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0
Nedávno jsem si instaloval maličký prográmek v Hakellu a balíčkovací systém mi kvůli tomu natahal několik desítek balíčků haskellovských závislostí.

Chápu, třeba v JavaScriptu to bude ještě horší.

Být to sestaveno více staticky, nejspíš by to mělo zlomek tý velikosti a bylo v jednom nebo několika málo balíčcích.

Jenže to je dané chybným návrhem těch knihoven, nevhodnou granularitou, a tím, že autor té aplikace nad závislostmi nepřemýšlí a natahá si tam náhodné knihovny a jejich tranzitivní závislosti a je mu to jedno. Je to prostě špatně odvedená práce a vadná kultura.

Máš pravdu v tom, že když se to kompiluje staticky, může kompilátor vyházet nevyužitý kód a zahrnout jen nějakou podmnožinu. Na druhou stranu tam máš duplicitní kód napříč programy, který je neudržovaný/neudržovatelný.

Nehledě k tomu, že proces mapování dependencí na balíčky nějaké konkrétní distribuce je nespolehlivý, nepredikovatelný opruz.

Mně se celkem líbí, jak má balíčky udělané Guix, kde můžeš mít instalováno více verzí od jednoho programu/knihovny a ten systém je na to připravený, není to tam jen tak dodatečně dohackované. A pak se mi líbí systém knihoven v Javě (Maven), kde jsou zase dobře vyřešené jedinečné názvy (groupId/artifactId/version)… tohle většina jiných systémů nezvládla a mají v tom bordel.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
17.8. 00:37 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Jenže to je dané chybným návrhem těch knihoven, nevhodnou granularitou, a tím, že autor té aplikace nad závislostmi nepřemýšlí a natahá si tam náhodné knihovny a jejich tranzitivní závislosti a je mu to jedno. Je to prostě špatně odvedená práce a vadná kultura.
Mně ani tak nevadil počet těch dependencí jako spíš hlavně to, že se řešily přes balíky distribuce. IMO v takovémhle případě to nemá žádnou výhodu.
A pak se mi líbí systém knihoven v Javě (Maven), kde jsou zase dobře vyřešené jedinečné názvy (groupId/artifactId/version)… tohle většina jiných systémů nezvládla a mají v tom bordel.
No takže javovské dependence taky neřešíš přes distribuci, ne?
xkucf03 avatar 17.8. 00:56 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše systém balíčků, závislosti
Mně ani tak nevadil počet těch dependencí jako spíš hlavně to, že se řešily přes balíky distribuce. IMO v takovémhle případě to nemá žádnou výhodu.

A jak by se to mělo řešit? Proč bych měl mít v OS spousty různých balíčkovacích systémů – pro každý jazyk jiný nebo dokonce několik pro jeden jazyk a ještě k tomu duplikovat stažené balíčky mezi uživateli?

Vždyť je to pořád dokola to samé:

  • globálně unikátní identifikace artefaktu (nemusí to být jen program, můžou to být i data, zdrojáky atd.)
  • indexování a hledání v katalogu, metadata (odkazy, licence, ukázky obrazovek…)
  • stahování přes síť, zrcadla
  • ověřování podpisů
  • vyhodnocování grafu závislostí
  • kontrola nových verzí, bezpečnostní aktualizace
  • sdílení artefaktů mezi uživateli téhož systému + případně možnost instalace do domovského adresáře bez administrátorských práv
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
17.8. 01:21 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: systém balíčků, závislosti
Proč bych měl mít v OS spousty různých balíčkovacích systémů – pro každý jazyk jiný nebo dokonce několik pro jeden jazyk a ještě k tomu duplikovat stažené balíčky mezi uživateli?
Huh? Kdyby byl ten Haskell prográmek sestaven staticky (více staticky), tak si stáhnu jeden distribuční balíček nebo třeba jeden nebo několik málo balíčků nějakého základního Haskell runtime a k tomu ten prográmek.
Vždyť je to pořád dokola to samé
Není. Ty balíčkovače mají jiné kompetence a řeší trochu jiné věci. Balíčkovacím systémem distra si řídíš, co máš v systému. Balíčkovací systém jazyka spravuje dependence nějakého software na různých systémech. Určitý přesah tam je, ale není to to samé.
17.8. 01:23 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: systém balíčků, závislosti
Huh? Kdyby byl ten Haskell prográmek sestaven staticky (více staticky), tak si stáhnu jeden distribuční balíček nebo třeba jeden nebo několik málo balíčků nějakého základního Haskell runtime a k tomu ten prográmek.
Resp. takhle: On ten balíček možná staticky sestaven byl (už nevim), ale nepřijde mi smysluplné, že jsem k tomu musel použít balíčkovač distribuce.
xkucf03 avatar 17.8. 00:59 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0
No takže javovské dependence taky neřešíš přes distribuci, ne?

Ne, ale je to špatně. Chtělo by to mít jednak možnost systémové instalace javovských knihoven a jednak to propojit s Mavenem, aby si knihovny bral odněkud z /usr/share/…, pokud tam jsou a ne jen z ~/.m2/repository

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
včera 11:22 jdsulin2
Rozbalit Rozbalit vše Re: Rust 1.37.0
2015 ? 2016 ? To je nedavno. C/C++ zkompiluje projekty stare 30 let (to sice Rust zatim ani umet nemuze, protoze tak stary neni). A nemusis pouzit stary kompiler, klidne muzes pouzit posledni.

Krasny priklad je treba Qt - to neni jenom o jazyku, ale i o celem ekosystemu a filosofii, ktera je velmi podobna C/C++:

https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/

Mas kod pro C++ knihovnu starou jako metuzalem a jsi schopny to preportovat do nejnovejsi verze, bez nejakych extra problemu - to je presne definice: nedelat nekompatibilni zmeny. Pro vice platforem.
včera 12:41 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
Já se obávám, že stejně jako Miloslav Ponkrác, nehrajete fér.

Samozřejmě že Rust měl svá dětská léta kdy se syntaxe divoce měnila. Ale, ač bych se nerad mýlil, tak od prohlášení že je to stabilní, tak si žádné BC nevybavuji.
včera 12:54 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ale, ač bych se nerad mýlil, tak od prohlášení že je to stabilní, tak si žádné BC nevybavuji.
Ale jo, breaking changes byly i po 1.0, ale to se děje snad v každém jazyce včetně C a C++. Jde spíš o to, že lidi vidí nové featury v jazyce a mají dojem, že tím pádem se jazyk mění. Nedochází jim, že ty změny jsou zpětně kompatibilní (stejně jako třeba u C++), že existují edice atd.

Takže ty breaking changes IMO +- nejsou o horší než v C, C++.

Mimochodem, triviální způsob jak v Rustu potenciálně porušit kompatibilitu je přidat metodu u primitivního typu nebo typu ze standardní knihovny. Protože si můžeš k libovolnému typu (včetně primitivních) přidat vlastní metody pomocí vlastní traity, přidání stejně pojmenované metody v jazyce/stdlib ti pak může rozbít kód. Samozřejmě když si přidáváš metody k primitivním typům nebo typům ve standardní knihovně měl bys s tímhle počítat (!) a člověk si moc nemá na co stěžovat, když se tohle stane, ale technicky vzato se stále jedná o breaking change.
včera 16:17 jdsulin2
Rozbalit Rozbalit vše Re: Rust 1.37.0
Jde o to, ze pokud si delas na svem pisecku nejaky projekt, tak je vlastne uplne jedno v cem to napises. Ale jakmile napises knihovnu v C nebo v C++ a pridas C rozhrani, tak ji muze pouzit uplne kdokoliv. Stejne kdyz pises program a nechavas uzivatelum moznost dopisovat si pluginy. Pokud je rozhrani v C, tak ten kdo chce tvou knihovnu pouzit / napsat plugin pro tvuj program, tak je ti uplne jedno jaky kompiler pouzije, dokonce je ti jedno jaky jazyk pouzije. U C++ uz je to problem, protoze musis pouzit stejny kompiler a mnohdy i stejnou verzi. Stejnym problemem trpi Rust. Kdyz napises nejakou knihovnu v Rustu a nepridas C rozhrani, tak ten kdo ji bude chtit pouzit bude muset pouzit Rust.

Nejvetsi a nejlepsi priklad tohoto jsou OS - muzou byt napsane v cemkoliv, ale pouzivaji C rozhrani, proc asi.
včera 22:38 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
"C rozhraní" se tomu říká taknějak lidově, ale reálně jde o ABI systému, případně některé z ABI systému (viz např. jaký byl bordel na 32bit x86).

Všimni si, že C++, Rust a další jazyky si spolu můžou povídat aniž by na to jazyk C potřebovaly (není potřeba použít kompilátor C).
16.8. 18:41 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
Přesvědčování tisíce výrobců čehokoliv nepovažuji za nijak zajímavé ani podstatné.

1,2/ To přijde. Už teď se jazyk výborně stabillní. Poslední nějaké větší BC byl tak dva roky zpět - což je prehistorie. 2,3.4/ Považuji za tvůj čistě soukromý názor. 5/ Oboje splněno.
15.8. 23:35 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Muze mi nekdo vysvetlit, proc Rust jeste nevytlacil C?
Tohle bude nejspíš trolling, ale minimálně bych se před takovou otázkou zamyslel, proč C++ nevytlačilo C...
16.8. 02:03 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
To je dost nesmyslná otázka, protože C a C++ jsou si tak podobní, že se dají považovat za dva stupně téhož jazyka.
16.8. 02:24 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Mohu přidat další body:

7) Web Rustu se snaží každého odradit od jazyka co to jenom jde.

8) Rust je víceméně zastřešován a placen Mozillou. To jest společností, pro kterou je mnohem důležitější podpora homosexualismu než nějaká schopnost a znalosti. Ono je to kromě Rustu dost vidět i na Firefoxu v posledních letech - a je důvodem velkého rozšíření Chrome.
16.8. 09:44 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Když Mozilla kopíruje vývoj Chrome, neznamená to, že hlavním zdrojem homosexualismu (ať už je to cokoliv) je Google?
16.8. 18:31 OkCupid
Rozbalit Rozbalit vše Re: Rust 1.37.0
Brendan Eich musel odstoupit z pozice ředitele Mozilly proto, že homosexuálové protestovali. Brendan Eich totiž kdysi před mnoha lety podpořil protest proti manželství homosexuálů. Homosexuálové uspořádali protest, a Brendan Eich musel rezignovat.

Homosexualismus je stav, kdy je nejdůležitější pro ředitele Mozilly, aby se líbil homosexuálům. Nepodstatné a málo důležité pak je, aby byl schopný a odborně na výši.
16.8. 18:42 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
To je žel pravda :-(
16.8. 22:22 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Ředitel není technická pozice.

A zapomeňte na homosexuály. Je to sice špatné PR v zemích, kde už většina lidí opustila potřebu páchat násilí na některých menšinách, ale je pádnější důvod nechtít Brendana Eicha jako ředitele Mozilly. Totiž on dlouhodobě přispíval Republikánům. To je ta strana, která je proti síťové neutralitě, pro extrémní interpretace IP doma a v mezinárodních smlouvách (ACTA, TPP).

Mozilla je o svobodném softwaru a internetu. Docela by mě zajímalo, jak si to představuje Eich, když podporuje politiky, kteří jdou proti tomu.
xkucf03 avatar 16.8. 22:30 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Jako kdyby soudruzi z tzv. Demokratické strany scházející se v kavárně Karla Marxe byli nějaká výhra…

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
16.8. 22:49 Piloslav Monkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
O žádných takových nevím.

Demokratická strana byla po desítky let pravicová, i když ne tak extrémně. Vlastně většinově dodnes. Vystupovala v zájmu sponzorů, takže byla pro ACTA nebo TPP. Čest výjimkám jako Bernie Sanders.

V postoji k síťové neutralitě byli Demokraté jednoznačná výhra.
16.8. 11:22 BoneFlute
Rozbalit Rozbalit vše Re: Rust 1.37.0
V mém případě se tak stalo. Co se mě týče nástupem Rustu C/C++ umřelo.
16.8. 11:48 pete
Rozbalit Rozbalit vše Re: Rust 1.37.0
Tak to zrovna nikoho nezajímá..
Bystroushaak avatar 16.8. 12:31 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Rust 1.37.0
Mě to zajímá.
16.8. 13:21 pete
Rozbalit Rozbalit vše Re: Rust 1.37.0
s/nikoho/nikoho důležitýho

navíc lžeš.
Bystroushaak avatar 16.8. 15:33 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Rust 1.37.0
Takové sebemrskačství se jen tak nevidí.
16.8. 15:44 _
Rozbalit Rozbalit vše Re: Rust 1.37.0
Chcete technickou diskuzi narušit toxickými egosračkami? Volejte Bystroushaaka na 1-800-NARCIS.

15.8. 20:17 muck
Rozbalit Rozbalit vše Re: Rust 1.37.0
Vida vida, už se to konečně přehouplo přes 137 uživatelů, gratulki. Tak zase za rok pa.
xkucf03 avatar 17.8. 19:58 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Mimochodem, když už se tu tolik řeší C++, v poradně mám jeden dotaz.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
17.8. 20:33 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
1) Já bych začal tím, že bych rozhodně nikdy nepoužíval typ uint16_t. A to jednoduše proto, že takový typ na mnoha platformách vůbec nemusí existovat. Pokud platforma/procesor nedokáže poskytnout 16bitový integer, tak prostě v C/C++ vůbec uint16_t neexistuje.

Zrovna 16bitový integer na mnoha 32bitových platformách vůbec neexistuje.

---

2) Jinak pro určování životnosti existuje věc, které se říká počítání referencí. Pokud dané třídě dáte statickou proměnnou s počtem kopií odkazu, řeší to problém. Jakmile počet odkazů klesne na nulu, zrušíte i zdroj. Pokud chcete mít multithreading prostředí pro inkrementaci a dekrementaci čítače referencí použijete atomické funkce.

Vytvoření kopie třídy inkrementuje čítač referencí. Destruktor třídy pak dekrementuje čítač referencí, a pokud dosáhl nuly, tak zavře handle.
17.8. 20:50 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Rust 1.37.0
Pěkně postaru, ale ukazující princip:
struct VlastnikZdroje
{
    unsigned  PocetReferenci;
    TypHandle Handle;

    void createRef() {++PocetReferenci;}
    void deleteRef() {if (--PocetReferenci == 0) close();}

    void close();
    void open(TypHandle NovyHandle) {close(); Handle = NovyHandle; PocetReferenci = 0;}
};


class TridaKPouzivani
{
  ...

  private:
    VlastnikZdroje * UkazatelNaZdroj;
};
dnes 01:25 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Rust 1.37.0
Hm. Seriózní programování zřejmě spočívá v tom, že člověk nekontroluje přetečení počtu referencí...
dnes 01:44 _
Rozbalit Rozbalit vše Re: Rust 1.37.0
ukazující princip
xkucf03 avatar 17.8. 21:01 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rust 1.37.0

Odpověděl jsem pod tím dotazem, kde je to víc k tématu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
včera 22:40 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Rust 1.37.0
1) Já bych začal tím, že bych rozhodně nikdy nepoužíval typ uint16_t. A to jednoduše proto, že takový typ na mnoha platformách vůbec nemusí existovat. Pokud platforma/procesor nedokáže poskytnout 16bitový integer, tak prostě v C/C++ vůbec uint16_t neexistuje.
Je kouzelne, jak Ponkrac v prispevcich nekde nahore horuje za to, ze jazyk, aby byl bran jako seriozni, musi mit precizne definovane chovani. A jako priklad dava C/C++, kde nejsou presne definovany ani zakladni skalarni typy, resp. jejich rozsahy a jejich chovani.

Dale, datovy typ ma vyjadrovat zpusob reprezentace hodnoty (jeji ulozeni) a mnozinu pripustnych hodnot. Proto se datovy typ voli podle toho, jake hodnoty ma reprezentovat, ne podle toho, jestli na dane platforme existuje, nebo ne. Takze uint16_t je naprosto validni volba, kdyz to clovek chce/potrebuje.
Zrovna 16bitový integer na mnoha 32bitových platformách vůbec neexistuje.
A nicemu to nevadi, protoze prekladac (a od toho tam je) se s tim umi vyporadat.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.