Mekkora memóriaszivárgás mondható kritikusnak szerinted?

Programozás

1 bit
54% (183 szavazat)
~ 4kB /óra
11% (37 szavazat)
~ 4MB /óra
12% (41 szavazat)
~ 4GB /óra
6% (19 szavazat)
~ 4TB /óra
2% (7 szavazat)
Egyéb
15% (52 szavazat)
Összes szavazat: 339

Magas rendelkezésére állású? Szolgáltatás-kiesés nélkül átterhelhető? Mi az elvárt SLA? Folyamatos üzemű?
Mekkora a szivárgásban érintett teljes memóriaterület és annak átlagos telítettsége? (Láttam már Windows-on egy alkalmazás miatt non-paged poolt szivárogni. Igaz, hogy lassú volt, de a kevés meg hamarabb fogy el...)

Üdv,
Marci

Mondjuk:
Scenario A,
99.95% .. 99.99% , igen atterlheto, kill -9 -al es nemi LB trukkel `gyogyithato` lehetne. (Hozza fersz a szivarogtato kodhoz is)
Tervezet rovid downtime 6 havonta.

Scenario B,
Nem atterhelheto, magasabb SLA.

Maskep szavazol A/B esetben?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kiszámoltam itt és igen, másképp:
Scenario A: a 4MB/óra számomra épp az elviselhetőség határán van (fél év alatt 17GB RAM lesz a szivárgás, rendszeres átterhelésekkel pedig kordában tartható)
Scenario B: a 4MB/óra nem vállalható. Mondjuk az is legény, aki 99.99% fölötti SLA-val át nem terhelhető szolgáltatást üzemeltet. Szívesen elbeszélgetnék vele. :)

Üdv,
Marci

( pilisig | 2016. 11. 29., k – 15:09 )

Mivel nemrég 3 hetet szoptam egy memóriaszivárgásos bulival, így zsigerből az 1bitre szavaztam. Tíccsákbe az illegális tevékenységeket memóriaszvárgásokat!!!

-pilisig-

"Mivel nemrég 3 hetet szoptam egy memóriaszivárgásos bulival, így zsigerből az 1bitre szavaztam. "

Szoval 1 bitnyi memoriaszivargasnak magas prioritast adnal, es szerinted megerne vele akar 3 hetet szivni?!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

"3 hetet szivni" attol fugg, ha dinamikusan skalazhato rendszered van, ahol igyis-ugyis jonnek mennek a peldanyok, es mondjuk fifo-val rotalod a peldanyokat, es normal eletciklusban alig kimutathato a szivargas merteke, es garantalhato, hogy a normal terhelesen tul nem omlik hirtelen 20x annyi request a peldanyra, es van egy prediktiv monitorozo rendszered, ami ha megis gaz van ki tudja vonni a forgalombol a peldanyt, akkor nem.
-
Go konkurencia kezelés gyorstalpaló

60 ember munkáját akadályozta az alkalmazás ami a szerveren 2 nap alatt felzabálta az összes memóriát, majd meg is döglött, ofkóz. Kicsit érzékenyen érintett, mostantól mindenféle szivárgást utálok. És ez vonatkozik a kurva csaptelepre is, pár hete az is elkezdte, hogy rohadjon meg. :D

-pilisig-

( nagy_peter v | 2016. 11. 29., k – 15:18 )

Szerintem definicióból adódik: "memóriaszivárgás: Kritikus programhiba, amelynek következtében a már használaton kívüli memóriablokkok sem kerülnek felszabadításra, és ami így hosszú távon a szabad memória teljes elfogyását okozza."

Nagy Péter
www.ddo.hu

Jön valaki, hogy kellene összeharácsolni egy lekérdezést, ami összehúz 3 db-ből valami komplexebb összehasonlítást. Tákolok rá egy PHP scriptet, ahol elfelejtem felszabadítani a db resultot. Egyébként hiba nélkül lefut a script (tehát nem "show-stopper"), csupán nagyobb a memóriaigénye.

Most akkor kritikus-e vagy sem?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igazad van, félreérthető.

Nem is a kritikus szót kellene definiálni, hanem azt, hogy súlyosságként (severity) vagy prioritásként (priority) értelmezzük. A memóriaszivárgás definíciójából, amit Nagy Péter idézett és a későbbi magyarázatból egyértelműen kiderült, hogy itt a kritikust súlyosságként értelmezik és a prioritása ettől lehet eltérő (nagyon ráér).

Összefoglalva: kritikus súlyosságú, de nem kritikus prioritású.

Ha egy one-time consle scriptrol beszelunjk, a kutyat sem ... , kilepeskor felszabadul...
Indokolatlanul nagyobb memoria igeny ( khm..PHP), es memory leak ket kulon dolog.

Ha egy 300..3000 req/sec server oldalon marado permanens obj leakrol beszelunk az mas teszta,
legalabbis az ilyesmirol szolna a szavazas.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ha egy 300..3000 req/sec server oldalon marado permanens obj leakrol beszelunk az mas teszta,
legalabbis az ilyesmirol szolna a szavazas.

Ha ez a rendszer microservice-ekből épül fel és egy szervice kiesése a kutyát se izgatja, akkor a script-es esetnél vagyunk.

Először azt kellene tisztázni, hogy a szavazásnál arra gondolsz, hogy kritikus súlyosságú vagy arra, hogy kritikus sürgősségű.

A súlyosság szerintem egyértelmű, minden olyan hiba, ami a program leállását okozhatja, kritikus súlyosságú. Az, hogy egy ilyen hiba következtében a program leállása mekkora valószínűséggel és mekkora problémát okoz, jön képbe a hiba javításának sürgőssége. Ez lehet kritikus sürgősségű és az egyáltalán nem kell javítani közt bármi.

Csak ha nem szandekos ;-)


main(){
...
a = alloc()
...
free(a)
exit(0)
}

vs.


main(){
...
a = alloc()
..
exit(0)
}

A 2. -ra siman re lehet fogni, hogy szandekos optimalizacio,
ettol meg minden elemzo szoftver alapbol sirni fog miatta.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Egyébként hiba nélkül lefut" tehat nem fut le hiba nelkul ;) ha hiba nelkul futna eleresztene a kapcsolatot

Ok tetelezzuk fel, hogy nem tekintjuk kritikusnak, erzem, hogy ezt sugallod a kerdes felvetessel. Mi torteni akkor, ha az a valaki elmeseli mondjuk masik 867 embernek, hogy milyen szuper funkcio van az oldalon, es megtoljak mindennyian. Utolag mikor osszahannya magat a rendszer kritikusnak fogod gondolni? Ha garantalva van, hogy mas nem hasznalja a scriptet, mondjuk azert mert azonnal torolted miutan lefutott, akkor "mernok oraban" egy percet sem erdemes raaldozni. De a script hasznalhatosaga szempontobol kritikus hiba van benne.

-
Go konkurencia kezelés gyorstalpaló

Ezzel az erővel a tervezett restartot is nevezhetjük "felszabadításnak". Vagy amikor az OOM killer legyakja és a watchdog újraindítja. Stb.

Az alkalmazás életciklusát tekintve lék. Csupán az alkalmazás életciklusa más.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( saxus | 2016. 11. 29., k – 15:28 )

Hol?

Egy folyamatosan futó serviceben? Egy folyamatosan futó service által időnként indított háttérfolyamatban? Egy desktop alkalmazásban, aminek a tipikus use-caseja szerint 8 óránál többet nem használják? Egy egyszer lefutó php scriptben?

Ez a kérdés így totál értelmetlen és értelmezhetetlen.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Java

:)

(Viccet félretéve, igen, tudom, managelt nyelvekben is el lehet leakelni dolgokat, pl. resourcekkel, vagy .NET-ben eseményekre való fölösleges feliratkozásokkal, de azért ahhoz már egy picit erőlködnie kell az embernek.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak én vagyok az egyetlen aki mindig alvó módba rakja a gépet? Hiába van ssd a gépemben, jobban szeretem ha másnap pontosan ugyanonnan tudom folytatni a munkát/olvasást/böngészést/stb ahol abbahagytam.
Ilyen felhasználási mód mellett még szerintem desktopton se elhanyagolható hogy van-e szivárgás.

( uid_20558 | 2016. 11. 29., k – 16:12 )

My memory-leak-o-meter:
* Amikor trollkodok a hupon: 1 bit
* Amikor osztom azt észt a kollégáknak: ~4kB/óra
* Amikor magamnak valami nagyon fasza programot írtam: ~4 MB/óra
* Amikor megrendelőnek kell átadni a szoftvert: ~4GB/óra
* Amikor a megrendelő péntek délután veri asztalt h nem jó ez a szar: ~4TB/óra...

Trolololo :-)

Mondok egy pár érvet a C mellett:

- a java / C# magas szintű nyelvek, kétlem hogy valaha is driver-t fogsz programozni benne. Lassú, a hardver hozzáférése korlátozott.
- a C++ nagyon kényelmes nyelv, akár garbage collection is megvalósítható vele, viszont nem átlátható. A java például nem engedi az operator overloading-ot, copy constructor-okat és társait, nem véletlenül. Nem véletlenül nincs java-ban unsigned int sem. Kényelmes, gyorsan haladsz vele, viszont amit látsz a programkódban és amit a C++ végrehajt, az teljesen más. Beírod, hogy "ComplexNumber c=2", ami meghív konstruktort, legvégén destruktort, sőt, egy csomó más is lehet bonyolultabb kifejezéseknél és fogalmad sincs a végén, hogy milyen sorrendben mész végig.
- interjúztattak C++-ból, megadtak egy bonyolult kifejezést, amit csak akkor tudtam volna megoldani, ha képben vagyok, hogy melyik konstruktor/destruktor mikor és miért hívódik meg. Megkérdeztem a vizsgáztatót, hogy ennél a cégnél ilyen kódokat szoktak írni?
- a C hardverközeli nyelv, amikor grafikus TFT kijelzőt írsz, esetleg ethernet TCP/IP stacket, akkor nincs módod szarakodásra. Nemhogy konstruktoron/destruktoron nem gondolkodol, de a függvényhívásokat is átnézed, mert lassítják a feldolgozást. Egy függvényt ha tízmilliószor meghívsz, akkor annak mérhető költsége van, ez pedig egyáltalán nem szokatlan az informatikában.

Jópár évet töltöttem informatikában, de videókártya drivert C-ben kezdenék implementálni (talán C++), az összes többi nyelv szerintem alkalmatlan rá.

Mi nem szeretjük a C-t, persze te attól még szeretheted.

Senki sem mondta, hogy videokártya drivert akarna C#-ban írni. Vagy bármiben.

"akár garbage collection is megvalósítható vele," — persze, megvalósítható, csak én még nam láttam olyan projektet, ahol használták volna a smart pointereket. Talán a QT az egyetlen projekt, ahol mégis.

A C++ meg 30 év fejlődés után lassan eléri a C# 2.0 tudását... Már csak egy rendes standard library kellene, ami jó is valamire.

Fuszenecker Róbert

> A C++ meg 30 év fejlődés után lassan eléri a C# 2.0 tudását...

Nem menjünk bele a részletekbe. Sokszor lerágott vitatéma, hogy a Windows-only nyelvekben mennyi fejlődési potenciál van 2017-ben, amikor a világ tele van Linux szerverektől, MAC-on, iPhone-on át Android tabletekig, routerekig, mikrovezérlőkig,... Mindezek mellett a desktop PC-k kora leáldozóban van. Nem vagyunk egy véleményen a C#-ban rejlő lehetőségek tekintetében.

Pfff, Windows only, igen:

* https://www.microsoft.com/net/core
* http://www.mono-project.com/download/
* https://www.xamarin.com/

"Mindezek mellett a desktop PC-k kora leáldozóban van."
És mindenki dobja kifelé a laptopjait, desktop gépeit, ugye?

Legalább ne hordj már össze ennyi hülyeséget. Vagy google-zz előtte.
Csak egy kis adalék: van egy linuxos szerverem, nginx + ASP.NET Core. Mert ez ugye Windows-only.
Van hozzá Android kliens, na milyen nyelven nav írja? C++, ja nem, C#.

Amíg a C++ szabvány készítői azon tanakodtak, hogy legyen-e UTF-8 karakter literál, addig a gonosz és gyűlöletes MS full open-sourcse-szá tette (GitHub) a komplett fordító platformát (Roslyn), kiadta a .NET keretrendszer forráskódját, biztosít 3 platformra IDE-t.

Fuszenecker Róbert

Bocs, Windows Forms only, ha már a mono-nál tartunk.
:)

Mellesleg a Linuxom alatt azért van mono, mert a Git Extensions használja. Komplett Linux disztribúció csodálatosan érzi magát mono nélkül is.
Eközben a C++-t nem lehet megkerülni.

A helyzet az, hogy még vagy 30 évet kellene a C#-nak fejlődnie, hogy eljusson oda, ahol a C++ most tart.

Használtál már mono-t? Tudsz választani: vagy Windows Forms, vagy GTK#. Egyik szarabb, mint a másik.

A "Git Extensions" nem is képes színezni a diff-eket Linux alatt, mert komplett trágyalé az egész grafikai alrendszere a mononak. A fejlesztők azt mondták, hogy nincs kapacitásuk Linux alatt újraírni az ablak kezelést, egyszóval meghaladja a képességeiket egy szöveg piros és zöld háttérrel való kiszínezése. Ami működik az nem kereszt-platformos, ami kereszt-platformos, az meg nem működik. Ebből tessék választani.

Linux alatt azért nem terjedt el a mono, mert nem versenyképes. Amit a mono nyújt, azt a java grafikai képességei is messze meghaladják.

Nem azért nincs Linux alatt mono, mert a fejlesztők tudatlanok és oktondiak, hanem azért mert nem racionális döntés Linuxon C# alatt elkezdeni fejleszteni.
Papíron keresztplatformos nyelvről beszélünk. Papíron elvileg használják is keresztplatformosan, van olyan ember, akinek az ismerősének a haverja használta is kereszt-platformosan.

De most őszintén, ki az, aki desktop appot ír Linuxra?
Amikor ott van az Android, amivel még esetleg egy kis pénzt is lehet keresni (a webről már ne is beszéljünk).
Vajon hány linuxos fog megvenni egy desktop programot?

Linuxon max. egy web appot vagy service-t érdemes hosztolni.
Arra kiváló, szerintem a legjobb.

De desktopként én már rég nem tartom számon.

Azt már csak halkan teszem hozzá, hogy a monodeveloposoknak mégiscsak sikerült megoldani GTK#-pal, hogy Linuxon is menjen a Monodevelop. És MacOS-en is. És Windowson is. Akkor ők rontottak el valamit? Vagy mégiscsak jó a GTK# valamire?

Fuszenecker Róbert

> Azt már csak halkan teszem hozzá, hogy a monodeveloposoknak mégiscsak sikerült megoldani GTK#-pal, hogy Linuxon is menjen a Monodevelop.

Légyszíves ne szórakoztass az egyetemi diplomamunkákkal. Majd 10 év kellett nekik, hogy debuggolni is lehessen a monodevelop nevű szarban. Mindent meg lehet oldani GTK#-pal is, csak nem érdemes. A Nokia Symbian telefonjaval is mindent meglehetett oldani, csak senkinek eszébe nem jutott, annyira undorító gány volt az egész.

Mostanra eljutottak odáig, hogy valami dokumentációnak látszó hányadékot csináltak, ami az esetek 90%-ában képes a "fingom nincs róla, mit csinál"-on kívül mást is mondani.
Gyönyörködj benne:
http://docs.go-mono.com/?link=T%3aGtk.MenuToolButton

Szerintem telepíts egy Linuxot, installáld rá a monodevelop-ot és mondjuk írj meg egy "frozen bubble" bonyolultságú játékprogramot. Miután kész, meséld el, hogy mekkora élvezetet nyújtott a programozás.

Aki azt az egyetemi diplomamunkát írta, most a MS "Distinguished Engineer"-je (bármit jelentsen is ez). Nyilván nem ő az egyetlen.
Az az egyetemi diplomamunka az alapja egy kereskedelmi terméknek, amire a MS supportot vállal.

A főnököm, aki mellettem ül, 10 évig fejlesztett Xamarinnal. Ő szerette. Én is szeretem (a Xamarint).
De eszembe sem jut Linuxon fejleszteni. Eszembe sem jut Monodevelopot használni.
Minek, ha van Visual Studiom vagy Visual Studio Code-om.

Nem mondtam, hogy a GTK# a legkiválóbb UI toolkit, de használható.
Emellett C#-pal használhatod a WPF-et, a Xamarin Formst, de fejleszthetsz UWP-re, ha akarsz.

A C++ hogy áll pl. a UI frameworkökkel? A QT-n kívül van valami normális?
Web Framework? Vagy ha egy REST API-t szeretnék? Esetleg SOAP API-t? Vagy egy jó ORM? Vagy bármilyen ORM?

Fuszenecker Róbert

Eszembe sem jut Linuxon fejleszteni. Eszembe sem jut Monodevelopot használni.

Annyit tennék hozzá, hogy nekem sem jutna eszembe Linux alatt monodevelopot és monot használni és láthatóan másoknak sem.
A Qt csodálatos keresztplatformos grafikai alkalmazás, gyors, jól dokumentált, megírod Linuxon, megy Windows alatt is, ugyanez elmondható a javaról is.

Itt le is zárhatjuk a témát. Mindketten beláttuk, hogy az ég világon semmi értelme a C#-os, gtk#-os baromságokkal szórakozni Linuxos rendszerek alatt.

Emellett C#-pal használhatod a WPF-et, a Xamarin Formst, de fejleszthetsz UWP-re, ha akarsz.

Ha Windows alatt win-only alkalmazásokat írsz.

A C# versenytársa Linuxon nem a C++, hanem a Java, ezt jobb ha tudod. Bárhol keresel a neten milliószámra találsz java-s megoldásokat. A linux disztribúciókon az openjdk alapból települ is és néha még működik is (bár javaslom mindenkinek, hogy cserélje Oracle jdk-ra). A C# Monodevelop - Java Eclipse kombó között azért van egy kis különbség...

"bár javaslom mindenkinek, hogy cserélje" ritka eseteket leszamitva semmi szukseg ra.

Q: What is the difference between the source code found in the OpenJDK repository, and the code you use to build the Oracle JDK?

A: It is very close - our build process for Oracle JDK releases builds on OpenJDK 7 by adding just a couple of pieces, like the deployment code, which includes Oracle's implementation of the Java Plugin and Java WebStart, as well as some closed source third party components like a graphics rasterizer, some open source third party components, like Rhino, and a few bits and pieces here and there, like additional documentation or third party fonts. Moving forward, our intent is to open source all pieces of the Oracle JDK except those that we consider commercial features such as JRockit Mission Control (not yet available in Oracle JDK), and replace encumbered third party components with open source alternatives to achieve closer parity between the code bases.

forras

-
Go konkurencia kezelés gyorstalpaló

Elég jól ismerem a Javat, pontosan tudom, hol a helye az ökoszisztémában.

De továbbra sem válaszolsz a kérdéseimre, helyette eltérsz a témától.

Szóval amit az okos C++ programozók össze tudtak hozni 30 év alatt, az egy őskövület nyelv és egy cross-platform GUI FW.
Bámulatos.

Fuszenecker Róbert

A seggembe kívánom a Win-only nyelveket, ez pedig nem meglepő, miután Linuxot használok. Nálam a C# = mono + monodevelop = trágyalé. Nem kell ezen többet filozofálni, egyszerűen egy büdös nagy szar az egész Linux alatt... Ez a szakszerű megfogalmazás.

Én meg érzelmi alapon nem óhajtok olyan programot írni, ami kizárólag Windows XP SP3-mal működik rendesen, írtózom a platform specifikus okádékoktól.
Inkább a perl5, bocs.

A rossz tapasztalataim 5 évvel ezelőttiek.

Erről a repóról nem tudtam. Ha van benne értelmes GUI API is, akkor el lehet kezdeni érdemben foglalkozni a kérdéssel, hogy C# és Linux.

Ez lehetne akár a GTK# is, ha vennék a fáradtságot és API doksit írnának hozzá. Nekem nagyon elgurult a gyógyszerem a dokumentálatlan API-tól. Semmi kedvem nem volt túrni a forrást, hogy kitaláljam, mit csinál egy metódus. Legalább MSDN szintű dokumentáció kellene, hogy érdemben munkavégzésre használható legyen.

Magával a nyelvvel egyébként nincs bajom, csak a fejlesztői környezettel, támogatással.

Látom, nem tudsz leszakadni erről a GTK#-os témáról.
Küldök egy repót, ebben végtelen mennyiségű példa van, megnéztem, text view háttérszínezés is.

Aki ez alapján nem tud megírni egy GTK#-os appot, annak valóban nem való a C#.
De ez nem a C# hibája. 


tag  = new TextTag ("red_background");
tag.Background = "red";
buffer.TagTable.Add (tag);

...

buffer.InsertWithTagsByName (ref insertIter, "a red background", "red_background");

Kb. 10 percet fordítottam a keresésre.

Fuszenecker Róbert

P.S. .NET Core-hoz (NETStandard 1.3/1.6-hoz) még én is várok a GTK bindingra, eddig nem készült el, de előbb-utóbb lesz.
P.S.2. Ez a GTK# kód nálam nem menne át a code reviewn. De demónak jó lesz.

Értem amit mondasz, de rendes API doksi linket küldj.

UI programozás az nem egyszerű a különféle interakciók miatt. Ami linket küldtél, az arra elég, hogy lefuttassam a demo programokat. Ha valami nincs benne a demo programokban, viszont szükségem lenne rá (a különféle view-k azért bonyolultak tudnak lenni), akkor lehet először a dokumentálatlan GTK#-ot túrni, ami a dolumentálatlan GTK-ba irányít bele, végül C kód szartúrásában végződik.

Sajnos belefutottam ebbe, hogy a GTK# programozáshoz elengedhetetlen C kódban vájkálni a pocsék dokumentáció miatt. A demo programjaikat megtarthatják maguknak, amíg nem lesz rendes dokumentáció, garantált, hogy hozzá nem nyúlok mégegyszer a GTK#-hoz. Nincs az a pénz, hogy én GTK C-s kódokban matassak.

Zsigerből utálom az egészet, nekem hosszú évekre elvette a kedvemet a C#-tól a GTK C-s libek túrása. Beleundorodtam.

A UI az sosem egyszerű, nem elég a demo programok gyűjteménye.

Nem érted, ezért összefoglalnám a dolgokat.

Amit én C#-on látok:
- a GTK# / GTK dokumentálatlan, GTK C API túrása nélkül használhatatlan.
- a Windows.Forms "egész jól megy", az MSDN-en dokumentálva van
- a WPF nem keresztplatformos
- van még Qyoto, Kimono, ami a Qt-t/KDE-t portolja C#-ra, előfordult már valakivel, hogy le is fordult, sőt az interneten van 2 projekt, ami használta is valaha. A fejlesztője utoljára pár éve committolt is a projektbe, szóval fantasztikus az egész

Te milyen keresztplatformos GUI-t használnál .NET alatt?
Én egyiket sem a fenti 4 közül, inkább más nyelvet használok, ahol van keresztplatformos GUI.

5 perc google után:
https://github.com/picoe/Eto

És itt van hozzá az MSDN szintű dokumentáció:
https://github.com/picoe/Eto/wiki

API ref:
http://api.etoforms.picoe.ca/html/R_Project_EtoForms.htm

Na, megnyugodtál? Ezek szerint mégsem olyan rossz a C#?

Na és melyik C++ GUI FW megy Linuxon, Windowson, Macen, iOS-en?

Fuszenecker Róbert

Személyes tapasztalatod van az Eto-ról, vannak nagy projektek amik használják, vagy csak úgy bedobtad a linket?

Bocs a kérdésért, de a mono/monodevelop alfa-pre verzióival való szórakozás egy kicsit szkeptikussá tesz engem C#-pal kapcsolatban. Elvesztettem a motivációmat a folyamatos dzsungelharcban és lehetőleg ha javasolsz valamit, azt ne 5 perc guglizás után tegyed, hanem mondjuk 2-3 hónap tapasztalattal, hogy igen, ezt használd, mert ez a tuti.

Demotivált vagyok. Próbáltam qyoto-t le sem fordult, próbáltam GTK#-ot, elakadtam a doksi hiányosságában, próbáltam Windows.Forms-ot, röhejes. Felraktam vagy 5 monodevelop verziót, egyikkel sem tudtam debuggolni,...

Valahol meg kell érteni, hogy egy komplett C# kiégés után nem fogsz 5 perc guglizással megoldásokkal dobálni, mert elhajtalak a fenébe.
Te mit használsz, neked beválik-e, érdemes-e javaról, C++-ról erre a C#-os platformra átállni, mennyiben jobb a C++/Qt párosnál, miben gyengébb...

Qt-ről tudni kell, hogy rengeteg projekt használja, bizonyítottan működik is.

Nekem az volt végig az érzésem, hogy volt egy 5 évvel ezelőtti rossz tapasztalatod, és elhatároztad, hogy utálni fogod az egész .NET ökoszisztémát. Írhatok én akármit, te azt már eldöntötted. Ehhez persze jogod van.

Nekem pozitív tapasztalataim vannak a C#-pal.
Nagy megelégedéssel használtam a Monot, a Monodevelopot (ma már nem, pedig ugye Roslyn backendet kapott), mindkettőt a hivatalos monos és monodevelopos repóból, nem azt a fosszíliát, amit a disztribúciókészítők adnak.

A desktop .NET-et lassan egy évtizede használom, a .NET Core fejlődését a kezdetektől nyomon követem és portolom a cuccaimat .NET Core-ra.
Ugyanez igaz a Visual Studio Core-ra.

A Xamarin is kiválóan működött, amikor használtam, egy gondom volt vele, azt a supportos srác megjavította (szombaton, ingyen).

Kiválóan és egyszerűen tudok akár desktop, akár web appot készíteni, vagy ha kedvem tartja, írhatok web service-t vagy mobil appot.
Amikor windowsra, akkor Windowsra, amikor Linuxra, akkor Linuxra, amikor Androidra, akkor Androidra.

Hogy te nem tudod a keretrendszert és a toolokat használni, azon én nem tudok segíteni.
Sokan vannak a .NET közösségben (igen, van ilyen, sőt, külön F#-os is, aminek én fenntartó tagja vagyok) még nagyszerűen megvannak vele.

Ha én csak azért dobnám a JS-t, mert 5 vagy 10 vagy 15 éve rossz tapasztalatom volt vele, akkor még mindig abban a föld alatti füstös lyukban ülnék backend vagy desktop programozóként, mint 20 éve.

Ahogy a bölcs latinok is mondják: Tempora mutantur, nos et mutamur in illis.

Fuszenecker Róbert

> Tempora mutantur, nos et mutamur in illis

Hiszek neked, így visszaveszek a fikkantásból. Jelenleg kicsit sem érdekel a C# téma, de ha valamikor lehetőségként előjönne, akkor újra letöltöm a legfrissebb verziókat és megnézem, hogy mi változott.

Magával a C# nyelvvel sosem volt bajom, csak azzal a környezetettel, amiben dolgoznom kellett...

> Mert az érveid csak a GUI-ról szóltak eddig.

A mobilisok Androidot használnak, ami egy java származék, a browser-ek javascript-et, java backend-del.
Nem látom, hogy hogyan jönne mono + monodevelop a képbe, amikor az égvilágon semmi szükség rá...

GUI-n próbáltam használni, GUI-n csődöt mondott az egész, ezután inkább maradtam a jól bevált valódi keresztplatformos megoldásoknál, ahol a C:\ az nincs bekódolva a rendszerbe nyelvi elemként.

Nem a felvazolt elvvel nem ertek egyet, csak kotekednek egy kicsit ;)

"Nem véletlenül nincs java-ban unsigned int" : In Java SE 8 and later, you can use the int data type to represent an unsigned 32-bit integer

"amit látsz a programkódban és amit a C++/JVM végrehajt, az teljesen más" : Ezert erdemes erteni legalabb nagyvonalakban, hogy mi az a bytekod vagy mit csinal a JIT. Szoval a lehetoseged ott van, hogy pontosan lasd azt is amire fordul a Java kod, ha szukseg van ra. A JIT meg nem valtoztat a vegrahajtas eredmenyen

"és fogalmad sincs a végén, hogy milyen sorrendben mész végig" : Az SCJP vizsga fele kb arrol szol, hogy mi milyen sorrendben tortenik, marmint mondhatod, hogy fogalmad sincs. neked! de pontosan specifikalva van, szoval nem random

"de a függvényhívásokat is átnézed, mert lassítják a feldolgozást" : ez platformfuggetlen dolog. Attol, hogy managelt a nyelv es/vagy oop attol meg ezt pont meg kell csinalni

"Egy függvényt ha tízmilliószor meghívsz, akkor annak mérhető költsége van" : Ha valamit Java-ban 10M meghivsz, akkor a JIT mar azt is reg optimalizalta, raadasul nem compile time hanem runtime, amikor mar pontos kepe van, hogy mi a fenet csinal az a metodus

Az a szep, hogy a lehetoseg ott van, de csak akkor kell foglalkoznod a reszletekkel, ha feltetlen elengedhetetlen.
-
Go konkurencia kezelés gyorstalpaló

"Palánkon kívülről" beleszólok informatív jelleggel.

írtad ---> "Egy függvényt ha tízmilliószor meghívsz, akkor annak mérhető költsége van" : Ha valamit Java-ban 10M meghivsz, akkor a JIT mar azt is reg optimalizalta, raadasul nem compile time hanem runtime, amikor mar pontos kepe van, hogy mi a fenet csinal az a metodus

Meglepődtem, x86-on igen szépen megy a Java JIT-je. ARM-on viszont nem működik a JIT és csigalassú a Java.

Konkrétan x86 esetén 100.000-szer futtatva 4096 pontos FFT algoritmust, Java-ban írtnak mindössze 1,6-szor több idő kellett a C-vel összevetve.
ARM-on viszont elvérzett a Java. Ott 100-szor lassabban futott a C-ben írt FFT-hez képest. További nyelvek teszteredményeiről a blogomba dobtam egy bejegyzést.

Amúgy valaki igazan eloallhatna mar egy "JVM via Java" szeru írással, mert szép meg jo, hogy a JVM erre meg arra képes, de nem igazan talalni semmi átfogó, részletekbe belemenő írást, hogy a gyakorlatban mi mit jelent, mi történik ténylegesen, stb.

(Főleg azért érdekelne ez, mert ugye rendszeres ervbek hozzak fel ezt az adaptív optimalizaciot/dinamikus reoptimalizaciot a JIT-telt nyelvekkel szemben, aztan kérdés, hogy a gyakorlatban mit jelent. Pl. A .NET 4-hez tartozó CLR via C#-ban is írjak, hogy bar elmeleti lehetőség volna a reoptimalizaciora, gyakorlatban nincs ilyen feature. Hogy azota raktak-e bele annak nem neztem utana. Igaz, a CLR kod az mindig atfordul natív kodra. )

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

lehet én nem olvastam végig ezt alaposan (biztosan), de ebben le van írva, hogy a JVM-nek milyen runtime optimalizációkat __kell__ végrehajtania?

mert tökjó, hogy specifikálva van, hogy az 

iconst_2

az azt jelenti, hogy ...
de azt előírja-e bármi, hogyha az 

iconst_2

eredményét figyelmen kívül hagyom (esetleg elrakom egy változóba, de semmi több), akkor bárminek, amit JVM implementációnak nevezünk:
* ezt nem szabad egyszer sem végrehajtania, tehát már az interpretálás alatt rá kellene jönnie, hogy ez fölösleges utasítás
* az első 3/10/100 futás után kötelező az ilyen fölös utasításokat kioptimalizálnia
* ...

Esetleg azt előírja valami kötelezően, hogy a 

Collections.singletonList(T t)

-n való iterálást mindegyik JVM-nek mennyire ki kell optimalizálnia?

Mert attól, hogy a szabvány megengedi, még messze nem biztos, hogy az OpenJDK/OracleJDK/IBM/etc tényleg csinálja is.
--
blogom

Igen, ilyesmire, csak részletesebben belemenőbe. (Nem feltétlen csak ebben, úgy kompletten a JVM-et illetően).

Pl. "During the second step of the machine-code generation process, the JRockit JVM uses a sophisticated, low-cost, sampling based technique to identify which functions merit optimization: a "sampler thread" wakes up periodically and checks the status of several application threads. It identifies what each thread is executing and logs some execution history."

Oké, de mitől low cost? Hogyan samplezik? Milyen gyakran ébred? Mit képes optimalizálni. Stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az elején hiányoltam egy ilyen könyvet én is, kifejezetten irigykedtem a CLR-sekre, hogy náluk van ilyen.
De elég kitartással lehet ilyeneket vadászni, például ezt: https://shipilev.net/blog/2015/black-magic-method-dispatch/

Az írás alapvetően másról szól (hogyan oldja meg a JVM az különböző függvényhívásokat), de van rá példa benne, hogy a JVM hogyan, s mikor optimalizál dolgokat.

tl;rd: Például ilyenek vannak, benne, hogy a következő kódban a 

do_Dynamic_Interface_Ref

mivé fodul, ha az id 0.1-0.9 arányban 0-1, vagy 0.5-0.5 arányban 0-1... 


interface Coder {
    int work(byte[] data);
}

class Data {

    private static final Coder coder0 = null; // new Coder0(); - itt volt megfelelő implementáció, de azt már nem másolom ide
    private static final Coder coder1 = null; // new Coder1(); - itt volt megfelelő implementáció, de azt már nem másolom ide

    private final int id;
    private final byte[] data;
    private final Coder coder;

    public Data(byte id, byte[] data) {
        this.id = id;
        this.data = data;
        this.coder = interface_ID_Switch();
    }

    private Coder interface_ID_Switch() {
        switch (id) {
            case 0: return coder0;
            case 1: return coder1;
            default:
                throw new IllegalStateException();
        }
    }

    public int do_Dynamic_Interface_Ref(){
        return coder.work(data);
    }
}

--
blogom

Igen, ez a bajom, hogy kitartással lehet vadászni. Nekem viszont pont, hogy egy átfogó írásra lenne szükségem. (Pl. a CLR via C# könyvben is szerintem az a jó, hogy ha valaki már tud azért programozni, akkor azt a könyvet elolvasva elég jól képbe kerülhet a nyelv és a CLR képességeivel, működésével, annak mélységével.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( iattilagy | 2016. 11. 29., k – 16:53 )

Csak én gondolkodtam vagy 1 percet mire rájöttem, hogy a memóriaszivárgás az a memory leak?

Illetve aki 4GB/órára vagy 4TB/órára szavazott az milyen vasra dolgozhat? :)

( mrceeka v | 2016. 11. 29., k – 17:24 )

Nézzük:
-1 bit: ez nyilván elvi kérdés akar lenni, hogy egyáltalán megengedhető-e? Gyakorlati oldalról az igen enyhe memóriaszivárgás kimutatása a varázslat...
-4kB/óra: ez kb. 34MB/év, a környezet, amit az Általad elmondottak alapján elképzelek, nevetve elbírja.
-4MB/óra: ez évi 34GB, ami bizonyos architektúránál és SLA-nál akár szolgáltatáskiesést is okozhat. A8_v2 és A8M_v2 Azure gépek árazásából kiindulva 1GB ára kb. 55€/év, így elasztikusnak véve a memóriát ez évenként 55*17 ~ 940€/év többletköltség. Ezt jelentősnek gondolom.
-4GB/óra, 4TB/óra: nehezen komolyan vehető az ismertetett környezetben.

Szóval a 4kB/óra valószínűleg nem vehető észre, a 4MB/óra pedig már gondot és/vagy költséget okoz.

Üdv,
Marci

( STP | 2016. 11. 29., k – 19:31 )

Hogy a p..ba tud 1 bit szivárogni? (Ugye nem 1bit/óra van kiírva.)

1 bitet nem nagyon tudok 'elhagyni', csak ha az allokációs egység 1 bit.
Értelmét nem látom a bites allokátornak, pedig fejlesztek cortex M0-ra (is) ami -mai szemmel- erőforrás tekintetében elég soványka jószág. Több a szopás az adminisztrálással, mint a nyereség RAM-ban.
Ameddig van értelme, az max a nibble kezelés.
Ettől függetlenül elméletben persze lehetséges. Mint a bug nélküli program.
.start
NOP
RET
.end

( bazso | 2016. 11. 29., k – 19:59 )

fejlesztői környezetben akármennyi, ott magát szivatja a júzer. Éles környezetben 1 bit is kritikus

( Andrei | 2016. 11. 29., k – 20:45 )

En is az 1bit-et jeloltem (disclaimer: c++ programozo vagyok). Tudom, hogy ha van egy csillio teras geped, es akkor egy kis szivargas beleferhet. Ezzel a magatartassal csupan annyi a baj, hogyha tapasztalati uton hatarozod meg a memoriaszivargas sebesseget, akkor sosem lehetsz biztos, hogy nem-e jon egy olyan use case, amivel a szivargas felgyorsul es az szivas. Masfelol meg garantalt felso korlatot talalni a memoriaszivargas mennyisegere nagyjabol ekvivalens a szivargas debuggolasaval.

Nalunk a memory leak (akarmekkora is legyen) szerver oldalon es kliens (beagyazott eszkoz) oldalon is kritikus hiba es mindig legnagyobb prioritasu.

Az mar csak egyfajta "szamurajmentalitas", hogy egyfelol a memory leak-ek debuggolasa es javitasa eleg jo gyakorlat. Masfelol meg ilyen hibakat tudva tartani a kododban szerintem ciki. Nagyjabol olyan, mint leszarni a rendszerhivasok visszateresi erteket, vagy kiveteleket nem lekezelni korrektul....

( pepo v | 2016. 11. 29., k – 21:01 )

Egyéb: anyád.

(Sok baromságot írtam, kérdeztem a HUP-on, de ez most szuicid gondolatokat ébresztett... Benned - remélhetően.)

( hokuszpk | 2016. 11. 29., k – 23:53 )

barmekkora memoriaszivargas programhibara utal.
az meg mindegy, hogy 1 bit vagy 4MB, ha a hibas kodot kihasznalva torik meg a szervered, vagy fertozik szenne a fonokod gepet, mindjart kritikus lesz.
de mar magat a kerdesfeltevest sem ertem, hogy lehet /ora a meroszam ?

4 TB/ora, az simman lehet kb 1GB/masodperc. :) Ha a processz kb ennyi ideig fut, akkor tulajdonkeppen eleg ha ennyivel szamolsz... :)
Amugy bugok mindigis voltak & vannak & lesznek. A kerdes csak az, hogy melyiket javitjuk eloszor. S vannak olyan esetek, hogy egyes uj feature-ok fontosabbak egyes bugoknal.

Ugyhogy szerintem a valasz az, hogy: ez attol fugg. Valaki egy konkret projekten, egy konkret kornyezetben, ellemzi a specifikus kockazatot, es hoz egy dontest arrol, hogy mennyi az elfogadhato. Ha egy projekten nincs egyetlen ismert hiba sem, akkor valoszinuleg keves/nem hozzaerto a tesztelo. :)

"4 TB/ora, az simman lehet kb 1GB/masodperc. :) Ha a processz kb ennyi ideig fut, akkor tulajdonkeppen eleg ha ennyivel szamolsz... :)"

ez azt feltetelezi, hogy minden konfig egyforma. ami ritkan igaz, a fejlesztesre hasznalt es az eles rendszer valahol mindig elter.
vagy eppen ha nem egyszeri felhasznalasra keszul a motyo, akkor a konfigok kozott lehetnek nagy eltereesek. pl. ami egy regebbi opteronon 1GB/s, az a legujabb csucs xeonon ez lehet harmadannyi ideig fut, viszont akkor mar 12TB/ora lesz a vegosszeg.
vagy eppen az egyik rendszerben van boven memoria, a masik meg swappol ezerrel, maris valtozik a futasi ido, fals lesz a szamitas.

Legfőképpen meg attól függ, hogy az adott szivárgást előidéző funkciót mennyiszer hívják. Ha egyszer egy óra alatt, akkor lehet 1 KB/óra, de ha egy milliószor, akkor 1 GB/óra.
Tehát itt igazán szerintem csak arról van szó, hogy valaki észreveszi, hogy adott idő alatt mennyi memóriával nő átlagosan a memóriahasználat. Lehet, hogy egy óra múlva fele annyi lesz vagy tízszer annyi. Sőt még az is, hogy nincs is szivárgás és egy óra múlva felszabadít minden korábbit :)
Biztosat csak akkor tudsz, ha megtaláltad a szivárgó programrészt, akkor meg már illő is javítani.
Ha egy-két hetente leáll OutOfMemory hibával, akkor azért erős lesz a gyanú! ;)
Bár még ilyenkor is lehet egy rosszul megírt rész hibája, ami túlzásba viszi a foglalást, pl. láttam olyat, hogy a feltöltött fájlt memóriába olvasta és még vagy kétszer le is másolta a memóriában. Pár gigás állománynál ezen már szépen elhasalhat úgy, hogy nincs is szivárgás.

mindegy hanyszor hivjak, elmeletileg minden lefutasnal szivarog.
es ha gyorsabban fut le, felteve, hogy valoban ugyanazt csinalja, mint a lassabb procin, akkoris ugyanakkora szivargast fog osszehozni.
tehat ha az opteronon 2 ora alatt fut le es 4GB az osszehozott leak, az uj Xeonon 1 ora alatt 4GB, akkor egyik esetben 2GB/ora jon ki, masodik esetben meg 4GB/ora ;
na ma sem veszek xeont, mert az jobban szivarog :)

mindegy hanyszor hivjak, elmeletileg minden lefutasnal szivarog.

Ezt azért gondold át, ha nem hívódik meg egy funkció, akkor nem is fog lefutni! ;)

Ha a szivárgó funkció annyiszor hívódik meg, amennyiszer csak bír, akkor valóban a processzor sebességétől függ a szivárgás mértéke, de ilyenkor is az van, hogy többször fut le az adott szivárgó funkció.
Függhet azonban mástól is a funkció lefutása. Pl. ha a Like funkció szivárog és egyetlen felhasználó sem Like-ol, akkor nem fog szivárogni, de ha egy millióan like-olnak, akkor egy milliószor fog lefutni és szivárogni.

Tehát, mi lenne a helyes gátépítési taktika szerinted?
Tökéletes biztonságot nyújtó gátat mindenhova?

A tökéletesség hiánya, amit említesz, nem faj-specifikus. Van az az erő, amitől törik a csont, az a fény, amitől tönkremegy a szem és az a hőmérséklet, amin záros időn belül elpusztul az élet...

Üdv,
Marci

Maradjunk annyiban, hogy a memóriát egy gáthoz hasonlítani, ahonnan "elég erős áradáskor" úgyis túlcsordul az adat, legalábbis erősen sántító hasonlat. Ha viszont komolyan így fogod fel a szoftverek erőforráshasználatának managelését, akkor légyszi, légyszi (no offense) ne fejlessz szoftvert.

Dehogy hasonlítottam a memóriát egy gáthoz, ne viccelj, legfeljebb Te értetted úgy! :)
Ezt a gondolatodat kritizáltam: nem a tökéletesre törekvés az elsődleges szempont.
És a gát példájával (ahogy később az élővilágból vett példákkal is) csak demonstráltam, hogy a tökéletességre törekvés általában máshol sem elsődleges szempont, jó okkal.

Üdv,
Marci

Ja értem, bocs akkor.

Általánosan egyetértek veled, de szerintem a sw stabilitás egyik sarokköve a feszes és minimálisra szorított memóriahasználat és 0 tolerancia a szivárgással szemben. Lehet pl. egy protokollt vagy API-t nem 100%-ig implementálni, esetleg feature-ökből párat lecsapni, ha arról van szó, de az erőforrásokkal bánjunk szigorúan, különben elszáll a fenébe az egész...

Csak hogy értsd, miért ez a hozzáállásom, ami. Jelenleg épp high speed image processing szoftvert fejlesztek gyártósori felhasználásra. 160FPS-es kép feldolgozása on the fly + hw vezérlés, 7/24-ben. Itt muszáj 0% leak-re törekedni, különben pillanatok alatt elfogy a világ összes RAM-ja is akár, aztán hisztifelhők gyűlnének igen gyorsan... :)

Le is zárhatjuk ezzel. Főként, hogy most mondtad el, hogy Te magad sem törekszel tökéletességre egyes területeken (API implementáció, feature-ök). Sőt, hozzátetted, hogy a 0% memory leakre is csak azért törekszel, mert az adott környezetben pillanatok alatt probléma forrása lenne...

Üdv,
Marci

Nanana. A 0% memleakre, illetve az erőforrások helyes kezelésére minden körülményke között törekedni kell, itt nincs "csak azért, mert" Nem értem, hogy ezt miért nem lehet elfogadni / betartani. Nem értem, egyáltalán hogy lehet ez kérdés, illetve, hogy mit csinál az az (éppen) 35%-a a válaszadóknak, akik szerint nem csak a 0 szivárgás az elfogadható.

Én is a kritikus súlyosságra szavaztam, de nem gondolom, hogy minden esetben kritikus prioritású a javítása. Ha nagyon kicsi az esély a memória elfogyására és vélhetően nagyon sok költségbe kerülne a 0-ra redukálása, akkor rengeteg más hiba javítása vagy új funkció fejlesztése bőven megelőzheti.

Most azért mert != csak azért mert

Tisztára kezdem azt hinni, hogy valami politikus vagy jogász vagy, azok szoktak így érvelni. Azért sem tetszik ez a válasz, mert ebben implicite benne van a "de bezzeg ha nem ez lenne, te sem így állnál hozzá", ami egyrészt nem igaz, másrészt meg amúgy is logikátlan a következtetés.

Szerintem már kiveséztük ezt. Elfogadom a kritikádat a "csak"-ra vonatkozóan, ez csúsztatás volt, kérem törölni.
"az erőforrások helyes kezelésére minden körülményke között törekedni kell" -- ezt egy egész iparág nem vallja. Nézd csak meg, mennyi erőforrást használtak az informatikai rendszerek hasonló feladatra 20 éve meg ma...

Üdv,
Marci

""az erőforrások helyes kezelésére minden körülményke között törekedni kell" -- ezt egy egész iparág nem vallja. Nézd csak meg, mennyi erőforrást használtak az informatikai rendszerek hasonló feladatra 20 éve meg ma..."

Na pontosan ez a baj :(

Hiába na, máshol is szóba került már itt a környéken. Tehénszar. Mert 100 milliárd légy nem tévedhet...

"a memleak pontosan detektálható és véges mennyiségű efforttal kiiktatható"

Az a sejtésem, hogy a gyakorlatban az a memleak detektálható csak, ami a definiált tesztesetek hatására (vagy az éles üzem során...) észlelhető méretűvé válik.
Az a másik sejtésem, hogy sok hiba kiiktatható lenne véges ráfordítással, a Megrendelő (okkal) mégsem akarja/tudja finanszírozni ezt és időben sem akarja/tudja kivárni.

Üdv,
Marci

+1

Még egy megoldás lehet a tökéletes gátak helyett, egy megfelelő üzemeltetés. Például vízlépcsővel szabályozni, hogy a gyenge gátakhoz ne érkezzen nagy vízmennyiség, vagy olyan gát megnyitása, ahol nem okoz nagy kárt a víz.

Memóriaszivárgásnál az üzemeltetés lehet pl. tervezett újraindítás havonta egyszer.

Vannak eszközök, amikkel a memory leak-eket fel lehet deríteni. Lefuttatod és megnézed, hogy hol leak-el a kód. Ennyire egyszerű.

Ha pedig véletlen nincs ilyen eszköz kéznél:
- akkor készíthetsz saját malloc-ot és free-t is, ami megmondja, hogy ki és hol hívta meg.

nem annyira bonyolult a dolog, ha a gdb képes stack-trace készítésére, akkor a malloc-odnak is menni fog.

Amikor szervert teszteltünk, akkor használtam felturbózott malloc-ot, hogy lássam, hogy mi a helyzet. Ezután egyesével végigmentem, hogy mi volt a memóriában és szabadna-e ott lennie.
Ha valamiből mondjuk 20 millió példány van, az gyanús lehet...

A tökéletes nagyon sokféleképp értelmezhető.

Egyébként pont nemrég vitáztam egyet-kettőt arról, hogy mérnöki munka-e a szoftverfejlesztés. Egyik álláspont szerint nem, mert az inkább matematikai. Szerintem meg nagyon is, mert nem önmagáért fejlesztünk szoftvereket, hanem adott probléma megoldására, aminek vannak egyéb vonzatai is (igények, költségek, célközönség, whatever). És ennek tükrében kell megtalálni a tökéletes megoldást, nem valami elvont matematikus szemlélet szerint "tökéletes"-t.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Teszek egy utolsó kísérletet.
Nézzük ezt a kis programot: 


Ciklus
  Ha Q gomb van megnyomva, akkor Kilép a programból
  Ha B gomb van megnyomva, akkor futtatja az fB funkciót
  Ha M gomb van megnyomva, akkor futtatja az fM funkciót
Ciklus vége

Nem fut le mindig minden funkció, csak akkor ha szükség van rájuk, jelen esetben, ha megnyomják a megfelelő gombot.
Az fB, fM funkció sem hívódik meg mindig, szerencsére még a programból kilépés funkció sem hívódik meg.
Tegyük fel, hogy az fM lefutásakor 1 KB memóriát foglal, de nem szabadítja fel (itt szivárog).
Ha egy óra alatt nem nyomnak meg semmit, vagy csak a B vagy Q gombot, vagy a B-t egymilliószor, akkor sem fog szivárogni.
Ha viszont egyszer megnyomják az M gombot, akkor 1 KB szivárog, ha egymilliószor, akkor 1GB szivárog.

Tehát ha szerencsénk van, sose szivárog 1 bitet sem, de csak azért, mert a felhasználók nem használják az fM funkciót. Ebben az esetben a funckiónak nem az a legnagyobb baja, hogy szivárog, hanem az, hogy felesleges.

Ebben az esetben a következő release-zel a funckió törlendő.
Minden más esetben akövetkező release-zel javítandó a szivárgás.

( leho | 2016. 11. 30., sze – 09:15 )

Zéró. Ami szivárog, az szar. És ha egy helyen szivárog, akár 1 bittel is havonta, ott biztos hogy lesz még pár bomba elrejtve máshol is. free() is your friend. Also delete is.

Ha egy rendszer havonta 1k-t szivárogtat, semmi garancia nincs arra, hogy másnap nem 1T-t fog.

Sajnos a tapasztalat azt mutatja, hogy időnként vannak események, amik más helyre tolják a program végrehajtását.
Volt szerencsém olyan szivárgást javítani, ami több évig probléma nélkül ment, utána valami megváltozott és naponta fogyott el a memória miatta.

( Jason v | 2016. 11. 30., sze – 09:26 )

...illetve gratulalok a mesteri trollbait szavazashoz :) Meg is jottunk :D

( leho | 2016. 11. 30., sze – 09:33 )

Turul, te aki anno FPGA programozás oktatással is foglalkoztál, hogy hagyhattad ki a 0-át az opciók közül? Ejnye :D

( tr3w v | 2016. 11. 30., sze – 10:57 )

Egyéb: amekkorát már észreveszek.

(Ha viszont tudok róla akkor az egyértelműen bug, magas prioritással.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( leho | 2016. 12. 01., cs – 10:43 )

Amúgy ebből milyen jó kis interjúkérdés lenne :D

( zoli78 | 2016. 12. 02., p – 12:18 )

Van, hogy nem gond még egy súlyos memóriaszivárgás se, mert az alkalmazás csak addig fut, amíg elvégez egy feladatzot, aztán már vége is. Pl. shell szkriptek vagy PHP-s webkiszolgálás... PHP-ben láttam is szép dolgokat, de hát csak legyintettek rá, hogy nem érdekes, hogy egy alkalmazás felzabálja a fél memóriát, mert úgyis gyorsan kilép a program amint legenerálta a választ. Mi mást lehet erre mondani: ANIA.DAT