V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
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: