Új hozzászólás Aktív témák
-
#90999040
törölt tag
-
#90999040
törölt tag
válasz Vasinger! #1899 üzenetére
Ezzel addig tudok beírni neveket, amekkora méretű tömböt hozok létre, ha eléri a megadott számot lefagy, nem pedig leáll.
Ez a gondolkodás eddig jó.
Most gondolatban cseréld ki a 0-t 49-re. Akkor nem fagy le a program? És ha lefagy, akkor miért? Nem a rossz feltétel miatt?
-
#90999040
törölt tag
válasz Vasinger! #1903 üzenetére
Szintaktikai tudás bővítéséhez egy link
De a probléma amint látom nem csak a szintaktika hiányából áll. Próbáld átgondolni, hogy mi a különbség az egyes logikai elemek között, és ebben a példában melyiket kellene használni és miért?
-
#90999040
törölt tag
válasz Vasinger! #1905 üzenetére
A #1884 kérdésedben ezt írtad:
Addig kérünk be stringeket/neveket, ímg üres string nem lesz vagy elérjük az 50-et.Ezt próbáld szem előtt tartani. A konkrét feladatra lefordítva a ciklus addig tart:
1.: amíg nem üres stringet ütünk be
ÉS
2.: 50-nél kevesebbszer kértünk be stringetÍgy bármelyik feltétel "HAMIS"-sá válik, akkor a ciklus befejeződik.
Miért kellene VAGY-ot használni??
-
#90999040
törölt tag
válasz martonx #1925 üzenetére
Eddig én ezt használtam, de amit Te ajánlottál, úgy látom, mintha részletesebb lenne(bár még csak éppen belenéztem).
Az alapokat azonban mindegyik tartalmazza. -
#90999040
törölt tag
válasz prog1000 #1938 üzenetére
abszolut kezdő vagyok
Ez pontosan mit jelent? Egy működő projectet sem készítettél még(pl. "Helló világ!"), sem consoleapplication-be, sem windowsapplication-be? Vagy ezen azért már túljutottál? Ez az első nyelv, amit tanulsz, vagy más nyelvben van tapasztalatod, csak a szintaktikával van gondod. Azért ezekről írhatnál valamit, mert így szerintem csak tapogatózni tudunk, de igazából segíteni nem -
#90999040
törölt tag
válasz kingabo #1967 üzenetére
Útvonalat valóban nem, de 2 Image-t össze tud hasonlítani, hogy pontosan egyeznek-e.
Persze kivétel például a "this.BackgroundImage", mert ide amikor betölti, akkor az eredeti képből vagy levág, vagy többszörözi, hogy kitöltse a méretet. Így ez sosem fog megegyezni az eredeti képpel.
Egyébként minden további nélkül meg lehet nézni, hogy 2 Image teljesen azonos-e. -
#90999040
törölt tag
-
#90999040
törölt tag
válasz kingabo #1973 üzenetére
Az az igazság, hogy én is csak "Memóriafaló" megoldással tudtam megoldani.
bool Imageegyezike(Image kep1, Image kep2)
{
System.IO.MemoryStream ms1 = new System.IO.MemoryStream();
kep1.Save(ms1, System.Drawing.Imaging.ImageFormat.Png);
System.IO.MemoryStream ms2 = new System.IO.MemoryStream();
kep2.Save(ms2, System.Drawing.Imaging.ImageFormat.Png);
int i = 0;
int j = 0;
System.IO.BinaryReader br1 = new System.IO.BinaryReader(ms1);
System.IO.BinaryReader br2 = new System.IO.BinaryReader(ms2);
br1.BaseStream.Seek(0, System.IO.SeekOrigin.Begin);
br1.BaseStream.Seek(0, System.IO.SeekOrigin.Current);
br2.BaseStream.Seek(0, System.IO.SeekOrigin.Begin);
br2.BaseStream.Seek(0, System.IO.SeekOrigin.Current);
try
{
do
{
i = br1.ReadByte(); j = br2.ReadByte();
if (i != j) break;
} while (i != -1 && j != -1);
}
catch (System.IO.IOException exc)
{
}
br1.Close();
br2.Close();
if (i != j)
return false;
else
return true;
}
Mondjuk nagyobb méretű képeknél a MemoryStream helyett lehet FileStream. Lassab, de kevésbé memóriafaló. -
#90999040
törölt tag
válasz kingabo #1976 üzenetére
ez is bitről bitre hasonlít össze, szal ugyanott vagy.
Viszont bármilyen formátumot képes kezelni(pl. [pod]Diablo programjában is .png van), nem csak bitmap-ot, és unsafe sem kell hozzá.
Valamint, ahogy írtam, Filestream-el lassabb, de kevésbé memfaló.
De a lényeg, hogy így vag úgy, de megoldható. -
#90999040
törölt tag
válasz martonx #1987 üzenetére
Azaz a kérdés az, hogy miért kell egy gombnak a képéről megmondani, hogy egyezik-e egy másikkal?
[pod]Diablo #1959-es hozzászólásában ezt írja:
if (A2.Image == Image.FromFile(@"C:\-school-\prog\sakk\feherparaszt.png",true))Ez akárhogy nézem, 2 képet akarna összehasonlítani. Hogy miért, azt nem tudom, de nem is az én dolgom. Mivel erre a feladatra sem a ==, sem a Equals nem alkalmas, ezért kerestünk más megoldást.
-
#90999040
törölt tag
-
#90999040
törölt tag
válasz kingabo #2012 üzenetére
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.
-
#90999040
törölt tag
válasz kingabo #2024 üzenetére
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. -
#90999040
törölt tag
válasz #90999040 #2027 üzenetére
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::ciklus0A 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 -
#90999040
törölt tag
válasz Sk8erPeter #2087 üzenetére
átneveztetnénk mondjuk "C# programozás"-ra vagy ehhez hasonlóra
Szerintem ez valóban jobb lenne, hiszen a Visual studio.net nem csak c#-ot tartalmaz, és természetesen c# sem csak a Visual studio.net-ben van.
-
#90999040
törölt tag
-
#90999040
törölt tag
válasz WonderCSabo #3174 üzenetére
Szívesen! Bár látom, sikerült vb.net példát belinkelnem, de ezek szerint nem okozott nagy problémát.
-
#90999040
törölt tag
válasz WonderCSabo #3323 üzenetére
Pl. ha megjeleníted a Form-ot Show(Dialog) metódussal, aztán a user bezárja, akkor már nem is jelenítheted meg újra Show-al.
Miért ne jeleníthetnéd utána meg? Annyi, hogy a referenciát el tudd érni, mert azzal, hogy a user bezárja, még önmagában nem lesz null(ezért a GC még addig nem végez vele, amíg van rá mutató referencia). Bezárás után nyugodtan mehet még a show() vagy showdialog is akárhányszor.
[ Szerkesztve ]
-
#90999040
törölt tag
válasz WonderCSabo #3331 üzenetére
Sima Show() esetén tényleg meghívódik a Dispose(), ShowDialog() esetén nem, ez zavart meg.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- DIGI Mobil
- CASIO órák kedvelők topicja!
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kerékpárosok, bringások ide!
- Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Milyen NAS-t vegyek?
- Milyen monitort vegyek?
- További aktív témák...