Kylix 3 tapasztalatok
2003-11-12T07:49:54+01:00
2003-11-13T18:21:38+01:00
2022-06-29T07:05:41+02:00
  • A c++ még 15 évig biztos nem hal ki, a Qt minősége se rossz és valóban multiplatformos.


    Ez igaz. Viszont ha nem GPL progit csinálsz akkor pofátlanul drága. 50%-kal több platformonként mint a komplett M$ Visual Studio .NET, pedig azért a tudása finoman szólva nemigen közelíti meg...

    Egyébként egyre szimpatikusabb a lazarus.freepascal.org. A CVS verzióban már elvben vannak adatvezérelt kontrollok is (csak data access komponenseket nem látok), jól beindult a dolog amióta utoljára néztem...
    Mutasd a teljes hozzászólást!
  • Igen! A TCriticalSection objectet már megpróbáltam, és nem sikerült. A 3. thread működését tisztázom, mert az 1-2-vel nincs gond.
    A kritikus adatokat egy adatbázis-tábla tartalmazza. A megjelenítéséhez egy TDBGrid objectet használok, tehát a megjelenítéshez és ahoz, hogy a felh. az új adatokkal számoljon, meg kell változtatnom a tábla adott sorát. Ezek után az adat a tábla>TDataSource>TDBGrid láncon át megjelenítődik. (szval azt csinálom, mintha a felh. változtatta volna meg az adatokat, csak ebben az esetben nem íródik fel a változás a kiszolgálóra) Ebben az esetben a táblámat hiába tettem TCriticalSession alá, mégis a szokásos accessviolation jött szembe, egészen addig, míg nem szinkron-végrehajtást választottam. Pedig csak a tábla-adatokat írja a 3. thread, a többit amúgy is a main-CLX-nek kéne csinálnia. Ebből nekem úgy tűnt, mintha a TCriticalSession csak a main thread ellen nem védne, amúgy jó.
    El kellett vessem ezt a megoldást, s miután ezzel egyetemben a MYDAC táblakészletre nyergeltünk át, itt lehetőség adódik arra, hogy az éppen aktuális sort, és csakis azt tudjam lekérdezni a táblából. Ez elég gyors, jóval gyorsabb, mint az előző megoldás, de nem annyira gyors, hogy a példában említett "távvezérléssel" frissítgessem a megváltozott sorokat, mert az adott sorra az adatbázis-kurzort rá kell léptessem. Ezzel újra fellépett az eredeti probléma lényege: hogyan lehetne ilyesmit megcsinálni?
    Szumma: olyan threadot kéne tudjak indítani, ami alacsony prioritással elvégzi a táblán a sorraugrás-frissítés-visszaugrás procedúrát, miközben a felhasználó csak egy számjegy változását lát az egészből.

    Misi
    Mutasd a teljes hozzászólást!
  • A leírás nekem így elsőre nem tiszta, viszont a hozzászólásod második része az:

    Szval azok a változók, amiket a fő thread kezel, nem írhatók más thread által, v nem jöttem rá, hogy hogy... És ilyen a grafikai megjelenítéssel kapcsolatos szinte minden object.(Kylix2-3 alatt) Köszönöm előre is...


    Ez így van. A A Delphi/Kylix változóhozzáférés, valamint a VCL/CLX nem thread-safe (azaz nem manipulálható egyszerre több szálból, a rendszer nem végzi el maga a zárolást).

    Erre alapesetben különböző kizárásokat lehet használni, kezdetnek javaslok egy ún. mutex megoldást (<mut>ually <ex>clusive, kölcsönösen kizáró). Intézd el, hogy mielőtt akár a szálad, akár a főszál hozzáférne az adott adatokhoz, kérje el a kizáró objektum kizárási jogát, majd a feldolgozás végén engedje el azt, hogy más is hozzáférhessen.

    Ezt VCL, illetve Win32 esetén a legegyszerűbben (?) ún. critical section (TCriticalSection, SyncObjs unit) objektummal lehet végezni és nagyjából úgy működik, hogy példányosítod az objektumot valahol és később azt használod a kizárásra, pl.

    procedure TForm1.OnButtonClick(Sender: TObject); var strData: string; begin { szerezzuk meg a kizaras jogat -- ha valaki mase a jog, akkor a program itt varakozni fog, amik a zarolas fel nem oldodik } critSect.Enter; try { masoljuk le az adatok sajat hasznalatra } strData:= KozosString; finally { engedjuk fel a zarolast } critSect.Leave; end; { irjuk ki az adatot } ShowMessage('Kozos ertek: ' + strData); end;

    A száladból pedig igy férsz hozzá:

    procedure TThread1.Execute; begin while not Terminated do begin ... critSect.Enter; try { mienk a zarolas, most irhatjuk } Form1.KozosString:= 'FeldolgozasEredmenye'; finally { engedjuk fel a zarolast } critSect.Leave; end; end; end;

    A lényeg az a filozófia és a tisztánlátás abban, hogy mikor melyik szálkontextusban jársz. Az emberek gyakran úgy gondolják, hogy csak azért, mert a főform kódját hivják meg, az máris a főform szálában hajtódik végre, holott természetesen nem.

    Péter
    Mutasd a teljes hozzászólást!
  • Kis plusz: "kritikus adatok változásának azonnali megmutatása" és még egy: a megváltoztatott adatokkal kell a ws-eknek tovább dolgozni. Ez magyarázat arra, miért csinál olyan sokat a 3. thread.
    Mutasd a teljes hozzászólást!
  • Következő az(egyszerűsített) helyzet:
    Adva van egy adatbáziskezelő jellegű progi, hálózatban fut max 20 ws-el, preferált kiszolgálóval.
    Felhasználói igény mutatkozott a kritikus adatok azonnali MEGMUTATÁSÁRA minden bejelentkezett munkaállomáson.
    Erre én:
    készítettem
    1, TCP-servert aki figyel(1. thread)
    2, TCP-vevőt, akit a server indít(2. thread)
    3, Execute: aki a vett info alapján "megmutat" (3. thread)

    Ezt az utolsót hiba nélkül csak úgy tudtam futtatni, hogy synchronize(execute): a program fő-threadjával szinkronban. Ennek az eredménye: az egész program megáll, amíg ez a megjelenítőke be nem végzi a dolgát. Ha sok esemény van, bele is hal. Kb ennyi a lehető legrövidebben...

    Szval azok a változók, amiket a fő thread kezel, nem írhatók más thread által, v nem jöttem rá, hogy hogy... És ilyen a grafikai megjelenítéssel kapcsolatos szinte minden object.(Kylix2-3 alatt) Köszönöm előre is...
    Misi
    Mutasd a teljes hozzászólást!
  • De(nem tudom hogy jöttél rá) pont thread-gondjaim vannak: nem sikerült rájönnöm, hogyan szabályozhatom saját thread-jeimet úgy, hogy thread-ek maradjanak és mégse vesszenek össze a mainCLX-threaddel(tehát nem jó a synchronize(execute))


    Nem jöttem rá, csak említettem a szálkezelést. Konkrétan milyen problémád van velük, mi az "összeveszés"? Mint mondottam volt, nem ismerem a CLX-et, gyakran dolgozok többszálú környezetben, talán tudok segíteni.

    Péter
    Mutasd a teljes hozzászólást!
  • Ahá! Méghogy a KDE is Qt-vel...
    Mutasd a teljes hozzászólást!
  • Köszönöm, a Qt-t meg kell nézzem. De(nem tudom hogy jöttél rá) pont thread-gondjaim vannak: nem sikerült rájönnöm, hogyan szabályozhatom saját thread-jeimet úgy, hogy thread-ek maradjanak és mégse vesszenek össze a mainCLX-threaddel(tehát nem jó a synchronize(execute)) A libc-vel próbálkoztam, de nem volt átütő siker... Elolvasom a cikket!

    Misi
    Mutasd a teljes hozzászólást!
  • A Qt thread-ekkel kapcsolatban egy remek cikket találsz az elmúlt két Linuxvilág számban, egyik fórumtársunk tollából. Az új moderálási szabályok szerint nem nevezhetem meg :)
    Mutasd a teljes hozzászólást!
  • Tényleg, nagyon láma kérdes ez a Qt-ről? Úgy érzem, ezt nekem tudnom kéne, hogy mi az...


    Legalábbis nem árt tudni :) Nem ismerem a D5 feletti/Kylix vonalat, de -- legalábbis egy ideig -- ez volt (vagy még mindig?) a CLX alapja.

    A Qt egy multiplatform C++ GUI/API könyvtár, bővebben a gyártó Trolltech honlapján.

    Mint a többi hasonló multiplatform könyvtár, elrejti az platformfüggő implementációs részleteket és egy egységes felületet nyújt a platform(ok) programozására, kezdve a GUI-tól (gombok, edit boxok, stb.) a szálkezelésen át az adatbázis-hozzáférésig (egyébként a wxWindows nagyjából ugyanezt nyújtja igy első ránézésre, csak ingyenes. Valaki majd kijavit, ha hazudok).

    Péter
    Mutasd a teljes hozzászólást!
  • Tényleg, nagyon láma kérdes ez a Qt-ről? Úgy érzem, ezt nekem tudnom kéne, hogy mi az...

    Misi
    Mutasd a teljes hozzászólást!
  • Javaslatodat köszönöm, én is hasonlóra gondolok, csak... Nem tudom pontosan, mi az a Qt, csak sejtem. Ezt a Qt-t mint unitot a Kyli3 delphi részébe is meg tudom hívni, de itt csak azért kellett eddig, hogy a billentyűlenyomások esetén ne word-el, hanem pl. key_enter-ként azonosíthassam a gombot. Ez egy típusgyűjtemény-könyvtár? Vagy más is? Szóval légyszi ha tudod egy pár szóban elmondani, mire is jó a Qt?
    Mutasd a teljes hozzászólást!
  • Nekem hasonlóképp, csak nálam az első már a TP5.5 volt PC-n (előtte ZX Spectrum, Videoton "GRAPHICS 2" TVC, stb.)

    bocs2 javaslata is megfontolandó a Qt-vel, nem is tudom, miért nem említettem.

    Péter
    Mutasd a teljes hozzászólást!
  • Köszi, a wxWindows-t azért megnézem közelebbről is. Amúgy én a tehetetlenségi nyomatékból adódóan maradtam pascal(jó öreg tp 3.0-val és masm-el kezdődött PC-s ténykedésem), a c-re meg halványan emlékszem, mikor nálunk még pár PC, ha volt. A basic rövid volt nálam, és nem átütő.

    Misi
    Mutasd a teljes hozzászólást!
  • szerény javaslat, ha multiplatformról van szó: c++ és Qt.
    A c++ még 15 évig biztos nem hal ki, a Qt minősége se rossz és valóban multiplatformos.
    Mutasd a teljes hozzászólást!
  • Igen, nagyon fontos lenne a cross-platform, de vajon a C++ meddig lehet az?


    Amíg a C (és fogjuk rá, a C++ is) a programozás
    lingua franca
    -ja, addig biztosan. Azt hiszem, még egy nagyon jó darabig az is lesz. LC tud mesélni a wxWindows-ról, ez egy nyílt keresztplatformos project, olyasmi funkcionalitással, mint a VCL/CLX vagy inkább az MFC (ld. még FX FX). Én Nem dolgoztam vele, csak annyit (sem) tudok róla, mint amennyit LC mondott.

    Sajnos Java-hoz még nem igazán szagoltam...


    Én sem, pedig igazán csinos nyelv, óriási és hatékony frameworkkel, támogatással a háta mögött, egyelőre nagyon stabil (és jól fizető :) választás.

    Hozzászólásaitokból egy biztos: c felé kell mennem, lehet hogy eleve hiba volt pascalba kezdeni...


    Nos, (elsősoran) Delphi fejlesztőként mondanám, hogy "nem is, jól választottál" de ez nem lenne igaz. Nálam anno a szimpátia döntött, nem tetszett a C és a C++ mégúgy nem (pedig akkoriban még sokat assemblyztem is :)

    Péter
    Mutasd a teljes hozzászólást!
  • Igen, nagyon fontos lenne a cross-platform, de vajon a C++ meddig lehet az? Sajnos Java-hoz még nem igazán szagoltam... Hozzászólásaitokból egy biztos: c felé kell mennem, lehet hogy eleve hiba volt pascalba kezdeni...
    Mutasd a teljes hozzászólást!
  • Minden izének van egy fejlődési ciklusa. Ez azt jelenti hogy x évenként úgyis újra kell írni mert addigra jön egy rakat új feature amit bele akarsz tenni, megváltoznak a számítógép architektúrák, fejlesztőrendszerek, stb.

    Teljesen jogos a felvetésed, gondolnom kellett volna erre nekem is. Az is látható(szrintem) hogy azért van pár év erre, de mostanság azért legalábbis gondolkoznom kéne, hogy mire váltani... szerintem igy v. úgy, a c-ben el kell mélyednem. Amúgy meg azt hiszem az izére is ráférne az átírás...
    Mutasd a teljes hozzászólást!
  • Hol nézhetném meg a linuxos .NET-et, pl. a motort azaz a CLR-jét?


    Amennyire én tudom, jelenleg ez a legfejlettebb Linuxos .NET motor (több párhuzamos project is fut):

    Home

    Péter
    Mutasd a teljes hozzászólást!
  • Hol nézhetném meg a linuxos .NET-et, pl. a motort azaz a CLR-jét?
    Speckó kellene, mennyire gyorsan forditja az IL-er kódot!!!!
    Mutasd a teljes hozzászólást!
  • A Borlandnál a Hízó J. egyébként azt mondta, hogy a CBuilderX-nél lehetséges, hogy a kdevelop is jobb. Engem nagyon lehangolt...


    ...de a kedvencem az volt, amikor nemrég valamelyik magyar szaklapban megszakértették a Borland C#Buildert (erre vajon mi szükség van, de hagyjuk...) és telinyomták MS Visual Studio.NET screenshotokkal a cikket.

    A Borland mintha kapkodna, nem? Úgy érzem, sokat akarnak markolni, de keveset fognak. Az egyébként látszólag stabil Delphi ágat is megnyomorítják.

    Péter
    Mutasd a teljes hozzászólást!
  • OK, de azért nem lesz gyenge ezt a kétéve fejődő izét, amit csinálok, áttenni bármilyen másik nyelvre... de ha muszáj, akkor C# Szóval eshetek is neki?


    Nézd, nem tudom megmondani. Ez egy pletyka, ami leginkább spekulációkon alapul, a Borland nem erősítette meg és sajnos nem is cáfolta.

    Ha a cross-platform fontos, akkor mivel a Mono project sorsa sajnos szintén kétséges részemről a Java-t javasolnám, illetve C++-t és wxWindowst.
    Mutasd a teljes hozzászólást!
  • Nem akarlak elkedvetleníteni de szvsz a KDevelop3 nagyon-nagyon sok mindennél jobb. Mondhatnám azt is hogy a legjobb IDE amit valaha láttam (igaz a legjújabb VS.NET C++ részével még nem volt időm megismerkedni). De tényleg cool, érdemes megnézni, legalábbis nekem nagyon bejött a felhasználói felülete (azt hiszem IDAI-nak hívják) és a szolgáltatásai sem rosszak. Kár hogy mostanság nem nagyon van C++-os melóm, főleg Kylix alatt tevékenykedem...

    Viszont a CBuilderX mellett szól hogy a wxWindows-hoz van felületszerkesztő, property editor, azaz komplett RAD környezet. Legalábbis screenshot formájában, működni még nem igazán láttam, és állítólag még fejleszteni fogják. Szintén mellette van hogy ha jól tudom van neki C++-ból elérhető dbexpresse. És annyira nem gagyi ez sem: kb azt tudja mint a JBuilder IDE-je. Szépséghiba csak a java-s megvalósítás ami nem tesz igazán jót az erőforrásigénynek, bár annyira a mai gépeken nem is vészes...
    Mutasd a teljes hozzászólást!
  • A Borlandnál a Hízó J. egyébként azt mondta, hogy a CBuilderX-nél lehetséges, hogy a kdevelop is jobb. Engem nagyon lehangolt...
    Mutasd a teljes hozzászólást!
  • Minden izének van egy fejlődési ciklusa. Ez azt jelenti hogy x évenként úgyis újra kell írni mert addigra jön egy rakat új feature amit bele akarsz tenni, megváltoznak a számítógép architektúrák, fejlesztőrendszerek, stb. Ez az x pedig programtípusonként különböző, dobozos progiknál elég ritka hogy < 3-4 év, ellenkező esetben azt veszed észre hogy egyre kevesebben veszik a jó kis DOS/Clipperes progidat és a konkurrencia messze elhúzott melletted...
    De ez még a jövő zenéje, szvsz úgy 3-4 évig a Kylix és a D7 még valószínűleg elketyeg, hacsak valaki ki nem talál valami forradalmi újítást a linuxban ami jól megborítja a bináris kompatiblitást, vagy az M$ úgy nem dönt hogy a win x+1-es verziójában már csak managed kódot lehet a usereknek futtatni. De én egyiknek sem látom túl nagy esélyét...
    Mutasd a teljes hozzászólást!
  • OK, de azért nem lesz gyenge ezt a kétéve fejődő izét, amit csinálok, áttenni bármilyen másik nyelvre... de ha muszáj, akkor C# Szóval eshetek is neki?
    Mutasd a teljes hozzászólást!
  • A C++ után a C# nem olyan nagy megrázkódtatás, legalábbis nekem nem tűnik annak. a VB.NET viszont nekem nagyon undorítónak tűnik, inkább megtanulnék még három új nyelvet minthogy VB.NET-tel foglalkozzak .
    Mutasd a teljes hozzászólást!
  • Igen, sajnos az már egy jó ideje tiszta számomra is, hogy a Delphi/Kylix ObjectPascal nem egy "job security".

    Sebaj, azért vagyunk fejlesztők, hogy egyszerre mozduljunk a piaccal vagy ha lehet, még korábban.

    Szerintem sincs sok értelme az ObjectPascal-os .NET-nek, akkor már C# vagy (horrible dictu!) VB.NET.

    Mind a Java, mind a C# szimpatikus nyelv, csak időm lenne rájuk :(

    Péter
    Mutasd a teljes hozzászólást!
  • Szvsz ez úgy 2-3 év alatt el fog dőlni, addig meg jó a Kylix.

    Jelenleg ugye ott van a .NET ami vagy nyer vagy nem. A nyerés mellett az áll hogy elég kényelmes programozási környezet, és a M$ beledob apait-anyait, ráadásul a Borland is melléáll. Viszont ha a .NET nyer az szvsz a Delphi/Kylix vonal kihalásával jár, mivel szvsz épeszű ember .NET-et C# alatt kódol, így az Object Pascal max. kompatibilitási okok miatt él még egy ideig.
    A nyerés ellen szól viszont a pici kis .NET futtatókörnyezet amit minden ilyen proginak hurcolnia kell, és az hogy a .NET nem igazán villámcsapás már ami a sebességet illeti. De hosszú távon szvsz a .NET a nyerő. Kérdés csak az hogy multiplatfrom lesz-e, azaz mi lesz a mono project sorsa.

    A másik dolog amerre el lehet indulni az a C++. Ott van mindjárt a Borland CBuilderX ami ha betartják amit a legutóbbi fejlesztői konferenciát igértek akkor elég cool kis dolog lehet. Ráadásul a C++ mehet natívan és managed módban, linuxon és .NET alatt egyaránt. A probléma a C++ fölötti rész: kellene ugye egy adatbázis interfész és valamilyen felület. Az utóbbinak igen kellemes a wxWindows és a CBuilder-X is támogatja némi RAD feature-ökel. Ráadásul eléggé multiplatform, azaz megy linux, win32, Mac platformokon. Az adatbázis kérdés már érdekesebb. Ezt elvben nyújtja a wx is de az ő adatbázisos dolgai a gagyi szint körül mozognak.

    Persze elvben ott a jó öreg java is. Neki csak két nagy gondja van: 1. az erőforrásigénye ami még a .NET-en is túltesz, különösen desktop alkalmazások esetén, a másik pedig hog őt is telepíteni kell. Ráadásul a C# nyelv is sokkal kellemesebb jószág mint a java, meg a .NET többi dolga is szimpatikusabbnak tűnik. De a javát is nagyon meg akarják újítani...

    Szóval ma még nem lehet tudni hogy mi lesz mire a K3 elavul...
    Mutasd a teljes hozzászólást!
  • Szerintem is csak (rövid) idő kérdése és kihal a Kylix. Érdeklődtem az ügyvezető igazgatónál és sajnos nem mondott olyat, hogy ezt meg lehessen cáfolni.


    Pedig ugye a Linux desktop terjedésének egyik kerékkötője a GUI ügyviteli szoftverek hiánya (nem abszolút, hanem relatív) és ebben a témakörben nagy segítség a Kylix.

    Kiváncsi vagyok, mi történik vele.

    Péter
    Mutasd a teljes hozzászólást!
abcd