???.txt

[Andras Tantos]

Hali!

>> Azutan ird meg a 'backspace' rutint - tudod, vissza torolni egy 
>> karaktert.
>> Azutan ird meg az index operatort, amelyik az 'i'-edik karaktert (es nem
>> byte-ot) adja vissza. Ha ez is megvan, ird meg a 'compare' fuggvenyt,
>> amelyik ket string-et hasonlit ossze egyezoseg szempontjabol (figyelembe
>
> Megirom! Akar ugy, hogy eloszor kikodolom valami unicode szeru formatumba,
> es ugy vegzem el a kavarasokat. Semmi problema.
> De lassuk be, nem egy eletszeru problema...
> Gondolod hogy a vilagon mindenki wordot szeretne irni?
> Pl a kavefozobe, vagy egy POS terminalba konstans sztringeket, es %d-t
> kell kiirni. Mi a rakert lenne benne unicode, ha akarhany nyelven is tud??

Ne vadits mar! Nem eletszeru egy string-et nem sorosan elerni? Nem eletszeru 
visszatorolni az utolso karaktert? Rendben, egy kavefozoben nem valoszinu, 
de egy POS terminalban, ahol mondjuk afas szamlat kell kiallitani, mar igen.

>> el ket string osszefuzesen, string-ek szetvagasan (kodlaphelyesen,
>> termeszetesen, tehat a masodik string elejere be kell esetleg szurni egy
>> escape szekvenciat), egy string kozepebe valo beszurason, vagy mondjuk a
>> sub-string keresesen (megintcsak kodlap helyesen termeszetesen).
>
> Nekem 3 sztringmuveletem van:
> RawDoFmt: kb mint a sprintf, de mindig ugyanabbol a bufferbol veszi az
> adatokat, es a formazott szoveg is egy fix bufferbe kerul
> zprint: Z pointer altal cimzett flash teruletrol ir ki formazas nelkul a
> kijelzore, de a vezerlokaraktereket kezeli
> bprint: a formazo bufferbol ir ki
>
> Mi egyeb kell egy tobbnyelvu GUI-val kommunikalo eszkozhoz?
> A beszuro, kereso, stb.. fuggvenyek nem tudom mihez kellenek, ehhez pont
> nem. Mondjuk ha forditoprogramot irnek, vagy ilyesmi, akkor talan...
> Szoval probalkozz egy eletszerubb peldaval!!

Aha. Az eredeti problema a TC unciode kodolasi hibaja volt. Aztan a vita az 
e-mail-ek kodolasara terelodott. Ekkor te javasoltad, mint megoldast a 
Unicode helyett az escape-elt kodlap-valtasokat kellene hasznalni. Erre en 
leirtam, hogy a standard, es sok helyen hasznalt string-muveletek rendkivul 
bonyolulta valnak egy ilyen abrazolasban. Ezek utan, te leirod, hogy, leven 
te flash-ben tarolod a string-jeidet, ezert eletszerutlen, ha barki mas 
maskent teszi.

De, hogy konstruktiv legyek: a 'tobbnyelvu GUI-val kommunikalo eszkoz' 
feltetelezi a kommunkiaciot, azaz a ketiranyi adatcseret. Meghozza tobb 
nyelven, ezert 'tobbnyelvu'. A ket iranyu, tobb nyelvu adatcsere, pedig 
feltetelezi, forditasi idoben ismeretlen, tobb nyelvi string-ek 
feldolgozasat. Peldaul egy masik eszkoztol, peldaul egy felhasznalotol, 
peldaul az internetrol, peldaul egy fajlrendszerrol - fajlnev formajaban 
erkezo isemertlen string-ek feldolgozasat.

Hogy eletszeru peldat mondjak, a felhasznalo beirta a kereszt- es 
vezetek-nevet a betegnek az EKG berendezesbe (ilyeneket is fejlesztesz, ha 
jol tudom), mire az EKG a korhaz halozatan lekerei a kozponti adatbankbol a 
beteg biztositasi adatait es korelozmenyet. A vissza kapott adatokat aztan 
(biztos, ami bizots) osszeveti a bevitt kereszt- es vezetek-nevvel, majd 
szepen ranyomtatja a kikopott papirra, aminek a tartalmat persze vissza is 
menti a kozponti adatbankba kesobbi feldolgozas celjabol. Leven a berendezes 
modern, ezert a kommunkiacio a halozaton (titkositott) HTTP protokollon 
keresztul tortenik, es tegyuk fel, hogy minden rendszer (Unicode helyett) a 
te altalad javasolt string definiciokkal mukodik. Azert itt mar van jopar 
string-muvelet, nem?

Vagy lehet, hogy nem jol ertem, es te ugy gondoltad, hogy az altalad 
javasolt megoldas nem univerzalis, es csak azokban az esetekben hasznalando, 
ahol elonyos, maskor meg nem? No de pont te magyaraztad, hogy az ordog a 
kulonbozo abrazolasi modok kozotti konverzioban rejlik, es hogy a 
Unicode-dal az a baj, hogy oda-vissza kell konvertalgatni, es, hogy az ASCII 
meg azert jo, mert ott meg nem. Most akkor a te megoldasod miert jobb? Ezt 
speciel nem oldja meg, nem szabvanyos es dinamikus string-kezelesre nem 
hatekony (statikus string-eken meg nem sok kezelni valo van).

>> Miutan ezzel is kesz vagy, forditsd a figyelmed a fentebb emlegetett
>> allokalo rutinra: leven itt kenytelen vagy worst-case szamolni (hiszen 
>> meg
>> nem tudod, hogy a user mit fog beirni, akar minden karakter utan kodlapot
>> kellhet valtanod) ezert a foglalt memoria tobb mint ketszer akkora lesz,
>> mint egy sima ASCII string-hez kellene.
>
> Miert irna be az user barmit is??????
> Miert engednem meg, hogy minden karakter utan kodlapot valthasson???
> Talan tobbfajta nyelven van a neve, vagy mi?

Azert mert olyan nyelven van a neve (kinai az urge), amiben tobb, mint 255 
karakter lehet. Igy a kodlapod nem a nyelvet, hanem a nyelvben elofordulo 
karaktereknek csak egy reszet tudja leiirni, es nem garantalhato, hogy nem 
lesz akar minden karakter mas es mas kodlapon. De egyebkent is: azert akarod 
a worst-case esetre foglalni a buffert, mert ha nem igy teszed, akkor 
konnyen buffer-overflow hibat vetesz a bevitel feldolgozasa soran.

Hogy miert irna be barmit is a user?
- Mert a POS terminallal AFA-s szamlat kell adnia
- Mert a beteg adatait szeretne felvinni az EKG-ba
- Mert leletet gepel az EKG adatok melle
- Mert a jegy nevre szol (repulojegy pl.)
- Mert a munkaido-nyilvantarto adatokat kuld (egy megadhato) szervernek, 
ahol (SQL) adatbazisban tarolja az informaciokat
- Mert a riaszto (megadott e-mail cimre) levelet kuld minden esemenyrol - 
ugye tudod, hogy ma mar egy DNS entry is lehet Unicode?

A kavefozo, es a mikrosuto valoban nem nagyon igenyli a szoveges (nem 
numerikus) adatmegadast. Bar lattam mar eloadast olyan (penzbedobos) 
kavefozorol, amelyik leadta az aktualis feltoltottsegi allapotat interneten, 
hogy a karbantarto brigad meg tudja tervezni reggel, hogy melyik gepeket 
kell aznap felkeresni.

> Tudod, kavefozo, jegykiado automata, munkaido nyilvantarto, riaszto,
> mikrosuto, POS, stb... Vagy EKG, vagy barmi egyeb.

Vagy TC, vagy levelezo. Leven ezekrol a programokrol volt szo a thread-ben, 
es ezeknek a programoknak a problemaira (konkretan a levelzore) ajanlottad 
az otletedet.

> Tovabba: nem ketszer akkora lehet, hanem akar 4x. ESC, kodlap valtas,
> kodlap, karakter. Na es? Worst case jo sok helyet foglal, altalaban
> viszont fele annyit mint az unicode.

Igen, de sok esetben nem az altalanos, hanem a worst-case esetre kell 
buffert foglalnod. Pl: tudod, hogy egy fajlnevet fogsz kapni, tegyuk fel azt 
is, hogy 8.3-as megadasban, de, leven UNICODE particiorol jon a nev, nem 
tudod, hany (a te megoldasod szerinti) kodlapvaltas lesz benne. Leven a 
nevet tarolni szeretned, le kell foglalnod neki a buffert. Mekkorat 
foglalsz? Ha jol szamolunk, akkor 32+12 byteot minimum. Hogy mindezt miert 
akarod tarolni? Mert mondjuk MP3 lejatszot csinalsz, ami USB-n csatlakozik 
egy PC-hez, es ott normal HDD-nek lattszik. Nincs rahatasod arra, hogy a 
fajlok milyen neven kerulnek ra, kezelned kell tudni oket. Es, ha megengeded 
hosszu fajlnevek hasznalatat, es teszem azt tobb formatumot is tamogatsz, 
amiket a kiterjesztes szerint kulonboztetsz meg, akkor maris meg kell 
keresned a 'string utolso pontja utani reszt' es azt osszehasonlitani elore 
definialt string-ekkel.

Vagy (szinten MP3 lejatszo), ahol a fajlokban talalhato informaciok alapjan 
akarsz ABC-sorrendbe rendezni, vagy szurni dolokat. Pl. egy eloado szamait 
kilistazni. Ehhez is string-eket kell osszehasonlitanod, ami a te abrazolasi 
modszeredben nem egyszeru feladat.

Vagy ez se eleg eletszeru pelda? Vagy nem elegge 'beagyazott' alkalmazas?

Amugy meg egy megjegyzes: leven nem koveteled meg, hogy az esc utan legalabb 
egy karakter alljon, ezert akar egy nulla karaktert tartalmazo string is 
tettszolegesen hosszu lehet:

ESC, kodlap valtas, kodlap, ESC, kodlap valtas, kodlap, stb stb.

Persze erre lehet azt mondani, hogy ez elkerulheto, es ez igaz is, csak meg 
tovabb bonyolitja a string-manipulalo fuggvenyeket.

Tovabbra se gyoztel meg arrol, hogy az altalad javasolt megoldas alkalmas 
altalanos string-abrazolasi modszernek, es mint ilyen a Unicode levaltasara. 
Ha nem erre gondoltal, akkor viszont nem ertem, miert hoztad fel peldakent a 
levelezes kodolasi problemainak targyalasakor.

Udv,
Tantos Andras