- iPhone topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Honor 200 Pro - mobilportré
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Huawei Watch GT 6 és GT 6 Pro duplateszt
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Mobil flották
-
Mobilarena

Ú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!
- AOC Q27G3XMN 27" 180Hz 1440p gamer monitor
- Iphone 13 mini mobiltelefon eladó
- Ryzen 5 5500 (ÚJ, 2 ÉV GARI) - 16 GB DDR4 3200 MT/s CL16 - 1 TB NVMe SSD (G4) - MSI MAG Vampiric ház
- Samsung NP270E5E-K07PL Notebook 3 órás akkuval
- Új Gamer PC - Ryzen 7 5700X / RTX 5060 Ti / B550M WIFI / 16GB RAM / 1TB SSD / 650W
- Samsung Galaxy Note 20 Ultra 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- 196 - Lenovo Legion Pro 5 (16IAX10) - Intel Core U7 255HX, RTX 5070 (ELKELT)
- Azonnali készpénzes Sony Playstation 4 Slim / PS4 Pro felvásárlás személyesen/csomagküldéssel
- Apple iPhone 14 / 128GB / Kártyafüggetlen / 12HÓ Garancia / Akku: 85%
- Bomba ár! Lenovo ThinkPad T14s G1 - i7-10G I 16GB I 512GB SSD I 14" FHD Touch I Cam I W11 I Gari!
Á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.

