Potvora Java dělá si, co chce sama (nebo ne? asi ne) [akt.] (diskuse)

[=^..^= AmigaPower®]

Nevim jak si to vysvětlit, protože je mi doma pořád zima a oba moje teploměry ukazují 26 stupnů...

[freshmouse]

Mně začíná bejt strašný vedro, protože tuhle blbost už řeším půl dne a nedovedu si to vysvětlit. Přitom je mi jasný, že to bude totální prkotina.

[=^..^= AmigaPower®]

...tuhle blbost už řeším půl dne a nedovedu si to vysvětlit. Přitom je mi jasný, že to bude totální prkotina.

...můj věčný Linuxový problém

[Mír]

UTF-8 je asi neco jineho nez UTF-16, ktere nejspis pouziva Java...

[freshmouse]

The Java programming language is based on the Unicode character set, and several libraries implement the Unicode standard. The primitive data type char in the Java programming language is an unsigned 16-bit integer that can represent a Unicode code point in the range U+0000 to U+FFFF, or the code units of UTF-16. The various types and classes in the Java platform that represent character sequences - char[], implementations of java.lang.CharSequence (such as the String class), and implementations of java.text.CharacterIterator - are UTF-16 sequences.

(Zdroj.)

Teď tu ale je otázka, co s tím.

[Mír]

Otevri si ten vystup s nastavenim spravneho kodovani :-P

[freshmouse]

To je mi jasné.

Spíš jsem myslel, jak zařídit, aby ten vstup do souboru byl v UTF-8 -- a je-li to vůbec vhodné, aby byl.

[Mír]

OutputStreamWriter(OutputStream out, Charset cs)

[freshmouse]

Moc díky!

[Andrei Badea]

Musíš zapisovat byty odpovídající znakům zakódovaným v UTF-8. Takže pokud trváš na NIO můžes použít CharsetEncoder nebo (v tomhle případě dostačující) String.getBytes(String).

Vždycky když budes převádět znaky na byty (nebo opačně) a nebudeš mít nikde v programu exiplicitně uvedené kódování je dobré se zastavit a zjistit co bude Java dělat "by default". Většinou to asi bude používát výchozí charset (Charset.defaultCharset()), ale i v tom případě je dobré si říct "je to to co chci?".

[Filip Jirsák]

Vždycky když budes převádět znaky na byty (nebo opačně) a nebudeš mít nikde v programu exiplicitně uvedené kódování je dobré se zastavit a zjistit co bude Java dělat "by default". Většinou to asi bude používát výchozí charset (Charset.defaultCharset()), ale i v tom případě je dobré si říct "je to to co chci?".

Za používání výchozího kódování platformy by měly být stanoveny tělesné tresty V OSS to ještě jde, tam to String.getBytes() člověk opraví a pošle patch, ale v uzavřeném software je to lahůdka.

[Kyosuke]

To je teda masakr, proč tak složitě? Zajímalo by mě, jak můžeš "všechno mít v UTF-8", když putChar určitě do bytebufferu nevkládá UTF-8 znaky. Jsi si jistý, že se učíš Javu?

[freshmouse]

Složitě? Možná. Já nevím, tohle je moje první práce se soubory v Javě... Mám knížku od Ivora Hortona, kde se píše, že to "je sice trošku složitější, ale výkon je vyšší" (to mluvil o bufferech). Tak jsem se tím řídil. Ostatně, proč ne.

Tím UTF-8 jsem myslel ten soubor. Jinak viz komentář výše (o UTF-16).

[Kyosuke]

Nechápu, co má buffering společného s java.nio, byl tu před ním a bude tu i po celé Javě. :o)

[Heron]

Sypat znaky do souboru přes kanál není zrovna nejjednodušší řešení.

[Filip Jirsák]

Mám knížku od Ivora Hortona, kde se píše, že to "je sice trošku složitější, ale výkon je vyšší" (to mluvil o bufferech).

ByteBuffer (NIO) bude rychlejší v případě, že se tím odstraní nějaké zbytečné kopírování – tedy pokud kopírujete přímo ze souboru do souboru, nebo možná při kopírování ze socketu do souboru (nebo naopak). Případně tedy při kopírování mezi souborem nebo socketem a pamětí, jenže data jen tak někde v paměti vám budou celkem k ničemu, a jakmile s nimi začnete něco dělat, budou se stejně nejspíš muset někam okopírovat. V tom kódu se ale stejně nepoužívají přímé buffery (taky k čemu), takže o vyšším výkonu se dá minimálně pochybovat.

Pro začínajícího programátora (v jakémkoli jazyce) bych doporučoval zapomenout na jakékoli optimalizace nebo cokoliv ve smyslu „je to sice složitější, ale…“. Je dobré se nejprve naučit, jak se ta která činnost v Javě (nebo jiném jazyce) normálně dělá. Až budete zvládat základní věci a proniknete do jazyka trochu víc, můžete se začít zabývat tím, jak JVM funguje, jak fungují různé třídy z JRE, jak rpogramovat vícevláknové aplikace atd. Pak teprve se můžete začít zabývat tím, kde je program neefektivní, a teprve když máte zjištěno, která část kódu zdržuje nejvíc, má smysl začít ten kód optimalizovat. Pokud totiž začne optimalizovat začátečník, dopadne to většinou tak, že optimalizuje část programu, která nemá žádný výkonostní problém, přepíše program tak, že je nečitelný a naseká v něm nejspíš spoustu chyb, a ve výsledku to nejspíš bude ještě pomalejší.

Taky mám každou chvíli nutkání něco napsat obecněji nebo to optimalizovat pro vyšší výkon, ale vždy je potřeba si položit otázku: a je to vůbec potřeba?

[freshmouse]

Pro začínajícího programátora (v jakémkoli jazyce) bych doporučoval zapomenout na jakékoli optimalizace nebo cokoliv ve smyslu „je to sice složitější, ale…“. Je dobré se nejprve naučit, jak se ta která činnost v Javě (nebo jiném jazyce) normálně dělá. Až budete zvládat základní věci a proniknete do jazyka trochu víc, můžete se začít zabývat tím, jak JVM funguje, jak fungují různé třídy z JRE, jak rpogramovat vícevláknové aplikace atd. Pak teprve se můžete začít zabývat tím, kde je program neefektivní, a teprve když máte zjištěno, která část kódu zdržuje nejvíc, má smysl začít ten kód optimalizovat. Pokud totiž začne optimalizovat začátečník, dopadne to většinou tak, že optimalizuje část programu, která nemá žádný výkonostní problém, přepíše program tak, že je nečitelný a naseká v něm nejspíš spoustu chyb, a ve výsledku to nejspíš bude ještě pomalejší.

Je to řečeno naprosto přesně.

Já jsem ten kód nepoužil proto, abych optimalizoval, ale popravdě řečeno proto, že jsem byl líný se mrknout na jiný postup -- zejména ve chvíli, kdy jsem se dověděl, že "takhle to je přece lepší". Jinými slovy, udělal jsem přesně to, o čem vím, že se to nemá dělat: "takhle to zatím stačí, nevadí, že tomu nerozumím, někdy to předělám". Tímto způsobem bohužel vzniklo hodně softwaru.

[freshmouse]

To je teda masakr, proč tak složitě?

Nicméně, jak bys to tedy řešil ty? Bez bufferů?

[Kyosuke]

BTW, tohle...

	try 
	{
	    FileWriter writer = new FileWriter(new File("nejaka_cesta_k_uloznemu_souboru"));
	    writer.write(outputString);
	    writer.close();
	}
	catch (IOException e)
	{
	    e.printStackTrace(System.err);
	}

...se tváří, jako že to dělá to, co chceš. A dokonce je to kratší (i když ne tak krátké, jako by to bylo v Ruby nebo v Lispu. ).

[freshmouse]

...se tváří, jako že to dělá to, co chceš.

Nejenže se to tak tváří, ono to tak dokonce i funguje.

i když ne tak krátké, jako by to bylo v Ruby nebo v Lispu.

[podlesh]

...se tváří, jako že to dělá to, co chceš.

Nejenže se to tak tváří, ono to tak dokonce i funguje.

Pozor na to, že soubor bude v defaultním kódováním platformy (podle LC_CTYPE na unixech, nastavení prostředí ve windows).

[freshmouse]

Kdyby ten Kyosukeho kód někdo zkoušel, tak ať si přidá do konstruktoru FileWriter jako druhý argument true, pokud chce, aby se to napojovalo na konec souboru. (Aby to bylo dle mého kódu.)

[tomm]

Jo jo, kdyz jsem videl ten kod, tak jsem badal, co tam dela za kejkle, ze to nemuze byt na 3 radky (bez try-catch).

[freshmouse]

Víc kódu = víc softwaru, no né?

[Kyosuke]

Spellchecker na dvacet řádků kódu, VLSI CAD v 10 KB včetně operačního systému...

[tomm]

No snad prece: Vic kodu == vic softwaru ... to byla ale zacatecnicka chyba!

[freshmouse]

[dementni.lojzik]

nechapu, proc to delas to, co delas (zvlast to puziti bytebufferu), ale jestli na tom trvas, tak staci char pretypovat na byte a ulozit pomoci put: byte b = (byte)outputString.charAt(i);
//buffer.putChar(outputString.charAt(i));
buffer.put(b);


[freshmouse]

O tom použití bufferu jsem psal výše.

Přetypovat na byte by samozřejmě šlo, nicméně, když tam byla ta metoda putChar()... Výsledek by měl být stejný (experimentálně ověřím). No nic, napíšu to tak, jak mi radil Kyosuke.

[dementni.lojzik]

1. vysledek neni stejny 2. ten bodel ti to tam pise, protoze "Writes two bytes containing the given char value..."

Jinak jestli chces jen proste zapsat do souboru, tak jak psal Kyosuke

[freshmouse]

Jo, jo, ještě na to mrknu.

Začátky v Javě jsou fakt krušný. Java Core API je jako slon a kdo se pak v tom má vyznat.

[Käyttäjä 11133]

Když ti vadí velké Java Core API tak se vrhni na forth, nebo na Assembler na nějakém RISC CPU

[freshmouse]

Nevadí mi, jen je těžké se v tom orientovat (v začátcích s Javou).

[Kyosuke]

Jo, a pak při uložení řetězce "Tenhle řetězec skončí příšerně zmrzačený." dostane soubor s obsahem "Tenhle Yet?zec skon í pYíaern? zmrza ený".

[podlesh]

Jak již někdo napsal výše - za používání defaultního kódování platformy by měly být tělesné tresty.

[Kyosuke]

A co to má společného s tímhle problémem? Ten je někde "poněkud jinde".

[podlesh]

Jen to, že jsem si to špatně zařadil do vlákna příspěvků...

[Kyosuke]

S pomocí komentářů uživatelů Kyosuke a Mír jsem se dopátral k tomu, že Java netiskne do souboru v UTF-8, ale UTF-16, takže se vlastně nejedná o chybu v kódu. Ještě jednou díky.

Já bych to upřesnil...ty tu prostě provádíš výstup binárních hodnot znaků, tak, jak jsou v paměti - takže vlastně provádíš výstup šestnáctibitových celá čísel bez znaménka, a pro Javu je výchozí endianness Big Endian, tj. "network order".

[freshmouse]

Doplnil jsem.

[freshmouse]

Jůů, dneska jsem byl nějakej produktivní. Asi jak jste mě nakopli. Semestrálka už má neuvěřitelných 13,1 KB kódu! A to nepočítám ty skripty v BASHI k tomu! A dokumentaci!

Až to bude hotový, dám to sem do blogu. Věřím totiž, že to je naprosto zásadní aplikace.

[Kyosuke]

Jo, dej ji pak sem, uvidíme, na kolik KB to pak dokážeme stáhnout.

[freshmouse]

Ale žádný přepisování do Perlu nebude!

[Käyttäjä 11133]

Myslím, že perl není třeba

[freshmouse]

Neberu si to osobně.

[podlesh]

Já bych celou diskusi shrnul: tu knihu z které jsi to opisoval zahoď. Pořiď si nějakou normální (Herout?), nebo třeba nějaký tutorial (třeba od Sunu?).

[freshmouse]

Chmm. Ta kniha mě stála tisícovku a řekl bych, že je vesměs dobrá. Sice je přeložená úplně šíleně, ale tak nějak mi poskytuje to, co chci.

Herouta mám (dostal jsem ho za pár korun). Rozdíl mezi Hortonem a Heroutem je ten, že Horton má cca 1400 stran, zatímco Herout tři sta (?).

Já mám rád, když se v začátcích (s čímkoli) učím z knihy, tzn. ne z nějakého elektronického média. Je mi to prostě pohodlnější. A v Javě je rozhodně se co učit. Mimo toho, že je mi bližší papír, než monitor, chci mít u sebe něco ve formě knihy, ne tutoriálu nebo dokonce manuálu.

Když si představím, že si sednu před monitor s tím, že "tady mám dokumentaci Java Core API a teď se z ní budu učit", to se mi dělá mdlo. Já potřebuju nabýt nějaký základ právě z knížky.

Jasně, knížky nejsou nejaktuálnější a není v nich všechno, takže se snažím se koukat do dokumentace atd. Chci pracovat s XML? Nastuduju v knížce základ, vyzkouším pár příkladů... Pak se mrknu na java.sun.com, co mi Core API dál nabídne. Stejně tak třeba práce se Swingem. Představa, že bych se učil pracovat s GUI podle nějakého tutoriálu kdesi na webu, mě děsí.

Vlastně se knížka a dokumentace doplňuje; mně to tak vyhovuje.

[Ladicek]

Herouti už jsou dneska čtyři (1. Java, 2. GUI v Javě, 3. Javovská knihovna se zaměřením na kolekce, 4. XML) a myslím, že pro učení je to perfektní materiál. A nejen proto, že to je česky, a ne anglicky s českou slovní zásobou (za takové knížky bych vraždil, cena obvykle vysoká, hodnota obvykle prachmizerná). Je fakt, že z toho člověk rychle vyroste, ale základ to dá dobrý a občas zjišťuju, že tam jsou zakamuflované i docela pokročilé věci

[freshmouse]

Hmm, jak říkám výše, já toho svého Herouta (Java) prakticky dostal. Jeho knížky o C byly super, ale tahle o Javě na mě takový dojem neudělala. Nebyla vysloveně špatná, jen nebyla tak dobrá jako ty o C.

Ten Horton a jeho překlad... Nevím, kdo to překládal. Jsou tam hlavně chyby ve smyslu gramatiky. Upozornil jsem vydavatele (neodpověděl). Ale číst se to dá. Koneckonců, co se gramatiky jazyka (tím myslím češtiny ) týče, ani Herout nemůže hodit kamenem.

Za Hortona jsem vyplázl litr. Za čtyři Herouty bych dal cca 4 * 250 korun, tzn. taky litr. Kvalita mi přijde dost podobná. Jinými slovy, Horton není drahý (uvažujeme-li, že Herout není drahý). (A zajímá-li někoho počet stránek, tak to je asi 1300 vs. 4 * 300. Ne že bych se domníval, že čím víc stránek, tím víc vědomostí...)

[Kyosuke]

Jsou i lepší způsoby, jak vyhodit kilokačku...

[freshmouse]

Dost možná. Jaké třeba?

Jestli za něco neváhám dát prachy, tak jsou to knížky, o kterých si myslím, že mi něco dají. Jasně, někdy si potom řeknu: "To je ale blbost, to jsem si neměl kupovat, spletl jsem se," ale co. To už je riziko. Já prakticky za nic neutrácím (mimo běžné výdaje typu jídlo v menze atd.), takže si myslím, že kdybych si ročně koupil i třeba tři zbytečné knížky, tak to tolik nevadí.

Já, jako pivař a slivovicář (a minule také vínař, vodkař a becherovkář, ajajaj), bych zase neutrácel za koktejly. To jsem byl (po letech) na nějaké oslavě (bylo to v nějakém hybridu mezi hospodou, klubem a diskotékou) a že si poprvé v životě dám koktejl... Otevřel jsem nápojový lístek. Nechci tu vypadat jako nějaká socka, ale přes kilo za jednu skleničku prostě nedám. Zvlášť, když to má názvy jako Sex on the Beach nebo Sperma... :-]

[Kyosuke]

Tak například - zcela konkrétně - tahle knížka. Lepší koupit knihu nenahraditelnou než zbytečnou. Nedávno jsem nahradil kvantitu kvalitou a zjistil sem, že se to dá mnohem lépe vstřebávat...

[freshmouse]

Lepší koupit knihu nenahraditelnou než zbytečnou.

Otázkou jen je, jak zjistíš, co je nenahraditelné a co zbytečné. Já to v obchodě prostě nepoznám.

[Kyosuke]

Podle doporučení a recenzí? Tohle je kupříkladu první knížka o algoritmech, o které mám pocit, že má opravdu hlavu a patu.

[freshmouse]

Doporučení? Zkus se zeptat deseti lidí, jaké pracovní prostředí je zaručeně to nejlepší*, a uvidíš, jak budeš moudrý.

* samozřejmě, že GNOME

[Kyosuke]

Ne, Fluxbox.

[Käyttäjä 11133]

A co si myslíš o The Art of Computer Programming?

[Kyosuke]

Moc pěkný, ale tomu budu rozumět tak za deset let. Zatím jsem v té pozici, že mi to může sloužit jako algoritmická kuchařka. Tak třeba by mě nikdy nenapadlo, že algoritmus pro generování seřazené posloupnosti reálných čísel s rovnoměrnou distribucí může být tak jednoduchý, jaký ve skutečnosti je , a ještě pořád ho budu muset vlastně pochopit.

[Martin]

Já uvažuju o Introduction to Algorithms. Sice je ta cena o dost vyšší, ale ta kniha toho obsahuje o dost víc. Měl jsem ji i v ruce, ale neměl jsem dost času si ji pořádně prohlídnout. Ty tu knihu čirou náhodou neznáš? Že bys ji třeba trochu zhodnotil.

[Kyosuke]

Zeptal jsem se MJe, a ten říkal, že to nemá moc cenu. Máš k němu blíž než já, zajdi za ním a prober to s ním, já už si všechny ty argumenty nepamatuju, ale vyšlo mi, že to pro mě aspoň prozatím nebude nutné. Časem si ji samozřejmě koupím, ale teď by mi tu jen zbytečně ležela.

[Martin]

Vzpomínám si, že MJ na začátku minulého semestru docela chválil "Algorithms", o které jsi tu už ostatně psal. Řekl, že obsahuje většinu věcí probíraných v Algoritmech a datových strukturách I. Tehdy jsem se bez knihy ještě celkem obešel, ale teď k ADS II a dalším předmětům by se mi myslím nějaká kniha hodila. A "Introduction to Algorithms" obsahuje vše od vyhledávání v textu, přes toky v sítích a Fourierovu transformaci k NP-úplnosti a spoustě dalších věcí. Takže s množstvím pokryté látky problém asi nebude, jen si nejsem jistý, jestli je ta látka podána dostatečně srozumitelně a pochopitelně.

[Kyosuke]

Nu to je právě to. Corman et al. je fajn, ale je to trošku víc hardcore, a možná ne úplně v tom nejlepším slova smyslu. Přeci jen jsem do ní taky nakoukl. No určitě je to dobrá investice, rozhodně lepší než nějaká "džava".

[Martin]

Tak dík, ještě si to promyslím. A taky je pravda, že mi huba neupadne, pokud se zeptám vyučujícího. Sice je fakt, že to je jediná kniha, o které vím, že obsahuje vše, co budu potřebovat, ale rád bych, aby mi taky k něčemu byla. Na poličce by se sice vyjímala hezky, ale jen kvůli tomu utrácet víc jak 1500 Kč nechci.

"Džava" u mě opravdu nehrozí.

[Ladicek]

A já myslel, že doporučíš SICP! Před pár dny jsem si ji objednal

[Kyosuke]

Tu už jsem párkrát doporučil, tak snad malá obměna by taky neškodila. (Hmm, možná bych mohl časem udělat seznam oblíbené četby... )

[Käyttäjä 11133]

Jo, to by jsi měl

[podlesh]

Chmm. Ta kniha mě stála tisícovku a řekl bych, že je vesměs dobrá. Sice je přeložená úplně šíleně, ale tak nějak mi poskytuje to, co chci.

A to je co? (co chceš)

Já tu knihu neznám, ale pochopil jsem to takto: ty jsi začátečník a při pokusu o triviální zápis do souboru jsi vyrobil naprostou obludnost. To je zcela v pořádku pokud bys to vyrobil sám od sebe (zkoumáním API). Od toho jsou knihy/učebnice/tutorialy, aby tomu zabránily. Jenomže ty jsi to vyrobil právě podle učebnice, která tedy žalostně selhala.

PS. V knize nazvané "Beginning Java" nemá vůbec NIO co dělat - maximálně jako zmínka že je API umožňující efektivnější práci s IO (především soubory, sockety) pro toho, kdo ví co dělá a proč.

[freshmouse]

A to je co? (co chceš)

Chci nějaký základní náhled na věc a vědět, co mám dál hledat.

Já tu knihu neznám, ale pochopil jsem to takto: ty jsi začátečník a při pokusu o triviální zápis do souboru jsi vyrobil naprostou obludnost. To je zcela v pořádku pokud bys to vyrobil sám od sebe (zkoumáním API). Od toho jsou knihy/učebnice/tutorialy, aby tomu zabránily. Jenomže ty jsi to vyrobil právě podle učebnice, která tedy žalostně selhala.

No, já bych to zase tak nesváděl na knihu. Ber to tak, že tohle byl první postup zápisu do souboru, který jsem našel v kapitole Zápis do souboru. Třeba byl někde i další postup.

PS. V knize nazvané "Beginning Java" nemá vůbec NIO co dělat - maximálně jako zmínka že je API umožňující efektivnější práci s IO (především soubory, sockety) pro toho, kdo ví co dělá a proč.

Ta kniha Beginning Java má 1300 stránek a už na obálce se píše, že naučí naprosté základy i psaní větších aplikací. Myslím, že si zmínění java.nio může dovolit.

[Daniel Kvasnička ml.]

Jasně, knížky nejsou nejaktuálnější a není v nich všechno, takže se snažím se koukat do dokumentace atd.

Proto je lepsi kupovat knihy o vecech, ktere tak rychle nezastaravaji (taky mam knihu o Pythonu 2.2.....) a rychle se menici veci studovat z internetu. Zrovna na Javu (at uz SE nebo EE) je na internetu mnoho kvalitnich materialu.

Ja si dneska poridil Navrhove vzory, coz je jedna z prvnich obsahlejsich veci na toto tema v cestine a rozhodne nezastara tak rychle jako kniha o konkretnim programovacim jazyce.

[freshmouse]

Já, pokud to jen trochu jde, čtu raději z papíru než z monitoru.

Ona ta literatura o Javě zase tak nezastarává. Alespoň ne pro moje potřeby. Základní věci platí prakticky pořád. Zrovna ta knížka od Hortona pojednává o 1.4 (s dodatky o 5. verzi od Viriuse). Z toho naberu pojem o tom, co to vlastně je, a musím počítat s tím, že se budu pořád něco nového potřebovat doučovat; ať už to jsou enumy, nové vlastnosti cyklu for nebo třeba jen vylepšené třídy J. C. API.

[Ladicek]

Ja si dneska poridil Navrhove vzory, coz je jedna z prvnich obsahlejsich veci na toto tema v cestine a rozhodne nezastara tak rychle jako kniha o konkretnim programovacim jazyce.

A můžeš o ní pár slov? Někdy Předevčírem jsem na ni koukal a přemýšlím, že bych do toho šel. Čeština je holt čeština (ale ukázkové zdrojáky mohl nechat Ruda anglicky ) ). I když přeložená jména některých návrhových vzorů zní trochu komicky.

[Bez něj je to jen Jo]

Ta kniha ale není překlad, ne? V každém případě bych poprosil, abyste mi doporučili nějakou dobrou (jakou jinou, že ) knížku na návrhové vzory (pro Javu) v angličtině. S package rup.česky.vzory._04_neměnné nebo metodou kdoVolá() bych se asi zžít nedokázal.

[Ladicek]

Jasně že není, výraz nechat anglicky je možná trochu zavádějící. To je pro mne právě zásadní klad, že to je původní český materiál. Ne že bych odmítal číst odbornou literaturu v angličtině (Modern Compiler Implementation in Java nebo Java Concurrency in Practice jsem taky zvládl), ale když je k disposici kvalitní knížka v češtině (a tohle by snad mohl být ten případ), je to pro mě jasná volba.

Btw, sžít

[Daniel Kvasnička ml.]

Az ted koukam na ty zdrojaky, ta diakritika v nazvech souboru s classama je poradna prasarna

Nemam ji ted pred sebou, ale co si pamatuju, tak je psana cela stylem otazek a odpovedi. Je tam fiktivni developer, ktery "jakoze" nektere veci nechape a poklada vice ci mene hloupe otazky, na ktere autor odpovida a veci mu vysvetluje.

Trosku mi tam chybi, ze se v podstate vubec nezminuje o DAO a jeho kombinaci s Factory patterny a naopak MVC bych tam az tak uplne mit nemusel (i kdyz pisu o nem diplomku, takze zdroj navic se vzdycky hodi ).

Vic dojmu az se do toho vice zactu... ale uz ted si myslim, ze to rozhodne byla dobra investice (a nejak ten danovej zaklad snizovat musim, zejo )

[|🇵🇸]

Ještě jsem nezapnul topení.

[David Jaša]

Sedíš v pasivním domě a provokuješ?

[Käyttäjä 11133]

Taky mám vypnuté topení Počítače topí dost :D

[|🇵🇸]

Sedím pravda v domě, ale samostatném. Navíc na půdě.

Teploměr mi už zamrzl. ^_^

[freshmouse]

Mimochodem, když už tu mám v diskuzi tolik odborníků...

Jak mám nejlépe implementovat (nechci kód, jen radu) smazání záznamu, jsou-li záznamy v takovéto struktuře:

#####Nadpis 1#####Nějaký text k tomu
#####Nadpis 2#####A zase text k tomu
#####Nadpis 3#####Úplně jiný text k tomu

Ono by asi bylo nejjednodušší načíst ty záznamy do pole (mám metodu pro nečtení záznamů do pole objektů), tu nepotřebnou položku z pole smazat a pak to zapsat celé znova. Nicméně mám vážné pochyby o efektivnosti.

[freshmouse]

Respektive takhle: jde to nějak rozumně smáznout bez toho, abych to všechno musel načítat? Ono by to samozřejmě šlo nějak optimalizovat, třeba načítat jen položky až od té smazané a pak je obrané o tu jednu vložit na konec souboru, ale řešení jako celek mi přijde špatné.

Mně by se hodilo nějak nastavit kurzor na začátek té položky a pak postupně smazávat až do \n (včetně; prostě celou řádku). Jde to nějak?

[Filip Jirsák]

Pokud „smazáním záznamu“ myslíte smazáním řádku, otevřel bych jeden soubor pro vstup a druhý pro výstup, ze vstupního bych postupně načítal řádky a ty, které se nemají smazat, zapisoval do výstupního. Klasická unixová roura

[freshmouse]

To vůbec nezní špatně!

A je nutné mít opravdu (fyzicky) dva soubory?

[Filip Jirsák]

Teoreticky ne, ale to už by znamenalo vyřešit správně zamykání, mít nějaký buffer (protože mazaný záznam může být kratší, než následující záznam, který mám na jeho místo vložit. Rozhodně bych se do takovéhle optimalizace nepouštěl hned na začátku

Ve skutečnosti neexistuje nic jako „smazat něco ze souboru“. Jediná možnost je přepsat to něčím jiným a na závěr soubor zkrátit.

[freshmouse]

Teoreticky ne, ale to už by znamenalo vyřešit správně zamykání, mít nějaký buffer (protože mazaný záznam může být kratší, než následující záznam, který mám na jeho místo vložit. Rozhodně bych se do takovéhle optimalizace nepouštěl hned na začátku

Já bych se do toho taky nepouštěl. Jen jsem se ptal. (Že bych "konečně" využil to svoje používání bufferu. )

[freshmouse]

Jak o tom tak přemýšlím, tak ten můj první návrh nebyl zase tak mimo...: 1. Načíst záznamy do pole objektů.
2. Obrat pole o ten smazávaný záznam.
3. Zapsat všechny zbylé záznamy do souboru, kde byly původně (tzn. zapisovat do souboru v režimu kompletního přepisu). To řešení se dvěma soubory by spočívalo v: 1. Vytvořit nějaký dočasný soubor.
2. Postupně načítat řádku po řádce (= záznam po záznamu), a má-li být zkopírována, zkopírovat ji do dočasného souboru.
3. Smazat původní soubor a ten dočasný přejmenovat, aby byl jako ten původní. Rozdíly: - první řešení se mi zdá náročnější na paměť
- u druhého řešení hrozí problémy s vytvořením souboru (nebo s přejmenováním)
- druhé řešení otevírá více souborů No, ono to asi bude skoro jedno, zejména v případě mé killer app, nicméně si to asi zkusím a uvidím.

[Filip Jirsák]

První řešení je náročnější na paměť, druhé řešení je náročnější na diskový prostor. Problémy se zápisem do souborů hrozí oběma řešením.

[freshmouse]

Problémy se zápisem do souborů hrozí oběma řešením.

V prvním případě hrozí jen to, že ten konkrétní soubor nebude zapisovatelný. V druhém navíc hrozí, že nebude zapisovatelný adresář.

[Filip Jirsák]

To je pravda, to mi nedošlo. Ale pomocný soubor by bylo stejně lepší dělat někde v tempu. Jenže to zase může znamenat jeden zybtečný přesun dat navíc. Bez konkrétních podmínek se holt ideální řešení hledá špatně