Új hozzászólás Aktív témák

• #336 cog777 őstag Sk8erPeter #334

  Új Válasz 2013-05-11 20:46:08 #336

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cog777

  őstag

  válasz Sk8erPeter #334 üzenetére

  Ja, ja.. illetve tudom ajánlani a globális new / delete operatorok felülírását és a memória foglalás könyvelését __FILE__ és __LINE__ finomságokkal egyetemben. A progam befejezésekor automatikusan kiköpi a fel nem szabadított objektumok listáját a sorszám és a fájlnévvel együtt ahol a lefoglalás történt

• #332 cog777 őstag cog777 #330

  Új Válasz 2013-05-11 09:36:00 #332

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cog777

  őstag

  válasz cog777 #330 üzenetére

  Jav: "Én már nem használom" a sima c tömböket nem használom.

• #331 cog777 őstag Sk8erPeter #301

  Új Válasz 2013-05-11 09:34:48 #331

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cog777

  őstag

  válasz Sk8erPeter #301 üzenetére

  > Egyébként nagyon nagy tévedés, hogy pl. C++-ban ki van kényszerítve, hogy ne gányolj: például elfelejtesz destruktort írni egy objektumhoz, felszabadítani a lefoglalt memóriaterületet, és hopp, máris elszáll a büdös francba az alkalmazás memóriaigénye.

  Kikényszerítve ugyan nincs.. de aki gányol az igénytelen. Az egész vitának nincs értelme ha csak 1000 soros programban gondolkodunk. Minden más esetben a kulcsszó a software design pattern / TDD / modern framework -ök használata. Fel sem merülhet hogy nem írsz destructort (Sőt. Kapásból virtualt. Max singletonnál nem.) meg nem használsz smart pointereket.

  Emvy > "hogy azt keptelenseg utolag megerteni."
  Hacsak nincsenek használva az általam említett technkák, egyre nehezebb bővíteni egy nagy szoftvert. Lehet egy húúú de nagy osztályt létrehozni bele drótozni mindent. Egyszerűbb persze. DE! Kapásból van egy csomó hátránya, nehéz bővíthetőség, folyton át kell írni mindent. Unit Test -et nem lehet rendesen használni. Nehezebb csapat munkába kiadni. Ha én találkozok egy bonyolult megoldással akkor neki állok függőségi diagramot rajzolni, megérteni a dolgot. Máshogy nem megy.

• #330 cog777 őstag emvy #299

  Új Válasz 2013-05-11 09:18:00 #330

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cog777

  őstag

  válasz emvy #299 üzenetére

  > Ennek igy onmagaban nem sok ertelme van
  Nyilván. Csupán összehasonlítottam korábban két adattárolásra használt lehetőséget. Mi lenne ha a vectornak csak az adattárolás funkciót venném igénybe.. Én már nem használom hacsak nem 2 KiB memóriájú MCU-ra kell programoznom.

  Nem sok érvük lehet azoknak akik ragaszkodnak a "jól bevált" egyszerű adattároláshoz C++-ban... és pont azért utaltam a legacy kódok tulajdonosaira. Szenved a világ a sok betörés miatt azért mert sok szoftver régi technológiákon alapszik és toldozzák foltozzák őket. Miközben az IT-s világ azt harsogja hogy java/.net/javascript mert bőven van erőforrás és milyen biztonságosan és gyorsan lehet fejleszteni. OK. De ugyanezt meglehet oldani a mostani modern c++ -os technológiákkal is kevesebb memória igénnyel és töredék indulási idővel. Tovább utalva Penge mondanivalójára .. hiába van a melóhelyemen 16GiB ramom, az igénytelenül megírt programok tetű lassan indulnak el. SSD-nélkül néha döcög egész.

  (A SUN-os dolgon kívül sztem ugyanaz a véleményünk)

• #295 cog777 őstag Glenda #292

  Új Válasz 2013-05-10 07:15:23 #295

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cog777

  őstag

  válasz Glenda #292 üzenetére

  Ha valaki igényes, akkor a c++ -ban sem. Csak használni kellene a modern framework-öket, vagy az újabb c++ szabványokat. Pont 10 éve mértem le egy egyszerű tömb és egy vector közti sebesség különbséget. Akkor volt 10 %.hátránya a vectornak. Gondolom most kevesebb.

  Arra akarok kilyukadni hogy pl a java framewok-öt ugyanúgy meg lehet fektetni buffer overflow-val (jönnek 1000-el a biztonsági patch-ek), pedig ha az oracle/sun nem lenne ilyen igénytelen akkor átírhatta volna már rég biztonságosabb alapra helyezve az egészet.

  Csak hát legacy kód.. pénzt már nem áldoznak rá..jó lesz az a népnek..

Új hozzászólás Aktív témák