string.StartsWith PEBKAC - CultureInfo a legvaratlanabb helyeken is. 

static void Main(string[] args)
{
  Console.WriteLine("kutya".StartsWith("k"));
  Console.WriteLine("kutya".StartsWith("ku"));
  Console.WriteLine("kutya".StartsWith("kut"));
  Console.WriteLine("kutya".StartsWith("kuty"));
  Console.WriteLine("kutya".StartsWith("kutya"));
}

Lefuttatva: 

True
True
False
True
True

Na ezt igy hogy?

(.NET FW 4.0, W7x32)

Szoval, az van, hogy a .NET FW tud magyarul.

( sj | 2013. 09. 11., sze – 13:32 )

irj sajat StartsWith metodust :-)

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

( uid_15483 | 2013. 09. 11., sze – 13:38 )

A "kutya" 3. betűje "ty", nem "t". Stringeket ugye illik megfelelő CultureInfo beállításokkal kezelni:


Console.WriteLine("kutya".StartsWith("k",true, CultureInfo.InvariantCulture));
Console.WriteLine("kutya".StartsWith("ku", true, CultureInfo.InvariantCulture));
Console.WriteLine("kutya".StartsWith("kut", true, CultureInfo.InvariantCulture));
Console.WriteLine("kutya".StartsWith("kuty", true, CultureInfo.InvariantCulture));
Console.WriteLine("kutya".StartsWith("kutya", true, CultureInfo.InvariantCulture));


True
True
True
True
True

( asch v | 2013. 09. 11., sze – 20:38 )

Én betiltanám az olyan API-t, ami mindenféle alapbeállításoktól függően eltérően működik különböző platformokon. A Java is tele van ilyenekkel, és hibák okozásán kívül másra nem jó.

Timezone, character encoding, line ending. Desktop alkalmazasoknal talan lenne ertelme, hogy ezeknek a defaultja felveszi a system beallitasokat, de szerveroldaliknal tenyleg csak a bajt okozzak.
Jobb lenne ha ez fix lenne (pl.: UTC, UTF-8, \n) aztan a system beallitasokat felajanlani kulon API-ban (pl.: SystemSettings class).

.NET 4.5-tol ezt ket sorban el tudod intezni:

http://msdn.microsoft.com/en-us/library/system.globalization.cultureinf…

Viszont gondolom az MS-nek az volt a koncepcioja, hogy ahol kell, ott atadod a CultureInfo-t ha nagyon multikulti kornyezetben kell dolgoznod (pl. tobbnyelvu weblap).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Javaban is át lehet őket állítani, nem nagy kaland.

Akkor sem ideális a jelenlegi API felépítés. Főleg ha libet fejlesztesz másoknak. Akkor oda kell figyelni, hogy a kódod ne függjön a defaultoktól, mert nem szabhatod meg a lib használó alkalmazásnak, hogy pl.: a te kódod csak English localeval működik jól.

Gondolom, te sem kodolsz kliens oldalra es/vagy desktopra, hogy ezt igy ilyen egyszeruen kijelented.

Erdekes, hogy ilyesmi kijelentest csak olyan ismerosom szokott tenni, aki nem hogy usert nem latott, de meg GUI-t se kodolt nagyon.

A helyzet az, hogy inkabb a programozoknak kellene tanulniuk picit errol-arrol, meg hogy mi a helyzet a nagyvilagban es akkor nem "csak a hibak okozasara" lenne jo ez.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt mondják erre az okosok, hogy most még csak mintaaillesztést végez, de későbbiekben lehet ez majd jobb és egyre tökéletesebb.

Én csak azt nem tudom, hogy hova fog ez vezetni... Egyszerű string műveleteknél is sokezer szavas szótárakat kell majd folyamatosan feldolgoznia a rendszernek és bonyolult heurisztikával eldönteni, hogy adott nyelv adott időszakában mi hogyan helyes? Mert a magyar helyesírás is folyamatosan változik. Tegnap még egyik módon írt szó volt helyes, holnap már a másik írásmód lesz az.

Értem én, hogy ez egy jó featúra (sic!) és culture* beállítás kérdése csupán az, hogy hogyan kezelje a stringet, de miért ez a default? A gyerekeknél a Hello World programozás oktatásánál már el kezdjük majd magyarázni azt is, hogy figyeljen arra is, melyik framework melyik verzióját használja, mert mindegyiknél másképp történik a string kezelés?

Namind1, csak hirtelen ezek jutottak eszembe. Kicsit "2*2 néha 5" érzésem van az ilyen dolgokkal kapcsolatban, még ha állítólag szépen le is van dokumentálva ez a működés.

Soha nem gondoltam volna, hogy eljön az idő, amikor valamiben épp Hungerrel fogok egyetérteni... Rosszul kezdődik (nekem) ez a mai nap... :(

-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

Nem hiszem hogy bármilyen júzert zavar, ha a "Zsáklin" név a "Zyron" név elé van sortolva. Ennél sokkal nagyobb bugokkal találkozik Juli néni mindennapi számítógéphasználata (titkárnői munkája) során. ;) Az "é" oké, hogy az "e" és az "f" közt jelenjen meg, de azon legalább tényleg elég egy karaktert megnézni, nem kell még futásidőt rontva kiokoskodni, hogy az "egészség"-ben "sz" vagy "zs" van.

Az a vicc, hogy főleg GUI-t fejlesztek, amit lokalizálunk is. Ennek ellenére már eddig is rengeteget szívtunk a véletlenül rosszul használt lokalizált Java API-val :-). Nem az a bajom, hogy léteznek nyelvfüggően működő metódusok. Hanem az, hogy ezeknek implicite paramétere az aktuális default locale ahelyett, hogy át kellene adni nekik explicite.

Miért probléma ez?
* Könnyű benézni, hogy az ember lokalizált, vagy lokalizálatlan metódust akar-e. És akkor ugyanaz a kód különböző gépeken különbözően működik. Ezek nehezen lekövethető hibákat jelentenek, amik többnyire nem a fejlesztőnél jönnek elő. Hanem élesben.
* .NET-ben ritkán dolgozom. A startsWith metódus különböző nyelvekből régóta ismert, tehát minden programozó a megszokott működést fogja várni tőle. De mivel téma lett, ezért a String.StartsWith doksiját direkt megnéztem most. A culture függő működés a megjegyzések között van. És az, hogy ez mit jelent konkrétan, további olvasgatással derül csak ki! Szerintem egyáltalán nem intuitív, hogy másképp működik ez a régi jó metódus mint eddig. Tehát aki több platformon is dolgozik felváltva, az még könnyebben benézi az ilyesmit.
* Nem ér semmit a tesztelés sem, csak akkor ha _mindent_ "keresztbeszorzol" az összes lehetséges locale beállítás kombinációval. Pláne hálózati protokollok esetén jó ez, mert akkor mindkét oldalt keresztbe kell szorozni.
* Még azt mondani sem elég, hogy "legyenek tökéletesek a fejlesztők, akik a teljes API doksit fejből nyomják, és soha nem felejtik el". A hibák jelentős része ugyanis nem is a saját kódodban lesz - lásd dong0 Oracle driveres hozzászólása.
* Ahogy Hunger írta, a teljesítményre is rossz hatása van az ilyesminek. A néhány bájt nyüstölése helyett 100 különböző objektum jön képbe mindenféle interfészeken keresztül.
* Szemantikailag is kb értelmetlen ez a fajta startsWith. Ugyanis valóban lokalizált stringre felhasználó által beírt kezdeményre van értelme használni, ilyen esetekben pedig kifejezetten idegesítő az, hogy a t, ty beírásakor a találati halmaz "ugrál"
* Mennél bonyolultabb az alap API, annál kevésbé lehetséges kompatibilis alternatív implementációt készíteni - lásd Mono. (gyanúm szerint ezt az egészet a Mono ellen csinálták, és a népszerű alapkomponensekbe tettek olyan kódot, ami a mongol StartsWith nélkül elszáll :-)
* Mivel ezek a nyelvfüggő dolgok kis nyelvek esetén alig teszteltek, ezért tele szoktak lenni hibákkal. Nem jó pontenciálisan alig tesztelt kódot tenni az alap API-ba.
* A teszteletlenség és hatalmas átláthatatlan kódbázis miatt ilyen jellegű API-k még biztonsági lukakat is jelenthetnek (.NET-ben kevésbé, de nem menedzselt kódokban simán).
* Lazán idetartozik a lokalizált - de valójában a fejlesztőnek szóló - hibaüzenet esete, amit szintén tüzes-vassal kellene irtani :-). De legalább hibakódot kellene adni mellé, ami keresőbe beírva egyértelmáen azonosítja a problémát.

Miért nem lenne probléma, ha explicite meg kellene adni a locale-t?
* A legtöbb programban futás közben lehet nyelvet váltani. Tehát a programfutás alatt állandó default locale eleve értelmetlen (tudom, .NET-ben lehet thread szinten állítani). Vagy eleve egyetlen program kezel több nyelvet - pl egy többnyelvű webszerver esetén. Az ilyen jellegű programok általában explicite kezelik a nyelvek kérdését.
* Ha nem működik a nyelvesítés a felhasználói felületen valahol, azt könnyen ki lehet szűrni teszttel ellentétben a fordított esettel.

+1
Én kapásból a Pokolba küldeném azt, aki kitalálta:

— hogy a magyar nyelvben tizedesVESSZŐ legyen a szeparátor, és ne tizedesPONT (ideje volna a magyaroknak áttérni a pontra hivatalosan... normális helyeken úgyis az a kvázi-szabvány...)

— azt az IQ-negatív köcsög idiótát, aki úgy elbonyolította a magyar névsorbarendezés szabályait, hogy annak betartásához egy egész irodalmár-team kell. Micsoda baromság, hogy az ékezetes karaktereket belekeverik a nem ékezetesek közé?! Meg hogy a kettős betűk 1 karakternek számítanak a rendezésben, meg egyéb baromságok.

— Aki kitalálta, hogy ha beállítom hogy hu_HU.UTF-8, akkor azt nemcsak a betűkészletre kezdi el alkalmazni, hanem rögvest mindent átállít a fenti fa$ságokra.

— Aki azt találta ki, hogy a bájt az 8 bit, és nem minimum ennek a kétszerese.

— Aki nem rögtön (legalább...) 2 bájton kezdett el kódolni karaktereket hanem csak 1-en, holott már akkor tudhatta, hogy ebbe még az európai betűk mindegyike se fér majd bele, nemhogy a többi ABC.

— Aki az IP címeket 4 bájtosra szabványosította az elején, aztán most emiatt suck az egész világ.

— Aki olyan tapipadokkal egybeépített billentyűzeteket készít, amin minden szarra van gomb, épp csak az egér középső gombja hiányzik.

— Aki olyan, USB-ről tölthető mindenféle kütyüket gyárt, amihez aztán ad is USB kábelt, de olyat, hogy azzal tényleg csak tölteni lehet a kütyüt, de amint olyan szerkentyűhöz csatolod ami adatforgalmat is továbbítana a kábelen át, kiderül hogy arra a kábel már nem jó - holott a csatlakozója szépen rámegy arra az eszközre. De hiába, mert úgy látszik pár huzalt kispóroltak belőle.

— Minden olyan hordozható zenelejátszó gyártót, amelynek a termékei nem képesek az ogg formátum lejátszására.

És még soká sorolhatnám...

-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

> — Aki azt találta ki, hogy a bájt az 8 bit, és nem minimum ennek a kétszerese.

fogalom nélkül*

> — Aki nem rögtön (legalább...) 2 bájton kezdett el kódolni karaktereket hanem csak 1-en, holott már akkor tudhatta, hogy ebbe még az európai betűk mindegyike se fér majd bele, nemhogy a többi ABC.

fogalom nélkül**

> - Aki az IP címeket 4 bájtosra szabványosította az elején, aztán most emiatt suck az egész világ

fogalom nélkül***

> — Minden olyan hordozható zenelejátszó gyártót, amelynek a termékei nem képesek az ogg formátum lejátszására.

mert három emberért megéri

> És még soká sorolhatnám...
Inkább ne :-(

Magyarázatok:

* lehet, hogy még meg se születtél, amikor ezt kitalálták. Álom nem volt még a 16 bit se, nemhogy a 32, 64, stb.

** ez főleg úgy mókás tőled, hogy büszkén emlegeted a C64-es múltad. Lett volna ~fele annyi memóriád, ha meg UTF-8-at használtál volna, sokkal macerásabb a stringkezelés, stb.

*** végülis jó móka az akkori csekély sávszélességen 2*128 bitet továbbítani.

Inkább gondolkozz, mielőtt a pokolba küldenél bárkit is.

Árnyalva a képet (bár tényleg nincs igaza, de kicsit van).
1) A byte nem feltétlenül 8 bit, csak ez a méret terjedt el, mint minimálisan megcímezhető rész.
2) K&R tényleg benézte a "char" típust, ami ha jól tudom egyedüliként volt méretre szabványosítva a nyelvben. Ha byte-nak hívják és bevezetnek (akár typedef-fel) egy char típust és utóbbival csinálnak stringeket, ma szebb lenne a világ.

BlackY

Hol láttál 8bit-től eltérő méretű _byte_-ot? (lehet, hogy volt ilyen, én nem hallottam róla)
A szavas felépítésű gépeket ne keverd bele, mert az eleve nem byte-ot, hanem word-öt használt.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Hitvita, de pl. a Wikipedia is velem ért egyet (na meg a Daily WTF is :) ). Látni nem láttam ilyen gépet, max képen, de a byte az én értelmezésemben továbbra is az információ legkisebb címezhető része (ahogy a bit sem 1 és 0, hanem az információ egységnyi mennyisége)

BlackY

Nem hitvita, mivel nem vitatkozni akartam róla.
Hogy hol láttál, az nem azt jelenti, hogy fizikailag hol az a gép, amin láttad, nekem megfelel egy létező gép leírása is, ahol byte-nak nevezték a 8bittől eltérő méretű adattárolási egységet. :)
Mert ilyenre nem emlékszem a közelmúltból.

ui: a bit, eredetileg a BInary digiT-ből ered, tehát az egyértelműen a 0/1 tartalomra utal. :)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Pl. a PDP-10, 1-36 bit egy Byte utasítással. http://en.wikipedia.org/wiki/PDP-10
Nem is a közelmúltról írtam, a "csak ez a méret terjedt el,"-be beleértettem a befejezettséget (múlt idő ;) ).

Az ui-ra: ez történik, ha matematikus nevez el dolgokat és nem valaki (informatikus, pl.) aki képes absztrakcióban is gondolkodni :)

BlackY

"— Aki kitalálta, hogy ha beállítom hogy hu_HU.UTF-8, akkor azt nemcsak a betűkészletre kezdi el alkalmazni, hanem rögvest mindent átállít a fenti fa$ságokra."

Hat de ha locale-t allitasz es nem csak karakterkeszletet, akkor mit csodalkozol, hogy valtozik a locale is? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még jó, hogy ekkora szakember lettél...
Tudsz róla, hogy anno 64KB már soknak számított memóriában?
Biztosan merő véletlen volt, hogy egykor 7 bites karakterkészlettel dolgoztak a számítógépek. (már amelyik)

Szerencséd, hogy papírod van az elmeállapotodról. :(

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( kmARC v | 2013. 09. 13., p – 09:29 )

Próbálok konstruktívan viszonyulni ehhez a számomra új tudáshoz, mégsem megy. Segítsetek.

A stringeket "karkterlánc"-ként tanultam, minden irodalomban mint "karakterek sorozata", stb. találkoztam vele. Itt azonban az idézőjelek között szót kell érteni. Vagy mondatot.

1) Van-e lehetőség karakterláncok kezelésére, és mint ilyen (a szemantikai értelmezéstől eltekinteni), és olyan startsWith függvényt használni, ami karakterláncokon működik?
2) Hol van definiálva az, hogy mely szavak hogyan elválasztandók?

Nem szót, karaktersorozatot.
Vannak különböző nyelvek, mindnek megvan a maga ABC-je.

Pl. a magyar:

a á b c cs d dz dzs e é f g h i í j k l ly m n o ó ö ő p q(?) r s sz t ty u ú ü ű v w(?) x(?) y(?) z zs

Attól, hogy látszólag több betűből áll, még egynek számít. A ?-lel jelöltekben nem vagyok biztos, melyik tartozik a magyar ABC-hez és melyik nem.

Mindennek semmi köze az elválasztáshoz.
(illetve bizonyos esetekben, ahogy korábban már említették, mégis — pl. pácsó, őzsuta stb.)

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Azt azért tegyük hozzá, hogy vannak értelmes nyelvek, akik fenntartották az írásjel - betű(hang) 1:1 leképezést, pl. a német a dupla s-el (lusta vagyok kikeresni a tényleges karaktert). A Unicode tervezésénél nekünk is vadul kellett volna kapálózni, hogy azt a néhány két/három írásjelből álló hangunkat/betűnket vegyék fel külön írásjellé, a duplázott alakjukat meg használják ligatúraként (pl. charCode(ly)charCode(ly) renderelése lly -ként), amivel hosszabb távon megoldható lett volna rengeteg gond (lásd: rendezés, elválasztás, tényleges betűszám számítás etc.).

BlackY

Azért ezt az 1:1 megfeleltetést én megkérdezném az adott nyelveket anyanyelvi szinten ismerőktől is. ;)
Mert hogy látszólag így van, az OK, de sem az arab, sem a kínai, de még a héber esetében sem vagyok biztos benne, hogy nincsenek ilyen kis "trükkök" a nyelvben, amit nem tettek át unicode-ra. Mivel egyik nyelvet sem ismerem, csak feltételezés természetesen.

Egyébként ez az egész a magyar ABC-vel valószínűleg a mechanikus írógépekre vezethető vissza. Mivel egyszerűbb volt csak az ékezeteket hozzátenni az angol ABC-hez, mint külön, gyakorlatilag feleslegesen felvenni a dupla+dzs karaktereket.

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Az oké (billentyűzetre nem is kellene feltétlenül kivezetni), csak az Unicode már az informatika elterjedése után jelent meg, ahol az írógéppel ellentétben tényleg nem mindegy, hogy az ott egy l és utána egy y vagy egy el ipszilon; gyakorlatilag információt vesztesz, mert legfeljebb heurisztikával lehet automatizáltan különbséget tenni, az meg a fent említett putty-nál látszik, hogy edge case-kre nem jó (mondjuk ha nincs kivezetve a billzetre, akkor kb. ugyanezen heurisztikák működhetnének csak a szövegbevitelnél, úgyhogy csak egy másik árokba ástuk be magunkat, de az esély meg lenne az adatveszteség-mentes használatra).

BlackY