Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
.cpp
ale i .cc
(což je IMHO lepší ).
deb http://ftp.cz.debian.org/debian jessie main contrib non-free
.c++
1. Je to tak že programy v C převládají nad těmi v C++? (hlavně psané pro linux) 2. if (předchozí_věta) {proč?};
libg++
byla často nestandardní, v horších případech navíc nefunkční. Teprve s příchodem trojkové řady GCC a libstdc++
se situace výrazně zlepšila.Mimochodem, podívejte se třeba na datové struktury, které používají funkce knihovny libc pro práci se sockety a jejich adresami. Opravdu si myslíte, že tohle by v C++ nebylo výrazně přehlednější?
C je paskvil, který svádí k mnoha neřesten a 100% bych si je nevybral pro větší práci Céčko je proti tomu jednoduchý jazyk, kde když přestanete zápasit s pointerama a vyhnete se několika málo záludnostem, tak lze vyžít.nejak se nemohu zbavit dojmu, ze si protirecite
Můžete, prosím, uvést nějaký konkrétní příklad? Znám jak C, C++, tak právě Javu (a spoustu jiných) a připadá mi, že jakmile jsem pochopil do hloubky sílu objektů, tak je pro mě programování v Javě daleko nejefekticnější. Malé prográmky nebo hračičky v OpenGL píšu v C.
int x = 3; int y = 4; int z = x+y;Tak by mi nevadilo psát:
Int x = new Int (3); Int y = new Int (4); Int z = new Int (x.add(y));S tím, že Int by byl immutable objekt. Tímto lze vyřešit všechny "nekonzistence". Existuje takový jazyk?
if (3.add(4).compareTo(7)) { } else { }Sakra, ale nějaký jazyk mi to připomíná, nemůžu si vzpomenout... Scheme také nemá operátory:
(+ 2 4 6 (- 7 8) (* 9 (/ 1 3))), kde +,-,*,/ jsou speciální formy. Podobně jako třeba define.
~/.emacs
byl přesvědčivější než hodiny přednášek o výhodách vim… :-)
new
má byť načo dobré?
C# bohužel vznikl jako kopie Javy a zkopírovali někdy i totální kraviny z Javy, jako je třeba Unicode řetězec v utf-16 ála Java
IMHO tohle není podle Javy, ale proto, že UTF-16 používají ve Windows. Tedy často spíš používají UCS-2 a pro zmatení nepřítele mu říkají UTF-16… :-)
tady by se hodil nějaký generický kompilátor z C++ do C a bylo by vystaráno, ale pokud vím, nic použitelného neexistuje
Mám pocit, že jsem někde zaslechl (agentura JPP), že první překladače "překladačů" C++ byly ve skutečnosti preprocesory, které C++ překládaly na C, ale výsledek byl velmi neefektivní, takže v okamžiku, kdy se objevily nativní kompilátory C++, po konverzi z C++ do C se slehla zem. Ale možná je to jen takový folklór.
v objektové knihovně toho moc nenajdete, nepočítám-li nějaké ty generické algoritmy a datové struktury a proudy. zbytek se bastlí pomocí knihoven zděděných z Céčka. v knihovně není třeba typ datum, nejsou tam thready, není tam žádná podpora GUI, není tam skoro nic. a dnes dost často o úspěchu jazyka rozhoduje kvalita knihoven.
GUI bych do standardní C++ knihovny určitě necpal, nejsem si ani příliš jistý, jestli se nějaký univerzální koncept, zastřešující rozdílnou filosofii jednotlivých GUI, dá vůbec vytvořit. Co mi tam ale zoufale chybí, je standardní interface pro síťovou komunikaci, to považuji za asi největší nedostatek.
první překladače "překladačů"
Pokud by to někomu nedávalo smysl (tak jako teď mně), tak tam mělo být první generace "překladačů".
float a,b;
FILE f=fopen("subor","r");
fscanf(f,"%f %f",&a,&b);
s ekvivalentnym zápisom v Jave, tak je to hrôza.
Na druhej strane som nedávno bol dokopaný napísať kus kódu (~50kB) s veľmi striktnou kontrolou chýb v C a tam by mi možnosť použiť exception handling ušetrila mnoho práce.
float a, b; std::ifstream f("subor"); f >> a >> b;nevychází z toho C++ zase tak zle. A v okamžiku, kdy těch operací bude dvacet za sebou a bude potřeba doplnit zpracování chyb, začne mít C++ (díky výjimkám) výrazně navrch.
sizeof(float)=32
, sizeof(double)=64
a sizeof(long double)=80
).
sizeof(float)=4
, sizeof(double)=8
a sizeof(long double)=16
. S tím, že u long double se používá jen 80 bitů.
extern "C"
, co nie je to prave orechove.
hovnocuc = 1tak nepoznám jestli je to globální proměnná nebo jde o
this->hovnocuc. Explicitní 'self' nebo 'this' je mnohem lepší. 5) Vloží se to co je využito. Ovšem když stejnou věc využiju v deseti modulech, je to tam desetkrát. Ten druhý model je sice hezký ale prakticky všichni jedou podle toho prvního. 6) Jak chcete například v C++ (efektivně) implementovat wrapper, který před a po volání každé (z několika desítek nebo stovek) virtuálních metod nějaké třídy něco jiného zavolá? Nebo jak uděláte delagaci.. Nebo chcete volat metodu, kterou určíte teprve za runtime ze seznamu metod se stejnou signaturou.. Prostě sáhnout do VMT na správný offset je nejčistší řešení, přesto to jazyk vůbec nepodporuje. Member pointers jsou proti tomu zoufale neefektivní. 7) nevím a je mi to jedno. C++ mi na disk ani do domu nesmí :)
class Global { static public int i; };
no a ako v kazdej diskusii o C++, neda mi nespomenut gotw
no a skoncil som v perli )
#define _PyObject_HEAD_EXTRA \ struct _object *_ob_next; \ struct _object *_ob_prev; #define PyObject_HEAD \ _PyObject_HEAD_EXTRA \ int ob_refcnt; \ struct _typeobject *ob_type; #define PyObject_VAR_HEAD \ PyObject_HEAD \ int ob_size; typedef struct { PyObject_VAR_HEAD PyObject **ob_item; } PyListObject;Ale fakt je že spousta magorů by začala používat blbosti jako přetěžování (když je to jiná funkce, tak to jinak pojmenuj, pitomče!), RTTI (jak se to vypíná? nechceme žádné hidden members!), výjimky, atd, takže je lepší zůstat u C.
foo()
, tak při vcelku běžných zápisech typu
foo(bar(0))nevidíte bez dohledání typu návratové hodnoty funkce
bar()
, která verze foo()
se vlastně bude volat, přestože ta vazba je plně statická.
Zatímco zdrojáky v C se dají normálně číst, v C++ se obvykle musí luštit, a neustále přitom grep-ovat headery. Tohle samotné je ohromná nevýhoda, a těch pár výhod které C++ přináší ji imho dostatečně nevyvažuje.
Přetěžování je velice přirozené a nenajdete programovací jazyk, kde by nebylo
Dynamicky typované jazyky nic takového nepotřebují a nemají. Staticky typované jazyky jako Java nebo C# to mají jen pro normální funkce (ne operátory), a podle mne pouze z historických důvodů- relativně snadno se to implementuje, ve spojení s manglingem to "zadarmo" dává typovou kontrolu v link-time, a v dobách začátků objektového programování se za to asi dával nějaký nepodstatný plus bod, takže to tam všichni přidali, přestože jde o blbost. S tím jestli je to potřebné nebo užitečné to ale nijak nesouvisí.
Pokud jste psal rozšíření RTTI, jak se vám to povedlo udělat portabilně, když formát RTTI dat není standardizován, ani de facto stabilizován? Není lepší RTTI vypnout a implementovat si nějaké tagování objektů plně ve vlastní režii, nebo ještě lépe vzít jen čisté C?
výjimky- ten samý problém. Je sice hezké že mám strukturované výjimky, a že se mi samy volají destruktory při stack unwindingu. Ale když chci například za běhu vypisovat call chain a aktivní exception handlery pro daný thread [což je zcela normální a legitimní věc a, C++ má veškerá data aby to umožnilo] opět narazím, protože portabilně to nejde, a formát tabulek není standadizován ani stabilizován.
C++ zkrátka všechno udělá "napůl"- buď je featura principielně zcestná (přetěžování, private members, implicitní this, zmršené konstruktory) nebo je sice užitečná, ovšem nejde ji portabilně použít naplno.
foo((typ)bar())To by bylo fajn, ovšem 1) ještě jsem to (redundantní cast pro zvýšení čitelnosti) v C++ nikdy neviděl použít- vy ano? 2) to rovnou mohu použít
foo_typ(bar())a nepotřebuju stinkin' C++. Ad sizeof, abs, atd.. ano, fakticky jde o přetěžování, ovšem ohraničené speciální případy. Při čtení libovolného kódu v C si můžu být jistý že
malloc(10)
a malloc(10U)
udělá tu samou věc, což C++ negarantuje, a já to považuju za jednoznačnou chybu, nikoliv "pokrok".
Navíc přetížení funkcí se v každém dynamickém jazyce dá zrealizovat, prostě zjistíte typy předaných parametrů a rozvětvíte kód podle zjištěných typů.
To je naprosto OK, protože pak to větvení JE VIDĚT. Kdežto v C++ stačí přehlédnout přetíženou verzi (což při bloated C++ headerech není problém), a kód dělá něco jiného než jak vypadá.
A zjistíte, že je portabilní interface k RTTI.
Už je to hodně dávno co jsem to používal, ale myslím že nebylo příliš kompletní, končilo někde u dynamického castování. Je to konečně použitelné? Jsou třídy konečně hodnotamí? Jdou srovnávat na ekvivalenci nebo pozici v hierarchii? Jdou konstruktory volat dynamicky? Pokud ne, je to stále nepoužitelné.
Ale zdůrazňuji, že mě standardní výjimky v C++ stačí víc, než dostatečně.
To je možné. Já bych ale chtěl každé smetí, které překladač přibalí, využívat podle svého uvážení, což bez standardního formátu, nebo *kompletního* API nelze. Pokud MSVC nabízí přístup k debug info, tak je to sice hezké, ale pouze pro windows. Když už C++ zavedlo runtime přístup k typovým informacím, a zpracování výjimek, měl být kompletní.
Céčkovský způsob není myšlení ve strojovém kódu, pouze méně zakrývá cenu každého řešení. Na tvorbu malého, bezpečného, spolehlivého a rychlého kódu je to stále ten nejlepší nástroj. Pokud chci vyšší efektivitu psaní, použiju Python, Perl nebo Javu, které věci jako výjimky nebo RTTI dělají pořádně, jsou výrazně přenositelnější, a nejsou přitom o moc pomalejší než ono C++.
Tiskni Sdílej: