C++ fejleszteni, de hogyan?
2006-06-18T10:16:04+02:00
2006-06-20T22:08:54+02:00
2022-07-18T21:05:46+02:00
  • Az új Win Vista kernel szinten a .NET 3.0-ra épül, a Win32 támogatás megmarad a kompatibilitás miatt, de csak Interoppal lesz elérhető

    Ez a terv. De a Vista még nem esik ebbe a kategóriába. Csupán csak jóval több .NET-es interfész elérhető, mint a .NET 2-ben. Majd a következő windows. Vagy a következő. Vagy a Singularity.

    LC:
    És az a M$ agyonreklámozott, az SQL szerverbe beleintegrált szolgáltatása - olyan hiányosságokkal amik az én saját Kylix-os reportgenerátoromban is meg voltak oldva pedig azt egyedül fejlesztettem úgy egy évig, ezen meg gondolom kismillió M$ rendszerprogramozó dolgozott.

    Ez a reporting hogyismondjam jóindulattal egy béta. Pedig házon belül egész tűrhető reporting megoldásaik vannak már, pl. az msaccess beépítettje. Csak most ugye nagyon erőltetni kellett ezt a webalapú vackolást.

    mik@gery:
    Elvileg a MS megirigyelte a java sikerét és látta,hogy fejlődni kéne ezért készült a .net.

    Nos a .NET eredetileg a COM+ 2.5-ös verziója lett volna, aztán kiderült, hogy a megoldás sokkal közelebb van a Java féle technológiákhoz, mint az elsőre látszott. Úgyhogy kidolgozták teljes szélességben. És látá az Úr, hogy jó.

    Azért az igaz,hogy rendesen el is lennék képedve ha a MS bármiféle módon is segítené a programfejlesztést linuxra

    Akkor kezdheted.
    A .NET teljesen nyílt, mindenki által hozzáférhető szabványokra épül, és ahogy mondod, bizonyos részeknek tényleg elérhető a forráskódja.

    új funkcióval akarod bővíteni a .net-et az bármely nyelv,bármely fejlesztőkörnyezetéből elérhető lesz.

    Csak olyan nyelvből, ami a CLS szabványnak megfelel.
    A CLS például megköveteli a case sensitivitást, a VB viszont nem, ezért habár VB-ből is CLS-compliant kódot gyárt a fordító, tehát VB-ből gyárthatsz bárki által használható komponenst, korántsem biztos, hogy bármilyen, más által gyártott komponenst (jelen esetben ami kihasználja a case sensitivitást) fel tudsz majd használni.
    Mutasd a teljes hozzászólást!
  • Mondasz valamit.
    Bocska!
    Mutasd a teljes hozzászólást!
  • Elvileg a MS megirigyelte a java sikerét és látta


    Gyakorlatilag meg az elavult WINAPI és a COM technológiát akarta lecserélni.

    hardwear és softwear

    hardware és software

    Nagyon okos ötletnek tartom,hogy elvileg ha valamilyen új funkcióval akarod bővíteni a .net-et az bármely nyelv,bármely fejlesztőkörnyezetéből elérhető lesz.


    Azért vannak/lesznek megkötések, főleg VB és Delphi-nél...

    hogy van futtatókörnyezetük windowsra,linuxra,solarisra.


    Mint ahogy írtad is, ott a MONO. Elég ígéretesnek néz ki.

    de azért a Linux társadalom elég nagy része kifejezetten MS utáló


    Nem a linux tábor jelentős része, hanem a hozzánemértők scriptkiddie-k (átlagkor és iq 13-18).
    Mutasd a teljes hozzászólást!
  • tényleg ne haragudj, de ezt nem hagyhatom ki:
    soft- és hardwear, vagyis könnyű- és nehézviselet?
    Mutasd a teljes hozzászólást!
  • Tegnap bővítettem a szinte nem létező tudásomat a .net-el kapcsolatban. igazából 5-6cikk elolvasása után egész más véleményem van róla mint ezidáig és pár tévhítem is megszünt.Ezidáig csak két VB hívő haverom előadásából tudtam vmennyit.Egy pár kérdés felmerült bennem.
    Elvileg a MS megirigyelte a java sikerét és látta,hogy fejlődni kéne ezért készült a .net.Ami magában hogrdozza a java jó tulajdonságait,a legtöbb helyen többet is nyujt annál,de érzésem szerint néhol kevesebbet.Ezek és a következő állítások az én meglátásaim és feltételezéseim az eddigi tudásom alapján,ha nem helyes valahol javítsatok csak agyba-főbe,végül is ez lenne a cél.
    Nagyon okos ötletnek tartom,hogy elvileg ha valamilyen új funkcióval akarod bővíteni a .net-et az bármely nyelv,bármely fejlesztőkörnyezetéből elérhető lesz.A szoftwear komponensek eltérése mindig is a rémálmaim voltak.Maga a futás közbeni fordítás lehetővé teszi nekünk a platformfüggetlenséget hardwear és softwear terén(ha jól tudom MS OS-eken csakis).Okos ötlet,gondolkodjon a futtatókörnyezet hejettünk.
    Programozás tanulásom elején megtetszett a java,sajnos a megtanulására azóta sem volt időm.csak nagyon zavartak a benne írt alkalmazások futási sebesség problémái.A .net-es alkalmazásoknál ilyet nem tudtam észrevenni.
    A java +ának érzem azt hogy van futtatókörnyezetük windowsra,linuxra,solarisra...A .net-nél ilyen sajnos nincs.Azért az igaz,hogy rendesen el is lennék képedve ha a MS bármiféle módon is segítené a programfejlesztést linuxra.Viszont itt jönnek a dolgok amiket nemtok felfogni.Valahol olvastam hogy az MS kiadta a .net forráskódját,hogy azt lelkes önkéntesek portolják linuxra!?Ilyen létezik? De pl. itt a dotGNU és a Mono.Ezekről pl nemtom eldönteni,hogy vajon a .net linuxos megfelelőjét jelentik -e vagy pedig épp az előbb említett foráskódot portolták linuxra.Azért valjuk be,hogy ha nem is mindenki de azért a Linux társadalom elég nagy része kifejezetten MS utáló. Szal hogy is van ez?
    Mutasd a teljes hozzászólást!
  • Konkrétan: ndoc
    Mutasd a teljes hozzászólást!
  • Abban azért bízom hogy valaki csak megcsinálja ezeket a vezérlőket böngészőfüggetlenre és előbb-utóbb közzé is teszi, akár a codeproject-en akár pénzes kontrollok formájában. De őszintén szólva idáig nem sok ilyen gondom volt, mondjuk tree-t speciel nem használok, a grid, textbox, stb. szerencsére megy mozilla alatt is. Amúgy jó fesztiválozást!
    Mutasd a teljes hozzászólást!
  • Először is bocsi, hogy ennyit postolok, de holnaptól Vekeri Fesztivál 2006, és ezért a héten szabit adtam magamnak.

    Az MSDN sajnos eléggé shittes. Tele van hibával, főleg a példaprogramok! Nagyrészt az 1.1-esből átkopipesztelt dolgok, amiket elfelejtettek revízionálni. Pont ezért tettem fel egy kérdést a Tudástárban (nem megy az MS féle kód, aztán nem találom, hogy miért), de még senki sem méltatta reagálásra.

    Sajna be kell vallani, hogy a .NET beépített cuccai közül nagyon sok csak egy rakás kaka. Gyönyörű példa erre az ASP.NET beépített WebControljainak nagyobb része. IE függő borzalom. Az a szerencse, hogy a framework minden eszközt megad (korrek absztrakt osztályok, interface-k), hogy ezek helyett létrehozzuk a saját változatokat. Mindezt úgy, hogy megőrizzük a jól átgondolt lehetőségeket, pl. DataBind. Ezért írtam arról, hogy ha valaki programozó akar lenni, akkor nem kerülheti el az olyan ismeretek elsajátítását, amik ahhoz szükségesek, hogy megértsük a teljes fw belső működését.

    Erről a reportozásról csak másodkézből vannak információim, mivel nem a szakterületem a dolog. Sok sikert hozzá! LOL
    Mutasd a teljes hozzászólást!
  • Háát miért nem ezzel kezdted!

    A dokumentáció pl. VS-ben marha egyszerű, mert a ClassView-ben is megteheted. Automatikusan megy a doksi vagy a dll-be, vagy egy külön XML-be.

    A Borland-féle .NET-es, VCL-es RAD Tool-ok az UML-t forszírozzák. Ahhoz is van szép class view, meg doksi szerkesztő.

    Ez a része abszolút nem kér enni.

    Ha másban dolgozol, akkor lehet, hogy ennyire nem vagy jó helyzetben, marad a papír, vagy a Word. Amúgy vannak jó UML dokumentáció készítő progik, van is erre egy topik valahol. De én nem szeretem az UML-t, mert annyira programozás idegen!
    Mutasd a teljes hozzászólást!
  • Nem igazán referenciákra gondoltam.Az rengetegem van.Nem hiszem, hogy az életem elég lenne arra,hogy átnyálazzam őket.
    Dokumentálást kérdeztem. Hogyan kellene dokumentálni a program felépítését, beleértve osztályokat,algoritmusokat... Meg persze főleg,hogy mivel.
    Mutasd a teljes hozzászólást!
  • Én már lassan a 40-hez állok közelebb (37) de azért tegezhetsz . A doksikra visszatérő szálat nem igazán értem, én elég jól el vagyok látva doksival minden irányból, más kérdés hogy vannak olyan problémák amire az MSDN fórumon sincs válasz... Az MSDN egyébként tényleg elég jó, bár vannak pontok ahol azért elkelne némi további magyarázat, és én már találtam bugot is benne, pedig csak pár hónapja .NET-ezek intenzívebben. De a .NET redmondi központjának felrobbantása nem emiatt lenne esedékes, hanem Pl. hogy a reporting service header-jében nem tudsz közvetlenül adatkötést csinálni, vagy hogy a page header-t nem lehet programból növelni/csökkenteni (csak a report definíciós fájl átírásával), az egyébkén elég korrekt autosize sem növeli a page header magasságát és ezért ha a textboxban több van mint ami belefér (és az autosize nincs letiltva) akkor a fejléc belelóg a tételekbe. És az a M$ agyonreklámozott, az SQL szerverbe beleintegrált szolgáltatása - olyan hiányosságokkal amik az én saját Kylix-os reportgenerátoromban is meg voltak oldva pedig azt egyedül fejlesztettem úgy egy évig, ezen meg gondolom kismillió M$ rendszerprogramozó dolgozott.

    A Qt-hez vagy a GTK-hoz egyébként ugyanúgy megvan a saját dokumentáció mint a .NET-hez, persze kevesebb de nem is akkora falat egyik sem. A probléma csak ott van hogy a Qt-t aranyért adják (a tudásához képest), a GTK pedig verziónként akkorát változtat az API-n hogy a lazarus project (VCL és RAD a Free Pascal fölé) Pl. még mindig 1.x-es GTK-ra épít /bár elvben van 2-es port is de az máig sem lett stabil/.
    Mutasd a teljes hozzászólást!
  • Én sem vagyok éppen mai csirke, sokkal közelebb állok a 30-hoz, mint a 20-hoz. Ez nem tudom, hogy mire elég Veled szemben. Őőőő, azért még tegezhetlek?

    A doksikra visszatérve: ha letöltesz egy toolkitet, vagy akármit, akkor ahhoz jár dokumentáció. Ha máshol nem, akkor a honlapon, ahonnan levadásztad.

    Ez ugyan úgy igaz a fejlesztőkörnyezetekre is. A VS 2005-höz pl. adják a teljes idevonatkozó MSDN dokumentációt, példákkal, tutorialokkal, mindennel.

    Azért írtam a Google-t, mert ha oda beírod, hogy Qt, vagy Gtk, vagy C++/CLR .NET, akkor évekre el leszel látva információkkal. Korrekt linkeket azért nem tok adni, mert szerintem még Te sem döntötted el, hogy merre indulsz el, igaz?

    Mondjuk ez egy jó oldal Internetes és .NET-es infókhoz: Code Project

    Mindent meg lehet találni a neten. Ha végképp nem megy, akkor még mindig össze tudsz dobni egy bombát, amivel felrobbanthatod az MS Redmondi központját!
    Mutasd a teljes hozzászólást!
  • A qt 4-es verziójától kezdve van GPL-es ingyenes változat, persze a vele készített programot nem lehet eladni.
    Mutasd a teljes hozzászólást!
  • Talán a google.com-ot nem kellett volna említeni.Az esetek 99%ában nagyon jól feltom találni magam, ezt a témát is csak azért nyitottam mert személyes segítség szükségét éreztem.
    Mint már mondtam nem vagyok teljesen zöldfülű csak éppen nem követtem ezidáig a programozás fejlődési irányát.
    Egyébbként mindenkinek köszönöm a segítséget.
    Szóval összefoglalásul a Borland IDE-ekre ne vesztegessek időt mivel nincs jövőjük,ha windows fejlesztés akkor VC++és .net,ha pedig keresztplatformos fejlesztés akkor minnél standardabb C++ használata valamilyen keresztplatformos GUI toolkittel.Világosan látom a lényeget?
    A dokumentáció mivel/hogyan kérdésem még áll.
    Mutasd a teljes hozzászólást!
  • Ráadásul kisebb projecteknél a wx sem olyan nagy varázslat. Nagyobb SQL-es, xml-es projectekbe pedig én nem kezdenék C++-ban...
    Mutasd a teljes hozzászólást!
  • A QT tényleg nem rossz, a hátránya a másik kettővel szemben az, hogy míg a wxWidgets és Gtk tudtommal teljesen ingyenesek, addig a QT-nak a Windowsos (illetve Mac-es) verziójáért elkérnek pár ezer dollárt.
    Mutasd a teljes hozzászólást!
  • Meg annyi, ha X-platformos UI-t akarsz (mondjuk kicsi SQL, XML, stb... ), akkor azert a Qt elegge finom darabb tud lenni, enyhen konyebb hasznalni, mint a Gtk++-t vagy a wxWidget-et.
    Mutasd a teljes hozzászólást!
  • Ez mondjuk igaz.
    Mutasd a teljes hozzászólást!
  • Nyugodtan hihetsz neki, mert látom, hogy vérprofi a gyerek!


    Ezen jót kuncogtam
    Ha látnád LC-t élőben, lehet, hogy nem azt mondanád rá, hogy gyerek
    Mutasd a teljes hozzászólást!
  • Köszönöm LC kolléga pontosítását! Nyugodtan hihetsz neki, mert látom, hogy vérprofi a gyerek! (tényleg) Én nem akartam ebbe ennyire belemenni, lévén mik@gery csak most kezdi az egész dolgot, felesleges itt ijesztgetni mindenféle törzsi humbuggal.

    mik@gery-nek válaszolva:

    Windowson messze kerüld az egész Win32-tőt és az arra épülő összes dolgot (MFC, VCL, stb.), mert uszkve egy év múlva éhen fogsz halni.

    Az új Win Vista kernel szinten a .NET 3.0-ra épül, a Win32 támogatás megmarad a kompatibilitás miatt, de csak Interoppal lesz elérhető (ez lesz a framework a Vistában ).

    Mióta Steve Ballmer vezeti a céget, előtérbe került a hozzáértés, és a marketing csak másodlagos szempont az MS-nél (legalábbis én ezt szeretném hinni, meglátjuk). Ezért is lesz teljes API váltás, amire már a Win95 megjelenésekor is nagy szükség lett volna.

    Fejlesztőkörnyezetnek ott a VS 2005. .NET 2.0, amit a Te C++-os ismereteiddel is hamar elsajátíthatsz a C++/CLR nyelv révén (módosított C++). Ezek után nagyon hamar, zökkenőmentesen át tudsz ugrani a C# -ra, ami a .NET igazi nyelve (ez így nem igaz, mert az az MSIL, de tényleg a C#-pal jársz a legjobban, ha a C++ felől érkezel).

    X-platfrom fejlesztésekhez pedig már mindent leírtunk, amit tudnod kell. Google-nek hívják azt az oldalt, amit keresel, ha információkra van szükséged!
    Mutasd a teljes hozzászólást!
  • Pontosítsunk...
    mert mind a VCL, mind pedig az MFC nem más, mint egy platformfüggő C++ library.

    Az MFC ugyan valóban platformfüggő C++ lib (bár mintha valahol láttam volna egyszer egy fizetős *nix-es MFC implementációt), viszont a VCL egy platformfüggő pascal library. A BCB pedig úgy műxik hogy van benne egy Object Pascal fordító is. Ezenkívül orrba-szájba bővíti a C++ nyelvet hogy az Object Pascal alapú VCL-lel kompatibilis lehessen, ezért aztán a C++-os kódodat nemigen tudod portolni Borland-mentes fordítóra.

    Erre próbálkozott a Borland a CLX-szel, ami szintén csúfosat bukott, mert a kutya nem foglalkozott vele.

    Ez sem egészen igaz. Ma is legalább akkora anyázás folyik a CLX vonal megszűnte miatt mint anno a BCB vonal leállítása miatt. Más kérdés hogy a C++-os clx kivételesen sikertelen volt, de ennek oka szvsz leginkább az implementáció volt, magyarán a Kylix C++-os IDE illetve fordító még Delphi-s IDE-nél is problémásabb jószág volt az újabb disztribeken. A CLX vonal megszüntetésének meg szvsz alapvetően 3 oka lehetett:
    1. Qt alapú volt, méghozzá a Trolltech és a Borland közötti egyedi megállapodás alapján. Ez a Qt 2.x-re vonatkozott, most pedig lassan Qt 4.x lesz az aktuális - amire már a megállapodás nem biztos hogy igaz.
    2. A win32 (Delphi7) vonal megszűnése. A Kylix úgy jött létre hogy fogták a win32 alapú fejlesztőeszközöket és a wine nevű windows emulátorral portolták linuxra. De ez a wine elég macerás jószág, különösen az a verzió amit a borland még használt a portoláshoz.
    3. A linux eléggé mozgó célpont a win32-höz vagy a .NET-hez képest. Már a Kylix3 sem nagyon követte a linux distrók változásait, amikor megjelent már akkor olyan oprendszer követelményei voltak (SuSE 7.x, stb) amik kb. a Kylix1 idején számítottak új verziónak.
    Mutasd a teljes hozzászólást!
  • Imho, ha cross platform forrasokat akarsz csinalni, akkor gcc/mingw (v mi az isten) forditot hasznaljal, ez a legtobb platformon megtalalhato. GUI toolkitnek ott a gtk (ezt ugy erzem, h kvazi szabvany lett), vagy a wxWindows. Gyors rajzolgatashoz SDL (nem probaltam), nyoszorgeshez OpenAL (Ezt se probaltam). Ezek az elterjedt platformokon megtalalhatoak, igy talan eleg rugalmas kodot tudsz eloallitani. Ja, es persze sok-sok factory pattern. :)
    Mutasd a teljes hozzászólást!
  • Még egy szó a Builderről.
    Azt szeretem benne, hogy ha a fejlesztésben olyan részhez érkezek amikor tudni akarom mit csinál a program azt pontossan megmondhatom neki,ha pedig olyan résznél vagyok ahol egyszerüen csak egy feladatot elkell végeznie azt elvégzi és nem terhel olyan dolgokkal amik nem érdekelnek. értsd: Assembly kódot gyönyörüen be lehet keverni a c++ kódba ha szükséges, ha pedig csak valamilyen gui funkció hiányzik csak bevágok egy vcl objektumot és kész.Valamilyen hasonló képességekkel rendelkező fejlesztőkörnyezet kéne,nemtom a VC hogy áll ilyen szempontból.A legidegesítőbb a két fejlesztőkörnyezetben,hogy a dll-ek felépítésében nem értenek eggyet.Jelenleg külső, saját készítésü hardverekhez készítenék támogató programokat,ezért fontos az assembly.Adatbáziskezelés és hálózati funkciók nem annyira,bár ha jól látom ha arra adom a fejem h programozó ként helyezkedjek el ezek lesznek a legfontosabbak,mármint hogy ebben van a pénz.
    Mutasd a teljes hozzászólást!
  • Juteszembe!Tudnál ajánlani valamilyen programozási portált amin nem csak tutorialok vannak,hanem komoly irások és összehasonlítások fejlesztőkörnyezetekről,nyelvekről,frameworkökről,ami segítene elígazodni a dzsungelben.
    Annak idején kb.6 éve nekem a tomshardware.com rengeteget segített hardware terén.Mármint nem a hardware müködésének megértésében, hanem magában az eligazodásban a márkák,platformok,és megoldások terén.
    Mutasd a teljes hozzászólást!
  • Köszi!Így már kissé világosabb.
    Egyenőre a C++os fejlesztést erőltetem mivel a vizsgáim mellett jelenleg nincs időm megtanulni c#-ot vagy java-t, de majd igyekszem.Esetleg milyen nyelveket ajánlasz?
    Szóval mielőtt nekiállok egy projekt fejlesztésének körülnézek, hogy milyen frameworköt is használjak.Ha windowsra fejlesztek akkor VCL/CLX, .NET,MFC, neadjisten Win32API,stl a lehetőségek. Ha pedig keresztplatformos fejlesztés akkor Qt,GTK és hasonlók.Azzal hogy az összes platformspecifikus kódot beillesztem és fordítás előtt csak egy sor megváltoztatásával kitom választani hogy mely kódrészletek fordítódjanak le. Jól értettem?
    Tehát az UML-t nem ajánlod ha jól értem.Milyen módon kellene/szokás a forráskódot dokumentálni? Van egy pár befejezetlen projektem ami olyan szintre jutott, hogy valamiféle dokumentáció nélkül elveszek benne mint gyerek a kakiban.
    Mutasd a teljes hozzászólást!
  • Elnézést ha néha nem fejezem ki elég világosan magam.


    Mint ahogy én sem egy másik topicban folyton...

    A C++Builderrel kapcsolatban csak jó tapasztalataim vannak ezidáig.

    ->
    A 2006os Buildert még nem próbáltam.




    Én is imádtam a BCB6-ot és a VCL-t annak idején. De ez már őskövület. A Win32 platform mint olyan, halott. Ez okozta a Borland megkeveredését is. Ezekben (Win32,VCL,VCL.NET) megkezdeni egy fejlesztést egyenlő a szakmai öngyilkossággal, és ezt a Borland is elismeri. Csak azért erőltetik tovább a VCL.NET-et, mert egy rakat projekt létezik VCL alá, amit így könnyű portolni .NET-hez. Azonban dög lassú, mert még egy absztrakciós réteget rak a már meglévő fölé. Új projektekhez a Borland sem ajánlja.

    Az a poén, hogy a Borland csak az új "Highlander" verzióban fogja kiadni mindazt (részben), amit még a "Dexter"-hez (BDS 2006) ígért. El is vesztette a híveinek 80%-át, ahogy a szakmai blogokból megtudhatjuk.

    Szóval én a Borland-re nem építenék a jövőben, mint fejlesztői (RAD) platform.

    Egy szónak is száz a vége, ha windóz, akkor .NET, (már) nem Win32 és végképp nem VCL...

    A kérdésedre válaszolva, röviden: sehogy.

    Hosszan: a BCB-s projekt a Borland féle C++/VCL implementációra épül; a Visual Studio (Win32) projekt pedig az MFC-re (általában). Ezek nem szeretik egymást, mert mind a VCL, mind pedig az MFC nem más, mint egy platformfüggő C++ library.

    Erre próbálkozott a Borland a CLX-szel, ami szintén csúfosat bukott, mert a kutya nem foglalkozott vele.

    Szóval, ha minden áron C++-os keresztplatformos fejlesztést akarsz, akkor a kül. feladatokra szintén keresztplatformos library-ket használj.

    Gafikára, hangra az SDL-t,
    UI-re pl. a Qt-t,
    stb.

    Minden másra használd fel az ANSI féle headereket. A kód legyen szintén ANSI/C++ kompatibilis. #IFDEF-ekkel válaszd szét a platformfüggő kódot. Ezt az egészet, ha így jársz el, bármelyik platform, bármelyik szerkesztőkörnyezetével elvégezheted, mindegy, hogy VS, hogy BCB, hogy Notepad+GNU C++. Ezeknek úgyis csak a natúr kódszerkesztő + fordító részét fogod használni.

    Szóval valahogy így. Egyszerű, mi? Nem véletlenül van létjogosultságuk az olyan fejlesztőkörnyezeteknek, mint a Java, vagy a .NET (Mono, ha x-platform)! Még mindig azt tudom javasolni, hogy keresztplatformos fejlesztésekhez nem feltétlenül a legszerencsésebb választás az ANSI C++ nyelv (lévén 20 éves a rendszer).

    De ez nem azt jelenti, hogy a feladat kivitelezhetetlen. Példaként a DOSBox projektet emelném ki. Feladata válogatja, hogy hogyan meg miben kéne nekiállni (nyílván nem lett volna szerencsés a DOSBox-ot Java-ban fejleszteni, mert tetűlassú lett vna az egész).

    A nagyvállalatoknak pedig megvannak az erőforrásaik ahhoz, hogy a fent említett keresztplatformos library-ket, házon belül, feladatspecifikusan kifejlesszék (neadjisten még az ehhez szükséges RAD környezetet is legyártsák) - ref.: Lightwave anno.
    Mutasd a teljes hozzászólást!
  • Elnézést ha néha nem fejezem ki elég világosan magam.A C++Builderrel kapcsolatban csak jó tapasztalataim vannak ezidáig.Mindig is Borland termékeket használtam,TurboC++,Builder különböző változatait.Igaz már nem egyszer megfordult a fejemben hogy átkéne szokni lassan Visual Studiora mivel rengeteg jó példaprogram iródott hozzá,builderhez meg alig találni segítséget.Csakhogy nekem a VCL sokkal jobban bejött mint az MFC.A 2006os Buildert még nem próbáltam.
    Kérdésem lényege az lenne,hogy vajon nagy vállalatoknál ahol keresztplatformos fejlesztést folytatnak,hogy is megy ez(pl. Adobe).Ha jól tom az Intelnek vannak ANSI-ISO fordítójai különböző paltformokra amelyeket az Adobe is használ.Egy ilyen compiler hogyan képes lefordítani egy BCB vagy egy VC projektet?Érzésem szerint sehogy. V a megfelelő könyvtárakkal lehetséges?
    Mutasd a teljes hozzászólást!
  • Ja az UML olyan, mint az olajbogyó. Vagy nagyon szereted, vagy nagyon utálod. Köztes állapot nincs. Pl.: A Borland ECO is erre épít.

    Én spec. az utóbbi kategóriába tartozom. Nekem egy osztály kusza forráskódja is többet mond első ránézésre, mint egy UML diagramm.
    Mutasd a teljes hozzászólást!
  • Nem állítom, hogy értem, mi a kérdés. Az ANSI C++ képességei maximum egy konzolos platformfüggetlen program megírásához elegendők.

    Ahhoz, hogy egy valóban platformfüggetlen programot írj C++ - ban, egy feladatfüggő library-t kell választanod. Olyat, aminek léteznek Linuxos/Windowsos/stb. átiratai. Mint például az SDL. Ez sem elég ahhoz, hogy a kód minden rendszeren fordítható legyen. Tele kell szúrkálnod a kódot egy rakás #IFDEF-fel, hogy ezt elérd.

    Alkalmazása válogatja, hogy hogyan álj neki a feladatnak. A C++ - t uszkve 20 évvel ezelőtt találták ki a C nyelv bővítményeként, mint az közismert. Akkoriban a hordozhatóság elérésére bőven elég volt az ANSI szabvány, hiszen szinte csak konzolos módban futottak a programok.

    Manapság megfontolandó inkább a Java-t használni platfromfüggetlen feladatokra.

    Windowsra ott a C++/CLR, vagy a C# 2.0, ha golyózik már a szemed a sok krix-kraxtól. A C++ Builder 2006 óta minden (ex)Borland hívő síkítozva menekül, ha meghallja a márkanevet. Az MS sem erőlteti tovább az MFC-t, mióta Steve Ballmer az atyaisten (végre egy olyan ember vezeti a céget, aki ért is a programozáshoz).

    Szóval nekem nem a C++ ugrik be, ha meghallom azt a szót, hogy platformfüggetlenség...
    Mutasd a teljes hozzászólást!
  • Üdv mindenkinek.
    c++ nyelvet ismerem elég behatóan, viszont gyakorlati szinten, konkrét programok kidolgozásánál nagyon kezdőnek érzem magam. A kérdésem az lenne, hogy hogyan is lenne érdemes fejleszteni?
    Elvileg a C++ szabvány kidolgozásakor nagyon okosan arra törekedtek,h a kód könnyen hordozható és portálható legyen más platformokra.Léteznek is nagyon jó compilerek windowsra, linuxra,solarisra...Tehát a portálás nagyon egyszerü ha a projekt követi az ANSI minden előírását,mivel h ANSI fordító minden platformra létezik.Manapság nemtom egy programozó életét elképzelni valamiféle fejlesztőkörnyezet nélkül mint pl. C++Builder,VisualC++.Azonban ezek eggyike sem generál ANSI kódot ami más compilerrel fordítható lenne.Komoly projekteknél mégis miben fejlesztenek,hogyan fordítanak? Az is érdekelne , hogy vajon az UML-t használják -e és hogyan.Tehát a tanácsokon kívül legfőképpen egy link érdekelne valamilyen példaprojekthez amiben láthatnám, hogyan is működik ez az egész a gyakorlatban.
    Előre is köszi a segítséget!
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd