.

21.4.2007 13:22 | fake | poslední úprava: 31.12.2010 16:43

.        

Komentáře

[tommy]

na TheDailyWTF som videl riesene tak ze sa nacitany string zahasoval a potom sa ten hash pouzil vo switchi

[manasekp]

mozna se ptam na blbost, ale prece zahashovanim stringu dostanes akorat jiny string ne? tim se neresi problem ze switch neumi switchovat podle stringu...

[Filip Jirsák]

Object.hashCode() vrací v Javě int.

[fakenickname]

Ale jestli se nepletu tak hash může vrátit pro dva různé řetězce stejnou hodnotu. Je to sice zanedbatelná pravděpodobnost, ale je reálná. Vůbec jako využívání hashe jsem v javě ještě nepřišel na chuť.

[Filip Jirsák]

To sice může, ale to už máte pravděpodobnější, že vsadit v loterii, vyhrajete hlavní výhru a do konce života už se nějakou Javou nebudete muset zabývat 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.

[Lu-Tze]

Haroval gádžo na Javě, spravil sa mu šíber na hlave.

http://www.xefer.com/2006/12/switchonstring

[Radek Podgorny]

Java fakt nema switch na string? To cumim! To si zase smslnu az nekdo bude nadavat na C#

[Michal Vyskočil]

Nemá, protože neumožňuje definovat operátory, což obecně Javisti vytahují jako její velkou výhodu (a nevýhodu C++). No a switch porovnává jednoduše pomocí ==, kdežto řetězce v Javě se porovnávají pomocí metody equals a nejde to jakýmkoliv způsobem změnit (mimo zásahu do překladače, ovšem ). Mě se toto chování hrubě nelíbí a považuji to za úplně nesmyslné omezení jazyka.

[Lu-Tze]

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#intern()

Takže řetězce by taky měly jít porovnávat (přesněji zjisťovat rovnost) pomocí ==.

[Filip Jirsák]

Pokud ovšem zajistíte, aby na každý řetězec, ke kterému máte nějakou referenci, byl výsledkem zavolání metody 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));

[Lu-Tze]

Jasně, nemyslel jsem to obecně. Ale jde třeba nejakyVstup.intern() == "quit", což je případ tohohle blogu.

[Michal Vyskočil]

Zajímavé, o tom jsem nevěděl (respektive mě porovnávání referencí z poolu nikdy nenapadlo) ...

[nhy]

Nastuduj si nieco o Design patterns a OOP. Zacal by som knihou Head First Design Patterns.

[Lu-Tze]

dej to na edisk.cz, jestli můžeš

[Martin Tůma]

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...

[Kyosuke]

Myslím, že slovo "pijáci" je společensky konformnější. Ale napadlo mě přesně totéž.

[Michal Vyskočil]

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

[Filip Jirsák]

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);
	}
}

[Radek Podgorny]

A odkud berete to, ze switch ma byt na nekolik malo moznosti? Je to prece jen syntakticky "sugar" pro hodne if-else if...

[Filip Jirsák]

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…

[Radek Podgorny]

Odnikud, to si proste myslim. Ale rad si necham vysvetlit, v cem se to lisi funkcne i ve zpusobu implementace.

[Filip Jirsák]

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.

[Radek Podgorny]

Podle mne je tohle zcela ekvivalentni:

if (a == 1) { } else if (a == 2) { } else if (a == 3) { }

switch (a) { case 1: break; case 2: break; case 3: break; }

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?)

[Radek Podgorny]

oops, zapomnel jsem na "pre"

[Kyosuke]

Přesně tak.

[Tom.š Ze.le.in]

Takže nazvat switch-em něco co je implementováno jako

- najdi hodnotu pro klíč třeba v hash tabulce

- pokud jsi našel, je to funkce a zavolej ji

je terminologicky špatně?

[Kyosuke]

Pokud jsou těla těch funkcí zapsaná jako bloky v alternativách, tak určitě ne. 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.

[Filip Jirsák]

Ekvivalentní to není, dosaďte si místo 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.

[Lu-Tze]

Ale nikdo netvrdil, že je to ekvivalentní... Bez switche se lze úplně krásně obejít a přesto to nebude mít žádný vliv na výkon (v situacích, kdy by se jinak použil switch, prostě se to přeloží jako switch). Je to syntaktický cukr.

[Filip Jirsák]

V tom případě je ale syntaktický cukr vše, co není test, aritmetická operace a goto. Tedy cykly, podprogramy atd. Můžete to tak brát, že všechny vyšší programovací jazyky jsou vpodstatě syntaktický cukr přidaný k assembleru. Ale nevidím žádný rozumný důvod se na vyšší programovací jazyky dívat zrovna takhle. Pokud se na to ale budete dívat na úrovni Javy, pak to není syntaktický cukr, protože jednak pro programátora by if a switch mělo znamenat pokaždé trochu něco jiného, jednak to může usnadnit práci optimalizátoru v JIT. Že se switch dá přepsat jako série ifů a if jako switch na tom nic nemění. Taky máte 4 různé druhy cyklů, a z 12 možností, jak jeden druh cyklu nahradit jiným, jich je 8 obecně proveditelných. To ale ještě neznamená, že je budu vzájemně volně zaměňovat – prostě každý druhy cyklu má pro programátora svůj význam, možná jejich rozlišení v něčem může usnadnit práci i JIT.

[Kyosuke]

"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.

[Kyosuke]

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?

[podlesh]

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.

[Kyosuke]

Není? No, kromě naleštěných assemblerů existují i inteligentnější jazyky. Není třeba chodit na vrabce s kanónem.

[Michal Vyskočil]

Nějak tomu nerozumím, znamená to tedy, že switch byl v Javě 15 let prakticky k ničemu, než přišla verze 5?

[Filip Jirsák]

Switch svou podstatou pracuje nad výčtovým typem (podobně jako if pracuje nad typem boolean). Java dříve neměla typově bezpečný výčtový typ, a nahrazovalo se to typem int – proto i switch pracoval nad typem int. Dneska už Java výčtový typ má, tak je rozumné přestat používat jeho náhražku. Switch tedy nebyl k ničemu, jenom svou nedokonalostí odpovídal nedokonalosti (resp. neexistenci) výčtových typů.

Právě proto, že by bylo zbytečné mít switch jako syntaktický cukr pro vícenásobný if (navíc s divnou syntaxí a s délkou zápisu ± odpovídající délce zápisu 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.

[fakenickname]

Díky za zajímavý příklad..

[thingie]

Java je ztracená. Angličtina asi taky. Chá. Teď už zbývá jen s úsměvem na rtech padnout.

[tomm]

A cim bych tu Javu jako mel nahradit? Snad ne .NETem nebo snad Mono? Nezkousejte mi cpat Python, Lisp nebo Adu ... potrebujete taky mit lidi, kteri se budou na dane platforme orinetovat a budou k sehnani.

[Kyosuke]

Před dvaceti lety bys totéž tvrdil o COBOLu. Že jsou lidi líní se učit, to je jejich problém, ne problém Lispu a Pythonu.

[tomm]

Urcite to neni problem tech jazyku, ale lidi, to se nehadam. Jenze ti lide jsou ti, kteri pracuji ... jazyky sami o sobe nic neudelaji

[thingie]

No, tak čím chceš, když teda cítíš potřebu ji nahrazovat

[tomm]

Ja ani ne ... to ti lide odchazeji a prichazeji - takovy normalni zivot

[Michal Vyskočil]

Myslím, že dobrých programátorů v Javě je úplně stejně, jako dobrých programátorů obecně 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

[tomm]

Jestlize to ma byt skutecny prompt, ktery ma ledacos umet, tak bych to resil parsovanim do (obecne stromove) struktury, kterou bych pak "spustil" (v pripade stromu rekurzivne). Ale taky je to mozna zbytecny kanon na vrabce

[Josef Kufner]

A když nahradíš strom stavovým automatem, tak nepotřebuješ ani tu rekurzi.

[tomm]

To je pravda, ale nejsem si jisty, jestli by stavovy automat zvladl i vnorene konstrukce. Nejak si to neumim predstavit - uz jsem postizeny tim stromem

[Josef Kufner]

Jasně, pokud uděláš něco, co by v bashi vypadalo takle:

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).

[wake]

poslys, a to na to java nema nejakou knohovnu? neco jako je tohle?

[fakenickname]

Možná jo. Zeptáme se pana Kůkla.

[podlesh]

Toto není správné místo na ptaní - akorát se strhne flamewar.

K samotnému problému - máš spoustu možností. Můžeš použít nějakou hotovou knihovnu (to ale spíš závisí na tom co chceš). Můžes to dělat if/else kolonou, ale to je humpolácké řešení (a na rozdíl od C# ho nelze zapsat jednoduše jako switch, jen jako if/else kolonu). Můžeš to dělat přes enumy. Můžeš to dělat "funkcionálním" stylem.

Já osobně mám nejraději poslední variantu. Načrtnu zjednodušeně jak na to:

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...

[fakenickname]

To je přesně to co sem chtěl vědět Díky

[Lu-Tze]

Pro tebe už nikdy opravdu nehnu prstem