- iPhone topik
- Minden a BlackBerry telefonokról és rendszerről
- Magisk
- Átlépi végre az iPhone az 5000 mAh-t?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Nem növel telepméretet a Galaxy S26 Ultra
- iOS alkalmazások
- Android alkalmazások - szoftver kibeszélő topik
- Yettel topik
- Okosóra és okoskiegészítő topik
Új hozzászólás Aktív témák
-
Miracle
senior tag
válasz
Gregorius
#171
üzenetére
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
irtam is, es ismerek mukodo valtozatokat is, es tudom, h nem 10 sor, de az ilyen elemzok algoritmusai jol ismertek, ha nehany nap alatt nem lehet egy ilyen hibat normalisan kijavitani akkor alapjaiban van elcseszve (ez, azaz hogy szar a kod egyebkent fel sem merul bennem, mint valos lehetoseg)
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?!
most erre mit mondjak? cebiten az avalonos microsoftos ember sajnalkozott, hogy a visual studio es a standard XAML design tool (aminek nem jut eszembe a neve) kulonbozo, egymassal nem kompatibilis XAML verziot hasznal a publikus >>BETA<< valtozatban. tehat ami UIt legeneralsz azzal kitorolheted a s****d, hab a tortan, hogy a 3Ds designer(szinten nem jut eszembe a neve) egy 3. verziot hasznal. tehat a kiadott 3 SW (VS2K5, 2d, 3d design tool) 2 teljesen hasznalhatatlan, es igy lett belole beta verzio. ez mar a nocomment kategoria nalam, annak ellenere, hogy az avalon (khm.. wpf vagy valami ilyesmi a relase nev) nagyon utos cucc.
Kevesebb verzióval kell foglalkozni, ha összeakad valamivel az egyik javítás.
ezt el tudnam fogadni, ha nem lenne egy halom visual studioval osszemerheto osszetettsegu opensource project, amelyek kifogastalanul buildelhetok current CVS snapshotbol, de mivel van, es nem hiszem hogy a CVS vagy a clearcase ilyen brutalis feature-folenyben lenne a ms verziokezelo rendszerevel (amit egyebkent nem ismerek) ezt az ervet nem tudom elfogadni, marad a hagyomany.
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'').
igazabol nem kell engem gyozkodni a kereskedelmi IDEk elonyeirol
a netbeans egyebkent azert lassu, mert a java swing az 1.5osig nagyjabol pure java, raadasul messze osszetettebb mint a win.forms, de ha igazak a pletykak az 1.6os nativ implementaciot kap windows, es X11 feluletre is.
Eclipse-el meg nem ertem mi a problema, nalam az remek gyors.
Es a kerdesem nem az volt, hogy miben jobb a VS mint az opensource IDEek, hanem az, hogy ha mar fizetek erte akkor miert nem kapok olyan szolgaltatasokat, amelyek ha nem is feltetlenul elozik meg, de legalabb nem maradnak el ilyen messze az opensource megoldasoktol. -
Miracle
senior tag
válasz
Gregorius
#169
üzenetére
lattunk mar BUGot, van ilyen
es igazan nem akarom itt az opensource flamet kelteni, de ilyenkor egy nyilt szoftverben orak kerdese egy workaround, es napok kerdese egy rendes bugfix. igazan elvarnek valami hasonlot egy kereskedelmi szoftvertol is, azaz nem nagyon latom, hogy akarmelyik kereskedelmi IDE hasonlo utemben tudna bugfixeket kozzetenni, mint egy opensource project. vajon miert nem? de most komolyan mondom, nem ertem mi keszteti a microsoftot arra h a bugfixeket service-packokba gyujtse azonnali relase helyett. van ennek valami oka is a tradicion kivul? -
Miracle
senior tag
válasz
Gregorius
#134
üzenetére
oki oki nem arrol volt szo, hogy nemkellGC mert szar, hanem arrol, hogy nekialltak es eleg komolyan megkutattak mennyivel lassabb, nyilvan meg lehet magyarazni, ami senkit nem erdekel es nem is szamit, inkabb csak tudni kell hogy a gepbe kell memoria mint allat mert az olcsobb mint amig a programozo kezzel kezel memoriat es ezzel szamolni kell
es a problemadhoz amit elozo hozzaszolasban mondtal otletem sincs, en nem csinalok installert ;) -
Miracle
senior tag
GC vs malloc : Bővebben: link
erdemes elolvasni, summa summarum nagyon vegyes es sokretu tesztek utan arra jutottak, hogy generacio GC rendszerek 5* akkora memoriaval tudnak olyan sebesseget elerni, mint manualis mem.kezelessel, ha nem all ennyi memoria rendelkezesre akkor az eredmeny romlik eleg meredeken. persze a fejlesztes idejerol es a mem.leakekrol nem szol az iromany, ez pusztan sebessegteszt, nem kell masra kovetkeztetni belole, csak a .NET meg a Java jovojere a powerappok teruleten :> -
Miracle
senior tag
válasz
Gregorius
#130
üzenetére
boxing vs wrapper class
igaz, a wrapping eleg szokatlanul hangzik, de a java scennek megfelelt par evig
amugy az erveleseddel az a baj, hogy valoban ket kulonbozo dologrol van szo, de nem okozhat felreertes, mert a szovegkornyezetbol egyertelmuen kiderul, hogy melyik jelentesre vagyunk kivancsiak. szoval ez kicsit ilyen risc-vs-cisc vita szeru dolog, hogy majdnem ugyanarra kell-e meg egy szo![;]](//cdn.rios.hu/dl/s/v1.gif)
es ugye tudjuk, hogy a m$ milyen processzorokon tud piaci eredmenyeket felmutatni
najo ez szar vicc volt, lenyeg az, hogy a ket jelentes keverese a wrapper szo hasznalataval sem okozott ertelmezesi problemat az elmult ~10 evben, ez megint csak egy affele m$os ki-ha-en-nem hozzallas eredmenye, ami engem bosszantani szokott.
az is nagyon felbosszantott, amikor olvastam a c# ref.manual bevezetojet... szoval az elso 3 oldal arrol szol, hogy igazabol a c#ot valojaban sok sok programnyelvbol kopiztak ossze, es hogy szerintuk ezzel nincs semmi baj. (szerintem sem, ez az elso nyelveket leszamitva sosem igy tortent) es fel is soroltak a szoveg kozben ilyen olyan nyelveket, amiktol atvettek dolgokat.
kitalalod, melyik az az EGYETLEN nyelv, ami hianyzott a szovegbol, mint nagy elod? -
Miracle
senior tag
válasz
Gregorius
#128
üzenetére
É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.
nem a preprocesszorra gondoltam, hanem jelezni a forditonak, hogy ezen a kodreszleten elmelkedjen kicsit tobbet, legyen belole egyszalu, tobbszalo, SSEs, SSE2es, stbstb...
De azokat nem is multiplatformos környezetbe szánják.
jo, hat akkor most eljutottunk oda, hogy akkor csak nem lesz a c# sosem olyan gyors, a c++ meg olyan rugalmas, de ezt nagyjabol az elejen is tudtuk
Ennek inkább az eléggé elavult C fordítási modell az oka
igaz, a Ct is, de foleg a c++t NAGYON nehez parsolni, az igazi implementacio LL{infinity} volna, habar ettol el szoktak tekinteni a forditofejlesztok
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.
a GCokkal tokeletesen egyetertek, a JITek meg meg elegge el vannak jelen pillanatban maradva, hogy ez a kerdes ne doljon el iden
csak tudod leggujabb intel fordito szekvencialis kodbol csinal tobbszalu kodot, HThez, es valodi tobbutas rendszerhez is kulon, mindemellett alapbol fordit minden kodot SSEre es FPUra (mar ahol ennek van ertelme ugye) es mindkettot bedrotozza az ojjekt fileba, majd futas idoben dont processzor alapjan h melyik a jo valtozat. arrol meg nem is beszelve, hogy ha nem fortrant hasznalunk akkor kb. az intel az egyetlen x86 fordito, ahol assembly betetek nelkul ertelmes SIMD kod szuletik. raadasul az intel fordito teljesitmenyben meglehetosen a konkurencia elott jar (most talan van valami AMDs fordito is, amit fuggetlen ceg fejleszt, es asszongyak h suti cucc lett, meg nem neztem meg) de ettol egy lepcsovel lejjebb van a gcc es MS forditok, es meg ezeknel is joval lassabb a JIT. szoval ha hirtelen leallnanak a hagyomanyos forditok fejlesztesevel, meg akkor is hosszu hosszu evekbe telne mire a JITek versenykepesse valnanak a gccvel, ill. mS forditokkal, es az elvonaltol meg akkor is messze lesznek.
Akkor pár korrekció. [referenciakrol]
nem ideztem be mindent, de eppen errol beszeltem, hogy ming c++ alatt erre egy nyelvi elem van, es gyakorlatilag ugyan az a szemantika mukodik parameteratadasnal, mint sima referencia letrehozasakor, mig c# alatt nem. (value type vs osztalyok a heapen)
amugy utalom a boxing kifejezest, mi a francert nem lehet wrappernek mondani, mint ahogy mar 20 eve mindenki mondja a hasonlo szerepu osztalyokat...
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.
eppen ez az, hogy a kiegeszitesnek csak olvasnia kell a textfilet, es az alapjan dolgozni, a nagy rendszertol fuggetlenul. a nagy rendszernek meg kb. a rendszertervet ertettem volna meg annyi ido alatt, mint ahogy elkeszitettem ezt a programot es ha modulban gondolkozok akkor figyelnem kell egy par dologra, amiket igy megusztam, az user eddig nem pampogott, es sztem nem is fog, mert jol mukodik amit kapott -
Miracle
senior tag
válasz
Gregorius
#126
üzenetére
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.
ezzel az a baj, hogy a: ezt mar gyakran nem is kell a programozonak megcsinalnia, mert a fordito elhelyez bizonyos kodreszletekbol tobb fele optimalizalt valtozatot a forditasi direktivak alapjan. masfelol ha megnezed, egy rendes fordito mennyit kepesz szarakodni egy nem is olyan nagy kodon, ennyi ideje egy JITnek nem lesz... szoval igen, elmeletben tobb infoja van, gyakorlatilag nem vagyok meggyozve, hogy a JIT algoritmusokat valaha is tudjak odaig finomitani, hogy versenykepes sebesseget nyujtanak. persze ez is egy olyan dolog, hogy time will tell
amugy meg valaki aki powerappot fejleszt szepen forditsa csak ujra idonkent es disztributolja a binarisokat, ez nem pelda nelkuli dolog.
Miért látná át nagyobb egészét?
ugye nem gondoltad, hogy komolyan teljesitmenyigenyes szoftvereket a hagyomanyos object-modellel forditanak? ;)
(hasonlóan a processzorok elágazásbecsléséhez P1 óta)
hat ez most lehet hogy nagy belekotes lesz, de mar a P1 elott is volt ilyen, igaz nem x86on.
Jól gondolom, hogy ezekről beszélsz?
igen, a c#ban uj nyelvi elemet vezettek be a referencia szerinti parameteratadashoz.
Ezt mondd azoknak, akik public domain-be rakják a kreálmányaikat.
kellene valami ECPSEL (Europen Computer Programming and Software Engineering License) szoval tenyleg eleg gaz arcok vannak, errol oldalakat lehetne irni, gondolom mindankinek megvannak a maga tortenetei
(amugy websphere erre is ad megoldast )
Akkor nem lesz fájlrendszer-független a programod.
nemerdekel, csak windows NT alapu szervereken fog futni, az NTFS levaltasa meg nincs tervbeveve a pico & puha cegnel.
a shared megnyitvatartassal meg az a haz, hogy a cegnel mar mukodik egy meglehetosen stabil, es nagyon nagy rendszer, es az en kicsi programomnak e melle kellene befekudni, ugy, hogy ne nagyon zavarja a masik, tenyleg nagy programot... eredetileg annak a moduljakent akarta a ceg megiratni ezt a kiegeszitest, csak mondtuk hogy az nem volna okos gondolat.
amugy egy sokkal elegansabb megoldast talaltam a problemara: kiegeszitettem a specifikaciot, hogy csak az adott directoryn belul mozgathato a file -
Miracle
senior tag
válasz
Gregorius
#124
üzenetére
A GC sem a nyelv része, hanem a platformé.
a malloc is a platform resze szoval ha a GC MINIMALIS kiszamithatosagat/vezerelhetoseget is tekintetbe vesszuk, akkor a malloc is jar, mint ,,alap'' szolgaltatas. de felreteve az elvi vitat, eleg ertelmetlen a nyelvrol platform nelkul beszelni
É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.
hat... igazabol a kodok teljesitmeny-kritikus reszet, normalis programozo sok sok architekturara leforditja szoval ez nem igazi elony, szerintem sokkal nagyobb fegyverteny az, hogy a kod joval nagyobb egeszet atlatja a fordito, es az optimalizacio elvegzesere is tobb ideje van.
Most már sosem tudom meg, mi ez a fantomelegancia, amiről beszélsz
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.
c#ban is van lehetoseg azonos fonkcionalitas megvalositasara, de nem ilyen szep, elegans, programozaselmeleti szempontbol is szep megoldas.
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?
hat igen, ezzel elegge meg lehet szopni persze amikor egy modult tobb projektben torteni felhasznalasra terveznek akkor erre figyelni kell.
[Filekovetes]
hat igen, ez lehet az en hulyesegem, de nem szeretek csak azert nyitva tartani fileokat, hogy ne veszitsem el oket ha elmozhatjak. szoval lehet hogy osszetakolt az az egesz unix vilag, de hogy mit meg nem adnek most egy rohadt i-node szamert .NET alatt...
[Szerkesztve] -
Miracle
senior tag
válasz
Gregorius
#122
üzenetére
A malloc/free nem tekinthető, az runtime library.
resze a standard libnek, legalabb annyira a nyelv resze, mint a System.GC vagy mindketto, vagy egyik sem persze lattam mar olyan C forditot, ami nem tamogatta, de az a szoftver, amit azzal forditottak vonatvezerlo volt, ott pedig 0 bizonytalansagnak van helye
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.
hat... NAGYON nagy projektek eseten eleg komoly aldozatokat kell meghozni az erthetoseg, es a csapatmunka oltara, es tobb, kisebb funkcionalitast megvalosito osztaly, amiket esetleg gyakrabban kell cserelni/letrehozni osszessegeben megiscsak megterulhet. szoval a hatekonysag neha utolso szempont, hogy 1000 ember is tudjon egyutt dolgozni, es ekkor igen hasznos technikak allnak a c++ programozok rendelkezesere, hogy a kodot a rendszer megvaltoztatasa nelkul tegyek hatekonyabba (PIMPL, palement/new stb... ilyenekbol tenyleg sok van).
igen, GC programtol fuggetlenul cserelheto... ja varj... c++ ala ismerek vagy 6 GCt, es mar 4et hsznaltam... mennyit is ismerek c# ala? egyet? van egyaltalan masik? lehet NEKEM is cserelnem? (rotor, mono nemjatszik )
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-é.
hat CIL ASMel nem megyunk sokra, masfele ASMet meg nem illik
a JITek meg igen komoly fejlodesen mentek mar keresztul, de naiv gondolat azt hinni, hogy egy rendes fordito optimalizacios kepessegeit valaha is elerheti. esetleg megkozelitheti
Akkor szépen meghívod előre a GC-t, hogy na akkor gyűjtsön most, megvárod amíg begyűjt (WaitForPendingFinalizers)
ez lesz csak a szep meg a hatekony kod az a baj, hogy a durvan optimalizalt GC mem.kezeleset elegge hasravagja az ilyen.
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 m$nal volt kis vita, hogy a rotorba beletegyek-e a rendes .NET runtime GCat, es ha jol tudom vegulis az dontotte el a kerdest, hogy valami eszmeletlenul bonyolult, es feltek, a budos eletben senki nem ertene meg a mukodeset, es az egesz rotornak nem ez a celja
Még mindig nem értem. Írsz egy C++ példát, hogy mi annyira jó miben?
nem, nem irok peldat, ez puszta elegancia kerdese, a c++ egy igen igenyes megoldast adott a problemara, a c# meg visszalepett egyet, es nem olyan igenyes megoldast adott. persze ez hasznalhatosag szempontjabol nem sokat jelent, a koder altalaban el tudja donteni, hogy parametert vesz at, vagy csak ugy referenciat keszit, ez pusztan szepseg kerdese
többszálú öröklődés...
hat igen... egy szoval nem mondtam, hogy a tobbszalu oroklodes jo dolog, ez is csak 1 tipikus pelda a ket nyelv kozotti tervezesi filozofia kulnbsegere:
a: minden lehetoseget megadni a programozonak, hogy azt csinaljon amit tud
b: olyan lehetosegeket adni a programozonak, ami az esetek 98%ban elegendo, igy konnyen tanulhato, egyszerubb, es hetkoznapi hasznalatra alkalmasabb nyelv jon letre.
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 .
amikor azt mondod hogy C akkor c++ra is gondolsz ?!?!?! ez halal komoly?! a windows programozas rejtelmeibe az egeszen kozeli multig nem nagyon volt betekintesem, ha valami nagyon kellett, akkor is QT+mingw vagy java ment, a nativ windows programozas kimaradt az eletembol... ez azert eleg durva
de ha mar itt vagyunk van valami otleted, hogyan kellene 1 c# programbol figyelni arra, ha az user egy filet (amit mondjuk masodpercenkent fel kell dolgozni, de nem tarthatom lefoglalva, mert akkor nem kerul bele amit fel kell dolgozni) masik konyvtarba mozgat? 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? -
-
Miracle
senior tag
válasz
Gregorius
#117
üzenetére
templatek
igen, a 2.0ban mar vannak, de nem olyan osszetettek, mint a c++ban levok.
Nem tudom, a C mióta csinál memóriakezelést.
a malloc/free es a new/delete tekintheto nyelvi eszkoznek a memoria kezelesere, de akar windowson akar linuxon problemas veluk 1 GBytenal nagyobb mennyisegu memoriat kezelni, es lassuak is.
hatekonysagi okokbol opcionalis GC (tobbfele implementacio)
Ezt miért tartod szükségesnek?
azert, mert a GC sajnos esetenkent nem elhanyagolhato ovreheadet jelent, es nem-szintetikus-tesztek eseten (amikor csinalunk ugyan abbol 50000 peldanyt mondjuk) lassabb lesz, raadasul ugy a .NET mint a java GCa elegge alkalmatlanna teszi a nyelvet realtime mukodesre, mert nincs definialva, hogy mikor collectel. presze, ki lehet kenyszeriteni, es ha te akarod ugy intezni, hogy a kritikus idopontokban NE kezdjen el gyujtogetni akkor joval bonyolultabb kodot is kaphatsz. persze ez az kis teljesitmenytoblet az esetek nagy tobbsegeben valoban kicsi, es megeri GCt hasznalni, de igy, hogy kotelezo lett, a juzer elesik a placement-new hasznalatatol, ami eleg komoly fegyverteny tud lenni bizonyos esetekben. persze sima, semmilyen kulonleges igenyt nem tamaszto feladathoz nyilvan tokeletes megoldas barmilyen GC, mert az esetek nagy tobbsegeben inkabb mem.leakeket szuntet meg, mintsem problemat okozzon.
elegans referenciakezeles
Nem tudom, mi nem elég elegáns rajta.
hat ha visszanezunk a programozasi nyelvek tortenetere, akkor eloszor jott a valtozofoglalas, ami nev, es memoria. aztan jott a memoria, amihez nem tartozik nev. aztan jottek ilyen olyan probalkozasok (pl. smalltalk) amibe nem mennek bele, de lenyeg az, hogy 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.
a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban...
...tudja elcseszni a programot
igen, en is odairtam, hogy az esetek nagy tobbsegeben a c++ bovebb feature-listajat a programozok gyakran inkabb bugtenyesztesre hasznaltak, mint elegans kod keszitesere, megegyszer mondom, en a nyelv osszetettsegerol, es nem az eletkepessegerol/hasznalhatosagarol beszeltem
-
Miracle
senior tag
most eppen c#ban fejlesztek, tudom, hogy van method overloading, en operator overloadingrol beszeltem, pl. sajat osztalyokra ertelmezheted az + operatort (operator+).
ez nincs c#ban.
es ha valamit nagyon gyorsra is kene csinalni akkor sincs lehetoseged kezedbe venni a memoriakezelest, engem ez zavar neha de a c# is igen remek nyelv, mindossze annyi, hogy nem tudja teljesen kivaltani a c++t, de hat nem is erre keszult. -
Miracle
senior tag
igen.
persze ettol nem lesz a c++ jobb nyelv, csak nem a do-what-i-mean filozofia menten fejlesztettek, mint a javat meg a c#ot, a cel az volt, a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban, legkifejezobben ki tudja magat fejezni. es persze joval tobb hibat is tudjon ejteni, es JOVAL JOVAL nehezebb legyen megtanulni olyan szinten, hogy ne on es kozveszelyes programokat irjon a kedves fejleszto -
Miracle
senior tag
válasz
Gregorius
#107
üzenetére
Például?
tobbszoros oroklodes, operator overloading, elegans referenciakezeles, hatekonysagi okokbol opcionalis GC (tobbfele implementacio), templatek, lehetoseg a nyelvi helyett az op.rendszer biztositotta mem.kezeles hasznalatara, parameteratadasnal kovariancia, member-poionterek, aut.tipuskonverzio
hirtelen tobb nem jut eszembe -
-
Miracle
senior tag
válasz
Gregorius
#98
üzenetére
hat igazabol nem ertem ez miben kulonbozik attol amit en leirtam
mondjuk meg annyi, hogy a m$ a .NET frameworkjeben bennehagyja a regebbi frameworkoket is, hogy regi appokat is futtatni lehessen. amugy en nem tudok olyan okot kitalalni ami miatt (meg ha elvileg mennie is keni) atirom az assemblyben a required versiont 1.1rol 1.0ra -
#73
Miracle
senior tag
return.value
#72
Miracle
senior tag
válasz
return.value
#72
üzenetére
igen, ha nem soronkent valtozna, hogy managelt kod, nem managelt kod akkor teljesen semmi bajom nem lenne, de sajnos ugy valtozik. elojohetnek olyan problemak, amikknek utana kellene olvasni, hogy mi mindent kell nekem torolni, hogy hogyan kell a GCt vezerelni, hogy mit lehet a heapra pakolni manualisan, hogy mi kerul a .NET heapre, es mi a win32 heapre, hogy .NET esemenykezelobol inditott .NET thread mennyire szeret a win32 hepjen turkalni, tud-e deallokalni, meg ilyesmi. na ez az amire most nem ertem ra megtanulni
-
#71
Miracle
senior tag
return.value
#70
Miracle
senior tag
válasz
return.value
#70
üzenetére
hmm managedC++ nem CILre fordit, hanem egy eleg erdekes megoldassal CILre es nativ X86ra is egyszerre. es ha .NET framework komponenseket szeretnek boviteni (az ontartalmazo widgetek hive vagyok) akkor egy csomo olyan problemaval talalom szembe magam, amire a fordito dob nekem warningot(tobbet nem tehet), es nekem kellene figyelmesnek lennem.
-
Miracle
senior tag
-
#40
Miracle
senior tag
paramparya
#38
Miracle
senior tag
válasz
paramparya
#38
üzenetére
akkor a tobbszoros oroklodes gyonyoreibol kimaradtatok
-
Miracle
senior tag
válasz
BlackWoOd
#35
üzenetére
eloszoris bocs a topicgazdatol, h szetoffoljuuk a topicot
akkor ugy latom, hogy nagyjabol egyetertunk. A problema szerintem az, h a delphit oktatjak, es a foiskolak nagyreszeben a delphivel le is van tudva a programozas tanitas, es az ilyen modon kepzett ,,programozok'' (mert ez azert nem igazi programozokepzes) elarasztjak a piacot. lehet, h azert haragszom ennyire a delphi programozokra, mert nemreg 3000 sor c++ kodot irtam ujra hasonlo okokbol
es a delphi programozok jelentos resze meg van gyozodve rola, h objektumorientalt kodot gyart na mind1.
RAD: igen, igaz, csak kiemeltem egyet (Eclipse, netbeans, designer rlz )
megkoti a kezem: hat most nem kezdem el sorolni a c++-al bevezetett sutemeny kis tecshnikakat(ilyen-olyan smartpointerek, nyelvi eszkozokkel keszitett GC, ... gondolom nem kell sorolni) amik mas nyelvekben nem erhetok el, es a template metaprogramming csak hab a tortan. -
Miracle
senior tag
válasz
BlackWoOd
#31
üzenetére
Akkor kezdetben emlitsuk meg azt az aprosagot, h a pascal kitalaloja nem tartotta erdemesnek a delphit arra, hogy megtanulja, mert a programozas az C* nyelven tortenik, a tanitas meg Pascalul, de ez csak egy apro annekdota.
Hogy mi bajom a Delphivel? az, hogy gusba koti az ember kezet, es objct-pascal ide, oda, igazabol erzesem szerint nem sikerult igazan objektum-orientalt vagy akar csak objektum-elvu nyelvve tenni, de sokan megis ekepp allnak hozza. Es a problema ott van, hogy ha valaki megtanul jol programozni Delphiben, akkor az a kenyszerkepzete tamad, hogy o most mar akkor tudja, hogy mi az az ojektum-orientaltsag, es amikor atmozdul mondjuk c++ra, akkor elkezd Delphi kodokat gyartani c++ szintaktikaval.(aki azt mndja, hogy c++ul JOL meg lehet tanulni 2 even belul, az hazudik) es mivel programozni alapjaban veve tud, nyilvan nem fog raszanni ennyi idot, hogy elmelyedjen a c++ filozofiajaban, es kedvenc tanaromat idezve ,,eletveszelyes c++ tudassal'' elkezd nagyobb szoftvert fejleszteni. Ekkor gyakran olyan hibakba utkozik, amit nem ert, vagy olyan hibakba, amik egy egy technologia felszinenek karcolgatasaval elokerulnek, de eleg ritkan melyed bele, es egy marad a heggesztgetes, hogy mukodjon.
persze tisztelet a kivetenek, vannak tenyleg nagyon tehetseges programozok, akik Delphivel kezdtek tanulni, es ,,jol'' nyergelnek at mas nyelvekre, de a nagy tobbseg nem ilyen. Es az, hogy az emberek nem zsenik persze nem az o hibajuk, hanem a tanaraike, akik az objektum-,,orientaltsagot'' delphiben tanitottak meg nekik.
Ugyan ez all a Javara, meg a c#ra is, bar azokat joval rovidebb ido alatt el lehet sajatitani, mint a c++t.
Szoval a problema nem azzal van, hogy valaki Delphiben programozik, user-interface tervezeshez az egy kivallo eszkoz, sot egyszerubb appokra is, hanem azzal, amikor a Delphi programozo egy 150 oldalas c++ konyvvel ter at egy masik nyelvre. mert az ,,oktatasnak'' nem ez lenne a celja szerintem. -
#28
Miracle
senior tag
paramparya
#27
Miracle
senior tag
válasz
paramparya
#27
üzenetére
megvan a velemenyem azokrol a tanarokrol, aki meg MA is delphit, vagy valami regi pre-szabvany c++ -t tanitanak az oraikon...
a pascal tanulonyelvnek szuletett, es nem is kellett volna sokkal tobbet kihozni belole, az oktatok lustasaga az egyetlen oka a sok sok delphi-programozonak, es delphiben fejlesztett -gyakran- ganyolasnak -
Miracle
senior tag
a c# nem nativ kodot fordit, hanem egy ugynevezett CIL azaz Common Intermediate Language kodot, amit a gepeden levo .NET framework JIT compilere fordit vegulis a te geped nativ kodjara.
a CIL egy stack-machine(hasonlo a Java Bytekodhoz, ), es mivel nem nativ kod semmilyen kornyezetben, teljesen folosleges ASM kodokat hasznalni, mert csak kevesbe optimalis megoldast tudsz gyartani, mint a c# compiler. nem CIL, hanem platformfuggo ASM betetek elhelyezesere ugy tudom nincs mod. ha megis CIL ASM-ekbol akarsz assemblyit epiteni, akkor a m$ weboldalain megtalalod a CIL specifikaciojat, es van CIL kodegenerator namespace is a .NET libben, csak mar nem emlekszek a pontos nevere -
Miracle
senior tag
mindent dobhatsz, aminek valamely ososztalya a System.Exception.
a windows formsot nem ismerem, es igy abban a kivetelkezelest sem, de szerintem a kivetelek terjedese ott is a hivasi stacken tortenik, szoval a kivaltas helyerol indulva lepked a kivetel a hivasi vermen visszafele addig, amig el nem kapod valamelyik metodusban.
ha van catch reszed, akkor az nem csak az ott emlitett kivetelt, hanem annak minden SZARMAZTATOTT osztalyat is elkapja, tehat mondjuk egy
catch (Exception e) {/*...*/}
MINDENT elkap. persze ez nem igazan okos megoldas, mert nem jo semmire, a kivetelek hasznalatat nem kell tulzasba vinni, ha mondjuk csak elkapnal egy helyen minden kivetelt, es utana kilepnel a programbol valami hibauzenettel, h innen meg innen leptem ki, akkor okosabb, ha inkabb megsporolod azt a par sor kodot, es olvashatobb marad, amit csinalsz, es egy csomo plussz informaciohoz jutsz, mert a stderr-en megjelenik a kivetel terjedesenek pontos utja, es vegeredmenyben igyis ugyis kilep.
na visszaterve: ha kulonbozo kiveteleket akarsz dobni adott helyen, akkor neked kell eldontened, hogy kulonbozo kivetelosztalyokat deklaralsz, vagy egy kivetelosztalyt, es annak tobb attributumat, ahogy neked tetszik. -
Miracle
senior tag
a beepitett kiveteleket nem biztos, hogy szerencses hasznalni, de te is tudsz sajat kiveteleket definialni, csak a dobhato, vagy kivetel osztalybol kell szarmaztatni
de eleg gyakran az is eleg, hogy sima Exceptiont dobsz egy jo kis stringgel, ami elmondja, hogy mizujsag.
Amugy ha kiveteleket akarsz hasznalni rendesen, akkor erdemes kicsit utanaolvasni a java fele kivetelkezelesnek, meg a c++ felenek, (elobbi kivetelterjedest szigoruan deklaralo, szabalyozo, utobbi ,,ertelmesen'' kivetelkezelo) es eldonteni, hogy neked melyik tetszik. -
Miracle
senior tag
-
Miracle
senior tag
hat igen, ha valamit javaban fejlesztesz, akkor azt valoban valtoztatas nelkul futtathatod MACen, linuxon, solarison, windowson is, de a .NET frameworknek csak windowsos portja van, barmilyen meglepo is ez a m$ reszerol
amugy a gombok, meg stapobbi elemmel kapcsolatban... nezd meg a borland c++ buildert, es kerdezd meg a m$ot, hogy mi tartott 10 evig? ok mar 10, de legalabb 9 eve csinalnak ilyen appokat IDEket
amugy felreertes ne essek, jo a VS 2K3, csak ha 5 evvel korabban jon, akkor meg korszerunek is mondhatnank...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
es ugye tudjuk, hogy a m$ milyen processzorokon tud piaci eredmenyeket felmutatni 
es a delphi programozok jelentos resze meg van gyozodve rola, h objektumorientalt kodot gyart 
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- BESZÁMÍTÁS! Gigabyte B760M i5 14600KF 64GB DDR4 512GB SSD RTX 3080 10GB Corsair 4000D Airflow 1000W
- DELL Precision 7540 - Intel Core i9-9980HK, RTX 3000 (nagyon erős GPU-val)
- BESZÁMÍTÁS! GigabyteA620M R5 7500F 32GB DDR5 500GB SSD RX6700XT 12GB Bitfenix Nova Mesh Enermax 750W
- LG 77G3 - 77" OLED evo - 4K 120Hz 0.1ms - MLA - 2000 Nits - NVIDIA G-Sync - AMD FreeSync - HDMI 2.1
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest