Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
Object.hashCode() vrací v Javě int.
Já bych tu metodu s hashem nepoužil ještě z jednoho důvodu – podle mne je součástí kontraktu metody hashCode() to, že v rámci běhu jedné aplikace vrací pro stejné objekty stejný hash kód. Ale při znovuspuštění aplikace už ten hash kód může být pro stejný řetězec úplně jiný. Pro String je sice metoda výpočtu hash kódu popsaná v JavaDoc, ale nejsem si jist, jak moc je závazná, a zda se třeba s novou verzí JRE nemůže změnit.
). Mě se toto chování hrubě nelíbí a považuji to za úplně nesmyslné omezení jazyka.
intern(). Což se bude zajišťovat dost těžko (jinak než na úrovni kompilátoru a předefinováním významu některých operací – např. konstrukce objektu – speciálně pro String). Takže obecně řetězce porovnávat přes == v Javě nelze. Třeba následující kód vám vždy vypíše false:
String text = "text"; System.out.println(new String(text) == new String(text));
nejakyVstup.intern() == "quit", což je případ tohohle blogu.
Pojídači koláčků a piči Javy útočí! S OOP na věčné časy a nikdy jinak!...
Já bych spíš doporučoval nastudovat něco o lexikální/syntaktické analýze, ale chápu, nezní to tak cool jako "Design patterns" a OOP...
Ale napadlo mě přesně totéž. 
Já bych spíš doporučoval nastudovat něco o lexikální/syntaktické analýze, ale chápu, nezní to tak cool jako "Design patterns" a OOP...To je těžké, když oni se s těmi patterny nacpou skutečně všude
switch na String je pěkný nesmysl, proto to taky Java neumí (a doufám, že umět nebude). switch je totiž výběr z několika málo možností. Stringů přitom může být nekonečně mnoho různých. switch pro int je taková berlička, protože když neexistovaly enumy, používaly se místo nich konstanty typu int. To už teď není potřeba, takže jestli máte někde switch nad něčím jiným, než enum, je docela dobré se nad tím pořádně zamyslet, zda tam náhodou není něco špatně.
Záleží na tom, co vše si od toho promptu slibujete. Pokud má být relativně složitý, asi by se dalo uvažovat o nějakém parseru. A pokud to má být jenom pár příkazů, řešil bych to přes enum, třeba takhle:
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.HashMap;
import java.util.Map;
public class Test2 {
private static enum Prikazy {
PRIKAZ1("prikaz1") {
@Override
public void akce() {
// TODO
System.out.println("prikaz1");
}
},
PRIKAZ2("prikaz2") {
@Override
public void akce() {
// TODO
System.out.println("prikaz2");
}
},
QUIT("quit") {
@Override
public void akce() {
System.out.println("Bye.");
System.exit(0);
}
},
;
private final String prikaz;
private static Map<String, Prikazy> mapa;
private Prikazy(String prikaz) {
Prikazy.init();
this.prikaz = prikaz;
Prikazy.mapa.put(prikaz, this);
}
private static void init() {
if (Prikazy.mapa == null) {
Prikazy.mapa = new HashMap<String, Prikazy>();
}
}
public static Prikazy getPrikazByName(String prikaz) {
return Prikazy.mapa.get(prikaz);
}
public abstract void akce();
}
public static void main(String[] args) throws IOException {
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
do {
System.out.print(">> ");
String answer = reader.readLine();
Prikazy prikaz = Prikazy.getPrikazByName(answer);
if (prikaz == null) {
System.out.println("Tenhle příkaz neznám…");
} else {
prikaz.akce();
}
} while (true);
}
}
Je to prece jen syntakticky "sugar" pro hodne if-else if...A to máte odkud? V Javě to tak není, v C/C++ pokud vím také ne…
if zjišťuje, zda je hodnota nějakého výrazu true – pokud ano, vykoná příslušný kód. switch porovná hodnotu výrazu s předem určeným seznamem konstant a skočí na příslušnou část kódu. Ony leccos napovídají už anglické názvy těch příkazů Implementace může být různé, switch by se dal implementovat i tak, že pro malé hodnoty souvislé řady konstant se prostě o onu konstantu zvýší ukazatel právě vykonávané instrukce, takže ani není nutné provádět test, stačí sčítání a skok. Některé programovací jazyky mají dokonce vícenásobný if i switch – switch stále porovnává hodnotu s konstantami, vícenásobný if je zkratka pro if … else if. Výrazy u ifů se pak samozřejmě vyhodnocují pokaždé znova.
Tohle jsou IMHO implementační detaily, podstratné je, že to navenek je řídicí konstrukce. Hmm, koukám, že mi z odkazu zmizel hash s IDčkem uzlu. Že bych ho tam zapomněl napsat? Asi jo.
a volání getA(), a hned máte buď jedno volání metody, nebo 3. break taky není povinnou součástí switche Vzhledem k tomu, že u enum máte zaručeno, že se začne na 0 a hlavně má souvislou řadu, může JIT takovéhle „šaškárny“ docela klidně dělat. A hlavně každý z těch dvou příkazů má jiné použití – if použiju, potřebuji-li rozhodnout o nějaké podmínce, switch použiju, pokud potřebuju vybrat jednu z více možností. Myslím, že je účelnější (alespoň v Javě) takhle k těm dvěma příkazů přistupovat a takhle je rozlišovat – vede to pak ke srozumitelnějšímu kódu.
"Můžete to tak brát, že všechny vyšší programovací jazyky jsou vpodstatě syntaktický cukr přidaný k assembleru. "Nesouhlasím. Nižší programovací jazyky jsou syntaktický cukr přidaný k assembleru. Vyšší programovací jazyky jsou syntaktický cukr přidaný k lambda kalkulu.
Ekvivalentní to není, dosaďte si místo a volání getA(), a hned máte buď jedno volání metody, nebo 3.Ale no tak, zachovat sémantiku při syntaktické transformaci snad není problém. Kdyby byl, neexistovaly by kompilátory, že?
jen si se switchem usetrim opruz s opakovanim "a". Je to podle mne stejne jak funkcne tak dokonce i implementacne (trikrat se udela porovnani v nejhorsim pripade). Nedokazu si predstavit kompilator, ktery by delal "saskarny" se scitanim apod. (mozna by se usetrila komparace, ale pokud by konstanta byla 1000, nacpalo by se tam kilo nopu?)Jo jo. Není důležité něco vědět, důležité je mít názor. To platí i pro experty na lambda kalkul, kteří ovládají lexikální analýzu, syntaktickou analýzu a mnoho dalších latinských slov.
Není třeba chodit na vrabce s kanónem.
switch byl v Javě 15 let prakticky k ničemu, než přišla verze 5?
else if), vidím jako rozumnější používat switch tam, kde vybírám z omezeného počtu možností (a tedy budu mít ve zdrojáku pro každou myslitelnou možnost odpovídající sekci case). Jedině takové použití má (v Javě) smysl.
Že jsou lidi líní se učit, to je jejich problém, ne problém Lispu a Pythonu.
Navíc pochybuji, že může být dobrým programátorem ten, kdo zná jen jeden jazyk, nebo jen jeden přístup. Produktivnějším (a to krátkodobě) možná, protože důvěrně zná knihovny a prostředí, ale lepším asi ne.
Jak psal Kyosuke, Java je prostě moderní COBOL, jazyk pro mainstream, pro rozsáhlé aplikace tvořené ve velkých firmách hromadou programátorů a i když se do této role dostala omylem, můžeme jí to místo na slunci z celého přát Ovšem nemyslím, že alespoň průměrný programátor v Javě nebude schopný se naučit dělat v Pythonu, vždyť ten jazyk je daleko jednodušší (alespoň, pokud nepřijde na pokročilé konstrukce), než Java
cat $( head -1 ./abc )tak to samozřejmě pustíš jednou na celek a rekurzivně zpracuješ $(). Myslel jsem to, že je zbytečné rekurzivně procházet stromem při dekódování jednotlivých tokenů. K tomu totiž nepotřebuješ znát cestu, ale jen konec, případně si cestu uložíš do řetězce (názvy proměnných, konstanty).
21.4.2007 23:55
wake | skóre: 30
| blog: wake
| Praha
21.4.2007 22:46
Command cmd = commands.get(answer);
if (cmd==null) {
System.out.println("unknown command: "+answer);
} else {
cmd.run();
}
Toto řešení se dá navíc do budoucna rozšiřovat: například přidat metodu getDescription() a pak automaticky generovat help, přidat metodu checkValidNow() která otestuje zda je příkaz použitelný v aktuálním stavu aplikace, atd.
Samozřejmě je ještě nutné mapu příkazů naplnit, to lze také dělat pěkně či ošklivě, ale nebudu se zde rozepisovat...
Díky