Mi lenne, ha a gombokat gomb1, gomb2, ... néven hívnád. Így gombnyomáskor a gomb nevéből meg tudod állapítani, hogy hanyadik elem.

Én kérek elnézést!

LOL hogy ez nem jutott eszembe, pedig régen én is ezt csináltam. De ott van még a tag property is, de ha jól látom azt már valami másra használja.

Esetleg ha nem akarja átnevezni őket, akkor kacifántosabban le lehet származtatni a buttonból egy osztályt, aminek csinál egy int propertyt erre a célra, és abban tárolja, hogy hanyadik elem a tömbben, így elég azt lekérdezni.

A név szerinti keresés szerintem gyorsabb. De ha ez nem lehetséges, akkor a for helyett a foreach talán gyorsabb.

És foreachel hogy nyeri ki az indexet abban a megoldásban amit írtam? Név szerintivel nyílván működni fog, de akkor az még nem jutott eszembe.

[ Szerkesztve ]

Valahogy így:

private int hanyadikgomb(Button button)
{
int i = 0;
for each(Button elem in tomb)
{
if (button.Equals(elem)
{
return i;
}
i ++;
}
}

Ha pl egy groupbox-ot használsz amibe csak a gombok vannak, akkor így is megkapod a sorszámát a gombnak:
int sorSzam = groupBox1.Controls.IndexOf((Control)sender);
A sorrendet a gb-hez való hozzáadás fogja jelenteni. (ha kódból pakolod bele, akkor a korábbinak lesz a kisebb sorszáma, ha az összehúzogatós felületen raktad össze a gui-t, akkor fordított)

(#2002) hunfatal: folyamatosan növel egy i változót.

(#2005) emonitor: megelőztél. De ennek így mi értelme? Kell ehhez még egy plusz változó amit szintén karban kell tartanod... Ha azt kiveszed, akkor meg megkaptad a for-t.

[ Szerkesztve ]

Ez szerintem nem lesz gyorsabb, mint a sima for.

Ezt érdemes átnézni a sebességet illetően

Ez rendben van csak te bevezettél még egy i változót, itt meg nem azt csinálja.

Mondjuk gondolom én nincsen 120 000 gombja így a sebességkülönbség majdhogynem elhanyagolható és sokkal szebb a kód a sima forral, mint a plusz változóval, amit külön kell kezelni.

De egyébként az egész úgy is kuka, mert névre keres akkor sima foreach.

Te nem használsz plussz változót?
for ( int i = 0; i < tombhossz; i++)

De igen csak a ciklus végén meg is szűnik. Ellentétben a tieddel ami ottmarad a függvény végéig.

Továbbra is azt mondom hogy jelen esetben a sima for szebbé teszi a kódot és a sebességkülönbség elhanyagolható.

Persze ha 150 000 gombja van akkor más a helyzet.

[ Szerkesztve ]

int i = 0;
for each(Button elem in tomb)

Hunfatal erről beszél. (meg én is)

Értem amit mondasz.
Mondjuk Hunfatal szerintem nem erről beszélt.

tomb
és
Button elem in tomb

Mind a kettő Button-t ad vissza. Hát nem tudom...
Ha több időm lesz kipróbálom.

"A név szerinti keresés szerintem gyorsabb. De ha ez nem lehetséges, akkor a for helyett a foreach talán gyorsabb."

majd az általad linkelt cikkben:

"Therefore, I strongly feel if you are planning to write high performance code that is not for collections, use for loop. Even for collections, foreach may look handy when using, but it's not that efficient. Therefore, I strongly recommend everyone to use for loop rather than foreach at any stage."

igen, ezt en sem ertettem... mert a cikk szerint is egyertelmu a for elonye performace szempontjabol...

''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''

Mondjuk itt elég nagyvonalú, amikor collectionst említ, mikor kb. az indexerrel rendelkezőkre gondol. Mi van például egy linkedlisttel, stackkel, queue-val for esetén.. Én nem állnék neki kézzel iterálni ezeket, inkább foreach / getEnumerator, többet ér egy olvasható kód, mint 10 milliszekundum.
Fordítva is igaz, ha index is kell, akkor meg inkább for, ha van indexere a típusnak, ha meg nincs, úgyis csúnya lesz.

Thank you to god for making me an atheist

Volt egy kis időm, így sikerült leellenőriznem. Pont az ellenkezője jött ki, mint amire számítottam. Az eltérés -3 / +3 % volt a 2 között. A foreach azonban kis méretű tömbnél és/vagy kevés hívás esetén volt gyorsabb, nagy méretű tömb és/vagy sokszori hívás esetén pedig a for volt gyorsabb. Az eltérés azonban mindkét esetben minimális volt. Mondjuk 1 millós tömb és 1000-szeri meghívás esetén 0,4 másodperc volt az eltérés a for javára.

shev7 és -Zeratul- : igazatok van, ezt benéztem.

Mindenesetre az is érdekes, hogy az equals itt is csak akkor haszálható, ha előtte "=" (tehát értékadással) lett a 2 button egyenlővé téve.

Ha már így tesztelgetsz.

for ciklusban itt is a ++i gyorsabb mint az i++, mint C++ban? Nincs kedved megnézni?

Ha már így tesztelgetsz

Tudod, én szeretem az objektív dolgokat, és ha valamiben nincs igazam, akkor azt beismerem, ellentétben egyesekkel.

Mikor állítottam, hogy ++i lassabb, mint i++?

Jó, csak, hogy objektív eredményt kapjak, ahhoz elég sok folyamatot le kell állítani.
Az előző tesztnél is 1 milló Button-nál a lapozófájl mérete 406 milló bájttal növekedett és a teszt alatt a proci 100%-on ment.

De azért ezt is leteszteltem.
void ciklus0()
{
int i = 0;
i++;
}

void ciklus1()
{
int i = 0;
++i;
}
Ezeket hívtam meg 100 millószor. Az eredmény:
120,815924676848 sec. a ciklus0-ra és
120,841825454048 sec a ciklus1-re
az eltérés 0,020 %, tehát nagyon minimális.
Egyébként a tesztelő programot elteszem, mert még máskor is jól jöhet, de mondjuk sűrűn nem használom a proci terhelése miatt.

Ezekszerint az i++ minimálisan, de gyorsabb. Meglepő.

Köszi a tesztet

[ Szerkesztve ]

A minimális eltérés miatt azonban nem merném kijelenteni, hogy ez szignifikáns eredmény, inkább az a valószínűbb, hogy azonos sebességűnek tekinthetők.
Nem lehet, hogy fordításnál ugyanúgy fordítja?

Jó volt a meglátásom. Megnéztem assembly-ben a kódokat. Íme:

A ciklus0(); :

.method private hidebysig instance void ciklus0() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] int32 i)
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: ldc.i4.1
IL_0005: add
IL_0006: stloc.0
IL_0007: ret
} // end of method Form1::ciklus0

A ciklus1(); :

.method private hidebysig instance void ciklus1() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] int32 i)
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: ldc.i4.1
IL_0005: add
IL_0006: stloc.0
IL_0007: ret
} // end of method Form1::ciklus1

Ezekszerint mindegy. Köszi a részletes elemzést.

De ha már itt tartunk: A foreach 16 bájttal hosszabb, mint a for.

csak hogy kötözködjek egy picit

static void Main(string[] args)
{
long a;

long start1 = DateTime.Now.Ticks;

for (long i = 0; i < 20000000000;)
a = i++;

DateTime dt = new DateTime(DateTime.Now.Ticks - start1);
Console.WriteLine("i++ : {0} sec, {1} ticks", dt.Second, dt.Ticks);

long start2 = DateTime.Now.Ticks;

for (long i = 0; i < 20000000000; )
a = ++i;

dt = new DateTime(DateTime.Now.Ticks - start2);
Console.WriteLine("++i : {0} sec, {1} ticks", dt.Second, dt.Ticks);
Console.ReadLine();
}

i++ : 51 sec, 519749728 ticks
++i : 49 sec, 492008142 ticks

i++ : 52 sec, 521009800 ticks
++i : 49 sec, 492998197 ticks

i++ : 52 sec, 520389764 ticks
++i : 49 sec, 493708238 ticks

akárhányszor futtatom, megvan a 2,6-2,7 mp körüli különbség

a másodiknál assembly-ben kevesebb a mov

[ Szerkesztve ]

Na jó, de ez nem csak assemblyben különbözik, hanem "a"-ra nézve a kimenet is más.

A ciklusváltozó szempontjából ment a vizsgálat, hogy az i++ vagy a ++i a gyorsabb, tehát az 'a' értéke a fentiek miatt lényegtelen. De ha zavar, a kód végére írsz egy --a-t.

Tudom, azért van ott a mosolygós bábu. Erre reagáltam:
csak hogy kötözködjek egy picit

Sziasztok!
Azt szeretném kérdezni, hogy a Visual Studio 2010. Professional változatot hány gépen tudom használni, ha megvásárolom?

hali.

Idézet az EULA-ból:

[...]
1. OVERVIEW.

a. Software. The software includes development tools, software programs and documentation.

b. License Model. The software is licensed on a per user basis.

2. INSTALLATION AND USE RIGHTS.

a. General. One user may install and use copies of the software to design, develop, test and demonstrate your programs. You may not use the software on a server in a production environment.
[...]

Ebből én azt szűröm le, hogy szerver gépet leszámítva akárhány gép(ed)re felinstallálhatod, de csak te használhatod értelemszerűen.

[ Szerkesztve ]

Thank you to god for making me an atheist

Oké, köszönöm szépen.

Az EULA alapján userhez van kötve (1db), nem géphez.

azért mielőtt elrohansz megvásárolni, én a helyedben megnézném a webspark és a bizspark lehetőségeket.
Ha pedig egyikbe sem esel bele, akkor érdemes e-bay-en venni fillérekért egy kósza 2008-as licenszet, és azt upgradelni 2010-re.

Én kérek elnézést!

Ha már így license kérdések vannak, akkor a VSProwMSDN ALNG LicSAPk OLP NL Qlfd esetén miket rakhatok fel? Kimondottan az Expression blend érdekelne.. vagy ezt is meg kell venni?

“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”

A rövidítéseid poénok akartak lenni? Mindenesetre az Expression Blend külön fizetős

Én kérek elnézést!

Ha csak a microsoft is annak szánta.

De talán ez választ adott rá.

[ Szerkesztve ]

“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”

Kellene egy olyan program ami nagy négyzetbe optimálisan el tudna helyezni adatbázisban szereplő kis négyzeteket. A programot C++ ban kellene megírni.
Akit érdekel a téma keressen meg.
Ha nem jó helyre írtam bocsánat, és kérnék egy tippet hol van ennek a kérésnek helye.

Szerintem ide illik talán.

“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”

Először is köszi a választ.

Nem meggyőzni akartalak csak a problémára megoldási javaslatot Sajna nem mondhatom meg egy cégnek sem, hogy holnaptól sql servert vagy éppen orclet használjon, még csak azt sem hogy ezek melyik verzióját. Legtöbb helyen SQL server 2000 van és nem is tervezik hogy más verzió bevezetését.

Nem egy cégnél van 2 fajta adatbázis hanem cégenként eltérő. Nem én találtam ki ezt a megoldást, csak örököltem a problémát.

Bocs hogy nem fogalmaztam egyértelműen, szép napot.

Alkimista

így igaz

Alkimista

Sziasztok! Lenne egy nagyon egyszerű kérdésem az objektumokkal kapcsolatban.
Legyen egy világ, benne sok objektummal, a példa kedvéért legyenek ők mondjuk "Emberek". Ezek az emberek élik a saját kis életüket, most random sétálgatnak. Mondjuk jelenítsük meg a helyzetüket egy konzol ablakban, de ez a feladat szempontjából igazából most lényegtelen.
A kérdés: Hogy lehet elegánsan megoldani azt, hogy ugyanarra a koordinátára ne léphessen két "ember"? Tehát, ha mondjuk a (13;14) ponton van már egy objektum, akkor lépjen máshova.

Létrehozáskor végigmész a tömbön/listán, amiben a többi objektum van és ellenőrzöd.

[ Szerkesztve ]

csinálsz egy kétdimenziós boolean tömböt, amiben nyilvántartod, hogy melyik objektum, éppen hol van. Ahol van, azt 1-el jelölöd, ahol senki nincs azt nullával. Amikor átlép az objektum egyik mezőről a másikra, akkor ellenőrzöd az ütközést, átfrissíted a tömb két elemét.

Én kérek elnézést!

Annyit fűznék csak hozzá, hogy minden ilyen esetben a probléma a sparse array problémája. Legjobban olvasható megoldás a 2 dimenzió look-up tömb használata (ahol az indexek a koordináták és az elemek az emberek sorszáma), de ha nagy a világ és kevés benne az ember, akkor list-be illik felfűzni az emberek sorszámát és aktuális pozíciójukat tároló object-eket, majd a listát bejárva azt frissítgetni.

''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''