- ZIDOO médialejátszók
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- NVIDIA® driverek topikja
- Melyik tápegységet vegyem?
- Analóg fényképezés
- Házimozi belépő szinten
- RDNA 4m architektúrával jönnek az AMD készülő IGP-i
- KINEK KELL EZ? 🤨 — MacBook Ultra leak
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen billentyűzetet vegyek?
-
PROHARDVER!

Ú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
● olvasd el a téma összefoglalót!
- ZIDOO médialejátszók
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- A Föld teraformálásával építene galaktikus birodalmat Elon Musk
- Milyen okostelefont vegyek?
- Drón topik
- Formula-1
- NVIDIA® driverek topikja
- Fotók, videók mobillal
- iPhone topik
- További aktív témák...
- Dell Inspiron N5010 i5 laptop
- Logitech G920 PC/Xbox kormány.
- Elektronikus tárolómérleg 40 kg-ig, LCD alig használt
- ROG Core PC - ROG X570, Ryzen 7 3700X, 16Gb RGB, ROG RTX 2060 Super 8Gb, 500Gb M2 SSD - Windows 11
- !AKCIÓ! GAMER PC Intel Core i5-12600KF/ASRock - Z790 PRO RS/D4/MSI RTX 3080 Suprim X 10GB/32 GB DDR4
- HIBÁTLAN iPhone 12 mini 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3818
- Azonnali készpénzes nVidia RTX 2000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Gaming PC! Ryzen 5700X / RTX 3070 / B550 / 32GB 2666Mhz / 512GB NVMe / 850w Gold! BeszámítOK
- HP ZBook Studio G8 i7 32GB RAM 1TB SSD RTX A3000/Garancia
- 171 - Lenovo Legion Pro 7 (16IAX10H) - Intel Core U9 275HX, RTX 5080 (ELKELT)
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

), 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.

