- ASUS ROG PG32UCDM: OLED csúcsmonitor tesztje
- Nvidia GPU-k jövője - amit tudni vélünk
- Egérpad topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- Xiaomi Pad 6 - kiapadhatatlan jóság
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Gaming notebook topik
- Rohamtempóban nő az érdeklődés az OLED monitorok iránt
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- ThinkPad (NEM IdeaPad)
- Luck Dragon: Asszociációs játék. :)
- Lalikiraly: MSI Cyborg 15 - Tényleg Kiborg.
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
Hirdetés
-
Nem megy az S25 Ultra 3x-os zoomkamerája sehova
ma Ice Universe záfolja a minap felröppent híreket, marad a négy kamera.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
PlayStationre és Xbox-ra tart a Horizon Chase 2
gp A folytatás a tervek szerint május végén debütál az újabb platformokon.
Új hozzászólás Aktív témák
-
MATEO6600
őstag
válasz MATEO6600 #4763 üzenetére
Bocs a dupe-ért, közben sikerült beimportálni rendesen.
Most Bitmap objektumként hivatkozok rá, aminek ugye van x és y koordinátája, így lehet majd mozgatni.
Egy olyan kérdésem lenne még, hogy a bitmap konstruktorába nem lehet olyan értéket megadni, hogy méretarányosan kisebb/nagyobb legyen a mérete? Width és height adott, de az nem arányos formában van ugye. -
vlevi
nagyúr
válasz MATEO6600 #4763 üzenetére
Létre kell hozni egy másik bitmap obejktumot, és abba átmásolni. Most nincs előttem csak táblagép, a pontos metódusnevet most ezért nem tudom megmondani.
Csak ne felejtsd el a régi, már nem használt, eredeti képet felszabadítani, pl. a korábban tárgyalt using használatával.[ Szerkesztve ]
-
-
Karma
félisten
válasz MATEO6600 #5400 üzenetére
A LINQ tényleg "túl nagy" könnyítés, de ezt én is írtam. Egyetértek veled abban, hogy egy ilyen eszköz kézbevétele előtt hasznos lenne, hogy a diák értse a különböző algoritmusokat, és ha olyan környezetbe kerül, meg is tudjon írni magától egy kiválasztást, min/max keresést, stb.
De még ezt sem teljesíti a mostani tananyag rendesen. Az egész programozás témakört céltalannak és átgondolatlannak érzem – főleg ha a tényleges lefolyását és eredményét látom az infóóráknak.
A listákkal kapcsolatban máshogy gondolom. A lista, mint adatszerkezet, algoritmikusan is érdekesebb, mint egy tömb. Ha meg az érettségi feladatokat meg a valós felhasználást nézzük, végtelenül hasznosabbak is.
Kicsit hasonló a történet, mint amit szüleim meséltek az angol oktatásról, amikor tömegesen képezték át magukat az orosztanárok angoltanárrá úgy, hogy pár leckével jártak előrébb a tananyaggal, mint amit órán leadtak. Csak itt az induló nyelv a Pascal, a cél meg a C#.
“All nothings are not equal.”
-
martonx
veterán
válasz MATEO6600 #5400 üzenetére
Nekem volt szerencsém korrepetálni középiskolás szerencsétleneket.
Szvsz ezt az egész programozós érettségizős dolgot a tömegeknek nem kellene erőltetni. Sokan kitalálják, hogy ha már úgyis egész nam fb-znek a mobiljukon, meg tök jól eljátszanak a tabletjeiken, akkor ők máris programozók lesznek. Aztán az első tömb bejerásnál for ciklusnál megáll a tudomány, és a delikvensek jelentős százaléka (a kis merítésű mintavételem alapján ez olyan 80%) erről a szintről soha a büdős életben nem fog tudni feljebb jutni.Azaz én az arra alkalmatlanokat (80%) kapásból kiszórnám az első felév végén. A többiekkel meg hagy haladjunk négyszer olyan tempóban, hagy oldjunk meg érdekes feladatokat, ne az unalmas sorbarendezésekkel töltsünk el egy félévet.
Persze ez amit mondtam a komplett közoktatásunkra igaz, ha egyszer valaki discalculusban szenved (ez eleve mekkora kamu már, buták mindig is voltak és lesznek), azért még nem kötelező neki matekból érettségiznie, és mindenféle felmentést kapnia (matek, fizika, kémia). Egyáltalán mostanra sikerült az érettségit a vicc szintjére süllyeszteni.
Én kérek elnézést!
-
Karma
félisten
válasz MATEO6600 #5404 üzenetére
N-edjére nekifutva a gondolatnak megkockáztatom, hogy nem is baj, ha nem érti az algoritmust teljesen a diák. Sokat nem nyer azzal, hogy mechanikusan belevasalják szorzótábla módján a "programozási tételeket", aztán vagy megérti és megszereti, vagy végigszenvedi ahogy a tanár pazarolja a saját és az osztály idejét valamire, amivel az életben nem találkozik újra. Ennél még a humán tárgyak is hasznosabbak.
Inkább kéne alapozni a sikerélményre, és azon sokat dob a LINQ is.
“All nothings are not equal.”
-
Karma
félisten
válasz MATEO6600 #5849 üzenetére
Ilyenkor nem használhatsz autopropertyt. Csinálnod kell egy tagváltozót, és azt használod a getterben és a setterben, mint azelőtt, hogy kitalálták ezt a rövidítést. A fordító is ezt teszi, csak azt elrejti előled.
private int _szam;
public int Szam
{
get { return _szam; }
set { _szam = value; HardcoreVoodooBlackMagic(value); }
}[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz MATEO6600 #5851 üzenetére
1) Ez nagyon helyzetfüggő, de az esetek többségében célszerű a propertyt használni tovább, akár osztályon belül is. Persze kérdés, milyen vudut kódoltál a setterbe, de például elég tipikus a PropertyChanged esemény gerjesztése, ami azért nem árt, ha mindig megtörténik.
2) Nem kötelező private-nak jelölni, mert a classok és structok adattagjai alapértelmezetten private-ek. Egy külső (azaz nem másik classon belüli beágyazott) class alapértelmezetten internal, de átírhatod publicra. A beágyazott dolgok private-ok alapból.
3) De egyébként a pattern nem attól lesz jól vagy rosszul implementálva, hogy propertyt vagy fieldet használsz. Ha egy osztály egy másik adattagjait sokszor, közvetlenül manipulálja, legyen szó az előbbi kettő bármelyikéről, ott valami bűzlik.“All nothings are not equal.”
-
Goose-T
veterán
válasz MATEO6600 #5876 üzenetére
1. Készíts külön osztályokat a metódusok paramétereire és visszatérési értékeire, akár úgy, hogy egy közös osztályból származtatod őket. Nagyban meg fogja könnyíteni a dolgodat a jövőben.
2. WSDL-es service proxy generálás helyett az interface-t tedd egy külön Class Library projektbe, és az abból létrejövő DLL-t referáld a kliensalkalmazásban. Ha így csinálod, akkor a ChannelFactory használatával egyszerűbben tudod majd hívni a szolgáltatást, és mivel ott lesz az interface DLL a kliensoldalon is, ezért biztos az a ToString() metódus fog lefutni, amit te írtál bele. Most azért nem az fut le, mert metódusokat nem szerializál a WCF, csak a [DataMember] attributummal ellátott property-ket.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
sztanozs
veterán
válasz MATEO6600 #5894 üzenetére
A lényeg lényege (megvágva)
newarr [mscorlib]System.Object
ldstr bytearray (41 00 20 00 73 00 7A 00 E1 00 6D 00 31 00 3A 00 // A. .s.z...m.1.:.
box [mscorlib]System.Int32
ldstr bytearray (2C 00 20 00 73 00 7A 00 E1 00 6D 00 32 00 3A 00 // ,. .s.z...m.2.:.
box [mscorlib]System.Int32
ldstr bytearray (2C 00 20 00 73 00 7A 00 E1 00 6D 00 33 00 3A 00 // ,. .s.z...m.3.:.
box [mscorlib]System.Int32
call string [mscorlib]System.String::Concat(object[])
call void [mscorlib]System.Console::WriteLine(string)Szóval csinál egy Sting.Concat-t egy Object[] array-on - amibe belepakolja az összekötendő részeket.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Goose-T
veterán
válasz MATEO6600 #5896 üzenetére
Nem. A C# compiler minden egyes idézőjelbe tett kifejezésből a forráskódban csinál egy string objektumot, így a te kódodban négyszer fut le a String osztály konstruktora: háromszor a leírásuknál (mivel három részletben írtad le), és egy az összefűzésnél. A string.Format metódus használata esetén viszont csak kétszer jön létre string (egy a format string leírásánal, egy pedig a metódus futása során), szóval az takarékosabb az erőforrásokkal.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
Goose-T
veterán
válasz MATEO6600 #5936 üzenetére
Vagyis ha az osztályodat egy using blokkban szeretnéd példányosítani. (Persze rakhatod egy try-catch-finally blokkba is, ahol a finally részben meghívod a Dispose metódust, de hát ki csinál már ilyet, amikor pont erre van a using blokk? )
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
Goose-T
veterán
válasz MATEO6600 #5939 üzenetére
Általában akkor szoktak IDisposable interface-t használni, ha az osztály unmanaged resource-ot használ, jó példa erre az SQL-es ConnectionString. Ilyenkor a Dispose metódusban az unmanaged resource-okat fel kell szabadítani, hogy ne maradjon a memóriában, mert a GC azokkal nem foglalkozik.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
amargo
addikt
válasz MATEO6600 #5939 üzenetére
Olyan esetben használd az IDisposable interface jelzőt, ha az osztályodban olyan globális objektumot hasznalsz, ami disposable. Az, hogy ez managed vagy unmanaged, azt a dispose ban kell lekezelni.
Try finally t pedig erdemes ismerni http://msdn.microsoft.com/en-us/library/ms182334.aspx[ Szerkesztve ]
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
-
-
-
Goose-T
veterán
válasz MATEO6600 #7628 üzenetére
Semmire sem mennél vele, tök fölösleges ma már C-t és C++-t tanulni. Van még pár terület, ahol hasznos lehet, de ez a programozói munkaerőpiac kb. 1%-a. Inkább tanulj elméletet, sokkal többre mész vele. Ezeknek nézz utána első körben: Clean code, GoF patterns, SOLID.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
kispx
addikt
válasz MATEO6600 #7628 üzenetére
C++ topikban több szerencsével járnál.
De azért itt hagyom Stroustrup ajánlását.
Ú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!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest