Letölthető az új Rad Studio XE és Delphi XE
2010-08-31T22:08:27+02:00
2010-09-07T17:50:40+02:00
2022-07-02T08:20:27+02:00
  • Próbálta már valaki a PHP fejlesztést ezzel az IDE-vel?
    Nekem eddig a PHPDesigner vált be legjobban.

    Ahhoz képest ez milyen? (amennyiben érdemes lehet a kettőt összevetni) Érdemes váltani?
    Mutasd a teljes hozzászólást!
  • Nem lehet.
    Egészen biztos.

    A 64 bites valóban nem kajálja.
    Mutasd a teljes hozzászólást!
  • A 3D csak egy példa volt mint a C++ egyik tipikus alkalmazási területe.

    Tudom-tudom, itt prog.hu-n elfogadott tény, hogy csak AAA játékfejlesztésre alkalmas a c++. Minden másra .net és xna, no meg silverlight :) .

    Lehet ott sok minden mást is csinálni C++-ban. Én anno ügyviteli szoftvert is csináltam vele és wxWidgets-szel (akkor még wxWindowsnak hívták). Csak egyrészt sokkal több meló volt mintha teszem azt Delphiben csináltam volna, másrészt a C++ tényleg nem igazán erre való. A nyelv erősségeit egy ügyvitel során nem igazán tudod kihasználni, viszont RAD szempontjából akkoriban a Delphi, most meg a .NET van messze előtte.
    Mutasd a teljes hozzászólást!
  • Ahh, oké, de nekem nagyon rémlik valami miatt, hogy gyakorta kaptam olyan hibákat, hogy ez 16 bites alkalmazás és nem tudom futtatni. Nem lehet, hogy 32 bites wined van?
    Mutasd a teljes hozzászólást!
  • Megeszi a W7. Nekem Clipper '87 alatt írt program fut különösebb gond nélkül (igaz, nem teljes képernyőn), assembler-ben írt soros port kezeléssel .... bár ez utóbbinál valóban akad néha kisebb gondom .... de ez inkább hardware-függő, nem a W7 problémája.
    Mutasd a teljes hozzászólást!
  • Őszintén szólva a 3D soha nem vonzott. De azt tudom hogy a legtöbb 3D motor C++-ban készült (bár van Delphis is).


    Akkor miért írogatsz róla, ha ennyit tudsz? :) Mint mondom, a lényegi mondanivalóval egyetértek, csak a mellérakott szöveggel nem ;)

    LC csuriban van, eselyed sincs


    Tudom-tudom, itt prog.hu-n elfogadott tény, hogy csak AAA játékfejlesztésre alkalmas a c++. Minden másra .net és xna, no meg silverlight :) .
    Mutasd a teljes hozzászólást!
  • LC csuriban van, eselyed sincs
    Mutasd a teljes hozzászólást!
  • Látszik te is régen programoztál C++-t. Pl msvc alatt x64-en nincs inline assembly.

    C++-ban is régen dolgoztam, assemblyben meg még régebben.

    Menjé farigcsálj kis bitet, vagy előbb nézz utána a 3d-nek, mielőtt ilyenekt írogatsz :)

    Őszintén szólva a 3D soha nem vonzott. De azt tudom hogy a legtöbb 3D motor C++-ban készült (bár van Delphis is).
    Mutasd a teljes hozzászólást!
  • És ott már játszanak a pointerek, a bitműveletek (eltolás és társai), esetleg az in-line assembly.


    Látszik te is régen programoztál C++-t. Pl msvc alatt x64-en nincs inline assembly.

    Menjé farigcsálj kis bitet, vagy előbb nézz utána a 3d-nek, mielőtt ilyenekt írogatsz :) . (mielőtt félreérted, nem védem a pascalt, én tisztán c++-ban melózom, és 3d terén...)

    Ahh, jó ideig nem veszi át az arm az x86 helyét, ahhoz túl lassú és gyenge. PC mindig is lesz :) . Mert pl azzal dolgoznak az emberek...
    Mutasd a teljes hozzászólást!
  • Persze és a kódot is optimalizálja rá, mi?

    Megteheti hogy optimalizálja. Persze hogy egy gyártó mit tesz meg és mit nem az megint egy más kérdés. Lásd az Android amire ugyancsak bytekódban fejleszthetsz (igaz javás bytekódban) és csak most kapott JIT fordítót. Áradoznak is a userek a hatalmas sebességnövekedésről... Pedig azért az Android tipikusan nem erőműveken futkározik...

    Amúgy azt ugye tudod, hogy nagy valószínűséggel, az x64-re írt kódod 10 év múlva is futni fog a sima pc-ken?

    Már ha 10 év múlva még lesz sima PC. És ha Intel alapon fog futkározni és nem ARM procival. Ma a PC egyre inkább laptop, ott pedig az energiahatékonyság is fontos tényező. Egyre inkább fontosabb lesz mint az x86 kompatibilitás.

    A bitfaragást meg hagyjuk. Miért hiszi mindenki, hogy ilyen bonyolult a 3d meg a kamera?

    Nem bonyolult, csak sebességigényes. És ott már játszanak a pointerek, a bitműveletek (eltolás és társai), esetleg az in-line assembly. És 1000x inkább csinálok ilyesmit C++ alatt mint Object Pascalban. Csináltam már mind a kettőben bitfaragást, de ha tehetem akkor inkább C++-ban farigcsálok.
    Mutasd a teljes hozzászólást!
  • nem igazan erre termett
    márpedig te 1000x
    nem igazan valószínű

    Igazándiból az ilyen mondatok nemi gazán túl jó érvek, de ha sokszor felolvasom oket magamnak, akkor valojaban, mar egyre jobban meggyoznek.

    De még 1.00001x inkabb maradok annal a kornyezetnel, ami ismeros, még ha nem erre termett is.
    Mutasd a teljes hozzászólást!
  • A win7 asszem már nem eszi meg a 16 bites cuccokat. Talán már a vista sem.

    Amúgy csak mondtam, exhas egy számot :) . Valószínűleg jóval több mint gondoljuk :)
    Mutasd a teljes hozzászólást!
  • "az x64-re írt kódod 10 év múlva is futni"
    Erre eloszor csuklottam egy nagyot, de aztan basszus, miota is fut 16bit kod a pc-ken? vagy 20 éve lol
    Mutasd a teljes hozzászólást!
  • "Ami a program kifejlesztésekor esetleg még nem is létezik. Ezt natív kód esetén nem igazán tudod megtenni."

    Persze és a kódot is optimalizálja rá, mi? És sültgalambok repülnek a nyolcadik ker közepén. Tudjuk ám.

    Amúgy azt ugye tudod, hogy nagy valószínűséggel, az x64-re írt kódod 10 év múlva is futni fog a sima pc-ken? És ha jól tudom, ms nem igazán csinál más platformra fordítót. (ügyvitelt ugyanabban a formában meg nem fogsz mobilon futtatni)

    A bitfaragást meg hagyjuk. Miért hiszi mindenki, hogy ilyen bonyolult a 3d meg a kamera? Nemtom hány tízezer sornyi shader kódot írtam már, és eddig egyszer sem nyúlkáltam bitekhez, vagy olyat sem nagyon műveltem, amihez olyan komoly bitwise műveletek kellenének, amit anélkül nem lehet ugyanolyan gyorsan, egyszerűen megoldani. Sose :) (az más kérdés, hogy 32 bitre sem fordítok már...)
    Mutasd a teljes hozzászólást!
  • Amihez 3D, kamera, stb. kell azok általában erősen bitfaragós dolgok. Márpedig én legalábbis 1000x inkább C++-szal állnék neki a bitfaragásnak mint a nem igazán erre termett Pascallal.
    Az meg hogy mit csinál a processzor utoljára a 286-osomon érdekelt Turbo C++-ban. Ott is azért mert néha hajlamos volt hülyeséget generálni a C++ fordító. De egy .NET esetén ez nem igazán valószínű. A másik dolog viszont az, hogy ha bytecode van akkor a futtató gépen lévő procira fordul a programod. Ami a program kifejlesztésekor esetleg még nem is létezik. Ezt natív kód esetén nem igazán tudod megtenni.
    Mutasd a teljes hozzászólást!
  • Egy opengl32.dll-t csak csak meghajtok vele.
    Egy directshow-s kamerat is.
    Egy gpgpu-t is meg lehet vele fingatni.
    Ha akarom, a cpu is pontosan azt csinalja, amit mondok neki.
    Ebbol kovetkezik, hogy ha bármi bug van, azt csak magamra tudom kenni.
    Ez mondjuk nem ugyvitel hogy [igazán jól] vagy [nem igazan jol] mehessen, ezek alap építőkockák, amik vagy mukodnek vagy nem. Ezek C++ -ban is mennek (hogyne mennének). Ezek csak eszkozok, amik kellenek a reklam parasztvakitas és vidékéhez (kamera/akarmilyen hardver input, realtime video/hang output). Minden feladat elott elgondolkozok persze, hogy akarom-e ezeket az epitokockakat másféle módon is megtanulni hasznalni, de minek? (plusz betanulasi ido, kezdeti benazasok/(ujra)felfedezesek -> allando anyazasok, hogy miert vagyok ilyen lassu, na ez nem hianyzik )
    Mutasd a teljes hozzászólást!
  • Abban amiben a Delphi igazán jó (ügyvitel és vidéke) nem igazán van értelme natívkodni. Ahol meg van értelme (Pl. játék, driver, stb) ott úgy is C++-t használ az ember.
    Mutasd a teljes hozzászólást!
  • Ilyenek vannak a feature matrixban pl:
    Enhanced in XE! Main toolbar with the addition of Run without Debug option
    Azaz egy mar letezo menu actiont belevonszoltak egy toolbarba :D

    Ilyen marketing bullsh1t feature matrix mellett elobb fog kozlekedni a 4-es metro, mint jol(!!!) mukodni egy 64bites compiler.

    Sztem rossz irányba mennek azzal, hogy .net hiveket akarnak elszivni az MS-tol es ekozben a nativ részt meg teljesen hanyagolják (bocsanat, lett egy uj $codealign 16 direktiva, es kb ennyi). Ha én .net-ezni akarnék akkor 100%, hogy a .net kitalalojanak az eszkozet hasznalnam ahhoz. Ha meg nativkodni akarok, akkor ennek az XE valtozatnak meg nincs sok ertelme az elozo ket verziohoz kepest.

    bit_vector: Jó hírem van: A paralell világ kapuját már az elôzô évezredben megnyitotta a CreateThread api. :D ParalellFor-hoz meg hasznalhatsz anonym method-okat.
    Mutasd a teljes hozzászólást!
  • Ott a Delphi Prism Igaz az .NET, és akkor már lehet VS alatt C#-ban is dolgozni... Ráadásul abból van ingyenes verzió is...
    Mutasd a teljes hozzászólást!
  • Még mindig nincs? Azthittem már rég megoldották... Ez azért szörnyen kínos...
    Mutasd a teljes hozzászólást!
  • Azt legkorábban csak 1 év múlvára (2011 második felére) ígérik, a Pulsar kódnevű kiadásban.

    "I've already stated that our goal is to deliver 64bit Delphi sometime in 2011 and 64bit C++ in 2012."
    Mutasd a teljes hozzászólást!
  • kicsit vicces így 2010 derekán, de én hiányolom belőle az x64-es kódgenerálást... legalábbis a feature mátrix mélyen hallgat róla. 32 bit alá meg már lassan nem éri meg, sőőt... a jövő a parallel világ lesz, talán abba az irányba is lépni kellene valamit!
    Mutasd a teljes hozzászólást!
abcd