Delphi VS C++

Delphi VS C++
2002-10-28T22:01:19+01:00
2002-11-19T15:05:21+01:00
2022-11-02T09:35:34+01:00
  • Én anno a Posta Számítástechnikai és Szervezési Intézetben kezdtem a 80-as évek végén és a C nyelvet az ottani TPA1140-es gépen tanultam meg. A többi "nagy gépen" (ESZR R36, Honewell DPS-8 tényleg csak COBOL volt és PL/1). Amúgy a nagyság múlandó: a múltkor kezembe akadt egy belső kiadvány ami valahogy megmaradt abból az időkből és ahol a cég gépidő eladást hirdetett. Föl voltak sorolva a gép tulajdonságai, Pl. memória : 4 MB !!!! És dolgoztunk rajta vagy huszan + rajta ment az ország akkori telefonhálózatának számlázása. Olyat meg hogy fagyi nem is hallottunk, legalábbis Honeywell-en nem. Az ESZR/MSZR gépek persze más lapra tartoztak
    Mutasd a teljes hozzászólást!
  • (szemben mondjuk a C-vel ahol legalább háromféle elemi módon tudom növelni egy változó értékét eljáráshívás nélkül is, vagy ahol egy "*" operátor bármit jelenthet, és nem tudom meg mit csinál amíg át nem néztem az _egész_ programot)


    Ez benne van a pascalban is, csak rejtve. Lásd Inc/Dec utasítást a ++ és --, +=, -=, helyett. Amúgy én pont ezeket a kényelmi dolgokat hiányolom a pascalból. Meg a feltétel ? egyik érték:másik érték szerkezetet.
    Ezek ráadásul a gyakorlott c-s számára még áttekinthetőbbé is teszik a programot. Pl egy objektum.masikobjektum.harmadikobjektum.elem = objektum.masikobjektum.harmadikobjektum.elem + 12 helyett elegánsabb az objektum.masikobjektum.harmadikobjektum.elem+=12 és szerintem sokkal olvashatóbb is. Ugyanez a helyzet az i++-szal az Inc(i) helyett.
    A C nyelven látszik hogy programozók csinálták programozóknak...

    Mindenesetre a C while-ja szerintem pont a rossz példa, mert azért az svsz durva dolog, hogy ugyanazzal a kulcsszóval kell két teljesen különböz? nyelv szerkezetet leírni.


    Szerintem az előltesztelő és a hátultesztelő ciklus az nem igazán különböző dolog, csak a feltétel ellenőrzésének helye különböző. Más kérdés, hogy az until repeatban még külön szépség hogy a repeat a nem teljesülésre figyel, azaz egy do ciklusmag while (! feltetel); nek felel meg. Na ez az amit nagyon utálok benne

    Hogy azért valami pozitívat is mondjak a pascalról, szvsz nagyon jó ötlet a beágyazott eljárás. Más kérdés hogy az oop ennek csökkenti a jelentőségét, de bizony én még az Object Pascal-ban is használom.
    Mutasd a teljes hozzászólást!
  • Érzelmi alapok miatt elég nehéz bárkit is bármiről meggyőzni, ha az nem vág egybe az ő elképzeléseivel, és nálad most mintha erről lenne szó (szvsz).

    - Én nem ismerem a C nyelvet, tehát nem fogok róla vitázni.
    - Ha már vki más felhozta az ősi pascal file-típus hiányát, emlékeim szerint az eredeti nagygépes pascalban valóban nem volt file, ugyanis a JCL (Job Control Language) nyelvben DD (Data Definition) környezetleírásban szerepeltek az adatok helyei (szalag, lemez, (lyuk)kártya, memória), amúgy a pascal file típusa a "byte-ok sorozata végjelig" volt, ami megegyezett az akkori C nyelv file definíciójával. Érdekes módon mo.-n nem volt a C elterjedve ('80-as évek), annak áldásos hatásából inkább csak az amerikai egyetemek profitáltak. Az ESZR, vagy R-XX sorozatú (jellemzően SZÜV-ös, én itt dolgoztam ilyenen) nagygépek rendszerében pl. semmi C nem volt, volt helyette asm, rengeteg rendszerkönyvtár, rendszerfüggvény, COBOL, PL/I, pascal, meg az egész alá egy OS, illetve VS :) //ezt példának csak azért hozom, mert az akkori (úgymond a PC elterjedéséig tartó) számítástechnikát talán a SZÜV fémjelezte -- neki voltak a legtöbb, és legnagyobb gépei.

    - a file-ra (emlékeim szerint) a PC-s pascal-nak lett hirtelen szüksége, ezért az akkori szabványtól való eltérést többnyire a 'turbo' előtaggal próbálták megkülönböztetni (úgy, ahogy az akkori C fordítókban is :)

    ui: nekem tetszenek az itt elhangzott hozzászólások -- amíg flame nem lesz belőle
    Mutasd a teljes hozzászólást!

  • Na, ez az ami nem igaz. C fordítót egyértelmûen sokkal könnyebb legyártani, mert a C kód - a Pascallal szemben - gyakorlatilag szekvenciálisan, teljesen lineárisan értelmezhetõ és dolgozható fel, míg a Pascal parsereknek bonyolult nyelvi szerkezeteket kell felismerniük mielõtt eldönthetik, hogy éppen milyen nyelvi elemrõl van szó. A többmenetesség ugyan igaz a C fordítónál (jó nagy hátránya is), de ez ugye nem jelenti azt, hogy nehezebb lenne a fordítót megírni. Csak azt, hogy többmenetes.


    Utso hozzaszolasom a temahoz. Erdekes modon kotod az ebet a karohoz :(. Utana is neztel a dolgoknak ? Egyszeruen nem ertelek. Azt mar tudom hogy a szemedben a c az rossz, mert a c-vel foglalkozo emberek aszondjak a delphisekre hogy nem tudnak programozni (nemtom ettol mer kene meg egy nyelvnek rossznak lennie, en pl szeretem a c egyszeruseget, s hogy megis gyonyoru kodot lehet benne irni).
    De itt elotted vki kifelytette hogy miert egyszerubb pascal forditot irni, s kapasbol ravagod hogy ez nem igaz. Legalabb elotte nezz szet a neten, ugy nehez vitazni, hogy nem vagy hajlando erofesziteseket tenni azert, hogy elfogadd a masik velemenyet is.

    firditas temaban par link, google meg tud tobbet is mondani:
    time to write a compiler
    Pascal v. C in compile speed

    Nekem spec semmi bajom Delphivel es a Delphi programozokkal. Altalanossagokba meg nincs ertelme beszelni. Olyan hogy Delphi hasznalo programozok vannak, de ezen felul minositeni oket nem tul okos dolog, hisz nincs ket egyforma. Ugyan ez all c-re is. Van aki nem tud c-ben jo kodot irni, van aki tud. Van aki tud jol fogalmazni, van aki nem. Foleg tolunk nyugatra tendencia az, hogy minel kisebb tudasu ember el tudja latni ugyan azt a feladatot. Ez tenyleg nem jelenti azt, hogy mindenki buta aki ilyen rendszerekkel dolgozik, de egy gyengebb kepessegu egyent is lehet jol hasznositani.
    Mutasd a teljes hozzászólást!
  • Gondolj csak bele Pl. hogy az repeat-until hogy lóg ki a ciklusszervező utásítások közül.
    A while, a for blokk orientáltak, azaz csak az utánuk jövő utasítást/blokkot hajtják végre, míg a repeat-unti úgy műxik mint a basicben a for-next azaz ami a két utasítás között van azt mind végrehajtja. Ráadásul feleslegesen vezet be egy utasításpárt, Pl. a while milyen szépen megoldja a C-ben a hátulteszlelő ciklust is.

    Abban igazad van, hogy a repeat-until kiugrik a többi nyelvi szerkezet közül (bár a terminológiában nem értünk egyet, mert szerintem valójában a repeat-untilt kell blokkos szerkezetűnek hívni, az összes többi pedig elemi utasításokat hajt végre, csak ugye a Pascal általános blokkdefiniálójával, a begin-end-del helyettesíthető bármilyen elemi művelet), de mondjuk ezt egyrészt nem tekintem kardinálás kihágásnak a tisztaság ellen (szemben mondjuk a C-vel ahol legalább háromféle elemi módon tudom növelni egy változó értékét eljáráshívás nélkül is, vagy ahol egy "*" operátor bármit jelenthet, és nem tudom meg mit csinál amíg át nem néztem az _egész_ programot), másrészt ez a kivétel ami erősíti a szabályt.

    Mindenesetre a C while-ja szerintem pont a rossz példa, mert azért az svsz durva dolog, hogy ugyanazzal a kulcsszóval kell két teljesen különböző nyelv szerkezetet leírni.

    Plusz, ha jól sejtem az eredeti Pascal-ban nem voltak fájlkezelő dolgok. Na most, ahogy ez a Turbo Pascal-ban bekerült, hát finoman szólva nem volt túl elegáns. Kezdve az Assign-nel, a compiler direktívát igénylő EOF kezeléssel ($i- és IORESULT ha jól emléxem) stb stb. Na ha valami gányolásnak tűnik akkor ez volt az, szemben a C igen királyul felépített stdio, stdlib, stb könyvtáraival.

    Talán nem a húsz évvel ezelőtti Pascalt kellene alapnak venni a megítéléskor. A mai Pascalok pedig a streamingtől kezdve minden extrát tudnak a fájlkezelés terén - nem mintha ez nyelvi elemek lennének.

    Fordító: én férfiasan bevallom a DOS óta nem foglalkoztam azzal hogy mit fordít a gép. A DOS-os időkben annál inkább, és meg kell mondjam hogy a Turbo C Pl. sokkal szebb, érthetőbb és hatékonyabb gépi kódot csinált mint a Turbo Pascal.

    Már megint több, mint 1 évtizedes Pascal fordító tulajdonságait hozod fel. A Delphi már nagyon régóta optimalizált kódot generál, ami nem mutat lényeges eltérést sebességben egy bármilyen csúcsszuper C fordító által generált kódtól. Ez egyébként manapság már csak azért sem különösebben jelentős, mert a mai rendszereken az idő >90%-ában általában az operációs rendszer / 3rd party komponens kódja fut, így a végrehajtási sebességre nincs nagy befolyással az alkalmazás fordítója által generált kód.

    Meg kell mondjam hogy a K3 nem csinált sem sokkal rosszabb, sem nagyobb kódot mint a gcc... Azaz a Borlandos fordítók ma sem rosszak...

    Na, ja. És akkor tegyük hozzá, hogy egy BCB/Kylix-nak egyáltalán nem a generált kód sebessége a fő előnye, és nem ezen hegesztenek éjjel nappal a Borlandosok, amíg bizony a GCC-s fiúk - már bocs, hogy ezt mondom, de - kizárólag ilyen 20 évvel ezelőtti, a mostani platformok ~0.001%-án komoly szempontot képező paradigmákban tobzódnak.

    Egyébként nyilván beágyazott eszközökben, meg mondjuk igen számításigényes feladatokhoz van létjogosultsága egy ilyen fordítónak is, és jó ha van ilyen is, de én nem mennék odáig, hogy egy BCB-t/Kylix-ot összehasonlítsak egy GCC-vel. Egyszerűen semmi közös pont nincs bennük azt leszámítva, hogy mindketten a C++ nyelvi szintaktikának megfelelő kódot tudnak lefordítani.
    Mutasd a teljes hozzászólást!
  • Éppen ezért tiszta nyelv a Pascal, és éppen ezért "gányoló" nyelv a C.

    Azért annyira nem tiszta. Gondolj csak bele Pl. hogy az repeat-until hogy lóg ki a ciklusszervező utásítások közül.
    A while, a for blokk orientáltak, azaz csak az utánuk jövő utasítást/blokkot hajtják végre, míg a repeat-unti úgy műxik mint a basicben a for-next azaz ami a két utasítás között van azt mind végrehajtja. Ráadásul feleslegesen vezet be egy utasításpárt, Pl. a while milyen szépen megoldja a C-ben a hátulteszlelő ciklust is.

    Plusz, ha jól sejtem az eredeti Pascal-ban nem voltak fájlkezelő dolgok. Na most, ahogy ez a Turbo Pascal-ban bekerült, hát finoman szólva nem volt túl elegáns. Kezdve az Assign-nel, a compiler direktívát igénylő EOF kezeléssel ($i- és IORESULT ha jól emléxem) stb stb. Na ha valami gányolásnak tűnik akkor ez volt az, szemben a C igen királyul felépített stdio, stdlib, stb könyvtáraival. A string kezelés viszont egy pont plusz a pascalnak.

    Fordító: én férfiasan bevallom a DOS óta nem foglalkoztam azzal hogy mit fordít a gép. A DOS-os időkben annál inkább, és meg kell mondjam hogy a Turbo C Pl. sokkal szebb, érthetőbb és hatékonyabb gépi kódot csinált mint a Turbo Pascal.
    Ami a hatékonyságot illeti, amikor megjelenta Kylix 3 csináltam egy kis sebességtesztet a gcc 2.98 és a K3 C++ között. Objektumokat hoztam létre, kerestem, töröltem, stb. Meg kell mondjam hogy a K3 nem csinált sem sokkal rosszabb, sem nagyobb kódot mint a gcc... Azaz a Borlandos fordítók ma sem rosszak...
    Mutasd a teljes hozzászólást!
  • AutoCad, 3dStudioMax -ezek VC-ben vannak

    Mint régebben leírtam, ezekre szerintem is a C++ a legalkalmasabb. Ezek egyike sem igazán GUI-orientált (pontosabban nem form-orientált) így egy ilyet nem igazán éri meg RAD-dal megcsinálni. Viszont ha meg kell írni egy 1000 formot kezelő ügyviteli programot akkor a vizuális C++-os emberke az első száznál sem fog járni mire én befejeztem...
    Ráadásul az én Delphis/Kylixos kódomat ezerszer könnyebb utána módosítani/karbantartani és ez sem mindegy. Plusz, a Delphi/Kylix kód hordozható, win-ről linuxra és vissza, később pedig managedből unmanagedbe ahogy csak akarod. És a CLX-ben minden benne van ami ehhez kellhet, az IDE pedig a legjobb amit idáig RAD eszközben láttam. De mondjuk játékot vagy CAD-ot én sem kezdenék benne (annak ellenére hogy végül is a nyelv lehetővé teszi).
    Amúgy a C(++) / (OBJECT) Pascal vitát alapjában véve hülyeségnek tartom. A két nyelv között nincs igazából lényegi, filozófiai különbség. Picit más szintaktikával kezelnek dolgokat, de nincs olyan rettenetesen nagy eltérés mint Pl. a Lisp/Prolog/Rpg/Cobol között, sőt szvsz C vs Perl vitának is több értelme lenne. Amikor áttérek az egyikről a másikra akkor úgy egy-két napig vannak problémáim az else ág végén lévő pontosvesszők és az if zárójel vagy then kérdés körül...
    Ami különbséget látok az inkább VCL/MFC/.NET között van, de szvsz az MFC teljesen ki fog halni (megeszi a .NET bár egy darabig kompatibilitási okokból ő is élni fog hogy a meglévő progikat könnyű legyen átvinni), a VCL pedig még sokáig élni fog, mivel szvsz jóval könnyebben tanulható mint a többkötetes referencia kézikönyvvel rendelkező .NET. és arra a célra amire ki van találva tökéletesen alkalmas. Max. a fejlesztők egy része hívni fog .NET-es függvényeket is, mint ahogy a perverzebbje most is hívogat WIN32 API-t. Csak ez ezután könnyebben fog menni, feltéve ha a Borland jól csinálja meg a .NET-es dolgokat. Lehet hogy a C# szép lassan le fogja váltani az Object Pascal-t a Delphisek között is (nálam valószínűleg igen, én nem igazán szeretem a Pascal szintaxist, különös tekintettel a for ciklusára és a pre/postfix operátorok hiányára) de a VCL/CLX szerintem még sokáig marad.
    Mutasd a teljes hozzászólást!
  • A Pascal nyelv nyelvtana [..] a konnyen kezelheto nyelvtanok koze tartozik, ezert lehet hozza kesziteni determinisztikus top-down elemzot, amely egyreszrol gyors, egymenetes forditasra alkalmas, masreszrol konnyu(ebb) ilyet implementalni. A C-nyelv nyelvtanara mar nem lehet ramondani, hogy erosen LL(k), az inkabb LL(k), ezert nem is lehet top-down elemzot kesziteni hozza. C forditok nemdeterminisztikus bottom-up elemzest alkalmaznak, amelyet mar egy "kisse" sokkalnehezebb legyartani.

    Na, ez az ami nem igaz. C fordítót egyértelműen sokkal könnyebb legyártani, mert a C kód - a Pascallal szemben - gyakorlatilag szekvenciálisan, teljesen lineárisan értelmezhető és dolgozható fel, míg a Pascal parsereknek bonyolult nyelvi szerkezeteket kell felismerniük mielőtt eldönthetik, hogy éppen milyen nyelvi elemről van szó. A többmenetesség ugyan igaz a C fordítónál (jó nagy hátránya is), de ez ugye nem jelenti azt, hogy nehezebb lenne a fordítót megírni. Csak azt, hogy többmenetes.

    A C-nyelvnek igen koros tortenelme van, es azt azert fejlesztette ki '70 korul Dennis Richie komoly munkaval (a B-nyelv tovabbfejlesztesekent), hogy megirjak benne a UNIX-ot. A Pascal-t pedig oktatasi celbol fejlesztettek ki, viszont azon mar joval tulnotte magat, amiert is nem lebecsulendo, es tisztelet neki. Csak, hogy a helyere tegyuk a dolgokat.

    Éppen ezért tiszta nyelv a Pascal, és éppen ezért "gányoló" nyelv a C. Kerninghammal és Ritchie-vel kapcsolatban pedig csak egy dolgot tudok mondani: tévedni emberi dolog. :)

    A C-nyelvrol meg csak annyit, hogy valoszinuleg megis 'hudekiraly', mert a mobil eszkozoktol kezdve (valoszinuleg ide az a mobiltelefon is beletartozik, amit a zsebedben hordozol) egeszen a mikrokontrolerek programozasaig, nembeszelve az operacios rendszerekrol, mind-mind C-ben tortenik.

    Na, már bocs, de ennek semmi köze nincs a technológiai szuperioritáshoz. Ha így működnének a dolgok, akkor nem ment volna tönkre a BeOS, és nem lenne olyan piaci részesedése a Microsoftnak a szoftverek piacán, mint amilyen most van.

    nem hiszem, hogy a C helyett valaki elkezdene egy uj hardverkozeli nyelvet kitalani, mikor mar van egy tokeletes

    Szvsz a C egyáltalán nem hardverközeli nyelv, pontosabban egyáltalán nem jobban hardverközeli, mint a Pascal. A Pascal fordítók egyetlen hátrány a C fordítókkal szemben a hardverközeli programozás során, hogy előbbiekben klasszikusan nagyon szoros egységet képez a fordító és a linker, és így általában kevésbé alkalmasak (nem elég rugalmasak) az ilyen speciális feladatokhoz. Utóbbinál ez nem gond, mert a C fordítókban klasszikusan élesen elkülönül a fordító és a linker (ami jó nagy adag szívás forrása ismét csak).

    Igy sok koca delphisnek a mai napig nincs fogalma arrol, hogy mi tortenik a hatterben (persze erre az ismeretre csak akkor van szukseg, ha az acces violak ropkodnek, es nem tudni, hogy ugyan miert).

    Na, ez ismét egy nagy tévedés, és nálad is már korábban említett az "übermensch"-komplexust vélem felfedezni a C nyelv használata kapcsán. Ti. azt sugallod, hogy aki Delphi-t használ az mind kockafejű, és gőze sincs róla, hogy belül hogyan működnek a dolgok. A Delphi programozók túlnyomó részére nagyrészt igaz is az állításod, csak az a baj vele, hogy a C programozóknak is kb. hasonló része hasonlóan hiányos tudással rendelkezik. (Az MFC-hez ugyanúgy nem kell feltétlenül ismerni a WinAPI-t, mint ahogy a VCL-hez sem.) A különbség, hogy utóbbiak általában gányos kódot is írnak. És ez most nem mese, meg elméleti fejtegetés, hanem gyakorlati tapasztalataim alapján mondom.

    Tehat miert fejlesztenenk D-alatt .NET-ben, mikor ott van a .NET keszitojenek a sajat OS-en, a sajat IDE-je, es ebbe mar mas nem igen tud ujat beletenni? Talan csak szolidaritasbol, de a vilag nem errol hires.

    Nem. Azért (is) fejlesztenek Delphi alatt, mert az egy tiszta nyelv. C alatt sem azért fejlesztenek annyian, mert az olyan király, hanem mert ezt tanulták/szokták meg. (Sok embert ismerek aki vette a fáradtságot, megismerte a Delphit, és áttért rá C-ről, mert jobbnak találta. Meg sok olyan C-st is ismerek, aki fikázza a Delphit, meg a Pascalt, aztán amikor odaültetjük elé, akkor kiderül, hogy gőze sincs róla a legalapvetőbb nyelvi szerkezeteken túl.)

    Egyébként pont ezért lesz jó ha majd lesznek teljesen .NET alapú fordítók. Mert azoknál majd valóban a nyelveket, és nem a hozzájuk adott többletértéket (a standard könyvtárakat, keretrendszerket) lehet majd összemérni. Persze valahol ez meg már feleslegesség fog válni, hiszen végre valóban simán együtt tud majd működni két teljesen más fordító által generált kód is, minden külön "varázslás" nélkül is.
    Mutasd a teljes hozzászólást!
  • A közhiedelemmel ellentétben egyébként nem azért a C a legelterjedtebb nyelv a platformok számát tekintve, mert annyira húdekirály, hanem, mert a C fordítót a legegyszerűbb dolog megírni a világon (ti. az egész nyelv, minden szerkezete, a szintaxis, stb. a gépi feldolgozás egyszerűsítésére van kidolgozva

    1. A C fordito megirasanak egyszerusegerol: A Pascal nyelv nyelvtana egy erosen LL(k) nyelvtan, amely a konnyen kezelheto nyelvtanok koze tartozik, ezert lehet hozza kesziteni determinisztikus top-down elemzot, amely egyreszrol gyors, egymenetes forditasra alkalmas, masreszrol konnyu(ebb) ilyet implementalni. A C-nyelv nyelvtanara mar nem lehet ramondani, hogy erosen LL(k), az inkabb LL(k), ezert nem is lehet top-down elemzot kesziteni hozza. C forditok nemdeterminisztikus bottom-up elemzest alkalmaznak, amelyet mar egy "kisse" sokkalnehezebb legyartani. Egyebkent innen ered a C fuggvenyek es a PASCAL elejarasok/fuggvenyek parameter vermelesenek forditott sorrendje is.

    2. A C-nyelvnek igen koros tortenelme van, es azt azert fejlesztette ki '70 korul Dennis Richie komoly munkaval (a B-nyelv tovabbfejlesztesekent), hogy megirjak benne a UNIX-ot. A Pascal-t pedig oktatasi celbol fejlesztettek ki, viszont azon mar joval tulnotte magat, amiert is nem lebecsulendo, es tisztelet neki. Csak, hogy a helyere tegyuk a dolgokat.
    A C-nyelvrol meg csak annyit, hogy valoszinuleg megis 'hudekiraly', mert a mobil eszkozoktol kezdve (valoszinuleg ide az a mobiltelefon is beletartozik, amit a zsebedben hordozol) egeszen a mikrokontrolerek programozasaig, nembeszelve az operacios rendszerekrol, mind-mind C-ben tortenik. Talan a multik mind hulyek, hogy a C-t valasztjak. Ezzel nem azt akarom mondani, hogy a Delphi rossz, vagy nem jo. Csak tudni kell hova valo (ku-val kezdodik es ka-val vegzodik , csak vicc).
    (pl. AutoCad, 3dStudioMax -ezek VC-ben vannak, persze a WCommander Delphi-ben)
    Az tuti, hogy a D/pacal magasabb szintu nyelv, mint a C/c++, de pont ezert vannak olyan dolgok, amire inkabb valo a C(VC) es ezeket jol el kell tudni hatarolni.

    Senki nem mondta egyebkent, hogy a C hajtja meg a hardvert, a C csak azert kell, hogy irjanak olyan alrendszert a csupasz vasra, amin a D kornyezet el tud indulni, es nem hiszem, hogy a C helyett valaki elkezdene egy uj hardverkozeli nyelvet kitalani, mikor mar van egy tokeletes.

    Egyébként meg miért kellene az összes komponenst átírni?? Azok egy csomó Windows specifikus dolgot tartalmaznak, ami nem hordozható. Akinek meg ez nem számít, annak ott lesz mindig is a "sima" Delphi.

    Azert, mert a D egyik (de szerintem a legnagyobb) elonye a nagy komponenskavalkadjaban van. A .NET elterjedese valoban meg kritikus, de ha megnezzuk erre az MS ra fogja kenyszeriteni a klienturajat, mert ehhez minden a kezeben van. Az MS feltett mindent a .NET-re, tehat ha bukik, akkor az egesz MS bukik, ennek pedig nincs nagy eselye. Gondoljunk csak arra, hogy vilag szamitogepein mekkora aranyban fut winfos. Aki pedig megmarad a windows specifikus dolgoknal az lemarad, tehat elobb utobb meghal. Aki pedig ugy dont, hogy .NET-re epit, annak a legjobb valasztas az MS kornyezete lesz, mivel .NET-ben mar nem tud a Borland masfele szemleletet kialakitani, mint a mostani D-Form, amely total eltakarja az eredeti windows ablakozo technologiat. Igy sok koca delphisnek a mai napig nincs fogalma arrol, hogy mi tortenik a hatterben (persze erre az ismeretre csak akkor van szukseg, ha az acces violak ropkodnek, es nem tudni, hogy ugyan miert). Tehat miert fejlesztenenk D-alatt .NET-ben, mikor ott van a .NET keszitojenek a sajat OS-en, a sajat IDE-je, es ebbe mar mas nem igen tud ujat beletenni? Talan csak szolidaritasbol, de a vilag nem errol hires.
    Mutasd a teljes hozzászólást!
  • Ennyi erővel semmit sem érdemes összehasonlítani, csak a teljesen identikus dolgokat. Azokat meg minek?
    Mutasd a teljes hozzászólást!

  • Álljunk meg egy szóra, miért hasonlítjuk össze a Pascal-Delphi és a C/C++ fordítót, legjobb tudomásom szerint a Pascal-Delphi fordító egyemenetes, míg a C/C++ pedig több menetes fordítást végez el a kódon.
    Ha venném a fáradtságot, akkor megkeresném az idevágó részeket, amelyeket "Compilerek - absztrakt automaták" - nál tanultunk ....
    Mutasd a teljes hozzászólást!
  • A Delphi ugyanis szerintem nem programozasi nyelv hanem egy fejlesztoeszkoz, amiben Pascal nyelven gramozol.

    A Delphi már szigorúan terminológia szerint is nyelv (éppen a napokban írtam ebben, vagy egy másik Delphi-s topicban egy idézetet egy Borland doksiból, ami szerint már Delphi-nek hívják a nyelvet magát is, és nem Object Pascal-nak), de ha nem így lenne akkor is érdemes ekként hivatkozni rá, mert egyrészt iszonyú a különbség a hagyományos/ISO Pascalhoz képest (kb. annyi, mint a C és a C++ között). És a Delphi-hez nyugodtan "hozzászámolhatjuk" a RAD IDE-t és a VCL-t is, mert egyrészt szoros egységet alkotnak, másrészt a C++ fordítókat is az STL vagy egyéb standard könyvtáraik teszik használhatóvá, mert azok nélkül ma már csak a szemétben landolhat minden.

    Szamomra kerdes meg meddig el a Pascal, a Java ugyanis nagyon megy, c++ erosen tartja magat, a pascal viszont szerintem 5 ev alatt eltunik a sullyesztoben.

    5, 10, de talán 15 évvel ezelőtt is voltak akik ezt mondták. Azt látjuk hol vagyunk. A Java nem csereszabatos, és sosem is lesz az a C++-szal és Pascal-lal. (Bár utóbbiakhoz készíthető olyan fordító ami Java bájtkódot generál - pl. volt ilyen Delphi fordító, csak sosem lett termék belőle -, fordítva már nagyon nem megy, mert sokkal magasabb szintű nyelv a Java, így egy csomó gépközeli dolgot nem lehet megoldani benne.) Éppen ezért nem is veszélyezteti azokat.
    A dolgok szerintem belátható időn belül úgy fognak tovább haladni ahogy most is vannak: a C++ megmarad mainstream nyelvnek, a Pascal meg (viszonylag) kevesek nagyon hasznos és tiszta eszközének.

    Ha nem lenne pénz a dologban (=nem lennének Pascal programozók) akkor nem jelennének meg az új Delphi-k és más Pascal fordítók (mert van belőlük bőven, csak éppen a Borland a legnagyobb név amit mindenki ismer).
    Mutasd a teljes hozzászólást!
  • A vitat talan ket reszre lehet bontani:

    1. Delphi vs valami C++ -s fejlesztoeszkoz
    A Delphi ugyanis szerintem nem programozasi nyelv hanem egy fejlesztoeszkoz, amiben Pascal nyelven gramozol.
    A Delphi mint fejleszoeszkoz eleg jo, nehany eve meg aki asztali gepen futo alalmazas akart kesziteni, annak ez vagy a C++Builder volt a legjobb valaszas.
    A C++ Builder egyebkent annyiban kulonbozik a Delphitol, hogy c++ nyelven kell benne programozni, maskulonben a termek azonos. Valamint mindketto Borland termek, de Borlandeknal a Delphi az elso gyerek, ezert mindig eloszor Delphibol jelenik meg az ujabb verzio, aztan fel evre ra a C++ Builder.

    1. Pascal vs C++
    Mindket nyelv altalanos celokra szuletett, a pascal kicsit emberkozelibb, a C++ kicsit gepkozelib. Ennek megvan az elonye/hatranya.
    Kezdo felhasznalak minden igenyet kielegiti mindketto, szintaktikai kulonbsegeket veszel csak eszre (begin-end helyett { }, stb. ).
    Amiert a C++ mellett tennem le a voksom az az hogy rengeteg platformon elerheto, tobb gyartonak is van c++ forditoja, mig pascal-bol igazabol csak a Borland van a piacon.
    Szamomra kerdes meg meddig el a Pascal, a Java ugyanis nagyon megy, c++ erosen tartja magat, a pascal viszont szerintem 5 ev alatt eltunik a sullyesztoben.

    Osszefolalva ha a C++-t C++ Builderben oktatjak en azt valasztanam, ha esetleg valami massal (pl MS Visual Studio 6) akkor viszont jol fel van adva a lecke, mert a c++ elonyosbb, de mindenkeppen erdemes egy olyan RAD eszkozt megtanulni mint a Delphi/C++Builder paros.

    Z.
    Mutasd a teljes hozzászólást!
  • A közhiedelemmel ellentétben egyébként nem azért a C a legelterjedtebb nyelv a platformok számát tekintve, mert annyira húdekirály, hanem, mert a C fordítót a legegyszer?bb dolog megírni a világon (ti. az egész nyelv, minden szerkezete, a szintaxis, stb. a gépi feldolgozás egyszer?sítésére van kidolgozva, míg más nyelveknél inkább az ember és a feladat szerepelt a középpontban).


    Szvsz pascal fordítót sem sokkal nehezebb írni mint C-t. Sőt, igazából a C-nek valamivel nagyobb az igénye. Pl anno Spectrumon egész jó kis Pascal fordítót hozott ki a HiSoft (HP4T pascal) ami igen jól működött anno, míg ugyanennek a cégnek a C fordítója már szinte használhatatlan volt. C64-re is volt pár Pascal fordító (Pl.Oxford) és ezek is kényelmesebben voltak használható mint a C64-es C fordítók (Pl. Power C).
    Ezzel együtt én még anno csináltam ügyviteli szoftvert C64-en Power C-ben ami kb Clipper look&feel-t biztosított a felhasználónak. Szóval szvsz a fordítóprogram bonyolultsága ebből a szempontból nem igazán játszik. Amúgy ha ez lenne a szempont akkor minden vas RPG-ben lenne programozva
    Mutasd a teljes hozzászólást!
  • Az idő nagy részét normális esetben a tervezés tölti ki. Más kérdés hogy sajnos errefelé a normális eset a ritka . Utána viszont csakugyan nagyon nem mindegy hogy egy formot mennyi idő alatt hozol létre, és főleg hogy később egy módosítás során mennyi idő alatt találsz meg egy dolgot.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    No, végigolvastam 1xe az egész topic-ot, s a következő észrevételeim lennének: jelenleg 5. éves infós hallgató vagyok a Miskolci Egyetemen. elég sok programnyelvet ismerek, edig elsősorban C++ -ban nyomultam. Kb 3 éve véletlenül megismerkedtem a Delphi 5-el (sűrgősen meg kellett írnom valamit, s a visualstudio installja nem volt otthon, de valaki azt mondta, hogy win alá van 1 Delphi nevű fejlesztőrendszer is.). Azóta az általam írt dolgok 95%-a Delphi-ben készül. Lehet szeretni, lehet nemszeretni, de:

    - nem hiszem, hogy lenne értelme annak a kijelentésnek, hogy csak GUI-ra jó. Most épp a dipi munkámon dolgozok, amiben elenyésző a GUI rész, kb 80% a szimpla matematikai művelet, meg file-kezelés. Ehhez képest tökéletesen tudok vele haladni, és ráadásul sokkal gyorsabban, mint pl MSVC-ben. (Hidjétek el, kipróbáltam ugyanazt megírni MSVC-ben is, de 3 hét után feladtam.)

    - Arról nem is beszélve, hogy pl. az IDE-be beépített csoportmunka támogató, illetve multilanguage rész igen igen sokat tud jelenteni. Szeretném megkérdezni a tisztelt C++ rajongóktól, hogy mennyi pluszmunkával jár MSVC alatt 1 alkalmazás automatikus ellátása többnyelvű interface-val? És természetesen ez a rész sem CSAK GUI-ban működik, consol alakalmazásoknál sincs vele probléma.

    - Az általános feladatoknál, s nem a specializáltaknál az esetek döntő többségében nincs idő arra, hogy hosszú hónapokig arra menjen el minden időnk, hogy "pepecseljünk" a programmal MSVC alatt, eléggé záros határidőn belül kell teljesíteni. Ilyenkor viszont kétség kívül a Delphi a gyorsabb megoldás.

    - Természetesen az MSVC++ -nak is megvan a maga létjogosúltsága: pl. nagyon sebességkritikus, win "lelkébe" nyúló programokat (videó lejátszó, grafikus engine, stb...) nem lenne értelme delphi-ben fejleszteni, ez nem kérdéses. De: a delphi-hez is léteznek pl. nagyon jó OpenGL komponenscsomagok, melyeket ha alaposabban megnéz az ember, s nem csak eszetlenül használja, jó dolgokat tud belőle kihozni. (GLScene: NEWS)

    Más: C# -hoz nem szólnék hozzá, mivel teljesen ismeretlen előttem.

    Remélem hozzászólásommal nem bántottam meg senkit.

    U.I: Delphi forever.
    Mutasd a teljes hozzászólást!
  • Viszont, ha valmi "komolyabb" dolgot kellene muvelni (pl. COM, ActiveX, sebesseg-kritikus, hardverkozeli megoldasokat igenylo problemak, driverek, videofeldolgozas, vagy a Windows lelkebe maszast igenylo megoldasok), akkor meg az eg mentsen meg a Delphi-tol, az erre nem valo.

    A Delphi pontosan ugyanannyira alkalmas mindezen feladatokra, mint a VC. Az egyetlen kivétel a driverek, mert azt sajnos Delphi-vel nem lehet készíteni (ennek formális, nem technikai okai vannak). De semelyik másik dologgal semmi problémája sincs a Delphinek. A Windows lelkébe éppen úgy be lehet mászni vele, mint az MSVC-vel (munkám nagy részét ilyen "mászások" teszik ki).

    De persze C mindig lesz, mert a hardver magatol nem fog megtanulni "beszelni", hacsaknem java-ul.

    Hát ez elég rossz érv volt. Nem a C az ami meghajtja a hardvert, innentől kezdve akármelyik másik nyelv is lehet az, amelyik "megmarad". Persze a dolgok eleve nem így működnek...
    A közhiedelemmel ellentétben egyébként nem azért a C a legelterjedtebb nyelv a platformok számát tekintve, mert annyira húdekirály, hanem, mert a C fordítót a legegyszerűbb dolog megírni a világon (ti. az egész nyelv, minden szerkezete, a szintaxis, stb. a gépi feldolgozás egyszerűsítésére van kidolgozva, míg más nyelveknél inkább az ember és a feladat szerepelt a középpontban).

    A Delphi-nek szerintem meg vannak szamlalva a napjai, amit a .NET-nek koszonhet. Ez mar csak ido kerdese. Ha Borland-ek nem talalnak ki valami okosat, akkor kampec. Talan az osszes komponest atirjak managed-kodra?!

    Már rég kitalálták a Delphi.NET-et (a D7 dobozában már benne is van a parancssori fordító belőle).
    Egyébként meg miért kellene az összes komponenst átírni?? Azok egy csomó Windows specifikus dolgot tartalmaznak, ami nem hordozható. Akinek meg ez nem számít, annak ott lesz mindig is a "sima" Delphi.

    Egyébként sem úgy működnek a dolgok, hogy akkor most jön a .NET aztán lesöpör mindenkit. Nézd meg, hogy a Java-t mikor dobták piacra, és ma hol tart! Vagy, hogy mennyi idő kellett ahhoz, hogy a DOS-t gyakorlatilag halott platformnak lehessen tekinteni! Szóval nem az elkövetkező 1-2-3 éven belül fog a .NET egyeduralkodóvá válni, ez tuti.

    Mert ugyebar azt mindenki tudja, hogy a .NET tamogatas (ami tudomasom szerint D6-ban mar megvan) beepitese meg nem jelenti azt, hogy van is ertelme D-ben ilyet csinalni.

    Szerintem csak a D7-ben van meg, és mondjuk azt nem igazán nevezném támogatásnak ami abban van. Fogalmazzunk úgy, hogy a D7 már hallott olyanról, hogy .NET.
    Mellesleg az OK, hogy attól, hogy egy nyelv támogat egy adott technológiát önmagában nem lesz ideális választás. De még egyetlen megalapozott érvet sem hallottam tőled arra vonatkozólag, hogy miért ne lehetne az.
    Mutasd a teljes hozzászólást!
  • Azért a VCL/CLX tényleg elég jól ki lett találva, arra amire a Delphi való szvsz tökéletesen elég. A java-ban pont azt nem szeretem hogy a nyelv szép és jó, de van hozzá osztálykönyvtár ami akkora hogy hat kötet csak a referencia . Szvsz a CLX-ben pont az a jó hogy kb még fejben lehet tartani hogy mi hol van, ugyanakkor mindent lefed amire egy átlag üzleti alkalmazásnak szüksége van. Ha meg még elérik hogy C# nyelven is lehessen programozni az Object Pascal és a C++ mellett, valamint hogy el lehessen belőle érni a .NET függvényeit, ráadásul a mono segítségével multiplatform is lesz a .NET kódja, sőt az egész rendszer (ellentétben az M$ VS-sel, ami egyébként kész röhely, elvégre ha valami értelme van a virtuális kódnak az pont a hordozhatóság lenne, márpedig a .NET az ugye fut W$ alatt meg fut W$ alatt de fut W$ alatt is , szerintem ők lesznek a királyok.
    Mutasd a teljes hozzászólást!
  • Szerintem a kerdes nem az, hogy melyik feljesztoeszkoz a jobb, hanem az hogy melyik mire valo. Ha ugyviteli alkalmazast kell kesziteni, akkor egyertelmuen a Delphi mellett voksolnek (bar mas alternativa is van), es csak igen alapos indok mellett valasztanam a VC-t. Viszont, ha valmi "komolyabb" dolgot kellene muvelni (pl. COM, ActiveX, sebesseg-kritikus, hardverkozeli megoldasokat igenylo problemak, driverek, videofeldolgozas, vagy a Windows lelkebe maszast igenylo megoldasok), akkor meg az eg mentsen meg a Delphi-tol, az erre nem valo.

    Egyebkent pedig a nativ kodokat generalo rendszerek napjai amugy is meg vannak szamlalva, es rohognek a markukba a Java-sok, meg a C#-osok. De persze C mindig lesz, mert a hardver magatol nem fog megtanulni "beszelni", hacsaknem java-ul.

    A Delphi-nek szerintem meg vannak szamlalva a napjai, amit a .NET-nek koszonhet. Ez mar csak ido kerdese. Ha Borland-ek nem talalnak ki valami okosat, akkor kampec. Talan az osszes komponest atirjak managed-kodra?! Mert ugyebar azt mindenki tudja, hogy a .NET tamogatas (ami tudomasom szerint D6-ban mar megvan) beepitese meg nem jelenti azt, hogy van is ertelme D-ben ilyet csinalni.
    Mutasd a teljes hozzászólást!
  • a VCL nem volna viszonylag olyan jó(?), akkor a Delphi már rég a kihalás útját koptatná .....

    Ja. Ha meg öreganyámnak kereke lenne, akkor...

    Az erős RTL-lel/S(T)L-lel/keretrendszerrel/RAD IDE-vel nem rendelkező fordítók már szépen mind ki is haltak. (Ami nem, az tud valami nagyon speciálisat ami más nem; mondjuk nagyon sok platformra fordít.) Ezt hívják evolúciónak...
    Mutasd a teljes hozzászólást!

  • Most úgy szólok hozzá, hogy még nem próbáltam a BCB-t, de nekem a VStudio állati kényelmes, billentyűzetről a funkciókat haláli gyorsan tudom elérni, az egér szinte nem is kell ...
    Azért hozzátok fel egy-két dolgot BCB-ből, ami nincs benne vagy hiányosan a VStudio - ban, azt a választ nem fogadom el, hogy "mert csak"!!!

    A 42. üziben a "Egy nyelv megtanulása egyébként is elenyésző idő a hozzá kapcsolódó framework megismeréséhez képest." kijelentéssel maxi egyetértek, ha a VCL nem volna viszonylag olyan jó(?), akkor a Delphi már rég a kihalás útját koptatná ..... [ bárcsak :)) C/C++ - os barátaim ]

    Mellesleg és épp most Delphi - ben sorosporton nyomok egy kütyüt, nincs is semmi gondom vele, hacsak éppen nem az, hogy Delphi - ben kell csinálnom ....


    dj
    Mutasd a teljes hozzászólást!
  • Hi! Azért Stinghez képest gyakorlott kezdő vagyok :)
    (Hé, csávó, mikor is kell fizetnem a következő részletet a nyilvános fórumokon történő dicsőítésért?)
    Mutasd a teljes hozzászólást!
  • A 25. bejegyzes miatt lettem kicsit ingerult. Mintha el sem olvastad volna. Persze lehet hogy megnezted az altalam emlitett dolgokat, s megis gagyi az MSVC, ekkor szivesen megneznem hogyan dolgozol Delphiben.

    (nem form epitgetesre gondolok, hanem kodirasra)
    Mutasd a teljes hozzászólást!
  • Felesleges ingerültnek lenned, mert nincs igazad. Én nem azt mondtam, hogy MSVC-ben nem lehet nyomkövetni, vagy nem lehet include könyvtárakat felvinni, csak azt, hogy a Borland eszközökben ez százszor kényelmesebb, és sokkal több apróság van bennük, amik egyike sem kardinális (végül is bármilyen ASCII editorban lehet programot írni), de nagyban megkönnyítik a munkát.

    Kb. olyan a két dolog, mint a trabant tekerős ablaka, meg egy merci motoros ablakemelője. Erre Te közlöd, hogy ne magyarázzak, mert bizony az MSVC-ben is van ablakemelő. Persze, hogy van - csak kurblizhatsz vele fél órát mire odáig jutsz, ahova BCB-ben egyetlen gombnyomással. Erről van szó...
    Mutasd a teljes hozzászólást!
  • (azért nem VC-t mondok, hogy ne keverjen be annak gagyisága a kényelmi funkciók tekintetében a Borland eszközökéhez képest)


    En vettem a faradtsagot es megneztem mi a kenyelem a borland eszkozokben. Mondtam is hogy hogyan lehet ezeket elerni MSVC-vel. Kerdesem csupan mostmar az, hogy el is olvasod amit masok irnak, s megnezed mit valtozik a vilag, vagy a levegobe vitazunk ?

    (bocsi a durva hangnemert, csak folyamatosan szidsz valamit, ami szerintem nem erdemli meg)
    Mutasd a teljes hozzászólást!
  • Így szó szerint valóban nem írtad le. Nekem mégis ez jött át.
    Mutasd a teljes hozzászólást!
  • A másik dolog, hogy mit?l lesz alacsonyabb rend? programozási feladat az "esemény kezelés" és "property állítgatás", mint változók állítgatása, vagy eljárások hívása?


    Már bocsi, de hol írtam én olyat hogy ezek alacsonyabb rendű dolgok ?
    Mutasd a teljes hozzászólást!
  • Na jó, mi irtunk benne multi-tier cuccot a Delphi beépített MIDAS übershit varázslása nélkül, működik gond nélkül.

    Hiába GUI-orientált egy ügyviteli alkalmazás, a feladatok jelentős része az adatbázisoldalon zajlik, a tárolt eljárások függetlenek Delphitől, C++-tól.

    Péter
    Mutasd a teljes hozzászólást!
  • .NET Framework biztos, hogy keresztbe bekapja Delphi VCL-t.

    Az eredeti kérdés szempontjából ez talán még lényeges is.

    Én nem kezdenék el tanulni C++-t, mert gáz lenne olyan ismeretekre pazarolni az időmet, ami később nem fogok effektive hasznosítani (effektive). Egy nyelv megtanulása egyébként is elenyésző idő a hozzá kapcsolódó framework megismeréséhez képest.

    Tanuljunk .NET Framework-ot, irjunk managed kódot, efelé mutat a Java és a .NET is.

    BTW ha valaki Delphi-ben dolgozik, nem jelenti azt, hogy nem fog API-t használni, nem látott még szálakat vagy épp nem tudja, mi az a message loop, ez kérem szépen nem roppantvizuális bézik. Kezdőként _pont jó_, hogy message loop rejtve van előtted, de aztán ha szükséged van arra, hogy valamit rendbevágj, előbb-utóbb úgyis megtanulod, mi is az.
    Nekem bejött az ilyen léptékű tanulás, teljesen elégedett vagyok.

    Az, hogy a Delphi csak GUI-ra alkalmas, minden más hónaljszagú izzadás benne, az kamu. Részemről vidáman írok benne különösebb megerőltetés nélkül gyakorlatilag mindent, amire szükségem van, driverek kivételével.

    <csakvicc>És amikor látom, hogy egyesek SetName() meg GetName() metódusokat irnak, akkor dörzsölöm a kezem :))))</csakvicc>

    Péter
    Mutasd a teljes hozzászólást!
  • mar ne haragudj Sting, de ez egy kicsit demagogra sikerult. ugyanilyen alapon en is mondthatnam, hogy a Te velemenyed nem mervado c++-ban, mert lathatolag nem sokat foglalkoztal mas jellegu feladatokkal, mint UI-oritenalt fejlesztes.


    Izé, lol :) Sting kolléga munkásságának egy részét ismerve azt kell mondjam, hogy ez így pont nem igaz, de mindegy :)
    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