- Milyen belső merevlemezt vegyek?
- Nem indul és mi a baja a gépemnek topik
- Itt van az ASUS legfrissebb, AMD platformra épülő mini PC-je
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Akkumulátor töltő digitális fényképezőgéphez
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- ASUS notebook topic
- Milyen billentyűzetet vegyek?
- Hogy is néznek ki a gépeink?
- Apple MacBook
Új hozzászólás Aktív témák
-
Gregorius
őstag
amugy utalom a boxing kifejezest, mi a francert nem lehet wrappernek mondani
Mert a wrapper a becsomagoló objektum neve, a boxing meg a műveleté.
Meg ha már mindenáron meg akarjuk különböztetni, akkor még ilyen lényegtelen különbségek vannak a wrappelés és a boxing között, hogy az előbbi rendszerint explicit módon történik, az utóbbit implicit elintézi a fordító, ahol lehet.
Nem utolsó sorban, a wrapper class valamilyen durvább különbséget hidal át két komponens között (pl. managed-unmanaged), a boxing meg nem.
[Szerkesztve] -
Gregorius
őstag
a fordito elhelyez bizonyos kodreszletekbol tobb fele optimalizalt valtozatot a forditasi direktivak alapjan
És ennek eredményeként ugyanaz a kód hatszor lesz benne a programban. Vagy ha az #if-#endif-es direktívákra gondoltál, akkor annak a különböző ágaiban is meg kell írnia valakinek a megfelelő optimalizált programot.
ugye nem gondoltad, hogy komolyan teljesitmenyigenyes szoftvereket a hagyomanyos object-modellel forditanak? ;)
De azokat nem is multiplatformos környezetbe szánják.
ha megnezed, egy rendes fordito mennyit kepesz szarakodni egy nem is olyan nagy kodon
Ennek inkább az eléggé elavult C fordítási modell az oka, de mégha ezt figyelmen kívül hagyjuk, akkor is erősen nyelvfüggő, hogy egy fordító milyen tempóban dolgozik. Pl. a VB.NET-es fordító érezhetően lassabb a C#-énál, pedig még emberi ésszel is simán lehet sorról sorra konvertálni a két nyelv között, és a célplatform is megegyezik.
gyakorlatilag nem vagyok meggyozve, hogy a JIT algoritmusokat valaha is tudjak odaig finomitani, hogy versenykepes sebesseget nyujtanak
Tényleg nehéz hosszútávon megjósolni, hogy mi lesz belőle, de ahogy egyre gyorsul a vas, egyre inkább előtérbe kerülni látszik a GC meg a JIT. Már 94-ben is igen komoly algoritmusok léteztek pl. GC ügyben, de akkor még olyan overhead-et jelentett a processzoroknak, hogy gyakorlatban nem nagyon volt értelme használni. Hol volt akkor még a Java? Sehol. Azóta bőven megduplázódott a JRE által fordított programok teljesítménye is. (Azért nem a .NET-et hozom fel példának, mert amögött még nincs elég nagy történelem).
Most meg már van izom vas, sőt jönnek a dual-core procik, ami már kimondottan előnyös a GC-nek is. Aztán szépen lassan eljutunk odáig, hogy 1-2% a különbség.
Persze azt sem szabad elfelejteni, hogy a JIT az nem a text forráskódon dolgozik, úgyhogy legalább egy igen költséges parszolást megtakarít.
Jól gondolom, hogy ezekről beszélsz?
igen
Akkor pár korrekció.
Az 1. eset tökazonos C-ben és C#-ban
A 2. eset megoldható az IntPtr-rel és a Marshal class-szal, nagyjából ugyanakkora méretű kódban, csak az átlag programozót rendszerint seggbe rúgják érte. Ha stílusosan akar az ember ''típustalan'' bulk memory-t foglalni, akkor ott a MemoryStream. Igény szerint előre rögzíthető, hogy mekkora terület legyen.
A 3. eset is foglal memóriát, nem csak nevet, merthogy a referencia csak egy szintaktikai elem, pointerre alakítja át a fordító (x86-32-n 4byte), szóval ez a háttérben gyak. ugyanaz, mint a 2.
C#-ban a value type-ok (struct) nem tudják ezt egyedül szépen (típusosan) megcsinálni, csak boxinggal, minden más (class) referenciaként van átadogatva mindenhol. Vagy ki lehet explicit írni a hívásban, hogy ref. Szerintem ez nem baj, legalább a hívásnál is látszik, hogy a kérdéses függvény babrálni fogja az értéket, hülyebiztos a megoldás. (megmondom őszintén, én még sohasem használtam C#-ban a ref kulcsszót, pedig már programozok egy ideje)
eredetileg annak a moduljakent akarta a ceg megiratni ezt a kiegeszitest, csak mondtuk hogy az nem volna okos gondolat.
Háát, hozzáhegeszteni egy meglévő rendszerhez általában bonyolultabb, mint bővíteni. Úgy legalább lehet, hogy nem kellett volna konkurálni a fájlért.
kiegeszitettem a specifikaciot, hogy csak az adott directoryn belul mozgathato a file
[Szerkesztve] -
Gregorius
őstag
igazabol a kodok teljesitmeny-kritikus reszet, normalis programozo sok sok architekturara leforditja
A különbség a kettő között az, hogy a programozó arra fordítja le, amit ő támogat, aztán kiadja a programot. A .NET esetében meg először kiadják a programot, aztán lehet, hogy két év múlva előkerül egy überfrankó architektura, amire aztán a .NET tud fordítani, és egyből fut a felturbózott program.
A programozónak viszont elő kell vennie a régi programját. Plusz neki kell arról is kell gondoskodnia, hogy a megfelelő rendszerképességeket felismerje és az annak megfelelő modult töltse be.
a kod joval nagyobb egeszet atlatja a fordito, es az optimalizacio elvegzesere is tobb ideje van
Miért látná át nagyobb egészét? A C fordító a legáltalánosabb dolgokon kívül semmit nem tud a célplatform hardver- és szoftverkörnyezetéről. Optimalizálni valóban több ideje van (és ezt az időt ki is használja alaposan, amilyen lassúak a C fordítók...), azonban a JIT-nek több információ áll rendelkezésére ugyanezen feladatok elvégzéséhez. És akár még teljesítményinfókat is gyűjthet (hasonlóan a processzorok elágazásbecsléséhez P1 óta)
na akkor volt eloszor az automatikus valtozo: egyszerre foglalsz memoriateruletet, es valtozonevet
aztan lehett foglalni kulon memoriateruletet
aztan a c++ oldotta meg eloszor, hogy NEVET lehessen foglalni, tarterulet nelkul
1: int i;
2: void *p = malloc(...);
3: int& i;
Jól gondolom, hogy ezekről beszélsz?
persze amikor egy modult tobb projektben torteni felhasznalasra terveznek akkor erre figyelni kell
Ezt mondd azoknak, akik public domain-be rakják a kreálmányaikat.
mit meg nem adnek most egy rohadt i-node szamert .NET alatt...
Akkor nem lesz fájlrendszer-független a programod.
Ha muszáj, esetleg érdemes a Distributed Link Tracking Client szolgáltatásba beleásódni, az csinál olyasmi követést NTFS rendszeren, amit szeretnél, de ez természetesen FAT/FAT32-n nem működik, szóval nem jó erre alapozni.
Bővebben: link
A Platform SDK-ba kell beleásódni.
[Szerkesztve] -
Gregorius
őstag
resze a standard libnek, legalabb annyira a nyelv resze, mint a System.GC
A GC sem a nyelv része, hanem a platformé.
naiv gondolat azt hinni, hogy egy rendes fordito optimalizacios kepessegeit valaha is elerheti
Épp ellenkezőleg. A JIT-nek van lehetősége a futtató processzor architekturális sajátosságait, spéci utasításkészleteit kihasználni. A ''rendes'' C-fordítóknak pedig az összes megcélzott architekturával kompatibilis kódot kell generálniuk.
az a baj, hogy a durvan optimalizalt GC mem.kezeleset elegge hasravagja az ilyen.
Nah, csak a statisztikáit. Általában nincs is rá szükség, de ha tudod, hogy utána egy igen sok memóriát igénylő folyamat következik, akkor célszerű előre takarítani.
nem, nem irok peldat, ez puszta elegancia kerdese, a c++ egy igen igenyes megoldast adott a problemara
Most már sosem tudom meg, mi ez a fantomelegancia, amiről beszélsz
amikor azt mondod hogy C akkor c++ra is gondolsz ?!?!?! ez halal komoly?!
Igen. Sajna az. Nem tudom, pontosan mi volt az előd, de a VB előtt sem a C/C++ volt a top. Sok az amatőr programozó a világban...
c++ ala ismerek vagy 6 GCt, es mar 4et hsznaltam... mennyit is ismerek c# ala?
Jogos. Sőt, C++-ban írhatsz akár saját mem.mgr-t is. Viszont az velük a probléma, hogy amint két program interfészel egymással rögtön ott a kérdés, hogy mi van, hogy ha különböző memóriamanagert használnak?
FileSystemWatcher-el odaig jutottam, h atnevezest (konyvtaron beluli mozgatast) mar elkapom, de amint kilep a konyvtarbol buktam a filet, hacsak nincs watcher allitva a celkonyvtarra is, de ez nem megoldhato... szoval otlet?
Lehet próbálkozni azzal, hogy arra állítod a FSW-t, hogy subdireket is monitorozzon, de ha nem tudod, hogy a fájl potenciálisan hova fog kerülni, akkor csak úgy kaphatnád el, ha monitoroznád az egész partíciót, de iszonyatosan nagy overhead kiválogatni, hogy téged melyik fájl érdekel. A másik megoldás a kernel hook, de az meg nagyon ronda.
Egyébként a fájlt nyitva tarthatod shared write módban is (FileShare.ReadWrite). Ilyenkor más is tud bele írni, csak törölni nem lehet. (áthelyezni lehet, hogy igen, nem tudom, de ettől nem válik invaliddá a file handle) -
Gregorius
őstag
a malloc/free es a new/delete tekintheto nyelvi eszkoznek a memoria kezelesere
A malloc/free nem tekinthető, az runtime library. A new/delete inkább, de azok is a malloc/free-re vannak visszavezetve, szóval csak ún. szintaktikus édesítőszerek. Ráadásul nem is kifejezetten a te programod, hanem az oprendszer része a kérdéses RT, úgyhogy effektíve akkor cseréli ki alattad a microsoft, amikor neki tetszik. (Volt már ebből problémám, hogy a letöltött program csak nem akart futni, aztán kiderült, hogy egy régebbi RT-vel linkelték, úgyhogy újra kellett fordítanom, hogy rendesen együttműködjön a többi komponenssel)
azert, mert a GC sajnos esetenkent nem elhanyagolhato ovreheadet jelent, es nem-szintetikus-tesztek eseten (amikor csinalunk ugyan abbol 50000 peldanyt mondjuk) lassabb lesz
Meg kell tanulni hatékonyan GC alá programot írni. Gondolom az ember a hagyományos programját sem tűzdeli tele folyamatos objektumallokációkkal.
Ráadásul a GC a programtól függetlenül cserélhető, ezért mire kitaláltál egy jobb GC algoritmust vagy netán megoldottad manuális memóriakezeléssel, addigra kapsz egy jobban optimalizált GC-t, amely ráadásul az összes programhoz használható.
Egyébként ha összevissza allokálsz mindent, azt a heap sem tolerálja valami jól.
a .NET mint a java GCa elegge alkalmatlanna teszi a nyelvet realtime mukodesre, mert nincs definialva, hogy mikor collectel.
A windows önmagában alkalmatlan hard real time működésre GC-vel, vagy anélkül. Viszont soft real time működés nyugodtan megvalósítható a GC jelentette bizonytalanság mellett, az átlagos idők ugyanúgy mérhetőek, mint bármelyik másik alkalmazás esetén. Ha meg a rendszer elkezd vergődni, akkor tényleg végképp mindegy, hogy GC vagy nem GC.
Persze kétségtelen, hogy a .NET teljesítményben egyelőre elmarad a natív C-től (és megsúgom, előzetes mérések szerint a .NET 2.0 Math könyvtára gyengébb lesz, mint az 1.1-é). De egyrészt aki powah rutinokat akar írogatni, az kódolja le az érzékeny részeket ASM-ben, másrészt ez nem szorosan a nyelv függvénye, hanem a JIT-é és a framework-é.
es ha te akarod ugy intezni, hogy a kritikus idopontokban NE kezdjen el gyujtogetni
Akkor szépen meghívod előre a GC-t, hogy na akkor gyűjtsön most, megvárod amíg begyűjt (WaitForPendingFinalizers), aztán végrehajtod a kritikus részt. Közben persze C-ben sem nagyon tudsz objektumokat allokálgatni, mert a heap sem a kiszámíthatóságáról híres, már ami az allokációt érinti. Egy esetben lehet értelme a dolognak, ha az ember C++-ban mindent a stack-re allokál, de akkor inkább maradjon a sima C-nél. (Találkoztam már olyan emberrel, aki tervezési elvi alapon teljesen hanyagolta a heap-et a kiszámíthatatlansága miatt)
A GC az alapból alacsony prioritáson fut, úgyhogy a CPU-intenzív working thread-eket nem nagyon zavarja, viszont ha vészesen fogy a fizikai memória, akkor realtime prioritással pillanatokon belül ledarálja az összes szemetet.
Egyébként döbbenetes, hogy a GC algoritmusokat milyen durván optimalizálják. Pl. ha jól tudom, a .net-es adaptálódik a processzor cache méretéhez, úgyhogy a 0. generációban felszabadított objektumok többsége lényegében sosem kerül ki az L2 cache-ből, így kegyetlen gyors tud lenni.
a c++ nyelvben lehetett eloszor ertelmesen uj nevet bevezetni hozza tartozo memoriaterulet foglalasa nelkul. es ezt 1 darab operatorral oldottak meg, ami minden esetben elegseges volt az egyertelmu kifejezeshez. c#ban eltunt ez a szep, egyseges, elegans megoldas.
Még mindig nem értem. Írsz egy C++ példát, hogy mi annyira jó miben?
többszálú öröklődés...
en a nyelv osszetettsegerol, es nem az eletkepessegerol/hasznalhatosagarol beszeltem
Én ezt inkább összefércelésnek hívom, mint összetettségnek, de ízlés kérdése. Az ilyen programozói agyelszállások inkább az interoperabilitás illetve a kódújrafelhasználás szempontjából fontosak.
szkepticizmussal kezelni, es/vagy utanaolvasni
És megcáfolni, ha nincs igazunk!
es felterjesztem megegyezesre, hogy altalanos celu alkalmazasfejlesztesre a c# bizony alkalmasabb nyelv
Ebben egyetértünk. Bár ez akár a 6-os vagy régebbi Visual Basic-re is mondható (inkább mint platformra a mindenféle designerjével), az pedig egy bűn rossz nyelv, mégis egy-két évvel ezelőtt többen használták, mint a C-t
.
[Szerkesztve] -
Gregorius
őstag
Nah akkor rögtön:
operator overloading
templatek
aut.tipuskonverzio
És ezeket miért is nem tudja a C#?
lehetoseg a nyelvi helyett az op.rendszer biztositotta mem.kezeles hasznalatara
Nem tudom, a C mióta csinál memóriakezelést.
hatekonysagi okokbol opcionalis GC (tobbfele implementacio)
Ezt miért tartod szükségesnek?
elegans referenciakezeles
Nem tudom, mi nem elég elegáns rajta.
parameteratadasnal kovariancia
Ez valóban jól jött volna néhány esetben. Majd megcsinálják a 3.0-ban. Szerencse, hogy template-ekkel megoldható.
a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban...
...tudja elcseszni a programot
[Szerkesztve] -
Gregorius
őstag
valojaban a c++ joval osszetettebb nyelv, mint a c#, tehat inkabb a c++ tud mindent, amit a c# is tud, nem forditva
Például?
zoty314:while( vanmégstring )
{
string[] tokens = olvasott.Split(new char[]{' '}, 2);
string nextToken = tokens[0];
olvasott = tokens[1]; //ez a maradek
}Vagy ha whitespace mentén (space, újsor, tab, stb...) akarod szétszedni a string-et, akkor a fenti sor kicserélendő erre:
string[] tokens = olvasott.Split(null, 2);
[Szerkesztve] -
Gregorius
őstag
Defaultban nem fognak futni. Átlag júzer átlag programja úgy kerül lefordításra, hogy azt a framework-öt használja, amelyikkel fordítva lett (vagyis VS2002->FW1.0, VS2003->FW1.1, VS2005->FW2.0). Ha van ilyen a rendszeren, akkor ezzel fog futni a program. Továbbá meg lehet jelölni AssemblyInfo-ban, hogy melyik FW-vel kompatibilis a progi, tehát egy jól összeszerelt (és esetleg CLS-compliant) programra rá bírod írni, hogy fut az 1.0-val, és az 1.1-gyel is. (asszem a 2.0 eltérő assembly szerkezetet használ, ezért az csak felülről kompatibilis, a 2.0-s progikat az 1.1 nem tudja futtatni, de fordítva igen)
-
Gregorius
őstag
Esetleg így:
this.cbbStatusz.SelectedIndex =
this.cbbStatusz.FindStringExact(''HIANYOS'');Az egy dolog, hogy kiválasztod az 1. indexet, de ott tényleg a ''HIANYOS'' van? A ComboBox lehet rendezett is.
Az Items.AddRange-nél meg szerintem nem kell az utolsó vessző.
[Szerkesztve] -
Gregorius
őstag
Nehéz kérdés, lévén sohasem foglalkoztam néhány óránál tovább PC-nél kisebb platformok programozásával, de amit te keresel, az a .NET Compact Framework. Ennek dedikált magyar nyelvű könyvről nem nagyon tudok, legfeljebb tanfolyamokat lehet találni, de azok többnyire fizetősek.
A funkciógombokat hogyan tudod használni?
Meg ha már mindenáron meg akarjuk különböztetni, akkor még ilyen lényegtelen különbségek vannak a wrappelés és a boxing között, hogy az előbbi rendszerint explicit módon történik, az utóbbit implicit elintézi a fordító, ahol lehet.
.
Ú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!
- EarFun Tune Pro - a család mindent tudója?
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Kecskemét és környéke adok-veszek-beszélgetek
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Béta iOS-t használók topikja
- Milyen belső merevlemezt vegyek?
- Python programozás
- Borderlands 4
- További aktív témák...
- RAZER Viper V2 Pro fehér (Hiányos) INGYEN FOXPOST
- ASUS ROG STRIX 1000W Gold Aura Edition RGB Moduláris Tápegység PCIE 5 ATX 3 12VHPWR
- Asus Rog Thor II 1000W Platinum OLED RGB Moduláris Tápegység
- 32" Interaktiv Monitor Érintőképernyővel - Iiyama ProLite TF3237MSC-B3AG Touch-
- Apple Iphone 12 64gb kék -független-
- Samsung Galaxy A50 128GB, Kártyafüggetlen, 1 Év Garanciával
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Lenovo ThinkPad 40AF docking station (DisplayLink)
- Bomba ár! Dell Latitude E6420 - i5 / i7 I 4GB I 320GB I 14" I HDMI I Cam I Garancia!
- Microsoft Surface Laptop 5 13,5" Fekete i7-1265U 16GB 512GB magyarbill 1 év garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest