Van különbség a két feltétel megadás között? For- ciklus meddig fut. (c#)

Én is még csak most ismerkedek a programozással, de szerintem semmi különbség nincs a kettő közőtt, mivel a tömböd hossza a szam nevű változótól függ.

Amúgy ilyenkor ha tesztelsz akkor ki fog jönni, hogy van-e különbség. Futtasd le 3 különböző számmal és a ciklusban irasd ki mondjuk az i-t. Akkor látni fogod, hogy hányszor ment le a ciklus ;)

A for ciklust nem érdekli hogy honnan jön a feltétel, egy egyszerű intet vár. Arra viszont nem vennék mérget, hogy a tomb.Lenght gyorsabb, vagy pontosan ugyanannyi idő alatt fut le, vagy sokkal-sokkal lassabb(attól függően, hogy hogy tudja meg hogy hány elemű az tömb, ha végigiterál mindegyik elemen(listáknál ez a helyzet, tömbnél nem tudom) akkor jelentősen lassabb).

Más nyelveknél is érdemes a legtöbb esetben egy ideiglenes változóba kimenteni a végigiterálandó kollekció méretét, nyilván ilyen 5-10-100 elemnél nincs túl nagy jelentősége, de pár ezernél már meglátszik, felette meg pláne.

Hello,

Szemely szerint en mindig a tomb.Length-et hasznalom.

Nem feltetlen azert mert, gyorsabb vagy ilyenek, hanem mert igy öndokumental a kodom. Plussz a szam-ot igy felhasznalhatod barmi masra, ha szükseged van ra. Tovabba kesobb nem is nagyon fogod tudni elmenteni hogy milyen hosszu egy tomb, mert az fölös memoria, helyette CSAK a tomb.length() fog menni.

(Nemetorszag - javaEE webfejlesztö vagyok)

#4

Dehogy fölös memória, ahogy nincs rá hivatkozás felszabadul(illetve ha már elég szemét összegyűlt), ugye ez az előnye a c# nak pl c++ hoz képest - na meg azért ne viccelődjünk kérem, nem 256kb memóriával kell gazdálkodni, bőven elférne egy felesleges int, ma már egy alsó kategóriás telefonba is annyi ramot raknak mint amennyi 10 éve ment egy gamer gépbe, ha kifutsz a memóriából akkor az nem emiatt lesz.

"felszabadul(illetve ha már elég szemét összegyűlt), ugye ez az előnye a c# nak pl c++ hoz képest"

Ez inkább hátrány a RAII -val szemben.

Persze nem az pár bitnyi kicsi int fogja meghatározni a memóriát, meg persze mindenben már GB-nyi memóriák vannak.

Csakhogy manapság rá kell nézni a programokra és el lehet nyugodtan hánynia az embernek magát. Annyi fölös memóriát foglalunk le hogy az már szemtelenség. És ehhez könnyű hozzászokni, és a végén már azt lesed, hogy hopp kifutottam a keretből. Egyáltalán nem egy int ről van szó. De azért mégis érdemes hozzászokni a memória kezeléshez.

Sajnos a mai programnyelvek, programok, programozók pazarlóan bánnak az erőforrásokkal, feltételezve hogy mindenki 'modern' gépet használ. A gyakorlatban ez nincs így, láttam pár jó nagy céget ahol ezeréves masinák vannak.

Én magam egy P4 HT, 3 GHz, 3 GB Ram programozok - ez a legrosszabb gép otthon, az asszony ezerszer jobb gépen játszik - de ami ezen elfut normálisan az csak jobb lehet más gépen.

Off:

Nem vagyok tanult programozó és nem is programozóként dolgoztam, de nem egyszer előfordult a CÉG-emnél, hogy a programozók hozzám küldték az embereket, hogy ők XT-re :) nem írnak programot. Nincs ezzel semmi gond, ha tisztában vagy az erőforrásokkal és jól állítod be fordítót. Nem kevés plusz pénzt kerestem vele :)

A #2-est nem tudom mért pontoztátok le, ő írta le a tutit.

Aki nem hiszi próbálja ki. A .NET JIT compilere nem fog index checkeket végezni, ha a teljes tömbön mész végig (for (i=0;i<tomb.Length; i++)), mert tudja, hogy ebben az esetben felesleges, úgysem lesz exception. Ezért gyorsabb, ha így van írva. Ha külön változóban van a méret az ember látja, de a compilernek már nem egyértelmű, hogy ez ugyanaz, így kénytelen lefuttatni az index ellenőrzéseket.

Persze a különbség nem releváns. 200 millió(!) elemre ha int[]-ről van szó és csak összeadod a számokat, akkor 430ms vs 450ms az eredmény a tomb.Length javára az én gépemen. (átlagosan)

Persze ha ez nem csak egy tomb.Length property lenne, hanem vmi

for (int i=0; i<myenumerable.CaculateItemCountVerySlow(); i++) akkor céleszerű kitettni külön változóba.