Organizovanje C++ programa kao u Delphi-ju

[ Predrag Damnjanovic @ 29.07.2003. 17:13 ] @

Moram da pokrenem ovu temu jer sam naleteo na klasčan problem - iako koristim C++ moj sors izgleda kao C sors - glavne stvari se dešavaju u klasičnim funkcijama.
Evo i zašto.

Koristim FLTK :)
Mislim da je on dobrim delom zaslužan za ovo - ako hoćeš callback za (recimo) klik - moraš da mu daš pointer ka funkciji koja će da handle-uje događaj. Znači, ta funkcija mora da bude obična, ne može da bude članica neke klase (ja barem tako mislim - nek me ispravi neko ako grešim).
Da stvar bude još gora, callback često može da se postavi za samo jedan event (recimo samo On_Click), pa često moraš da subclass-uješ klasu da bi dodao svoj handle za željeni event (ovo me najviše nervira).

Zato sam praktično prinuđen da sve trpam u obične funkcije, pa kad program naraste (a naras'o je) - kuku mene - pola sata tražim šta je gde, koja funkcija koju poziva... tužno... kao da programiram u C-u...

I onda kad se setim dana kada sam programirao u Delphi-ju, dođe mi da plaćem... kad se setim kako tamo svaka kontrola ima svoje Event-e, pa tu lepo smestiš program, pa je sve lepo organizovano...

E sad se ja pitam... ima li šanse da takvu organizaciju imam u C++ ?

Da li je rešenje u nekoj drugoj GUI biblioteci ?

Da li postoji GUI biblioteka koja je organizovana tako što svaka kontrola ima prazne virtual-ne funkcije za svaki Event, pa ti onda lepo napraviš subklasu i 'preuzmeš' virtualne funkcije koje ti trebaju ?

Znači, klasa ima:

Code:

class button
{
  virtual int On_Click ()
  {
    // prazno, nista ne radi
    return 0;
  }
};

I onda ti preuzmeš taj event, tako što subklasuješ klasu :

Code:

class button1 : public button
{
  int On_Click ()
  {
    // ovde ide tvoj program
    return 1;
  }
};

... i posle kreiraš objekat od te izvedene klase.
Ovako sors izgleda mnogo organizovanije, baš kao u Delph-iju.

Jasno je da FLTK ne može ovo.
Jedino rešenje za FLTK je da ja sam napravim podklasu za svaku komponentu (Widget), i da izmenim handle() funkciju tako da ona poziva prazne virtual-ne funkcije (koje postoje u toj podklasi), pa onda u mom programu da napravim podklasu te podklase, i tu da napravim svoje virtuelne funkcije, u koje mogu da ubacim program za Evente.
Ovo je popriličan smor, pošto koristim desetak komponenti, pa sve njih trebam da subklasujem.

I postoji drugo rešenje, lakše, ali nije kompletno.
Rešenje je da napravim namespace za svaki objekat (kontrolu) na formi, i tu da trpam funkcije za handle-ovanje, i globalne promenljive.
Tako sors izgleda pregledniji, svaki objekat ima svoj 'kutak', koji ima svoje ime, tako da je sve raspoređeno...
Mana je što ne mogu da handle-ujem svaki Event, pa ću negde morati da sublasujem neki Widget, da bi dodao callback za željeni event.

Elem, interesuju me vaša iskustva i rešenja u organizaciji sorsa.
Postoji li neka portabilna GUI biblioteka koja ima onakve prazne virtual-ne funkcije, namenjene baš Event-ima ?

[ sspasic @ 29.07.2003. 18:28 ] @

Verovatno ima takvih biblioteka, ali sve popularne C++ biblioteke (GTK--, QT, ...) koriste signal/slot fazon - svodi se na to da kada kreiras objekat, pomocu connect povezes njegov signal (npr. onclick), objekat koji ce biti pozvan i njegov metod (tj. callback).
I wxWindows ovo radi s tim sto se connect radi staticki kao u MFC-u, u vreme kompajliranja. Mislim, doduse, da moze i dinamicki, ali nisam se upustao u takve detalje.

Dakle, signal/slot je kombinacija nacina iz GTK++ (a po tvom tekstu i FLTK) i ovog sa nasledjivanjem.

[ Dragi Tata @ 29.07.2003. 19:04 ] @

Pogledaj VCF na http://vcf.sourceforge.net/index.php

Ova biblioteka koristi objektne callback-ove (nešto slično kao .NET delegates). Ne znam dokle se stiglo sa portovima na Linux i Mac, ali pod Windowsom radi dosta dobro.

[ leka @ 29.07.2003. 19:52 ] @

Ko kaze da FLTK nema signal/slot mehanizam dokazuje samo da pojma nema o FLTK-u. Postoji nekoliko implementacija i sve se mogu naci u FLTK bazaru!

[ Predrag Damnjanovic @ 29.07.2003. 20:01 ] @

to dokazuje da taj ne posecuje FLTK bazar, a ne da nema pojma o FLTK-u... :)

[ leka @ 30.07.2003. 01:44 ] @

Pitaj iskusnog FLTK programera sta radi svakodnevno - posećuje news.easysw.com . A tamo o signalima nedeljno ima bar nekoliko poruka. - Dakle ne mora da posećuje bazar.

[ Predrag Damnjanovic @ 30.07.2003. 12:34 ] @

usput, FL_Signal nece da se iskompajlira na gcc 3.2.2 :

Code:

$ cd Fl_Signal/makefiles/
$ make
g++ -O -Wall -I../../fltk -c -o Fl_Signal.o ../Fl_Signal.cpp
In file included from ../Fl_Signal.cpp:26:
../Fl_Signal.H:149: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
../Fl_Signal.H:172: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
../Fl_Signal.H:200: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
../Fl_Signal.H:241: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
../Fl_Signal.H:537: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
../Fl_Signal.H:560: friend declaration requires class-key, i.e. `friend class
   Fl_Cb_<R>'
make: *** [Fl_Signal.o] Error 1

u Redme-u pise da je testiran samo pod gcc 3.2.0 :(

[ leka @ 30.07.2003. 12:38 ] @

Pa ti popravi, napravi patch i pošalji autoru - logično - zar ne? :)

[ Rapaic Rajko @ 30.07.2003. 15:41 ] @

"Efikasno" programiranje, nema sta...

Leko, a ko bi platio to patch-ovanje tudjeg koda, da bi mogao da radis sopstveni posao? Ili bolje, koliko vremena to kosta?
Da se razumemo, i ja volim da programiram po principu "u se i svoje kljuse" (stalno se svadjam na poslu zbog "third-party" komponenti), ali ovo bas lici na arcenje vremena i para...

Rajko

[ filmil @ 30.07.2003. 15:53 ] @

Ne zaboravi da je tulkit besplatan (free as in 0$). Dakle možda arčiš pare, ali to su one iste koje si uštedeo ne kupujući recimo licencu za Qt. :)

f

[ Dragi Tata @ 30.07.2003. 18:07 ] @

Totalno off topic:

Zna li ko neki besplatan toolkit koji je pod nekom ne-GPL licencom? Podrazumevam da i ne koristi nikakav GPL kod "ispod haube".

[ NastyBoy @ 30.07.2003. 18:25 ] @

Well, da bi to dobio u C++u treba ti C++ builder :) Zasto? Zato sto to sto ti navodis kao lepotu u Delphiu je takodje moguce u C++Builder-u, ali samo zato sto Borland koristi nestandardne ekstenzije jezika (posebno __closure keyword) koje mu dozvoljavaju da "izvuce" metod klase "napolje", tako da iako ti je Button ustvari klasa za sebe, ti pises Event-response kao metod njegove forme (tj. potpuno druge klase)!
Zgodan trik, ali tako je samo na Borlandu i NIGDE drugde.
E sad, FLTK ne znam, i ne znam da li ima nekih "precica" da se dobije slicno ponasanje, samo sam naveo kako to Delphi/Builder rade :)

[ leka @ 30.07.2003. 20:33 ] @

Citat:

Rapaic Rajko:
"Efikasno" programiranje, nema sta...

Leko, a ko bi platio to patch-ovanje tudjeg koda, da bi mogao da radis sopstveni posao? Ili bolje, koliko vremena to kosta?
Da se razumemo, i ja volim da programiram po principu "u se i svoje kljuse" (stalno se svadjam na poslu zbog "third-party" komponenti), ali ovo bas lici na arcenje vremena i para...

Rajko

Da si malo pažljivije čitao tekstove i malo, ali baš samo malo, razmišljao, shvatio bi da je FLTK tim ponudio svoje rešenje. Univerzalnog rešenja nema. Signal/Slot mehanizam je samo jedna programerska paradigma. Ja lično više volim upravo kako to radi Borland C++ Builder, ali FLTK koristim jer sam od onih ljudi čiji je moto "size and speed do matter". Takođe mislim da nisi shvato osnovnu stvar u celoj priči - Siglan/Slot sistem o kome je Peca govorio (pa onda ja, pa ti) NIJE difolt FLTK solucija. FLTK godinama koristi drugi sistem koji Peci ne odgovara. - Govorimo o mehanizmu koji je čini mi se napisao Roman Kantor (jel taj Peco?). A taj nije jedini... Ima ih još.

Potpuno se slažem sa drugim delom tvog teksta - programeri nažalost u komercijalnom svetu ne mogu da se bave optimizacijama, da koriste najbrže tehnike itd. Zato sam potpuno siguran da je OS software taj koji ima budućnost - jedan programer koji radi na OS projektu će sesti nedelju dana i optimizovati jednu jedinu klasu - parčence celog projekta - dok će komercijalac da kupi gotove stvari, JER NEMA VREMENA ZA SVE zbog kratkog dedlajna... Na kraju, bar iz ličnog iskustva pričam, komercijalni proizvod je zapravo sve ostalo osim brz i malen, što nije ni čudo jer se svakim danom pojavljuju kojekakvi priučeni java, .net, c++, python, visual basic (etc) programeri...

[Ovu poruku je menjao leka dana 30.07.2003. u 20:39 GMT]

[ leka @ 30.07.2003. 20:36 ] @

Citat:

Dragi Tata:
Totalno off topic:

Zna li ko neki besplatan toolkit koji je pod nekom ne-GPL licencom? Podrazumevam da i ne koristi nikakav GPL kod "ispod haube".

Citat:

FLTK comes with complete free source code. FLTK is ©1998-2001 by Bill Spitzak and others. Use and distribution of FLTK is governed by the FLTK Library License (which is the GNU Library General Public License with an exception added that allows you to distribute statically-linked programs using the library without providing source code to the program or the library). You can use it in commercial software!

Mislim da ovaj deo teksta sve govori...

[ Predrag Damnjanovic @ 30.07.2003. 21:22 ] @

Citat:

leka:
Da si malo pažljivije čitao tekstove i malo, ali baš samo malo, razmišljao, shvatio bi da je FLTK tim ponudio svoje rešenje. Univerzalnog rešenja nema. Signal/Slot mehanizam je samo jedna programerska paradigma. Ja lično više volim upravo kako to radi Borland C++ Builder, ali FLTK koristim jer sam od onih ljudi čiji je moto "size and speed do matter". Takođe mislim da nisi shvato osnovnu stvar u celoj priči - Siglan/Slot sistem o kome je Peca govorio (pa onda ja, pa ti) NIJE difolt FLTK solucija. FLTK godinama koristi drugi sistem koji Peci ne odgovara. - Govorimo o mehanizmu koji je čini mi se napisao Roman Kantor (jel taj Peco?). A taj nije jedini... Ima ih još.

Taj mehanizam mozes da okacis macki o rep...
Jednostavno, nije kompletan - niti mozes da napravis callback koji tebi treba, niti callback moze da bude funkcija neke klase.

Recimo treba mi callback za event MouseOver - kada misem predjes preko widgeta.
Da bi to napravio treba da subklasujes widget, pa da napises svoj handle()

I drugo - to resenje dovodi do toga da ti sors izgleda kao papazjanija... gomila globalnih funkcija (za callback) i gomila globalnih promenljivi u jednom cpp fajlu.

Definitivno sam primoran da koristim namespace za svaki objekat, da bi uveo kakav takav red... to ispada najbolje resenje.
A sto se tice dodatnih callback-ova - subclassing - nema mi druge :(

[ leka @ 30.07.2003. 22:16 ] @

Peco care, ako ti se ne svidja - ti nadji neki drugi ToolKit koji se tebi vise svidja.
Druga stvar - postoji news, pa ljudima iz FLTK tima mozes da se izjadas a oni ce videti ima li smisla to sto pricas ili ne. :)
Ja probleme tog tipa na koje ti nailazis nisam imao (sa FLTK-om).

[ Dragi Tata @ 30.07.2003. 23:45 ] @

Citat:

which is the GNU Library General Public License with an exception added

LGPL je previše komplikovan za moj ostareli mozak i bez "exception added". Ima li nešto pod BSD licencom ili public domain? VCF je dobar, ali još nije stigao do 1.0 verzije.

[ leka @ 31.07.2003. 00:21 ] @

LGPL je nešto najotvorenije što postoji među svim licencama. FLTK je upravo zbog toliko poularan (to je jedan od prvih toolkita koji je izdat pod LGPL-om), i debelo se koristi u komercijalnim aplikacijama, koje ga najčešće statički linkaju, što je specijalitet FLTK kuhinje :)

[ Predrag Damnjanovic @ 31.07.2003. 11:43 ] @

Citat:

leka:
Peco care, ako ti se ne svidja - ti nadji neki drugi ToolKit koji se tebi vise svidja.
Druga stvar - postoji news, pa ljudima iz FLTK tima mozes da se izjadas a oni ce videti ima li smisla to sto pricas ili ne. :)
Ja probleme tog tipa na koje ti nailazis nisam imao (sa FLTK-om).

Epa da znas da cu da im pisem...
Mada, imam ja i par sitnih primedbi na widget-e. Recimo onaj ListBox, mora da drzis da bi lista bila otvorena - video sam da ste to sredili u eFLTK-u, na moje veliko zadovoljstvo...

Tako da, kada im budem pisao, bice to poduze pismo...
Ili cu jednostavno da predjem na eFLTK, ako napravite (mada mogu i ja da pomognem - ako dozvolite & zelite) normalan callback sistem :)

[ filmil @ 31.07.2003. 12:22 ] @

Mislim da je jedini pravi potpuno OO pristup pravljenju tulkita stavljanje po jedne virtuelne funkcije clanice (metoda) za svaki moguci event. Mana pristupa je u tome sto sve klase onda vuku sve virtuelne funkcije iako realno widgeti koriste samo jedan mali njihov podskup. Problem je verovatno u tome sto svi widgeti u principu ne podrzavaju sve evente a u c++-u je nemoguce 'ubiti' metode koji se ne koriste. To naravno povecava footprint tulkita pa se svako dovija na svoj nacin. Qt je smislio signal/slot resenje koje lepo radi ali to vise nema veze sa c++-om, a FLTK je usvojio callback pristup koji je postojao jos od Motifa, a koji daje uzasno ruzan kod, i sve to pod parolom ocuvanja brzine.

Dakle na prvi pogled se vidi da malte ne nijedan tulkit ne koristi jedini pravi OO pristup resenju ovog problema i zivo me zanima zasto je tako. Recimo, kako su (e)FLTK-ovci zakljucili da su callback funkcije brze i bolje od virtuelnih f-ja? To verovatno zavisi i od kompajlera, ali zaista ne vidim razlog da se takve stvari ne mogu iskompajlirati tako da daju potpuno identican kod!

Ali ako su u pravu, onda evo zadatka za Pecu: da napravi konvertor koji ce od OO koda u eFLTK-u (dakle sa virtuelnim funkcijama) da izgenerise dodatni fajl u koji smesta sve ruzne callback-ove i povezuje na 'fltk nacin' sa ostatkom programa.

f

[ leka @ 31.07.2003. 14:11 ] @

Citat:

Predrag Damnjanovic:

Citat:

eFLTK ekipa se jednoglasno odlucila za (vec ubaceni) Signal/Slot sistem, koji je deo eFLTK-a ima jedno nedelju dana. Ti si odavno pozvan da budes clan eFLTK tima i znas dobro sta bi radio (ono sto si sam zeleo da radis - Net deo)...

[ Dragi Tata @ 31.07.2003. 18:18 ] @

Citat:

filmil:
Mislim da je jedini pravi potpuno OO pristup pravljenju tulkita stavljanje po jedne virtuelne funkcije clanice (metoda) za svaki moguci event.

Eh, mislim da ne vredi raspravljati o tome šta je "pravi potpuno OO pristup", već koji je pristup najelegantniji, najčitljiviji i najlakši za održavanje. U principu, meni se najviše dopada sistem opisan design pattern-om Observer - Subscriber. Jednostavno se jedan objekat registruje da ga drugi objekat obavesti kad se desio neki događaj. Taj pristup recimo koristi Java Swing, ili .NET Windows Forms, mada malo različitim tehnikama: Java preko interfejsa i unutrašnjih klasa, a .NET preko specijalnih objekata koji se zovu delegates. Od C++ toolkitova koje koliko-toliko poznajem, VCF ima vrlo sličan pristup, a recimo zanimljivo je da (po mom skromnom mišljenju) najbolja GUI biblioteka za C++ WTL koristi nešto slično kao MFC - makroe. Objašnjenje je da se na taj način dobijaju najbolje performanse.

[ filmil @ 31.07.2003. 18:40 ] @

Nisam to rekao da bih krenuo u polemiku koji je jedini pravi i sl (a sad vi, pošto nema citiranja poslednje poruke, pogađajte ili tražite šta sam to reko) nego da mi je zanimljivo da niko nije krenuo tim (očiglednim?) putem.

f

[ Dragi Tata @ 31.07.2003. 18:51 ] @

Evo objašnjenja zašto MFC nije implementiran na taj način:

http://msdn.microsoft.com/libr...vclib/html/_MFCNOTES_TN006.asp

"Microsoft Windows implements what are essentially virtual functions in window classes using its messaging facility. Due to the large number of messages involved, providing a separate virtual function for each Windows message results in a prohibitively large vtable.

Also, since the number of system-defined Windows messages changes over time, and since a specific application may want to define some Windows messages of its own, the message-map mechanism provides a level of indirection that prevents interface changes from breaking existing code."

[ leka @ 31.07.2003. 23:47 ] @

Legende, predlažem da ovu diskusiju prebacimo (poslednjih nekoliko poruka) u Art of Programming, šta mislite?

[ Dragi Tata @ 01.08.2003. 00:18 ] @

Citat:

prebacimo (poslednjih nekoliko poruka) u Art of Programming

Zar je to moguće uraditi? Ako znaš kako, samo napred.

[ leka @ 01.08.2003. 12:07 ] @

Pa mislio sam da je moguce, zar nije?? :( Eto necega za "Predlozi i pitanja" diskusionu grupu :)