Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Tolik rozruchu
jen v Lopuchu

Lopuch.cz
Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: mnazzcr
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 23.8.2006 08:20  537
AL3XMno o teoretické možnosti že linux je jen jeden jedinečný bych polemizoval (už z toho pohledu, že má dva desktopy není jedinečný, ale prostě se s tím musí počítat). Bohužel často nepatřím k nadšencům čehokoliv (a týká se to i technologií pod windows), ale spíš ke všemu přistupuju kritičtěji.

Ostatní:

S Qt už jsem s ním měl tu čest. Jediná věc, která mě odrazuje je hnusná (graficky) implementace pod windows a jakákoliv rezignace na nastavení windows... i když to možná je spíš chyba programátorů v honbě za tím být originální. Každopádně QT aplikace se ve Win pozná na dálku. Opačný problém mám s WinAPI, MFC, atd, které zase pro změnu na Linuxu nerozběhám ale mnohem lépe sedí do stylu Windows. Na druhou stranu ani MFC není svaté, spíš je to opruz v něm dělat. Takže proto píšu rozhraní, které by na straně aplikace bylo stejné, implementace uvnitř bude záviset na platformě (a žádné #ifdef LINUX, ale prostě úplně unikátní zdroják). Samozřejmě plně objektové. Na té nej nejnižší úrovni bych si dokázal představit implementaci pod X11, ale ostatní api samozřejmě prostuduju.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 23.8.2006 08:19  536
Bredy [533]: To je prave to, co Ti kazdej rekne jinak, ja bych Ti zase rek, at to delas radsi pro KDE nez pro Gnome. Presneji receno ani ne tak nutne nad KDE knihovnama, ale nad QT (nad kterym stoji i KDE, cili KDE je zase jeste o neco vys). Tady jde proste ciste o osobni preference a QT vs. GTK tabory proti sobe stoji asi zhruba jako vim vs. emacs (nebo treba i Windows vs. Linux). Mne osobne prijde GTK divne, vsechna temata, ktera jsem pro nej videl, pomerne hnusna, a hlavne open/save dialogy hrozne spatne pouzitelne a furt se menici, takze jen co si clovek zvykne, jak je z ty klavesnice ovladat, tak je to v pristi verzi zase uplne jinak. Nicmene stejne tak dobre Ti muze nekdo jiny popsat stejne mnozstvi veci, ktere se jemu nelibi na QT. Tady asi neexistuje spravna volba, tady musis jit cestou toho, co Ti vic vyhovuje. Ale shodnu se s AL3Xem na tom, ze proti tomu existuje nejspis spatna volba, kterou je pokouset se o to vsechno sam.
al3x 22.8.2006 22:58  535
Vidim, ze s nekterejma odpovedma jsem trosku zaspal.

Ad 3) Neexistuji "ruzne Linuxy". Linux je bud jenom jeden, nebo kazdy jedinecny (podle hloubky pohledu). Skoro bych radil neco si predem precist o cele "filosofii" nez se do toho pustis. A opravdu bych vubec neradil delat to tak, aby to vypadalo co nejvic jako Win. Kdyz pouzijes neco existujiciho (GTK treba), tak mas jistotu, ze to bude na vsech "Linuxech" vypadat spravne. Pokud se toho pokusis docilit sam, tak (se svou zkusenosti s Linuxem) patrne neuspejes.
al3x 22.8.2006 22:51  534
1) Pouzivam vim + gdb, ale to ti je asi na nic.

2) pthread.h tutorial: http://www.llnl.gov/computing/tutorials/pthreads/
plus v konzoli:
man pthread.h
man jmeno_konkretni_fce

3) Qt, nebo GTK je lepsi volba nez si patrne myslis. Vetsina uzivatelu bude mit uz jedno, nebo druhe zavedene v pameti, takze to pobezi rychlejc. Dale budou mit nastavene fonty a barvy, ktere jim vyhovujou. Jakykoliv tvuj widget bude bud presne kopirovat existujici, nebo bude vypadat znatelne hur. Linux se od Win vyrazne lisi mnohem sirsi variabilitou vzhledu oken a dost na tom, ze existuji dve ruzne Qt/GTK - jeste aby nejakej program pouzival svuj vlastni.
bredy 22.8.2006 20:50  533
Někdo mi poradil, že existují nějaké přímo SDK na KDE nebo Gnome. Říkal ať radši dělám na gnoma, tak nevím. Mne by ideálně vyhovovalo api, ktere je na úrovni WinApi, tj, žádné pokusy o nějaké objektové šíleností, prostě čisté ovládání, vytvoř okno, překresli okno, sejmi událost kliknutí myši atd... i když by se třeba hodilo i "vlož editační okénko", ale nic kolosialniho. Kdo programuje zároveň ve WinAPI ten bude vědět.

Co se threads týče, posix bude stačit. Naopak moje knihovna je v C++ a wrappuje thready, které jsou spíš napsané pro C (i v tom winapi)
king King Born to be king - ... 22.8.2006 16:36  532
jj, to je to ide k ve wxWidgets
huh huh 22.8.2006 16:35  531
já jako IDE používám Code::Blocks, hlavne proto, ze mi necpe tvorbu configure a spol.
king King Born to be king - ... 22.8.2006 15:57  530
IDE: Anjuta, MonoDevelop (primarne pro C#, nevim jak je na tom s C++), Eclipse a Kdevelop - to je seznam tech sofistikovanejsich co znam, nedelal jsem ani s jednim (delam ve ViMu)

Debugger: me se libi DDD, coz je nadstavba nad GDB

Ad Xlib Vs GTK (Qt nemusim ;) ) : tady je otazka na co ta knihovna bude, jestli obsahuje neco jineho nez ciste grafiku (tedy i nejake widgety) Xlib neni dobry napad. Zkus se jeste zamyslet nad necim stylu wxWidgets (a propos kdyz se na to budes divat, myslim ze nekde k tomu meli i IDE), ale to ti asi taky nebude vyhovovat...

jinak ty thready jsou v linuxu standardni posixovy, tedy hledej pthreads, jen nevim jak se s nima pracuje z C++ (pouzival jsem je jen v C)
bredy 22.8.2006 13:34  529
KdokolivNo ideálně by bylo, kdyby to UIčko vypadalo na chlup stejně jako ve windows :-)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 22.8.2006 13:07  528
Bredy [527]: Asi bude problem v tom, ze poradne nevim, co potrebujes (a taky v tom, ze ja nikdy nebyl poradnej C++ programator, ani na jedny platforme, jenom jsem absolvoval jednu prednasku, kde nas pro ten Unix donutili cosi delat).
Pokud jde o QT - proc jsi to celou noc buildil? Mandrake pro to musi mit pripraveny balicky, stahnu, nainstaluju, jede to. Popravde receno Mandrake ma urcite jako vychozi prostredi KDE (aspon bych to cekal), tudiz to proste nainstalovano QT mit musi, bez toho byto vubec nejelo. QT samozrejme trosku kolos bude, ale neni to zas az takova hruza.
Pokud si chces jenom malovat po oknech, tak to muzes delat, jak chces, ale na druhou stranu stejne dobre muzes pouzit QT a malovat si po nejaky QCanvasu (nebo co tam je). Jinak s portovanim by problemy byt nemely, kvuli tomu jsem to nezminoval, sips jde o to, ze kdyz to bude nad QT, tak to muze vypadat podobne jako nektere jine aplikace v systemu uzivatele (myslim ten vysledek, co bude pracovat nad tou Tvoji knihovnou), zatimco kdyz to bude ciste nad Xkama, tak to nebude vypadat jako cokoliv jinyho. Ale zase - jde o to, co presne tam budes delat. Pokud opravdu jenom malovat (zadny tlacitka, zadny menu, zadny jiny widgety), tak je to asi jedno.
Ty thready by urcite nejak preportovat jit mohly a ta dokumentace v manualovejch strankach je pouzitelna, kdyz se do toho clovek dostane. Ale nejakej uvodni tutorial nebo overview by to urcite chtelo.
bredy 22.8.2006 12:53  527
KdokolivJde o to, že GUI knihovna pracuje na nízké úrovni s WinAPI. Všude používám pimpl idiom abych windowsy zakryl. Tak mi přišlo divné psát střeva portu na něco, co vlastně portovatelné už je. CO se QT týče, tak po celonoční instalaci (a buildování) jsem jej nějak moc nerozchodil. Docela mi přijde jako kolos.

Co jsem se díval na X11, zatím jsem viděl jen otevírání oken a malování po oknech. Což o to, to by mi klidne vyhovovalo (Java si přece taky maluje všechno sama). Připomínám, že nepíšu aplikaci co si chce otevírát okénka a vyplňovat kontrolky, píšu knihovnu, nad kterou běží cosi, co si prostřednictvím jednotného interface otevírá okénka a vyplňuje kontrolky, a tahle knihovna to vlastně má malovat.
(a když bude problém s portováním, napíšu varianty pro různé linuxy).

Na KDevelop a podobně se podívám. Celkem mi nevadí, jestli to je pro KDE nebo něco jiného, na začátek to bude stačit.

Ty thready ... trochu se toho děsím, podívám se po google. Ale kdyby to vyšlo přeportovat, dost by to ulehčilo práci s některými věcmi (též pimpl idiom knihovna)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 22.8.2006 12:39  526
Bredy [525]: Vyvojova prostredi urcite nejaka budou, z hlavy mi vyvstava KDevelop, jenze dost mozna bude hodne zamereni na vyvoje KDE veci (byt to urcite nebude tak, ze by jinak v nem vyvijet neslo). Pak pokud vim jsou nejaky C/C++ pluginy pro Eclipse, ale netusim, v jak pouzitelnym je to stavu. Mozna budes muset hledat sam, protoze konkretniho doporuceni by ses nejspis zvlast tady na Lopuchu tezko dockal, tady spis vetsina pojede ve vimu, mozna nekdo krom me i v emacsu, ale tim to asi skonci.
K stardandnimu vlakennimu API je afaik dokumentace v podobe manualovych stranek. Mohlo by Ti stacit dat vhodny dotaz na Googlu, z nej nacerpat zakladni predstavu a zbytek se docist tam. Ja bych musel sahnout do svejch slidu z prednasek, abych vedel, odkud se odpichnout, ale ty asi nejsou nikde verejne vystaveny.
Ad GUI - durazne nedoporucuju pracovat s tim na nizke urovni. Priznam se, ze nerozumim te namitce s portovanim knihovny na port, kazdopadne bych opravdu zvazoval QT nebo aspon GTK (byt ja radsi QT), je par dalsich tooliktu (Tk, FOX), ale ty jsou min rozsirene a treba zrovna to Tk je hrozne divny a hnusny (muj osobni nazor) a jet uplne bez nich a vsechno si delat pres xlib (ci jak se to jmenuje) je sebevrazda a vysledek bude od pohledu hnusnej (a navic nezvyklej). Fakt bych doporucil tenhle bod prehodnotit a vzit nejakej rozumnej existujici toolkit.
bredy 22.8.2006 12:23  525
LinuxRozhodl jsem se, že po zkouškách zkusím přepsat některé své knihovny do linuxu. Potřeboval bych

1) existuje nějaké vývojové prostředí, nebo aspoň UI debugger?
2) První na řadě je knihovna pro vlákna. Mám ji pro WinAPI, a budu ji portovat do Linuxu. Doporučite mi nějakou dokumentaci / knihovnu, jak s vláknama pracovat? (nechci žádnou nadstavbu, ideálně na nejnižší úrovni co to půjde).
3) GUI - už jsem si našel nějakou dokumentaci k X11, přesto, jestli o něčem víte, sem s tím (o QT nechci slyšet, přijde mi divné portovat knihovnu na port - spíš na nižší úrovni)

PS: Mám Mandraka.
makak makak 19.8.2006 09:43  524
dickjprecti si RFC 919, broadcasting pomoci 255.255.255.255 funguje pouze na jednu "podsit" a je mozne, ze v tvem pripade neni "server" a "klient" v jedne siti. Take ne kazda gateway "na ceste" paketu musi broadcasting podporovat, takze se ti to mozna nepovede vubec, nemas-li moznost jejich nastaveni ovlivnit.
bredy 18.8.2006 23:33  523
dickj1. Adresu broadcastu si musis zjistit, mam pocit, ze 255.255.255.255 ne vzdy funguje.
2. naopak myslim, ze neni treba nastavovat SO_BROADCAST, protoze to bez nej funguje taky.
3. nevim, jesltli v prvnim pripade je chybejici bind zamer nebo opomenuti pri prepisovani do lopuchu
4. stejne tak server by mel asi nejspis na zpravu pockat pomoci prikazu select, a pak ji teprve prijmout.
5. kdyz nefunguji broadcasty, je nekdy dobre nejprve posilat paket na primou adresu, a paklize dojde, hledat chybu v broadcastu. Nedojde-li, je chyba nekde jinde nez v broadcastu (chyba na nektere strane).
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt