ARCHIV

Ja fakt nevim, proc treba nepouzit uz napsanou knihovnu socketu (a nejen socketu) (samozrejme objektovou), treba Synapse.
http://www.ararat.cz/synapse/
je to mnohem lepsi (a udrzovatelnejsi) nez se trapit s klasickymi sockety.
Hold ale to by autor muset umet objektove programovani co :).

V soucasne dobe bych jednoznacne preferoval objektove programovani a pak se nemusite bat ani vetsich projektu (viz muj Seksi Commander).

Radek

Použít napsanou knihovnu socketů je samozdřejmě také řešení. Nevěděl jsem že něco takového již dnes existuje pod rozumnou licencí pro FPC. Zmiňovaná knihovna synapse mi z prvního rychlého pohledu na seznam vlastností příjte jako kanón na vrabce. Ale matně si pamatuji, že právě produkty firmy Borland používalo mnoho lidí, kteří programovali tak že slinkovali největší dostupné knihovny které dělají "cosi" a mezi ně napsali dvě tři třídy jako rozhraní a naklikali nějaké GUI čudle. Nevím mě osobně toto nepříjde jako zrovna správný přístup k programování a radši se podívám do hloubky jak to funguje a případnou (objektovou) obalovou knihovcnu si napíšu sám, tak aby vyhovovala mým potřebám.

Docela se divím, jak všichni v poslední době považují objektové programování za univerzální odpověď na jakýkoli problém. Osobně si hlavně nedovedu příliš představit co tak prudce objektového může být na socketové knihovně.

--
Aleš Hakl

ja taky nemam rad knihovny ktere jsou obrovske, ale prave synapse je velice dobre navrzena, ktera ac umoznuje spoustu veci tak z ni muzu vzit jen treba 2 jednotky.

jo a ja klidne vezmu radsi nekdy knihovnu (nebo jeji cast), ktera se mi libi (pohledem do zdrojaku), a ktera je programatory navic uznavana, nez bych stravil x hodin tim ze budu znovu vynalezat kolo.

>které dělají "cosi" a mezi ně napsali dvě tři třídy jako rozhraní a >naklikali nějaké GUI čudle

to je ale chovani spatnych programatoru ve vsech jazycich

>radši se podívám do hloubky jak to funguje a případnou >(objektovou) obalovou knihovcnu si napíšu sám, tak aby
>vyhovovala mým potřebám.
ti nikdo nebrani, ale podivat se existujici je mozno taky(a casto to delam), navic autor te knihovny jiz vetsinou tim stadiem prosel

> co tak prudce objektového může být na socketové knihovně.
to by ses divil. (treba ze treba naslednikem soketu muze byt ftpsoket, httpsoket atd, ze informace o soketu si drzi objekt soketu, tudiz v programu se to nehemzi promennymi, chyba se opravi jednou v zakladni tride a je vymalovano, atd. ). Vyhody toho se samozrejme projevi v programech dejme tomu nad 20000 radku
(coz je v projektech ktere spravuji skoro nic).

Radek Cervinka

Prave priklad s implementaci nejruznejsich protokolu, jako naslednika obycejneho socketu mi neprijde zrovna dobry navrh. Daleko rozumnejsi by bylo kdyby kazda implementace protokolu mela obdobne rozhrani jako obdobna sluzba fungujici lokalne (tj. http a ftp do jiste miry podobne souboru etc.)

Pokud si dovedu predstavit nejakeóu rozumnou dedicnost socketu tak prave to, ze ruzne site mezi poskytuji obdobne sluzby (prenos datagramu, spolehlivy prenos proudu, nespolehlivy prenos datagramu ze zarucenym poradim...) a na teto urovni rozumnou dedicnost poskytuje jiz samotne BSD sockety, pravdou je, ze pro pouziti ve vyssim programovacim jazyce ma smysl, tyto nizkourovnove operace nejak zabalit. Faktem ovsem je, ze ruzne varianty sitovych protokolu 4. vrstvy a jine IPC mechanizmy poskytuji ramcove podobne sluzby, ovsem ne vzdy stejneho druhu a tudiz klasicka "objektova" dedicnost neni zrovna idealni pristup.

Ohledne jadra - v prostoru jadra by se C++ pouzivalo dosti spatne - jednim z hlavnich predpokladu prace v jadru, je ze programator vi pomerne presne co dela a jak to dela, coz vetsina programatoru v C+ nevi a ani je to vlastne nezajima. (Existuje jakysi modul jadra, ktery je napsany v C++, ale musi si sebou nest pomerne znacny kus kodu, aby vubec bylo mozne C++ v jadru pouzit)

Ono to s tim Free Pascalem je takove osemetne, neni to jazyk, ve kterem by se v UNIXu neco nejak vyrazneji psalo a je to pochopitelne, jednak jde o to, ze kompilator Free Pascalu do nedavna existoval pouze na platformu i386 a tusim m68k (nebo mozna PowerPC) a ani dnes neni podporovanych platforem zrovna mnoho. A za druhe to s onou abstraktnosti a cistotou FP neni az takove, je to takovy zvlastni hybrid. Ve FP je mozne psat opravdu obektove, ale nikdo to ve zkutecnosti nedela a pouziva ho tak jak byl myslen a drive ci pozdeji narazi na nejaky problem (napada me absence neceho jako je vicenasobna dedicnost ci rozhrani)

K dalsim dilum bych rekl tolik, ze Free Pascal uz nejaky ten patek nepouzivam, ale vzhledem k tomu, ze o pokracovani je zrejme docela zajem, tak o nem zacinam premyslet.

Rozhrani ve FP jiz drahnou dobu je. Vicenasobna dedicnost je docela rozporuplna vlastnost.
Citace z manualu:
"As of version 1.1, FPC supports interfaces. Interfaces are an alternative to multiple inheritance as implemented for instance in C++."