- gban: Ingyen kellene, de tegnapra
- Rap, Hip-hop 90'
- Luck Dragon: MárkaLánc
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- vrob: Az IBM PC és a játékok a 80-as években
- hdanesz: Elektromos autózás - első élmények
- Parci: Milyen mosógépet vegyek?
- zebra_hun: Hűthető e kulturáltan a Raptor Lake léghűtővel a kánikulában?
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
Új hozzászólás Aktív témák
-
Miracle
senior tag
válasz
Lortech #1925 üzenetére
Garbage collector meglepően hatékonyan végzi a dolgát, nyilván egy jó programozó manuálisan hatékonyabban meg tudja oldani, csak sok felesleges meló és komoly odafigyelés kell hozzá, sokkal nagyobb a hibalehetőség. Szóval a GB jóó.
A modern, generacios elvu GCok, amiket a java es .net is hasznal hetszeres memoriaigeny mellett tudjak azt a sebesseget hozni, mint ugyan az a kod manualis felszabaditas hasznalataval. Ez nyilvan fugg az objektumok szamatol es meretetol, es nem problema egy word vagy egy explorer eseteben, ezek igy sem esznek sokat, de az az alkalmazas amin most dolgozok egy egyszerubb kiepiteseben megzabal 8 gigat es ez csak feljebb megy. nagyjabol 15 eve az eppen aktualis esszeru hataron mozog a memoriaigeny, nalunk meg ketszeres memoriaigeny is keresztbetenne, de akkor mar eleg komoly overheadre kell szamolni a processzorigeny teruleten is. a GC megkerdojelezhetetlen elonyokkel is rendelkezik, eppen ezert keszitettek olyanra a c++ nyelvet, hogy magaban a programunkBAN, egy libraryban, c++ nyelvEN lehessen garbage collectort imlementalni, a fordito legkisebb buheralasa nelkul, tisztan a nyelvben(en eleg gyakran hasznalok GCt, igaz nem az elobb emlitett projektben), ugy, hogy nem kotelezo minden objektumot a GC felugyeletere bizni, ha valamirol pontosan tudod meddig kell elnie akkor nem csinalja az overheadet. De azzal, hogy a GC hasznalata kotelezove valt beledrotoztak a nyelvbe egy overheadet, es ha ki akarom kerulni a programom szerkezetet kell modositani (keves objektum, sok tomb adattaggal) ami szerintem nem szerencses.
Arra gondoltam, hogy a végén ugyanaz a kód fog lefutni, attól függetlenül, hogy c#-ban írtad eredetileg, vagy c++-ban. Persze ez a.net (CLS, CLR) sajátossága. Mindegy, ezt így kár kiragadni, a contextusban volt értelme.
Hat igen, ha c++t forditanank .NETre, akkor bizony nem kapnank gyorsabb kodot, mint c# eseteben, de a c++t ugy terveztek, hogy ne legyen szukseg egy .NETre a futtatashoz, a c#ot pedig ugy, hogy szukseg lett ra.
Az utolsó előtti bekezdéseddel értek egyet legkevésbé, én nem gondolom, hogy a c#-ban ennyire alárendelték a minőséget és a teljesítményt az elsajátíthatóságnak és a ''fejleszthetőség sebességének''
nem a minoseg rossz, hanem a koncepcio joval egyszerubb, es keevsebb benne a feature, ezt konnyebben meg lehet tanulni, de gyengebb eszkozt kapsz. Nem a minoseggel van a baj, hanem a tudassal. Azaz azzal sincs baj, pontosan azt a szintet talaltak el amit akartak: a javanal okosabb, de megis egyszeru en tanulhato nyelv. Az elobbi hasonlatra visszaterve az eldobhato muanyag ollo is jol mukodik 1-2 evig, teljesen tokeletes, de 60 ev mulva aligha fogsz vele akarmit elvagni. Nem a minoseg gyenge, hanem az eszkoz maga gyengebb, kisebb celokat celoz meg mint a ,,nagymamam acelolloja'' amit meg en is hasznaltam es most is mukodik tokeletesen
és a c++-t sem tartom ebben etalonnak
etalon nincs, csak bizonyos celokra valamely nyelv jobban megfelel mint a tobbi.
mission critical rendszerekhez ada, vagy funkcionalis nyelvek imho, kis egyszeru appokhoz java/c#/perl/python, igazi izom applikaciokhoz C/C++, numerikus algoritmusokhoz fortran, stb. persze ez nem ultimate elosztas, csak szereny velemenyem.
c/c++/c# guru és mégis a c#-ot forszírozza, pedig a többszálú illetve párhuzamos programozás a szakterülete, erősen a hatékonyságra és teljesítményre kihegyezve.
Igazabol a C es a C++ memoriamodellje alkalmatlan igazan jo tobbszalu programok keszitesere, mar ahhoz is fordito-oldali segitsegre van szukseg, hogy egyaltalan lehessen optimalizalt kodot kesziteni tobbszalu progikhoz. Ezzel szemben a c# es a java nyelvi elemekkel tamogatja a tobbszalusagot, es a .NET 1.1 illetve a java 1.3 mar viszonylag kifejlett es hasznalhato memoriamodellt ad a juzer kezebe amivel lehet masszivan tobbszalu progikat irni multiprocesszoros rendszereken is. (1.1es .net es 1.4as java meg el-el halt igazi MPU rendszereken)
/Na meg a 4gl nyelvek./
na ezeket tartom kamunak, 4. generacios nyelvek nincsenek, ezek technologiak es nem nyelvek, sajnalom, h terjed ez a fogalom... ez is csak marketing, es elegge szar h szakman belul is el lehet adni
[Szerkesztve]
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- CNC topik
- Okosóra és okoskiegészítő topik
- Starlink
- Genshin Impact (PC, PS4, Android, iOS)
- Vivo X200 Pro - a kétszázát!
- Anglia - élmények, tapasztalatok
- IGP nélküli processzorokkal készül az Intel és az AMD
- Kecskemét és környéke adok-veszek-beszélgetek
- Házimozi belépő szinten
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- AKCIÓ! ASUS STRIX B650E-E R7 7700 64GB DDR5 1TB SSD RTX 3080 10GB Thermaltake Ceres 500 850W
- ÁRGARANCIA! Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! GIGABYTE AORUS MASTER RTX 3070 8GB GDDR6 videokártya garanciával hibátlan működéssel
- Telefon felvásárlás!! Samsung Galaxy S21/Samsung Galaxy S21+/Samsung Galaxy S21 Ultra
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025) - 3 év gari - MAGYAR
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest