BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

3517 | #1be3 | ^ | Idézet | Tue, 17 Apr 2012 18:15:02 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
A ciklust nem biztos, hogy lehet párhuzamosítani. Ha ami mögötte jön épül az eredményre, akkor meg pláne nem.

Ha ez így volna, nem lennének párhuzamos összesítő, rendező, kereső, stb. algoritmusaink. Egyébként a tapasztalatom az, hogy sokkal kevesebb olyan ciklust használunk, ahol szükséges az előző érték, mint ahol nem. Ld. listázások, akár PHP-ben. Miért ne lehetne egy 100 elemű lista elemeit mondjuk 4 szálon legenerálni és a végén összefűzni? Vagy pl. listák feldolgozása. Rengeteg ilyen művelet van, valamint rengeteg olyan művelet van, ami aszinkron módon elvégezhető. Nem véletlen, hogy a C#5 -ben is az egyik jelentősebb újítás a C# async lesz.

TCH írta/wrote:
Egyáltalán nincs minden erre ráállva, van ami már most párhuzamosan hajtódik végre.

Az a helyzet, hogy de. UI rajzolásra UI thread van, IO műveletek jórészt blocking műveletek, egyedül hálózatkezelés terén vannak jelei az eseménykezelt megoldásokra.

TCH írta/wrote:
Ez sem igaz. C-ben is létezik szálkezelés.

Léccineee... A C minden memóriabuzeráló műveletet (foglalás, felszabadítás) szinkron csinál a free/malloc-al. Ezzel szemben a Java/.NET az ilyeneket háttérben csinálja.

C-ben meg önmagában nincs szálkezelés, a fork és a threading mindenhol az OS (és a hozzá tartozó libekből) ered. Eleve C++ dettó, ott is jellemzően valamilyen libet használ mindenki arra, hogy elfedje a különböző OS-ek különböző szálkezelési megoldásait. C++11 e téren mondjuk előrelépés, ott már végre része lesz a standard library-nak.

TCH írta/wrote:
WTF? Ezt elmagyaráznád?

Mit magyarázzak? Azért van a fordító, hogy ne nekem kelljen pointerekkel meg gotokkal foglalkoznom, ha nem muszáj.

TCH írta/wrote:
endben van, de én tisztán funkcionális megoldásokra gondoltam. Szokás szerint balfaszul fejeztem ki magam, előfordul.

Sose gondoltam volna, hogy haskell fan lennél, főleg, hogy utálod a matekot ;) Na az tisztán funkcionális ;) (Amire te gondolsz a struktúrált, imperatív)

TCH írta/wrote:
Delphiben pl. így van.

Igen, de a Delphi egy részben OOP nyelv :P

TCH írta/wrote:
amit nem lehet OOP nélkül megcsinálni, vagy legalábbis szarabb lesz a végeredmény.

Egy eseménykezelt, UI toolkitnél adja magát. Egyébként egy szóval nem mondtam, hogy amit OOP-ben meg lehet csinálni, azt ne lehetne megcsinálni procedurális modellben. (Hisz, ha ez nem lenne igaz, eleve egy OOP kódot se tudnál lefordítani gépi kódra. És az OOP-nek nem is az a célja, hogy minden esetben hatékonyabb legyen az elkészült kód.

Az OOP-nek az a célja, hogy sok feladatra adjon egy absztraktabb, magasabb szintű, rugalmasabb, újrafelhasználhatóbb fejlesztési módszert. Van a programtervezési minták című könyv, érdemes elolvasni. Engem az tanított meg arra, hogy mit jelent OOP-ben programozni, mi az, hogy felületre (interface) fejleszteni, stb.

TCH írta/wrote:
Énnekem a library, modul, template modell jön be. :P

Legalább pontosan idéznél ;) Modulok voltak meg blokkok. Aztán utána kiegészítettük még egy model réteggel is, mert kellett. Az MVC meg pont nem webre alkalmas szerintem, de mindegy. Mellesleg a BC ilyen szempontból utólag visszatekintve meg se közelítette az OOP kódokat, csak vannak benne néhol objektumok :)