Hirdetés
- LTE frekvenciák
- Honor Magic5 Pro - kamerák bűvöletében
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Magisk
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Samsung Galaxy A52s 5G - jó S-tehetség
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Poco X6 Pro - ötös alá
Új hozzászólás Aktív témák
-
nagyúr
LOL!!
Köszi a hozzászólást. Nem kellett volna off topc-ként írnod.
Igazad van. A .NET Framework nélkül nem megy. Persze ez is MS trükk, hogy vegyél inkább MS terméket...gondolom
A Borland C++ Builderről már hallottam, de sose néztem meg. EDDIG! Mostmár érdekel.
Az IDE kérdésről tudtam. Nem ez az első, de aVS.NET-ben ''IS'' nagyon hasznos.
Tudod hogy reklámozzák ezzel magukat? Azt mondják, hogy e .NET Framework bevezetésével minden szoftvercsaládjukat lecserélték, ezzel ELSŐKÉNT ismerve fel az XML és a webes programozás nyújtotta lehetőségeket.
És ezt ki veszi be? Szerintem már régen a köztudatban él az XML és a web fontossága és létjogosultsága.
Persze mindezek mellett szerintem a .NET valóban a haladást szolgálja és nem is kis mértékben. -
-
BlackWoOd
aktív tag
Khmm.
A kőfaragó is vésőt meg kalapácsot használ, meg a szobrász is.
Ugye nem gondolod, hogy a végeredményt az eszköz egyértelműen meghatározza?
Aki tud programozni, annak mindegy, milyen ''eszközt'' adsz a kezébe, elsajátítja a sajátosságokat és _nagyon_rövid_idő_alatt_ ugyanolyan produktívan képes azt használni, mint az eddig használt eszközeit.
Ugyan úgy lehet Delphiben, Javaban, C#-ban, C++-ban, VB-ben is gányolni mint szinvonalas programot, rendszert összehozni. Az object pascal meg pont egy általános célú és valóban egyszerűen tanulható nyelv.
Akit ismerek és programozói vénával van megálddva, az a delphi-t ugyan úgy kezeli, mint a fent említett szobrász (vagy kőfaragó) a vésőt/kalapácsot. Kap egy új eszközt, megnézi a kezelésbeni eltéréseket és használja. Teccik érteni...
(Igen, főképp Delphi-ben programozok már sok éve (1.0 óta). Ez nem jelenti azt, hogy megilyedek akár a C-től, akár a C#-tól akár a Java-tól. )
Egyébként meg nyilván figyelemmel követed a Delphi verzióinak fejlődését és Te is elismered, hogy a legtöbb modernnek számító szoftver-technológia megfelelően támogatott a részéről. Innentől kezdve meg minden a RAD-n múlik ( _Rapid_ Application Development ), legyen akár egyszerű szoftverről szó, akár komplex rendszerről. A Delphi meg RAD-ban elég erős.< ..kevés az ember, sok az emberszerű lény... >
-
BlackWoOd
aktív tag
A Delphire/object pascalra szerintem hozzáértő sosem mondta, hogy tisztán objektum-orientált nyelv...
Abban teljesen egyetértek, hogy nem Dephiben kell megtanulni az objektum-orientáltság mibenlétét, de ez legalább annyira igaz más nyelvekre is.
Az objektum-orientáltságot papíron, elvi alapfogalmakon keresztül célszerű megérteni, majd a gyakorlatba átültetni. Erre az ember fia vagy eleve tisztán objektum-orientált nyelvet használ, vagy saját bőrén megtapasztalja, hogy mit és hogyan célszerű megcsinálnia (ez természetesen pascalt használva tovább tart).
A ''jól programozni'' egy erősen szubjektív fogalom, nem tudom, hogy te mit értesz alatta. Az én értelmezésemben a jól programozni inkább algoritmus-szintű jóságot feltételez, csak másodrendű a nyelvi sajátosságok maximális kihasználása (persze ez a két dolog gyakran összefonódik, természetesen).
Én sem arról írkáltam, hogy ha delphiben tud valaki programozni, akkor ugyan olyan szinvonalú (frappáns, elegáns megoldások, stb) forrást hoz össze C*-ben, minden nehézség nélkül, de a probléma-megoldás és a tanult/_tapasztalt_ algoritmusok alkalmazása vitathatatlan előnyt jelent számára.
Valóban szemléletváltás szükséges a régi jó moduláris / struktúrált programozás módszereihez képest.
Szerintem amire te utalsz (delphiről átnyergelt programozók) ezen az ''apró'' lépésen nincsenek megfelelő módon túl, talán átugorták (esetleg az általad említett kényszerképzet okán), talán sosem ismerték fel.
Szvsz programozni ''megtanulni'' nem nagyon lehet, tapasztalati úton sokkal több/hasznosabb tudást lehet begyűjteni.
Mindegy, nem akarok vérre menő vitába bonyolódni, főleg nem off-ban.
Szerintem valami nagyon hasonló dologról beszélünk mindketten, csak az ellentétes oldalról.
Apróság, de szerintem RAD alatt nem egyszerűen a GUI összehányása értendő.
(Arra meg tényleg csak kíváncsi lennék, mi a ''gúzsba köti az ember kezés'' jelentése pascal vonatkozásban.)
mod.: offba akart menni...
[Szerkesztve]< ..kevés az ember, sok az emberszerű lény... >
-
BlackWoOd
aktív tag
A GC (bármilyen, akár Java-szerű módszer is) nekem személy szerint nagyon hiányzik op-ből.
A delphi programozókról meg csak annyit, hogy a cégnél, mielőtt felveszünk valakit, akkor egy egyszerű ''beugró'' feladatot kap. Ez nem bonyolult, de a forrást is oda kell adnia és az tanulságos tud lenni... Meg hogy azt a roppant bonyolult kb. 1000 soros programot a jelentkezők hány százaléka adja egyáltalán be. (durva becslés, max 25%)
(Netbeans-et szeretem én is, de az Eclipse még nem lopta be magát a szívembe.)
Na, de tényleg ne offoljunk ennyit.
C#-ra, VS.NET-re fel, fiatalok!
[Szerkesztve]< ..kevés az ember, sok az emberszerű lény... >
-
orbano
félisten
attol fugg mire. ha el akarod riasztani szegenyt a matektol es a programozastol akkor csoportelm. de pl jatekokhoz linearis algebra es analizis kell, no more. ha meg titkositani, akkor johet a csoport- es szamelmelet. fujj. utalom. hulye bevmat...
A vér nem válik VAZZE!™
-
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
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] -
zoty314
aktív tag
-
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
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
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
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
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
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
Amint hazaértem, elolvasom, csak RDP-n keresztül kicsit komplikált
Addig egy kérdés: csinálok egy setup&deployment projektet (jelenleg a VS2005RC1-ben, mert úgy tűnik, a 2003-asom megadta magát és nincs kéznél az install CD, de látszólag ugyanaz). Hogyan tudok olyat csinálni, hogy telepítés után minden egyes júzer bejelentkezésekor elinduljon egy konfigurációs lépés? Arra volna szükség, hogy ha a júzer a telepítés óta először jelentkezik be, akkor az Application Data mappájába bekerüljön néhány fájl. Ezt meg tudja oldani a VS-féle setup projekt, megoldható-e custom step-pel, vagy nézzek valami komolyabb megoldás után?
Egy meglévő programot wrappelek msi-be, hogy lehessen távtelepíteni, úgyhogy magát a programot nem tudom módosítani. -
Gregorius
őstag
Nah beleolvastam.
Aszongya a 7. pontban
this paper examines only stop-the-world, non-incremental,
non-concurrent garbage collectors.
Kár, hogy a .NET GC és az újabb Java cuccok nem ilyenek.
If their applications will be deployed on
systems with at least three times as much RAM as needed
Megmondom őszintén, olyan rendszert még nem nagyon láttam (az otthoni játékpc-ket kivéve), ahol átlagosan a RAM több, mint 50%-a ki lett volna használva. Ökölszabályként is ezt használják rendszerméretezéskor.
De ha már mégis fogytán a RAM, nem csoda, hogy a garbage collection szarul teljesít, lévén egy csomó szemét kikerül a pagefile-ba ahelyett, hogy a rendszer engedné előtte a GC-nek begyűjteni. (A bookmarking collector-juk, ami figyelembe veszi ezt a paging-et, állításuk szerint alig veszít a teljesítményéből nagy memóriaterhelés esetén) -
Gregorius
őstag
Ha írtál már valaha önerőből on-demand lexikai- és szintaxiselemzőt, ez sajna nem a tíz soros ''Hello World'' kategória (ráadásul atomra ki van optimalizálva), és őszintén szólva kétlem, hogy bárki bármilyen tapasztalattal képes lenne két napnál hamarabb megoldani (még ha tökéletes a dokumentáció, akkor sem), kivéve ha az illető az azon a kódrészen dolgozó csapatban van.
Ez idáig rendben van, csak azt nem értem, hogy melyik balf*** tolta hónapokkal egy stabil változat előtt piacra a VS-t?!
a bugfixeket service-packokba gyujtse azonnali relase helyett. van ennek valami oka is a tradicion kivul?
Kevesebb verzióval kell foglalkozni, ha összeakad valamivel az egyik javítás.
nem nagyon latom, hogy akarmelyik kereskedelmi IDE hasonlo utemben tudna bugfixeket kozzetenni, mint egy opensource project.
Ezt majd akkor fogadom el érvnek, ha mondjuk a NetBeans vagy az Eclipse sebességben és memória-hatékonyságban utoléri a Visual Studio-t. Akár a 2005-öst, pedig az nagyságrenddel lassabb, mint a 2003 (szintén ''bug''). -
d3ad93
újonc
Én fősulin fogalkozok C#-al. Előtte java volt az, a programozás alapjait pedig c-ben tanultam. Ha azért tartod bonyolultnak a C#-ot, mert objektum orientált és ott pont a tömböt említetted akkor azt javasolnám, hogy az OOP alapjait nézd át kicsit, itt példányosításra és öröklődésre gondoltam. Ha azt megérted akkor szerintem nem lesz problémád vele.
-Hány lány lakik a Schönherz koliban? -1024. 2 a tizediken.
Ú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!
- Apple iPhone 13 Midnight 256GB iSTYLE 2025.03.26. GARANCIA
- LG UltraWide 38WN95C-W Monitor 1 év Garancia
- iMac 2017 27" Retina 5K CTO / i7 4.2 GHz / 40 GB DDR4 / 1 TB SSD + doboz
- iMac 2017 27" Retina 5K CTO / i5 3.8 GHz / 40 GB DDR4 / 1 TB SSD / Radeon Pro 580 8 GB + doboz
- iMac 2017 27" Retina 5K CTO / i7 4.2 GHz / 40 GB DDR4 / 500 GB SSD / Radeon Pro 575 4 GB + doboz