Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Tiskni Sdílej:
Object.hashCode()
vrací v Javě int
.
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.
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...
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 enum
y, 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.
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.
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.
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).
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...