C# .NET vs MFC
2004-07-12T18:13:28+02:00
2005-04-11T11:09:48+02:00
2022-07-18T21:16:07+02:00
  • Sejtettem, de jó bizonyosságot is szerezni, köszi az infót. Azt nem tudjátok véletlenül, hogy ha letöltöm a mono-t, vajon a Microsoft ad hozzá egy Machintost is?

    Nem valószínű, mivel a mono a microsofttól teljesen független, ha van cég mögötte az inkább a Novell. Viszont ha a cuccost megírod linux alatt mono-ban x86-32 platformon az jó eséllyel futni fog x86-64-en (bár a M$ csak a .NET 2.0-nak csinál 64 bites verziót ha jól tudom, a mono 64 bites támogatását meg nem ismerem) vagy akár PowerPC/MacOSX pároson is.

    Ez így van, azonban én nem magáról a fejlesztésről beszéltem, hanem a .NET technológiáról... Szerintem annak a jövője nagyon bizonytalan. Alapjaiban (az eléképzelés) megmarad, de szerintem ebben a formában nem, lesz gyökeres változás...

    Szvsz a .NET jövője kb. annyira biztos mint a microsofté. Persze kisebb változások biztos lesznek benne, de túl nagyok azért szvsz nem: a M$ mindig is ügyelt arra hogy lehetőleg túl nagy kódbázist ne kelljen újraírni. És mivel a M$ - és jó pár más cég is - ezerrel mögötte áll, ráadásul magára a dologra elég nagy szükség van, így alig hiszem hogy a jövője túlzottan bizonytalan lenne.

    Mégiscsak üzlet nem? A Microsoft terjeszkedik, piacot szerez

    Minden üzlet. Ingyen ebéd nincs... Kérdés az hogy nekünk, programozóknak mit hoz (és visz) a dolog.

    Hidd el, hogy vannak, mégpedig nem is kevesen és nem 'Hello World'-öt írkálnak.

    Ezt erősen kétlem. Szvsz még maga a microsoft sem nagyon használja a win32-t közvetlenül, amit lehet MFC-ben csináltak a windowsban is. Persze lehet fölé tenni más OOP wrappert is, én Pl. a wxWidgets-t használtam, de a lényeg hogy a közvetlen win32 API programozáshoz igen nagy fokú mazohizmus szükséges. Már a legősibb C++-os windowsos progik is erre épÚltek, már a windows 3.1 környékén is, akkor az MFC mellett a borlandos OWL volt divatban (ami mára szerencsésen ki is puszult).

    Alapjábanvéve Win32API-ban a kezdet 'nehéz', vagyis mire megkódolod azokat a részeket, hogy egyáltalán láss valamit, magát a keretet. Utána nem könnyebb/nehezebb mint az MFC-ben való programozás...

    Tulajdonképpen ha megírod magadnak a saját MFC-det vagy wxWidgets-edet akkor utána már ugyanúgy haladhatsz vele mint ha ezeket használnád - csak szenvedhetsz a benne lévő esetleges bugoktól, plusz nem biztos hogy tudsz olyan színvonalú dolgot kiizzadni saját kútfőből mint a fent említett, jó pár ember jó pár éves munkájával előállított cuccok.
    Mutasd a teljes hozzászólást!
  • Érdekel a téma igy vettem a fáradságot és végigolvastam ezt a topic-ot, nos minden kiderült csak az nem hogy akkor melyik is? Szerintem mondjuk nem is lehet igazán választani, feladattól függ. Mondjuk ami a jövőjüket illeti, egyikről sem mernék mondani semmit, lehet hogy a .NET elhal de lehet hogy csak az lesz, nehéz megjósolni, nem is teszem.

    Nekem egyébként elsőre tetszett a C#, de végülis a programot mégsem abban irom, mivel egymás után ütköztem akadályokba, mint hogy pl. nem tudtam az MMX kódjaim beilleszteni, pointereket normálisan kezelni stb. Lehet hogy tévedek de ahogy mások is mondták, igazán gyors és alacsony szintű kódok előállításához (3D motor, tömörités, képfeldolgozó rutinok, driver-ek stb.) unmanaged C++ a megfelelő. Én is úgy vagyok, mint némelyek akik itt felszólaltak,vagyis szeretem tudni/látni mi is történik, bár lehet hogy ez hardware-s mivoltomból ered, és hogy sokat programozok RISC procikat ANSI C-ben, sőt gépi kódban ahol kell. Ott aztán azt is megmondom melyik nanosecundomban melyik regiszterben, melyik lábán a procinak stb. mi van.
    Mutasd a teljes hozzászólást!
  • Szia LC!

    Már most is megnézheted, legalábbis a mono fut powerpc-n. Azt mondjuk nem tudom hogy JIT van-e hozzá de úgy tudom hogy a fejlesztői verzióban már van.


    Sejtettem, de jó bizonyosságot is szerezni, köszi az infót. Azt nem tudjátok véletlenül, hogy ha letöltöm a mono-t, vajon a Microsoft ad hozzá egy Machintost is?

    Mindig a jövőről van szó, legalábbis ha új programot kell fejleszteni, és nem "Helló világ" szintű dologról van szó. Ugyanis a fejlesztésnek van időtartama, ahhoz hogy egy projected sikeres legyen nem árt ha legalább 5 évre előre látsz.


    Ez így van, azonban én nem magáról a fejlesztésről beszéltem, hanem a .NET technológiáról... Szerintem annak a jövője nagyon bizonytalan. Alapjaiban (az eléképzelés) megmarad, de szerintem ebben a formában nem, lesz gyökeres változás...

    A linuxos ".NET" a mono ingyenes és nyílt forráskódú. Mint ahogy amúgy a windowsos .NET is ingyenes.


    Mégiscsak üzlet nem? A Microsoft terjeszkedik, piacot szerez Linuxon, Mac-en, stb. Letöltöd a keretrendszert és megveszed a Microsoft kínálta termékeket, hiszen minden .NET-es program fut az adott OS-en, már ha van hozzá keretrendszer. Ők nem a hordozhatósággal foglalkoznak, mint ahogy valójában senki sem, hanem a piaccal és a haszonnal. A hordozhatóság csak azért kell, hogy dőljön a lé.

    Nem igen hiszem hogy lenne olyan őrült aki a windowst közvetlenül win32-ben programozná (szintén a helló világnál nagyobb progiknál).


    Hidd el, hogy vannak, mégpedig nem is kevesen és nem 'Hello World'-öt írkálnak. Alapjábanvéve Win32API-ban a kezdet 'nehéz', vagyis mire megkódolod azokat a részeket, hogy egyáltalán láss valamit, magát a keretet. Utána nem könnyebb/nehezebb mint az MFC-ben való programozás...Mindkettő macerás, ha RAD-ot akarsz, tény.

    Annyira azért nem jó a win32 API hogy felhagyjak a programozással ha nem lesz elérhető


    Persze, sarkítottam én is, de én ellene vagyok annak, hogy mindent készen kapunk és nincs beleszólásunk az alapokba, mi hogyan és miért működjön úgy, ahogyan azt teszi. Kell a RAD, hogyne kellene. De egyelőre nem látom a Win32API alternatíváját Longhornon. Ha valaki erről tud valamit, szívesen venném az infót, hogy nyugodtan tudjak aludni. ;)

    Üdv!
    Mutasd a teljes hozzászólást!
  • Most akadtam bele, bár gondolom ismered, de inkább 2x halld mint egyszer se:)

    The Unofficial VisualCLX patch 3.8 is now released.
    Codecomments.com
    Mutasd a teljes hozzászólást!
  • Megnéznék egy .NET-es programot hogyan is fut (majd) egy PowerPC-n.

    Már most is megnézheted, legalábbis a mono fut powerpc-n. Azt mondjuk nem tudom hogy JIT van-e hozzá de úgy tudom hogy a fejlesztői verzióban már van.

    Nem a jövőről van szó ugyanis, mert azt tudtommal senki sem látja, hanem a Microsoft kampányáról amit a .NET-el a piacszerzés miatt végeznek.

    Mindig a jövőről van szó, legalábbis ha új programot kell fejleszteni, és nem "Helló világ" szintű dologról van szó. Ugyanis a fejlesztésnek van időtartama, ahhoz hogy egy projected sikeres legyen nem árt ha legalább 5 évre előre látsz. Ha nem sikerül akkor megszívhatod... Én Pl. pont ezt csináltam a Kylixos fejlesztésemmel...

    Tudtommal már van Linuxon is. Na és ez üzlet.

    A linuxos ".NET" a mono ingyenes és nyílt forráskódú. Mint ahogy amúgy a windowsos .NET is ingyenes.

    Mindeközben azonban arról nincsen szó, hogy milyen alacsonyabb szintű programozási lehetőséget kívánnak nyújtani az új Longhornban (itt a Win32API közvetlen programozására gondolok).

    Nem igen hiszem hogy lenne olyan őrült aki a windowst közvetlenül win32-ben programozná (szintén a helló világnál nagyobb progiknál). Legalább MFC vagy hasonló OOP wrapper lib kell fölé.

    Nyomatják a managed témát, de -felhozva egy előttem szóló példáját- 'hogyan fejlesszünk játékot C#-al, .NET-hez' című könyvet még nem láttam. Remélem nem is fogok, mert akkor abbahagyom a programozást és visszatérek Commodore-ra!


    Annyira azért nem jó a win32 API hogy felhagyjak a programozással ha nem lesz elérhető. Sőt, ami azt illeti most sem használom, jelenleg is CLX alatt fejlesztek (és ha a Borland nem állítja le a Kylix fejlesztését, plusz ha rendes munkát végeznek és nincs tele hibával akkor most is nagyon boldog lennék vele).
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Nem vagyok benne biztos hogy a managed programok hosszabb távon lassabbak lesznek mint egy unmanaged C++. Ez tisztára attól függ hogy a JIT fordító mennyire hatékony, ez pedig főleg attól hogy mennyi pénzed van JIT fordítót csinálni az egyes procikra.


    Hosszú távon természetesen minden lehetséges és nem csak arról van szó, hogy mennyi pénz lesz JIT-et fejleszteni, hanem hogy az egyes procigyártók mennyire veszik figyelembe ezt az új módszert. Rá lehet ugyanis 'segíteni'. Megnéznék egy .NET-es programot hogyan is fut (majd) egy PowerPC-n. Bár a PowerPC-ket elég nehéz összehasonlítani az Intel-el és az AMD-vel...No mindegy. Nem a jövőről van szó ugyanis, mert azt tudtommal senki sem látja, hanem a Microsoft kampányáról amit a .NET-el a piacszerzés miatt végeznek. A .NET es dolgok futtathatóak lesznek elvileg az összes OS-en, amint kijön hozzájuk a keretrendszer. Tudtommal már van Linuxon is. Na és ez üzlet. Mindeközben azonban arról nincsen szó, hogy milyen alacsonyabb szintű programozási lehetőséget kívánnak nyújtani az új Longhornban (itt a Win32API közvetlen programozására gondolok). Legalábbis én nem tudok róla. Nyomatják a managed témát, de -felhozva egy előttem szóló példáját- 'hogyan fejlesszünk játékot C#-al, .NET-hez' című könyvet még nem láttam. Remélem nem is fogok, mert akkor abbahagyom a programozást és visszatérek Commodore-ra!

    Lényeg a lényeg, amit kimondtunk már ezerszer:sem a Win32API, sem az MFC nem halott!

    Yeah és üdv!
    Mutasd a teljes hozzászólást!
  • Thirdly, one of the indisputable advantages of Windows XP Professional x64 Edition is the ability of this system to work not only with the 64-bit applications, but also with the traditional 32-bit applications without any functionality limitations or performance drops. This is possible due to a special x86 Windows on Windows 64 (WOW64) emulator built into the OS. (Windows XP Professional x64 Edition Preview: AMD64 and Intel Extended Memory 64 Technology. Page 2 -)

    Hát ezért gondoltam hogy a Win32-nek hamarosan befellegzik...
    Mutasd a teljes hozzászólást!
  • Na ja, de ugysem uszom meg, egyszer majd bejon az nagy longhorn... amikor otthoni userek kulvilagi kapcsolatai a messenger 999999. variaciojaval lesznek csak hajlandok majd kommunikalni, az meg majd csak longhornon lesz... brrr userek es programok brrr
    Mutasd a teljes hozzászólást!
  • Ha csak netezel akkor az is elég, ahhoz viszont nem kell Longhorn, elég egy linux egy Mozillával.
    Mutasd a teljes hozzászólást!
  • Tizenenezer Ft videokartyaert???
    Abbol mar komplett gepem van :))))))))
    Sosem eri meg beruhazni pc-be, kiveve ha dolgozol rajta, vagy gamer vagy...
    Ezert nincs mas otthon csak pII-333.
    5 rongy volt alaplap + proci, melle raktam az sdramot/kartyakat a megdoglott p1-166-ombol, aztan megy. Minek mas?
    Mutasd a teljes hozzászólást!
  • Bar hw szinten ugysem vagyok eleg jo hozza, hogy Longhornom legyen. Meg sosem volt pld 3D videokartyam, mert minek?


    Azért hogy a Longhorn futhasson a gépeden . Amúgy ma egész jó kis 3D gyorsított videókártyákat lehet venni tizenezer forintért, szvsz lassan olyan ami nem 3D gyorsított nem is igen kapható.

    A régi progik pedig szvsz idővel csak emulátorban fognak futkározni, bár szvsz a longhorn még valószínűleg biztosítani fog valamiféle natív futtatási módot is.

    Amúgy lehet hogy pont ezért vette meg az M$ a VirtualPC-t anno.
    Mutasd a teljes hozzászólást!
  • Win32 api jo is, meg rossz is. Jo, mert aranylag alacsony szinten el lehet erni a dolgokat, nem csak oop-vel, meg vizualis krix-krax-al (persze melozni gyorsabb ilyesmivel, alairom), rossz, mert olyan, amilyen.
    Managed kod ide, .Net oda, biztonsagi alrendszer meg amoda, C-ben/asm-ben irt programot lehet forditani/futtatni Longhornon? Mi varhato a jovoben?
    Ha ilyesmik nem fognak mukodni, ms vesztett egy leendo klienst szemelyemben. Elvegre akkor regi programok sem mennenek rajta....
    Bar hw szinten ugysem vagyok eleg jo hozza, hogy Longhornom legyen. Meg sosem volt pld 3D videokartyam, mert minek?
    Mutasd a teljes hozzászólást!
  • Nem csoda, hogy erőmű kell majd hozzá, ha valaki mindent ki akar hozni belőle..

    Nem vagyok benne biztos hogy a managed programok hosszabb távon lassabbak lesznek mint egy unmanaged C++. Ez tisztára attól függ hogy a JIT fordító mennyire hatékony, ez pedig főleg attól hogy mennyi pénzed van JIT fordítót csinálni az egyes procikra. Márpedig azt hiszem hogy ez a M$ esetében nem gond. És szvsz egy i586-ra fordított kód bizony idővel lassabb lehet egy modernebb procin mint egy managed amit a JIT az adott, esetleg Intel P4 vagy az AMD egy adott modelljére optimalizál.
    Mutasd a teljes hozzászólást!
  • Ha annyira rossz lenne a WinAPI, akkor nem epulne ra minden!


    Pedig tényleg veszettül rossz. Viszont mivel a windows a legelterjedtebb oprendszer és annak a win32 az API-ja, így aztán a win32 a legelterjedtebb API. De maga a cucc kb. a 80-as évek elejének a technológiája, anno volt a MacOS, erre finoman szólva kissé hasonlított a 16 bites windows API (ami amúgy szvsz inkább 8 bites volt, lásd 64KB-os szegmensek). És ennek továbbfejlesztése volt a win32. Közben nőtt mint a rétestészta, de az eredeti problémáját, tudniillik hogy abszolút nem OOP nem igazán tudta levetkőzni.

    Az MFC-ről nem tudok érdemben nyilatkozni, ahhoz túl keveset használtam, amit próbálkoztam vele és a Visual C++-6-tal az alapján nem nagyon kezdenék vele nagyobb projectet: egy mezei tabbed notebook-os ablak összehozása is jókora meló volt mondjuk egy Delphihez de akár a wxWidgetshez képest is, persze lehet hogy csak én voltam lamer. Én mindenesetre ha C++-ról van szó akkor inkább maradok a wxWidgets-nél, azt legalább ismerem, ráadásul free és multiplatform is.

    Viszont van olyan gyanúm hogy idővel a nem .NET-es programok "csúf kiskacsák" lesznek az újabb windowsokon, legalábbis ha a biztonsági rendszer a .NET-ére fog épülni akkor szvsz a nem managed programoknak nem nagyon fog örülni a rendszer.
    Mutasd a teljes hozzászólást!
  • Mindenki csak azert ajanlja neked a C#-ot, hogy legyen sikerelmenyed.
    Nemcsak azért, mint lejjebb írod: Csak hogy a termelekenyebbek legyenek az emberek. Minél kevesebbett kell tökölni (feleslegesen) az API-val, annál több idő marad a kódra. Persze ennek ára az univerzalitás elvesztése.

    A HalfLife 2 motorjat nevezetesen a Source Engine-t nem Visual Studio 6-al keszitettek volna, ha annyira no future a Win32 API.
    azért egy HL2-nél nem igazán szempont hogy 5 év múlva is tovább lehessen fejleszteni, mikor 1 év alatt lejárt játéknak számít, a következő HL meg úgyis tök más motort fog használni. Ez pont rossz példa volt. Ma még erre jobb a Win32, de majd ha már tele kell pakolni mondjuk a HL5-öt WinFX-es effektekkel, akkor valszeg nem abban fogják írni.

    Ha eleve igy indulsz neki, hogy ne legyen 2 ev kidobas, akkor szerintem mar most felejsd el a programozast!
    Ez az életben nem így működik. Nincs unlimited időm, se tanulni, se később fejleszteni. Ennyi erővel lehetne Quick Basicet is tanulni, mert az se fog megártani, de minek?

    Ez hala istennek egy olyan szakma, hogy orok eletedben kell tanulni.
    De nem mindegy hogy értelmesen vagy feleslegesen. Egyébként nem vagyok totál kezdő, ismerem a C-t, C++-t, CBuilderben is programoztam kicsit, de most az a célom hogy valamelyikbe jobban belemélyedjek, lehetőleg olyanba, ami hosszabb távon is megtérülő "befektetés", nem csak hobbi magamnak. Szempont az is hogy ezt a tudást kamatoztatni tudjam a való (üzleti) életben. Nemcsak most, hanem később is.
    Mutasd a teljes hozzászólást!
  • Ha annyira rossz lenne a WinAPI, akkor nem epulne ra minden! Legyen az maga az oprendszer, (a 3.1-tol a 2K3-ig, amugy ugyan az lesz a Longhorn is csak ugye megy a vakitas), vagy a kulonbozo keretrendszerek,(MFC, .NET, itt egy kis obejktum orientaltsagot beleraktak, ami neha jo, neha rossz)

    Mindenki jatekokkal mint peldakkal dobalozik, ezert tessek:
    A HalfLife 2 motorjat nevezetesen a Source Engine-t nem Visual Studio 6-al keszitettek volna, ha annyira no future a Win32 API. Ott meg sehol nincs .NET. Sima egyszeru Win32. De barmelyik hiresebb jatekot megnezheted.

    Ha lattal mar MS fejlesztoi kornyezetet, azonnal rajonnel, hogy ott is az egesz Win32 es Visual C++ al lett megcsinalva. Es azonnal tudnad, hogy az egesz koceraj arra epul. Az hogy hozzafoltoztak egy magasabb szintu fuggveny konyvtarat, legyen MFC, .NET ugyan az a dolog. Csak hogy a termelekenyebbek legyenek az emberek.

    Mindenki csak azert ajanlja neked a C#-ot, hogy legyen sikerelmenyed.

    Ha eleve igy indulsz neki, hogy ne legyen 2 ev kidobas, akkor szerintem mar most felejsd el a programozast!
    Ez hala istennek egy olyan szakma, hogy orok eletedben kell tanulni. Ma C#, holnap rajossz hogy megiscsak C++, utana rajossz hogy nem mindig olyan fasza dolog az objektum orientaltsag, akkor ugye mar csak pure C-ben nyomulsz, aztan teszem azt csodbe megy a ceg ahol voltal, hogy elhelyezkedj a VB.NET et kell megtanulnod, szoval ilyen ez a pop szakma.
    Mutasd a teljes hozzászólást!
  • nem vitatkozni vagyok itt, de lehet te sem így értetted.
    Hát nem is. De kiváncsi vagyok mások érveire, álláspontjára, végülis azért jár az ember fórumozni. Én leírtam nekem mi a véleményem és várom rá másokét. Jön mondjuk 10 válasz, abból 8 ilyen, 2 olyan, abbál lehet következtetést levonni.

    azonban továbbra is elég alacsony szinten mozgunk ahhoz, hogy természetesnek érezzük az 'API-s' gondolkodást.
    Ezért érdekel(t) engem is, csak a jövőre nézve a kilátásokat nem látom túl kedvezőnek.

    maga az API is managed lesz a Longhornban. Nem csoda, hogy erőmű kell majd hozzá, ha valaki mindent ki akar hozni belőle
    Hát igen, de ha nem lesz más... Persze marad a Win32 is, de az új funkciók nem biztos hogy (maradéktalanul) belekerülnek ebbe is, ha meg már van olyan, elobb-utóbb elvárás lesz a használata, főleg a megrendelők részérol. ("Miért nem tud ez olyat mint az x program?")

    a .NET sem fog ebben a formában megmaradni, arra is mérget lehet venni (jóllehet a C# talán nem fog sokat változni).
    Hogy mi és mennyit változik rajta azt nemtom, de hogy a jelenlegi állás szerint a 28-as verziójú .NET-hez is a C# fog "passzolni", az elég valószínű, tehát érdemes ezt ismerni, az új verziónak is ez lesz a nyelve (végülis nem azért nyomják ennyire hogy aztán kidobják és visszatáncoljanak), a többit majd csak hozzágányolják (pl. managed C++).

    tényleg sokszor találkoztam olyan véleménnyel, hogy az MFC ócska, meg Win32 ócska
    Nem ócska, csak kicsit olyan "no future". :)
    Mutasd a teljes hozzászólást!
  • Kedves Ishniggarab!

    Kezdem azzal, hogy nem akarok sem cáfolni, sem bizonyítani; nem vitatkozni vagyok itt, de lehet te sem így értetted.

    [MFC]
    hogy nem fejlesztik tovább (tudomásom szerint).


    Hmm. Valóban kicsit nehéz infóhoz jutni, hacsak nincs valami fejes ismerős Microsoftéknál. A legfrisebb dolog amit olvastam a Visual Studios 2005 FAQ-jában, hogy bővitík az MFC-t, hogy el lehessen vele érni a .NET platformot is. Az MFC-t azonban önmagában szerintem nem is nagyon kell fejleszteni, mégpedig azért nem (ismét csak magánvélemény), mert elég közel van a WinAPI-hoz, tulajdonképpen talán ezért is lehet a legjobban szidni; nem sok mindent kapunk a 'sima' API-hoz képest. Nekem egy időben volt dolgom Delphivel is (Object Pascal), jóllehet az is megfér a WinAPI-val (itt a hívásokra és az Object Pascal valamint a WinAPI összeférhetőségére gondolok, nem pedig arra, hogy a Delphi is WinAPI-t hívogat!), azonban nem olyan természetesen mint az MFC. Szóval elég sok mindent kapunk a plain API-hoz képest, azonban továbbra is elég alacsony szinten mozgunk ahhoz, hogy természetesnek érezzük az 'API-s' gondolkodást. Ha értitek mire gondolok...

    A C++ és a .NET viszonyáról vmi olyat olvastam hogy ott a C++ is vmi managed cuccos lesz, így meg semmit nem nyerek vele a C#-hoz képest.


    Én is hasonlót olvastam, jóllehet azzal kapcsolatban, hogy maga az API is managed lesz a Longhornban. Nem csoda, hogy erőmű kell majd hozzá, ha valaki mindent ki akar hozni belőle..

    A Win32-vel meg csak 1 a bajom: jön a 64 bit, aztán ez is múltidő. Nem értékálló befektetés belemélyedni, ugyanannyi energiával tanulhatok olyat is ami évek múlva is használható.


    A Win32 függvénygyűjtemény, ami C-ben van megírva, 32 bites processzorra fordítva. Nem látom a nehézséget abban, hogy előkotorják a forrást, kicsit felpofozzák, és 64 bitre fordítsák. Az elnevezés kicsit megtévesztő talán..
    Nem lehet a WinAPI-hoz képest merőben új dolgot alkotni, még a függvényneveket sem igazán lehet megváltoztatni, mert minden annyira passzol. Nem azt mondom, hogy tökéletes, de térdreborulok a mérnökök előtt, akik megcsinálták.
    Komolyan, le a kalappal szvsz :)

    Mégis:a WinAPI egyetlen 'hibája' az, hogy önmagában nem objektum orientált. Aki WinAPI-ban programozik, az magát az API-t csak nehezen tudja OOP-be erőltetni. Ezen segített az MFC. Azt már logikus lépésnek tartanám, ha magát az API-t írják át úgy, hogy alapból támogassa az OOP-t.

    Teljesen egyetértek veled abban, hogy akkor lesz majd teljesen tiszta a kép, ha kiderül mi is lesz. ;) Mármint, hogy mi bizonyul életképesnek a Longhorn által felvonultatott színes kavalkádból. Nekem megalomán rémálom az egész, de majd meglátjuk. De én épp ezért nem döntöttem úgy, hogy .NET. Win32 még lesz sokáig, szerintem nem fölösleges foglalkozni vele és a .NET sem fog ebben a formában megmaradni, arra is mérget lehet venni (Jóllehet a C# talán nem fog sokat változni).
    Én nem téríteni akarok, vagy elbizonytalanítani, csak tényleg sokszor találkoztam olyan véleménnyel, hogy az MFC ócska, meg Win32 ócska.. Szerintem ez butaság.. Én sem mondtam, hogy rossz a .NET. Az én gépem kicsi hozzá, nincs elég memóriám (egy 'sima' form 7 mega körül van, 30 dll-t tölt be, azokat beleszámítva), hogy minden .NET-be menjen esetleg.. :)

    Jó .NET-ezést mindenkinek!
    Mutasd a teljes hozzászólást!
  • Az MFC nem szűnik meg, ezt olvashatjátok a Microsoft oldalán is. Egyáltalán nincs tervbe véve, hogy hanyagolják, sőt lesznek új osztályok, melyekkel elérhető lesz a .NET platform is. Just for you ;)
    Hát ez se kisebb gányolás mint szerinted a C#. :)

    A Win32-t az életben nem mossa le magáról a Microsoft, ami szerintem nem baj, mert én nem nagyon érzem azt, hogy kiöregedett lenne.
    Mostmég. De lehet hogy 64 biten sokkal hatékonyabb ugyanaz, és váltanak arra.

    Ebből kifolyólag valóban mi lesz a low-level dolgokkal? Azt is .NET-be fogják írni?
    Hát a WinFX-ből kiindulva...

    A Longhronnal pedig szerintem igen be fognak faragni, az ő dolguk.
    Miért? Eddig is fekália volt az összes oprencerük a win2k előtt, mégis mindenki azt használta.
    Mutasd a teljes hozzászólást!
  • Nem mondtuk hogy megszűnik, csak azt hogy nem fejlesztik tovább (tudomásom szerint). Azaz jelenleg jó mindenre, de később egyre inkább nem, úgy jár mint a dosos cuccok.

    A C++ és a .NET viszonyáról vmi olyat olvastam hogy ott a C++ is vmi managed cuccos lesz, így meg semmit nem nyerek vele a C#-hoz képest.

    A Win32-vel meg csak 1 a bajom: jön a 64 bit, aztán ez is múltidő. Nem értékálló befektetés belemélyedni, ugyanannyi energiával tanulhatok olyat is ami évek múlva is használható.

    Azért döntöttem a C# mellett, mert bár távpéról se vetexik az asm hatékonyságával, de a jövője a MS által biztosítva van (ennél jobban semmit nem nyomnak most), így tuti hogy ehhez lesz 64 bites támogatás, WinFX is, ami a jövőre nézve fontos szempont. Sztem akkor lesz értelme vmi rendszerközelibbet tanulni, amikor a Longhorn után letisztul a kép hogy mi is valósul meg. Lesz-e a Win32 helyett "Win64", lesz-e egyáltalán a managed kódon kívül más is támogatva (ugye a WinFX is az lesz), vagy teljesen ezirányba nyomul minden. És a támogatáson nem azt értem hogy kompatibilitás miatt megmarad-e mint választható lehetőség, hanem hogy fejlesztik-e, meglesz-e hozzá minden újdonság ami a többihez igen.

    Ha nincs igazam, cáfolj +.
    Mutasd a teljes hozzászólást!
  • Szia Ego!

    Ezzel tudnek vitatkozni (no nem a mernokokrol, hanem a nyelvrol). A C# nagyon jol kitalalt nyelv. 1-2 dolog hianyzik belole, de ami benne van es ahogy benne van, az szerintem nagyon jo.


    Hmm. Érdekes, mert ezzel én ugyan oda kanyarodnék vissza, ahonnan minden elindult; milyen célre melyik a legideálisabb nyelv... Átfutottam(!, tehát jogos a vád) egy könyvet a C#-al kapcsolatban, nekem igazából elég C++-osnak tűnt (vagy akkor legyne Delphis?),de mindjárt az elején fennakadtam az inline deklarációnál. Lehet, hogy én értettem félre a dolgot, de mintha a C#-ban az inline deklarációt szorgalmaznák, vagy egyenesen az a kötelező??
    Másodrészt -és ebben is igazad lehet, hogy hiányos ismereteim miatt jutottam erre a következtetésre- nem igazán értettem miért továbbgondolt C++ (ezt azért mondhatom rá szintaxis alapján?).. Nem vitatkozni akarok, mert annak úgysincs értelme, már mondtam, hogy minden jó valamire, mindössze azt nem látom be, hogy ezt a lépést miért kell ennyire "nyomatni"...
    Belátom, hogy ezt a nyelvet a .NET-re írták, vagyis egy elsősorban komponens alapú programozást hivatott elősegíteni.

    Nem tom mit ertesz low-level alatt, de termeszetesen a c# nem univerzalis programozasi nyelv, a .Net meg nem univerzalis programozasi platform.


    Szerintem nagyon fontos dolgot mondtál ki! Én kicsit skizofrén állapotban leledzem, ugyanis a Microsoft annyira nyomatja .NET-et (amit ugye kín lenne C++-ból programozni), hogy olyan érzésem van, valami iszonyat fontosból maradok ki és semmi másnak nincs létjogosultsága. Holott ez tényleg nem így van, de ez a fránya marketing rám ilyen hatást tesz.

    MFC? Nem tudsz véletlenül egy online cikket mutatni, amiben szidják? ;) Kíváncsi lennék rá, de tényleg! Lehet mindent szidni és dícsérni, ezt is. Nekem bejön az MFC...

    Üdv!
    Mutasd a teljes hozzászólást!
  • No fene.
    Ez nem lesz rossz.
    Egyik oldalrol. A masik, hogy ezzel hatalmas dofes lesz a tobbi platformra.
    :/
    Mutasd a teljes hozzászólást!
  • XNA

    hogy ebbol mi kerul egy frisen telepitett op.rendszere az meg a jovo zeneje
    Mutasd a teljes hozzászólást!
  • Es ezzel tenyleg ott a gaz, amikor jon egy ujabb verzio.


    Nem igazán - ha M$ elég jó interface specifikációt ad és utána azt nem nagyon bolygatja.

    Meg ugye ehhez valahogy be kene "epulni" oprendszer szinten. Abba meg az MS nem menne bele.

    Már miért ne menne ? A driverek ennél sokkal mélyebben kavarnak a rendszerben, ehhez kb. hasonló mélységű hozzáférés is elég lenne mint amit Pl. egy video codecnek van. Legalábbis szvsz.

    Es ez miert lenne erdéke egy jatek gyartonak?

    Ez nem a játék gyártóknak hanem a M$ érdeke lenne. Viszont szvsz annak annyira az hogy akár egy ilyen motor és az azt körülvevő infrastruktúra kifejlesztése is megérné nekik. Csodálom hogy ez idáig még nem jutott az eszükbe... Bár ki tudja mit hoz a Longhorn...
    Mutasd a teljes hozzászólást!
  • Igazabol nem lenne hulye otlet ez a pluginosdi, de ehhez a kulonbozo szoftver gyartoknak kene meg ezzel is foglalkozni. Es ezzel tenyleg ott a gaz, amikor jon egy ujabb verzio. Meg ugye ehhez valahogy be kene "epulni" oprendszer szinten. Abba meg az MS nem menne bele. (Jogosan)

    "ugyanakkor az így kifejlesztett játékot igen nehéz lenne áthozni linux alá a wine segítségével, vagy épp PS2 vagy más konzolra. "
    Es ez miert lenne erdéke egy jatek gyartonak?
    Mutasd a teljes hozzászólást!
  • A .NET platform valóban inkább internet alá készült platform


    Ebben igazad van, de azert a win kliens oldali programozast is rendesen megcsinaltak alatta szerintem.

    a C# nyelv sem a legkiválóbb mérnökök agyszüleménye


    Ezzel tudnek vitatkozni (no nem a mernokokrol, hanem a nyelvrol). A C# nagyon jol kitalalt nyelv. 1-2 dolog hianyzik belole, de ami benne van es ahogy benne van, az szerintem nagyon jo.

    Butított C++, de annak tök jó


    Ebbol szamomra az jon le hogy valamelyiket nem ismered elegge (gondolom a C# -ot). Ugyanis igen tavol all a c++ -tol ahoz hogy azzal hasonlitsd ossze. A c++ a nyelvek kiralynoje, de azert nem kell minden nyelvet vele osszehasonlitani, amiben van for,if,while meg kapcsoszarojel.

    Ebből kifolyólag valóban mi lesz a low-level dolgokkal? Azt is .NET-be fogják írni?


    Nem tom mit ertesz low-level alatt, de termeszetesen a c# nem univerzalis programozasi nyelv, a .Net meg nem univerzalis programozasi platform. Nem celja kiirtani a winapit. Az MFC mas teszta. Nem ismerem elegge ahoz hogy kritizaljam, de nekem sose volt szimpatikus es rengeteg negativ kritikat olvastam rola. Az altalanos kozvelekedes az altalam olvasott cikkekben is az volt, hogy az MFC gany.
    Mutasd a teljes hozzászólást!
  • Mondom az MI kivételével. A 3D formátumok meg mehetnének pluginként. Egyébként nem állítom hogy ez a jövő útja, pláne azt nem hogy ez kívánatos lenne, viszont a M$ eddigi lépéseit figyelve nem lenne logikátlan lépés a M$ részéről. Már csak azért sem mert így a windows + az X-Box játékplatforomot igencsak bebetonozná, mivel ha erre van ilyen beépített 3D motor, akkor olcsóbb a fejlesztés, ugyanakkor az így kifejlesztett játékot igen nehéz lenne áthozni linux alá a wine segítségével, vagy épp PS2 vagy más konzolra.

    Sőt, hogy még durvább legyek: az M$ helyében én létrehoznék egy kis ingyenes 3D szerkesztőt is (meg egy nagyobb nem ingyeneset) és odaadnám a .NET illetve a Visual Studió prof mellé. Így a kezdő játékfejlesztő emberkék egyből a windowsra kattannának. A 3D motorjuk pedig elsősorban ezt támogatná... Szóval a Nagy Testvér lehetőségei korlátlanok, max. a fantáziájuk hagy némi kívánnivalót maga után - szerencsére.
    Mutasd a teljes hozzászólást!
  • Hat erre inkabb nem reagalok.

    Csak egy kicsit:
    Melyik lenne akkor az az objektum forma, ami eletben maradhatna? 3D Max,Lightwave,Blender,Maya? Akkor a jovoben nem is kene ezeket fejleszteni?

    Milyen MI-t drotozzanak be? Fuzzyt,neuron alaput,pathfindingot?netan kepfelimerest?

    Ugye ez csak vicc.
    Mutasd a teljes hozzászólást!
  • De igen, valami hasonlóra meg ami ezekkel együtt jár, Pl. objektumok összetett mozgatása csontváz alapján, stb. Azaz minden ami egy FPS-ben benne van a játékosok és a szörnyek MI-je, drótváza és skinjei kivételével . Ennek igazán egy nagy előnye lenne technológiailag: ezeknek a dolgoknak egy része is lekerülhetne a 3D kártyák drivereinek szintjére - azaz ezekből is gyorsíthatna a kártya ezt-azt hardveresen.

    Persze lehet hogy hülyeségeket beszélek, a 3D nem igazán az én világom, de az alapján ami keveset tudok róla ez elég logikus lépés lenne a D3D után.
    Mutasd a teljes hozzászólást!
  • "alacsonyabb szintű dolgokat (Pl. 3d motor) elve belerakják a windows API-ba."
    Ezt ugye nem gondolod komolyan.
    Tudod amugy mik vannak egy ilyen motorban? Nem csak sprite vagy objectum kirakas.
    Vagy akkor nezzuk visszafele!
    Mit lehetne belerakni egy windows rendszerbe, amit lehetne hivogatni a managed kodbol? Hogy rakjon ki ezt es ezt az objektumot, ami ilyen es ilyen formatumban van, erre a poziciora, vagy itt vannak az objektumaim, nezd meg, hogy van-e utkozes, ugye nem ilyenre gondoltal?
    Mutasd a teljes hozzászólást!
abcd