C# forritun ToUpper vandræði

[thorgeiro]

Regular expression FTW!

string name = Console.ReadLine();
name = (new Regex("(^.)|( .)")).Replace(name.ToLower(), new MatchEvaluator(match => match.Value.ToUpper()));

[SteiniP]

Loks. Þetta með að strengir séu ekki breytanlegir. Er það til að styðja þræði (threads)? Að þá þurfi ekki að læsa þessum "smá" breytum/klössum þegar unnið er með þá í þráðum. Vekur samt upp spurningar hjá mér hvort ekki sé hægt að búa til "static" ( breytur af strengum í C#

Strengir hafa verið immutable í flestum forritunarmálum sem ég hef notað, en er svo sem ekki klár á ástæðunni fyrir því. Myndi halda að það hafi eitthvað með minnisnotkun að gera. Hver stafur tekur X mörg byte eftir hvaða encoding þú ert að nota og strengurinn fær bara úthlutað akkúrat þeirri stærð sem hann þarf þegar hann er búinn til, þannig geta stafirnir verið í beinni röð í minni.
Ef að strengir væru mutable þá þyrfti:
1. Hver char að fá úthlutað hámarksstærð sem að stafur getur tekið
2. Hver char að vera geymdur í minnisaddressu sem að er ekki endilega í beinni röð m.v. stafina á undan.
Sem að leiðir til þess að mikið auka minni er notað til einskis og strengja aðgerðir verða hægari.

En C# er jú nánast algjörlega OOP og klassadrifið, enda mikið byggt á java.

[Garri]

Þú ert þá að tala um unicode

Ég er enn að nota Delphi 7 sem er ekki með unicode og þar er breytan strengur alveg eins og array of char, það er, 8-bita út í gegn. Ekki klassi, ekki reference breyta, heldur hrein og bein breyta a la old style sem þess vegna er hægt að "hakka" að vild.

Hef ekki kynnt mér þetta í Delphi XE2 en það litla sem ég hef rekist á sýnist mér leyfa breytingar á unicode strengjum til jafns á við venjulega, það er breyta hvaða stökum í minnishóflum breytunar. Það eru notuð stýritákn 195, 196 osfv. til að auðkenna sub-töflur, næsta bæt fyrir aftan er þá nýja sub-byte eða unikóðinn. Edit: Sá þetta hjá Embarcadero, "Note: Delphi also supports UnicodeString, but implements it as a primitive type rather than a class. By default, variables declared as type String are UnicodeString. "

Getur verið að strengir séu svona í C# út af garbage collection?

[codec]

Þetta er nú bara til að flækja málin fyrir honum.
Þar sem hann þyrfti að geta skilið kóðann sem hann á að skila þá bendi ég á núbbavæna lausn mína hér

Ég get alveg tekið undir þetta að hluta, allavega hvað einfaldleikan varðar.

Eina "vandamálið" við þessa lausn hjá JoaKulp er að það er sífellt verið að búa til nýja strengi, af þeirri ástæðu sem áður var nefnd. Það þurfa menn að hafa í huga ef verið er að loopa og breyta strengum sérstaklega ef lengdin er breytileg.
Það breytir ekki öllu ef fjöldin er lítill en þetta fer að telja þegar ítranir eru margar og strengir lengri.

Þetta skiptir svo sem ekki öllu máli í þessu tilfelli en ef t.d. menn eru að eiga við stærri strengi t.d. væri verið að lesa inn úr skrá eða eitthvað því um líkt þá getur maður lent í vandræðum og því mikilvægt að vita af þessu.
Muna bara líka að ef þú notar StringBuilder að nota capacity (sett í smiðun þegar hann er frumstilltur) það bætir perfromance á honum umtalsvert.

dæmi um nokkrar lausnir sem hafa komið fram hér, ath listinn er hvorki tæmandi né fullkomin , þessu var bara hent upp í fljótheitum bara til að sýna fram ákveðið mynstur:
Fyrst keyrt 1 sinni.
Sláðu inn nafn:
test nafn
Testing with 1 iterations
19.03.2012 19:05:31 TitleCapsStringHagur() time: 1014
19.03.2012 19:05:31 TitleCapsStringBuilder() time: 906
19.03.2012 19:05:31 RexEx() time: 1979
19.03.2012 19:05:31 JoiKulp() time: 666

og svo ef ég spæsi nafninu saman 50 sinnum fyrir keyrstlu, til að bara til að prófa útkomuna ef um er að ræða lengri streng.
Sláðu inn nafn:
test nafn
Testing with 50 iterations
19.03.2012 19:04:45 TitleCapsStringHagur() time: 1032
19.03.2012 19:04:45 TitleCapsStringBuilder() time: 974
19.03.2012 19:04:45 RexEx() time: 2470
19.03.2012 19:04:45 JoiKulp() time: 1033

Sláðu inn nafn:
test nafn
Testing with 1000 iterations
19.03.2012 19:20:25 TitleCapsStringHagur() time: 1972
19.03.2012 19:20:25 TitleCapsStringBuilder() time: 2030
19.03.2012 19:20:25 RexEx() time: 10491
19.03.2012 19:20:25 JoiKulp() time: 50133

Það sést hér vel að lausn JoaKlup er hröðust með litla strengi en ef þeim fjölgar þá vesnar í því, stringbuilder lausnin og lausn Hags halda sínu striki nokkuð vel.
RexEx geta verið öflugar og þægilegar til að gera flóknari hluti með texta en performa ekki alltaf eins vel.

þessi mynd skýrir þetta kannski betur.

[Posus]

@Posus

Í hvaða skóla ertu að gera þetta verkefni?

Tækniskólanum

[hagur]

Ég get alveg tekið undir þetta að hluta, allavega hvað einfaldleikan varðar.

- Kúl samanburður -

Vel gert, gaman að sjá þennan samanburð á mismunandi úrlausnum

Það er mjög hollt að hafa performance í huga strax frá byrjun og hugsa alltaf um worst case scenario, "hvað gerist ef kóðinn minn þarf að keyra á gagnasett sem er 10000x stærra en það sem ég er að þróa á móti núna?". Oft hefur maður brennt sig á því að gera það ekki og skrifað eitthvað sem skalast hræðilega illa

[coldcut]

Af hverju í fjandanum er Tækniskólinn að kenna C#?

Af hverju ekki Java/C++/C og Python/PHP/Ruby/Perl? Er þetta e-ð samningsdæmi við M$ eða bara asnaskapur í kennurum/stjórnendum?

Er ekki að reyna að hræra upp neinu OS-wari hérna en væri gaman að vita ástæðuna...

[hagur]

Af hverju í fjandanum er Tækniskólinn að kenna C#?

Af hverju ekki Java/C++/C og Python/PHP/Ruby/Perl? Er þetta e-ð samningsdæmi við M$ eða bara asnaskapur í kennurum/stjórnendum?

Er ekki að reyna að hræra upp neinu OS-wari hérna en væri gaman að vita ástæðuna...

Hvað er svona slæmt við C#? (Fyrir utan að vera frá MS, ég veit að þú ert ekki beint MS fan #1).

Annars skiptir forritunarmálið í sjálfu sér litlu máli þegar verið er að kenna forritun. Forritunarmálið sjálft er bara verkfæri í verkfærakassanum.

[coldcut]

Hvað er svona slæmt við C#? (Fyrir utan að vera frá MS, ég veit að þú ert ekki beint MS fan #1).

Annars skiptir forritunarmálið í sjálfu sér litlu máli þegar verið er að kenna forritun. Forritunarmálið sjálft er bara verkfæri í verkfærakassanum.

Alveg sammála því en ég skil bara ekki af hverju þeir kenna ekki frekar "opið" forritunarmál. Ég hef sjálfur þurft að forrita í C# í HÍ og það var fínt (Mono virkar ágætlega).

[Frantic]

Af hverju í fjandanum er Tækniskólinn að kenna C#?

Af hverju ekki Java/C++/C og Python/PHP/Ruby/Perl? Er þetta e-ð samningsdæmi við M$ eða bara asnaskapur í kennurum/stjórnendum?

Er ekki að reyna að hræra upp neinu OS-wari hérna en væri gaman að vita ástæðuna...

Ég veit til þess að þeir eru að kenna PHP og Python svo var einhver fyrirlestur fyrir nokkru síðan um Ruby.
Þetta er allt búið að breytast svo mikið á svo stuttum tíma.
Gæti vel verið að þeir séu byrjaðir að kenna fleiri mál.

[codec]

Af hverju í fjandanum er Tækniskólinn að kenna C#?

Af hverju ekki Java/C++/C og Python/PHP/Ruby/Perl? Er þetta e-ð samningsdæmi við M$ eða bara asnaskapur í kennurum/stjórnendum?

Er ekki að reyna að hræra upp neinu OS-wari hérna en væri gaman að vita ástæðuna...

Ég veit það ekki. C# er allvega mjög gott forritunarmál og sjálfsagt ekkert að því að nota það í kennslu. C# er var hannað af Anders Hejlsberg miklum snillingi sem hannaði einnig turbo-pascal og delphi (allavega einn af aðal mönnunum í því).

Ég held að það sé ekkert mjög mikill munur á c# og java hvað varðar hversu opið þau eru, svona þannig lagað. Oracle á Java og Microsoft c#.
C# er staðlað af ECMA og ég verð að segja að xamarin eru að gera mjög spennandi hluti með c# og mono projectið.
T.d. getur þú forritað í c# cross-platform apps t.d. fyrir android og iphone ofl. með þeirra lausnum. Þeir eru einnig með "compiler as a service" sem er mjög áhugavert.

Það er til fullt af open source c# og .net projectum og bara ég verð bara að segja það virðist vera töluverð gróska í kringum open source hjá Microsoft þessi misserin.
350.000+ open source project segja þeir hér http://www.microsoft.com/en-us/openness ... .aspx#home
Ég held að þetta M$ hatur sé að verða svolítið gamalt og out-dated.

[coldcut]

Ég held að þetta M$ hatur sé að verða svolítið gamalt og out-dated.

ókei ég nenni ekki OS-war þræði. En fyrir mína parta...á meðan M$ heldur stýrikerfinu closed source og einbeitir sér meira að því að vera bullies heldur en tæknifrömuðir þá mun mér vera illa við þá. Vona svo innilega að Ballmer fari að hverfa og að einhver ungur og klár tæknimaður taki við. M$ er meira lögfræðistofa heldur en tæknifyrirtæki...

En hefur það e-ð að gera með M$ að það séu til fullt af open-source C# projectum? Það held ég ekki...

Að mínu mati á að kenna þeim sem eru að byrja í tölvunarfræði-tengdu námi á scripting-forritunarmál. Mín reynsla er allavegana sú að þegar þú ert að byrja þá ertu mikið mun fljótari að sjá árangur og fljótari að "gera eitthvað" í scripting-málunum. Java/C/C++ ættu svo að koma seinna og svo enn seinna ættu að koma haskell/caml/scheme/and_whatever...

P.S. plís hættum að tala um OS því þau koma þessu ekkert við. Varð bara að svara því sem codec sagði

[codec]

fair enough, þetta eru allt bara verkfæri fyrir mér, maður notar það sem hentar hverju sinni.

[coldcut]

fair enough, þetta eru allt bara verkfæri fyrir mér, maður notar það sem hentar hverju sinni.

já vissulega. En nú eruð þið nokkrir hérna sem skrifið mikið í C#, segjið mér eitt. Í hvað hentar C# sérstaklega vel? Og af hverju hentar það betur?

[Arnarr]

Af hverju í fjandanum er Tækniskólinn að kenna C#?

Af hverju ekki Java/C++/C og Python/PHP/Ruby/Perl? Er þetta e-ð samningsdæmi við M$ eða bara asnaskapur í kennurum/stjórnendum?

Er ekki að reyna að hræra upp neinu OS-wari hérna en væri gaman að vita ástæðuna...

Ég er í Tækniskólanum og ég er að læra c++

[codec]

fair enough, þetta eru allt bara verkfæri fyrir mér, maður notar það sem hentar hverju sinni.

já vissulega. En nú eruð þið nokkrir hérna sem skrifið mikið í C#, segjið mér eitt. Í hvað hentar C# sérstaklega vel? Og af hverju hentar það betur?

ja, oft getur maður valið en stundum ekki, verkefnin ráð því.

Það er til ein þumalputta regla, sem er ágæt, hún er sú að velja alltaf highest level mál sem samt gefur ásættanlegt performance og öryggi. Málið er að c og c++ eru það sem sumir forritarar kalla unsafe, það er þau geta verið viðkvæm fyrir array og buffer overflow og minnis vandamálum. Á móti kemur skila þau oftast mesta performance. Það eru einnig margir sem telja erfiðara og dýrara að viðhalda miklum code base í c og c++. Þú ert oft mikil fljótari að koma product í loftið með c# eða java heldur en c eða c++.

C# er elegant, einfalt, type-safe og hlutbundið mál sem mörgum líkar að vinna í. Það er með ríkulegu library og í virkri þróun. Það er einnig til nokkuð mikið af forriturum sem kunna málið og aðrir eru oftast nokkuð fljótir að koma sér inn í það. Þannig að mannauðurinn/þekkingarpollurinn sem hægt er að sækja í er nokkuð stór. Einnig bjóða c# og java cross-platform þróun, í það minnsta að ákveðnu marki (sjá t.d. mono project).
Oft standa menn þá frammi fyrir því að velja á milli t.d. java eða c# sem hafa svipaða kosti og galla, í raun er ekki neitt gífurlegur munur á málunum sjálfum.

Ef performance skiptir öllu og að vera nálægt vélbúnaði þá er c/c++ málið.
Ef þú er að gera vefviðmót þá er javascript nánast defacto standard.

[hagur]

What he said ---^^

[Daz]

Annars hef ég alltaf verið á móti C, forritaði í því fyrir c.a. 25 árum og einmitt ein af þeim ástæðum að ég er á móti C er sú gegnheila heimska að byrja að telja í 0

Varla til minni rökhyggja en að byggja heilt forritunarmál sem gengur út á rökhyggju á jafn mikilli ó-rökhyggju.

Það er nú ekkert einskorðað við C að byrja að telja í 0. Ég myndi halda að það séu til fín rök fyrir að byrja að telja í 0 (nota allt integer sviðið??)
Annars virkar fínt að byrja í 0 þegar maður getur notað hluti eins og

Kóði: Velja allt

count < length(someArr)

Mun leiðinlegra þegar maður þarf að gera

Kóði: Velja allt

substr(str,varX,length(str)-1)

[Garri]

Sælir

Þið fáið mig ekki af því að finnast þetta heimskulegt og til vansa, til þess er ég bara búinn að forrita of mikið eða frá um 1980 og þá í vélamáli

Og trúðu mér ég skil afhverju menn byrjuðu á þessu en trúðu mér líka, ég veit að hvert smáatriði sem eykur flækjustig, veltur upp á sig í kostnaði, tíma og ekki síst, gæðum forrits.

Það er hægt að leysa þetta (count < length(someArr) ) á í það minsta tvo vegu þar sem byrjað er á 1, til dæmis, (count <= length(someArr)) og síðan sem ég mæli ekki með upp á lesanleika (not (count > length(someArr)))

En það er einmitt lesanleiki sem ég legg mest upp úr í forritunarmáli, ekki mega söfn sem ég get kóparað inn í minn eigin kóða.

Ég verð þessa galla áskynja mikið í dag þar sem ég nota meðal annars API og dynamisk array mikið og þau byrja öll í 0.

Til dæmis síðast í gær var ég að forrita smá varðandi virtual buffer á bak við visual grid. Þetta visual grid var með efstu röðina fixed þannig að fyrsta eiginlega línana var 1 sem ég kann extra vel við, virtual bufferinn sem geymdi ítarlegri upplýsingar á bak við visual línuna, byrjaði hinsvegar í 0. Nú, ég var að integrera fítusinn að bæta inn línu inn í þetta módel. Ef ég hefði haft þann munað að hafa 1:1 þá er ég þess fullviss að ég hefði verið í það minnsta tvöfalt fljótari að forrita þetta (kannski 5 mín í stað 10mín) og að sama skapi veit ég að í framtíðinni þá þarf ég meiri tíma til að skilja kóðan ef þarf bara vegna þessa atriðis eins og sér.

Hér er kóðinn með örfáum kommentum (ekki merkilegur kóði á einn né neinn hátt en gefur nasasjón af hvað við er að eiga þegar byrjað er á 0 annarsvegar og 1 hinsvegar ):

Kóði: Velja allt

PROCEDURE Ny_Lina_RHref (Obj_Buffer : TWincontrol; W_Row : WORD);
  VAR
    i         : INTEGER;
BEGIN

  // Ég tæp-kasta klassaskilgreiningunni yfir pointerinn í objectinu af almennu visual týpunni WinControl, finnst það lesanlegra
  WITH Obj_Buffer AS TBuffGrid DO
  BEGIN
    //Arr_RBuff er virtual dynamic array innbyggt í VCL klassann TStringGrid sem ég extenderaði
    IF (Length(Arr_RBuff) >= W_Row) THEN
    BEGIN
     //Editorar eru overlay object yfir grid sellur í gridi
      Loka_Editorum(Col, Row); 

      //Stækka dynamic arrayið
      SetLength(Arr_RBuff, Length(Arr_RBuff) + 1);

     // Hér þurfti ég að staldra smá við. W_Row er Pos arr + 1
     // Þurfti bæði að íhuga hvar ég átti að byrja og enda þar sem length(arr) er ekki á sama basa og W_Row
     // Spreytið ykkur á þessu verkefni í huganum, þá skiljið þið betur við hvað ég á

      FOR i := Length(Arr_RBuff) - 1 DOWNTO W_Row DO
      BEGIN
        Arr_RBuff [i]   := Arr_RBuff[i - 1];
        Rows [i+1]       := Rows [i];
      END;

      Hreinsa_Editora;

      FillChar (Arr_RBuff[W_Row-1], SizeOf(Arr_RBuff[W_Row-1]), #0);
      Rows [W_Row].Clear;

      WITH Obj_Sameign DO
        Numera (Obj_Reikhref);
    END;
  END;

  WITH Obj_Sameign DO
     Uppreikna_Reikning (Obj_Reikn, Obj_Buffer);
END;
{****************************************************************}


Edit: Það fyndna við þetta dæmi er að ég fann villu þegar ég setti það inn núna áðan og las það yfir. Ég gleymdi að hafa W_Row - 1 í brutal Fillchar skipuninni á dyn array-inu, lifandi sönnun þess hvernig lítið atriði getur oltið auðveldlega upp á sig og feitletrar það sem ég er að segja varðandi þetta atriði enn frekar.

[Daz]

Ég skil svosem ekki Delphi kóða, sem sést nú best á því að ég skil kóðann

Kóði: Velja allt

      FOR i := Length(Arr_RBuff) - 1 DOWNTO W_Row DO
      BEGIN
        Arr_RBuff [i]   := Arr_RBuff[i - 1];
        Rows [i+1]       := Rows [i];
      END;


Þannig að það séu sömu value sett í öll gildi í þessum 2 arrays.


Hins vegar myndi ég nú segja að vandamálið þarna sé ekki að þú sért með array sem byrjar á 0, heldur að þú sért með tvö array sem byrja ekki á sama stað. Mér finnst einmitt ósamræmi miklu miklu verra en að þurfa að byrja á 0. Ég vinn t.d. stundum með umhverfi þar sem til er fallið substr(x,y,z). Það tekur 3 input, streng, upphafsstað og fjölda stafa sem á að klippa. S.s. substr('DRASL',0,2) = 'DR'
Það sem er furðulegt er að í þessu umhverfi er þetta jafngilt.
substr(varX,0,1) == substr(varX,1,1)
Þetta finnst mér fáránlegt ósamræmi.

[Garri]

Þannig að það séu sömu value sett í öll gildi í þessum 2 arrays.

Ha nei.. alls ekki.

Það er verið að setja inn nýja tóma línu. Annað arrayið er það sem sést (visual) í gridi hitt er array sem er á bak við og er ósýnilegt (virtual)

Bæði Array-in þurfa að sínka og þessi rútína gerir það.

Og þessi rútína yrði mun einfaldari bæði við hönnun og lestrar ef array-in byrjuðu á 1

Kóði: Velja allt

     
      SetLength(Arr_RBuff, Length(Arr_RBuff) + 1);  //Tómri línu bætt við array-ið

      FOR i := Length(Arr_ABuff) DOWNTO W_Row + 1 DO  //Þessi lína segir mér að i byrjar aftast í arrayinu og endar í línunni fyrir ofan W_Row
      BEGIN
        Arr_ABuff^[i]    := Arr_ABuff [i - 1];  // í fyrsta skipti fær aftasta línan gildið í línunni á undan, svo koll af kolli
        Rows [i]         := Rows [i - 1];       // Sama hér
      END;

Og varðandi þessa subst rútínu þá hefði haldið að það sé einfaldlega villa í henni, annars getur þú ekki afritað stak númer tvö út osfv.

[hagur]

Ha nei.. alls ekki.

Það er verið að setja inn nýja tóma línu. Annað arrayið er það sem sést (visual) í gridi hitt er array sem er á bak við og er ósýnilegt (virtual)

Bæði Array-in þurfa að sínka og þessi rútína gerir það.

Og þessi rútína yrði mun einfaldari bæði við hönnun og lestrar ef array-in byrjuðu á 1

Og varðandi þessa subst rútínu þá hefði haldið að það sé einfaldlega villa í henni, annars getur þú ekki afritað stak númer tvö út osfv.

Já, eða ef þau byrjuðu bara bæði á 0



Sorrí, bara varð

[Garri]

Hér eru screen shot úr forritinu sem notaði þessar rútínur

mynd01.png (85.95 KiB) Skoðað 4468 sinnum

mynd02.png (84.74 KiB) Skoðað 4468 sinnum

[Garri]

Málið er að öll rökhugsun grundvallast á að telja frá einum, það telur enginn frá 0

Og í leiðinni verður fjöldi staka jafnt og endastak þegar byrjað er á 1

Og þegar við drögum 1 frá fyrsta staki, þá fáum við 0 en ekki einhverja risa tölu eftir stærð breytu (invertar bitunum í 1 sem og sign bitanum) sem einmitt gerðist í þessu dæmi skólapiltsins.

Eitt dæmi af mörgum:

Ef ég rita skipunina, teldu frá 0 upp í fyrsta stak - 1 fyrir 16 bita int breytu, þá mundi þýðandinn væntanlega umsnúa þessu í 0 til 65536 ef stak 1 er 0 (offset er aldrei neikvætt) ef stak 1 er 0 og lúppan mundi framkvæma +65k aðgerðir út um allt minni eða koma með villu ef hann er stilltur þannig.

Ef ég rita sömu skipun frá 1 upp í fyrsta stak - 1 út frá sömu forsendum, þá mundi þýðandinn væntanlega umsnúa þessu í 1 til 0 ef stak 1 er 0 og lúppan mundi ekkert framkvæma sem er 100% rökrétt.

Það er nokkuð örugglega hægt að telja fram miklu fleiri dæmi eða rök sem mundi útskýra þetta. Þetta er stór mínús á forritunarmálum og fyrir alla verkfræði í forritun.

[codec]

Ég held að maður lendi helst í vandræðum ef hlutir eru gerðir á svona mismunandi máta eins og Garri lenti í, einn telur frá 0 hinn frá 1 og þess háttar.

Varðandi rök Garra fyrir því að byrja á einum þá hef ég allavega vanist því að nota 0 enda er það notað í flestum þeim málum og forritasöfnum sem ég hef notað í gegnum tíðina. Sumar array aðgerðir geta orðið flóknar ef maður byrjar á 1, en allavega þá held ég að þessi venja að telja frá 0 eigi sér upphaf í stræðfræði.
Hér eru ágætar umræður um þetta http://programmers.stackexchange.com/questions/110804/why-are-zero-based-arrays-the-norm

Ég get ekki komið með betri rök en Edsger W. Dijkstra læt hann því eiga loka orðin frá mér um þetta mál.
http://www.cs.utexas.edu/users/EWD/tran ... WD831.html