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
  • akkor bocsi, ha igy letezik, bar szamomra illogikus, hogy miert const a deklaracioja,
    vaoo, a delphi - ben a logikatlan dolgok is mukszenek!!! (megintcsak bocsi, most genya voltam)

    Hát az voltál...

    Egyébként én is írtam az előző hozzászólásomban, hogy elég hülyeség, hogy a const kulcsszóval kell az ilyesmit deklarálni. A dolog valószínűleg arra vezethető vissza, hogy az eredeti Pascal terminológia "típusos konstans"-nek (typed constant) hívja ezt a szerkezetet, és ezért a "const" a logikus kulcsszó a deklarálásához. Persze a terminológia ettől még hülyeség, mert valójában semmilyen értelemben nem hasonlít a konstansok működéséhez az ilyen módon deklarált változó, hanem sokkal inkább a hagyományos változókhoz hasonlóan viselkedik azzal az apró különbséggel, hogy definiált kezdőértéke van. Éppen ezért szoktam én "inicializált változó"-nak hívni ezeket.
    Mutasd a teljes hozzászólást!
  • Egy mezei GUI-orientált progi elkészítésének nagy része azért bizony eseménykezelés és property állítgatás,[...] Más kérdés hogy egyes események sokszor hívhatnak közös, általános függvényeket.

    Na, látod, szerintem ezt hívják csúsztatásnak. Egy eseményvezérelt környezetben ugyanis nyilvánvaló, hogy minden a keretrendszeren kívüli kód eseménykezelőkből indul.

    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?

    Komolyan mondom, hogy a kognitív disszonancia erős jegyeit vélem felismerni az "érvrendszereitekben"...
    Mutasd a teljes hozzászólást!
  • Hát, szerintem aki olyanokat ír, hogy "a feladatatok 90%-a abból áll hogy megírod a pár tíz soros kis eseménykezel?t a nyomógomb OnClick-jére" az nem nagyon lehet gyakorló programozó az adott eszközzel. Még a leggagyibbnak számító alkalmazásnoknál, mint pl. egy számlázóprogram SEM áll a feladatok 90%-a az eseménykezel?k kitöltéséb?l.


    Attól függ. Egy mezei GUI-orientált progi elkészítésének nagy része azért bizony eseménykezelés és property állítgatás, legalábbis ha jól van megtervezve az adatbázisszerkezet és a user interface. Persze ehhez előzőleg kőkeményen meg kell tervezni a programot, de akkor is így van. Pl. most írok egy nagy ügyviteli programot (ami épp most parkolópályán áll egy pici német munka miatt amit webbrokerrel csinálok) igazán csak a szám->szöveg átalakító osztályom az aki önmagában létezik meg egy generátor érték képző függvény, a többi gyakorlatilag eseménykezelés. Más kérdés hogy egyes események sokszor hívhatnak közös, általános függvényeket.
    Ez egyébként nem baj, pont ez a Delphi/Kylix nagy előnye hogy könnyen és gyorsan kézben lehet tartani a programban lezajló folyamatokat. Én azelőtt csináltam egy viszonylag nagy ügyviteli progit C++/wxWindows párosítással (ez olyasmi mint az MFC csak multiplatform), ott bizony időbe telt amíg eltaláltam az adott form adott elemének valamelyik eseményéhez. Egyébként a Delphi/Kylix fejlődésével csökken is a kézimunka aránya, Pl. anno D1-es és D3-mas programoknál jó sokat szívtam a TempTable/InMemoryTable csodácskákkal, meg hasonlókkal, míg a dbExpress ezeket a dolgokat nagyon leegyszerűsíti.

    Más a helyzet ha picit összetettebb dolgot csinálsz, Pl. multi-tier, webbroker, websnap, ezekhez már picit több programozás kell (különösen a webbrokerhez, a websnappal egész sok mindent csinálhatsz minimális kódolással, csak az a szerver oldali javascript nem igazán szimpatikus nekem).
    Mutasd a teljes hozzászólást!
  • hi,

    A Delphi-ben is van a C "static" módosító kulcsszavával ekivalens szerkezet. A következőképpen kell használni
    const <változó neve>: <tipus> = <kezdőérték>;


    akkor bocsi, ha igy letezik, bar szamomra illogikus, hogy miert const a deklaracioja,
    vaoo, a delphi - ben a logikatlan dolgok is mukszenek!!! (megintcsak bocsi, most genya voltam)

    csa Timna, az elso delphi-s, akit a tudasa alapjan elismerek, hiii

    dj
    Mutasd a teljes hozzászólást!
  • Igaz. Rosszul emlékeztem. Egyébként használható a "var <változónév>:<típus> = <érték>" szerkezet, de csak globális változókra (arra azért kíváncsi lennék, hogy miért van ez korlát, meg arra is, hogy ki volt az az agyament a Borlandnál, aki kitalálta, hogy a "const"-ot kell használni az inicializált változók deklarációjához a "var" helyett). Ja, és a dolog már D5-ben is megy (de lehet, hogy előtte is ment már).

    Ettől függetlenül a C static-jával egyenértékű "const <változónév>:<típus> = <érték>" szerkezet működik. Már a TP-ben is működött.
    Mutasd a teljes hozzászólást!
  • <i>D6-tól úgy tudom már a "var" kulcsszóval is lehet ilyen inicializált változókat deklarálni, bár mivel D6-ot nem haszálok, így ezt biztosra nem mondom</i>
    Nem lehet, megnéztem épp. :)
    Mutasd a teljes hozzászólást!
  • Ahoy all. Icc big szánsájn hír! Felveszem a szemcsit :)

    Én Delphit használok, a C-hez annyira értek, hogy az egyszerűbb kódokat (extra nyelvi elemek, pl template meg ilyesmik nélkül) megértem.
    Rengeteg Delphis ismerek neten keresztül és/vagy személyesen. Szintén sok (bár kevesebb) C programmert ismerek.
    Úgy vettem észre, hogy a Delphi programmerek (ofkoz a tapasztalt vén rókák) sokkal inkább rendszerszemléletűek - átfogóbban, inkább tervezőként vagy szervezőként látnak egy problémát, míg a C programozók afféle hackerként. Mindig a technikai részletek lebegnek a szemük előtt, és a kód rafinált szépsége... Míg én a kódban az abszolút egyszerűséget és egyértelműséget értékelem. Engem a kód "hagyjon békén", hagyjon a problémára koncentrálni.
    Azon kívül, hogy a két nyelv másra jó, ezt a különbséget vélem felfedezni. Ez ismétcsak nem minősíti egyik nyelvet sem, csak rávilágít valamire, amit pályafutásom során tapasztalni véltem.
    Ui: sajna semmi más nyelvben annyi kontárt még nem láttam, mint Delphi alatt. Mindenki azt hiszi, hogy ez már annyira egyszerű, hogy kitt-katt összedob bárki egy alkalmazást. Végülis lehet, de olyan is lesz.
    Mutasd a teljes hozzászólást!
  • Ja, én is C/C++ - os vagyok, nekem állatian hiányzik a lokális statikus változók a Delphi - ben .....

    Na, erre mondom, hogy nehéz úgy _megalapozott_ ítéletet mondani valamiről, ha nem ismerjük...

    A Delphi-ben is van a C "static" módosító kulcsszavával ekivalens szerkezet. A következőképpen kell használni
    const <változó neve>: <tipus> = <kezdőérték>;
    Az így deklarált változó bár csak lokális szkóppal fog rendelkezni, viszont globális adatterületen (és nem a vermen) kerül tárolásra, így a hívási menetek között megőrzi értékét. (D6-tól úgy tudom már a "var" kulcsszóval is lehet ilyen inicializált változókat deklarálni, bár mivel D6-ot nem haszálok, így ezt biztosra nem mondom.)
    Mutasd a teljes hozzászólást!
  • Még mindig nem értem, miért hasonlítjátok össze a Delphi-t és az MSVC-t, azaz a VCL-t és az MFC-t, mivel ezek nélkül kissé nyögve nyelős lenne a fejlesztés windowsra. (és is dolgoztam natív API-ban és messageloop használatával, nehéz volt de legalább megismertem(?!) a windows müködését!!!)
    Már több mint egy éve nyomulnom kell Delphi-ben, ennek tükrében kimerem jelenteni, hogy a VCL a szolgáltatásait illetőleg átlagban gazdagabb funkcionalitású mint az MFC, de a .NET Framework viszont szöröstül-böröstül megeszi a VCL-t oda-vissza, ez a nyers kijelentésem! de nincs alapja az összehasonlításnak, csak gondoljátok végig.

    Ja, én is C/C++ - os vagyok, nekem állatian hiányzik a lokális statikus változók a Delphi - ben .....

    dj
    Mutasd a teljes hozzászólást!
  • Hát, szerintem aki olyanokat ír, hogy "
    a feladatatok 90%-a abból áll hogy megírod a pár tíz soros kis eseménykezelőt a nyomógomb OnClick-jére
    " az nem nagyon lehet gyakorló programozó az adott eszközzel. Még a leggagyibbnak számító alkalmazásnoknál, mint pl. egy számlázóprogram SEM áll a feladatok 90%-a az eseménykezelők kitöltéséből. A fordított arány talán már inkább közel van az igazsághoz.

    A feladatok 80%-ára ugyanúgy alkalmas a Delphi (értsd, egyenértékű megoldás készíthető vele minden szempontból), mint mondjuk egy BCB (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). A maradék 20%-ból meg 10%-ot Delphi-vel, és 10%-ot BCB-vel célszerűbb/gyorsabb megoldani. Persze feltételezve, hogy mindkét eszközt ugyanúgy ismeri a dolgozó.
    Mutasd a teljes hozzászólást!
  • Aki olyanokat ír a Delphir?l, mint Te, az nyilvánvalóan nem ismeri, így talán a véleménye sem mérvadó ebben a témában.

    Na ezzel picit mellélőttél ))). Kb a Delphi 1.0 óta többé-kevésbé folyamatosan Delphi programozából élek (kivéve néhány fél-egy éves megszakítást amikor C++-ból) és mostanság amikor már inkább Kylixozok ha tehetem.
    Amire pedig célozni akartam az pont az hogy mindennek megvan a maga célterülete és ha valaki ettől eltér az bakot lő. Ha valaki ügyviteli szoftvert akar csinálni annak nem a Visual C++ a barátja (sőt, szvsz nem is a C++ Builder) hanem a Delphi/Kylix. Ha valaki adatbáziskezelőt vagy Quake4 engine-t akar írni az szvsz jobban jár C++-szal (bár már láttam Object Pascal-ban írt adatbáziskezelőt is). Az operator overloading, meg a kényelmes multicasting, stb stb, a C++-ban igazán akkor jön jól ha sok szintű, összetett objektumhierarchiát akarsz csinálni. Ez pedig általában nem RAD jellegű feladat. Persze nem mondom hogy Delphiben nem tudod kihasználni az OOP-t, Pl. ha komponenst fejlesztesz. De a tipikus képernyő-orientált progi általában ennél ritkán igényel többet, ő inkább a kész objektumokkal és az adatbázisokkal operál. Persze itt is van az OOP-nek jelentősége, Pl. form öröklés.
    Mutasd a teljes hozzászólást!
  • >a lassulás oka a kismillió header fájl, nem pedig a projekt szervezése (pontosabban ugye én maximum a saját fájljaimat tudom átszervezni, de amit az SDK-ban kaptam azt nem)

    Hm, az SDK-nak mi koze a C++-hoz ?
    Tenyleg tisztazni kene mirol is beszelunk, mert aszem nem azonos a dolog. En Object Pascalrol meg C++-rol. Te mint kiderul komplett rendszerrol beszelsz. Az MFC-t s a Winapit nem all szandekomban minositeni.

    Teny hogy C++-t forditani nem ecceru, s mint ilyen igazad van. De tul nagy nagysagrendi kulonbsegek azonos szerkezetu kodok eseten nem hinnem hogy kellene lenniuk (persze ezt nem egyszeru kiprobalni, leven nem nagyon van egyforma szerkezetu kod, hisz egyik vcl, masik mfc/winapi barmi).
    Mutasd a teljes hozzászólást!
  • Ha lassan fordit az MSVC, akkor a projectben kell keresni a hibat.[/qoute]
    1. minden C/C++ fordító bűn lassú, ez a nyelvből ered
    2. a lassulás oka a kismillió header fájl, nem pedig a projekt szervezése (pontosabban ugye én maximum a saját fájljaimat tudom átszervezni, de amit az SDK-ban kaptam azt nem)
    A lényeg, hogy ekvivalens kódót a Delphi legalább egy nagyságrenddel gyorsabban (ha elég nagy a projekt, akkor kettővel is) fordít le. Aki dolgozott már mindkét eszközzel, az ezt pontosan tudja.
    Mutasd a teljes hozzászólást!
  • A vitat lehetne mondjuk Delphi vs CBuilder-re modositani Delphi vs MSVC helyett.

    Template es operator overloading is eszkozok, megvan a helyuk, ahol hatekonyak, s nem erdemes agyba fobe dobalozni veluk (nem is szokas), viszont a generic programming nehezen menne nelkuluk.

    En sajna nemtok igazan vitatkozni, mert nem ismerem az Object Pascalt, de nem erzem szavaidbol ugy, hogy igazan vegigmasztal volna a C++-os gyotrelmein, s ugy mondanad mi tetszik, mi nem tetszik a C++-ban.

    (rangletra az tudas/tapasztalati szintet akar jelenteni)

    Ha lassan fordit az MSVC, akkor a projectben kell keresni a hibat.
    Mutasd a teljes hozzászólást!
  • esemenyek kezzel bevakarasa: nekem szemely szerint a legjobban .net event-modellje tetszik. ott semmivel sem nehezebb 'kezzel bevakarni' egy esemenyt, mint IDE-bol, es raadasul a kodban is jobban latszik

    Bár leszögezném, hogy nem vagyok gyakorló .NET programozó, csak belekukkantottam még a dologba, de nekem semmivel sem tűnik egyszerűbbnek/könnyen kezelhetőbbnek a .NET eseménykezelése, mint a Delphi-é. A közhiedelemmel ellentétben a Delphi-ben is csak egyetlen sor beírása szükségeltetik egy eseménykezelő egy eseményhez történő hozzárendeléséhez.
    De talán te el tudod mondani, hogy a .NET-ben ez miért és hogyan egyszerűbb...

    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.

    Mondhatnád. Csak a különbség, hogy Te akkor találgatásokba bocsátkoznál (mert pl. nem tudhatod, hogy mivel foglalkoztam), én viszont az itteni, nyilvánvalóan megalapozatlan hozzászólásaid alapján mondtam azt amit.
    Ha Te is tételesen meg tudod mutatni, hogy valahol hülyeséget írtam, akkor OK, de talán nem kellene a gondolatolvasás és a kártyákból kiolvasás révén megszerzett - feltételezett - információkat tényként kezelni ténykedésemmel kapcsolatban.

    az operator overloading valoban okozhat kaoszt is, de sok esetben azert nem art. es most ne csak a ++, /, meg hasonlokra gondoljal, hanem peldaul a cast-ok is operatorok. meg a -> is. ld. auto/smart pointerek. ha szerinted azok nem hasznosak, akkor nem tudom, hogy ez a fogalom szamodra mit jelent.

    Éppen ezért nem is szabad használni a "buta" castot ugyanúgy, ahogy az operator overloadingot sem - már ha tiszta és átláható kódot akar kapn az ember. Az autoptr szerintem más tészta - ott maximum abból adódhatnak problémák, hogy aki használja az nem tudja hogyan is működnek pontosan. A Delphi egyébként az interface-ek segítségével tud hasonló referencia-számolt, automatikusan megsemmisülő objektumokat kezelni.
    A Delphinek egyébként van egy "intelligens" cast-ja is, ami futásidőben végez típusellenőrzést, és ha érvénytelennek ítéli meg a cast-ot, akkor kivételt generál. Ez azért nagy különbség egy hagyományos cast-hoz képest, ahol csak áttételesen észlelhető a hiba, de nem a hibás cast helyén.

    template-k: legyszi, indokold mar meg, hogy szerinted miert csak alacsony szintu dolgokban lenyegesek. te szoktad hangoztatni, hogy milyen tipusos a Pascal (amivel egyebkent egyetertek). ha ezt a tipusossagot ki akarod hasznalni, akkor ugye nem fogsz altalanos ObjectList-et hasznalni, hanem megirod minden tipusra a megfelelo wrapperosztalyt

    Pontosan eltaláltad, hogy mire céloztam. Bizony ebben az egy esetben nagyon hasznos tud lenni egy template, amivel formai értelemben nagyon szépen meg lehet oldani a problémát. Csak, hogy
    1. bár formailag nem annyira szép, de azért egy meglévő kód egy az egyben átmásolása (vágólapon) és benne a típusreferenciák kicserélgetése az IDE replace funkciójával nem tellik órákba (még percekbe sem)
    2. egy kezemen meg tudom számolni, hogy 1 hét alatt hány TList-leszármazottat, vagy olyan osztályt hozok létre, ahol valóban hasznos lenne egy template, mert szebben lenne vele megoldható a dolog
    Pedig - fetételezéseddel ellentétben - nem komponensdobálgatásból áll az életem, hanem sokkal inkább a komponensek készítéséből, API-közeli programozásból, stb.

    A fentiekből az következik, hogy bár a template és az operator overloading hasznos dolgok, valójában a statisztikai átlagot tekintve a feladatok <1%-ában lehet vele csak munkát megspórolni. Így más szempontok sokkal fontosabbak lehetnek a megfelelő eszköz kiválasztásánál egy adott feladathoz.

    azt meg ugy nem mondod komolyan, hogy a c++ azert rosszabb, mert mondjuk ketszer annyi idot kell a forditora varni. a mai gepek teljesitmenye mellett ez elegge hulyeseg. ha ujrabuild-eled az egesz kodot minden alkalommal, akkor persze mas a helyzet, de arrol is meg van a velemenyem, aki ezt teszi.

    Ez nem igaz, hogy ti. a mai gépek mellett nem szempont. Bár nem 3GHz-es P4 ketyeg a gépemben, viszont nem is 500-as Celeron, és bizony legalább 1 teljes (de inkább 2) nagyságrendi különbség van a VC és a Delphi sebessége között. Ez pedig elsősorban a nyelv szerkezetéből adódik. Egy alig pár 10 KB-os kis Symbian alkalmazáson a VC hajlandó akár egy teljes percet is eltökölni a fordításssal (nem build!, make, minimális módosítások után), míg ennyi idő alatt a Delphi kétszer újrafordítja a teljes VCL-lel együtt (!) a több megás alkalmazásomat (na, utóbbi viszont teljes build). Szóval ezeket akár csak hasonlítani is egymáshoz durva dolog...
    Mutasd a teljes hozzászólást!
  • Ha Rad-olni akar az ember VC-vel, akkor Domain Default page 100$, szal nem koltseg (kb ennyibe kerulhet egy MSVC6 is manapsag ha meg lelsz).
    En nem akarok RAD-olni.

    Nezegettem CBuildert, s amiket hianyoltal azt itt lehet meglelni: Visual Assist - a Visual Studio extension by Whole Tomato Software (sztem meg jobb is mint ami a cbuilderben van, kicsit tovabbvittek a dolgot, de persze azert laccik hogy volt honnan otletelni [79$]. Erdemes a legutolso betat nezegetni, mert az mar jobban elbanik a namespace-ekkel es a template-kel)
    Auto ident az jobban teccett msvc style.

    Nezegettem debuggert is, de arra meg nem volt eleg idom hogy kitapasztalgassam. Amit eszrevettem elsore,
    hogy egy sima for ciklust debuggoltam:
    for(int i=0;i<10;i++) { std::cout << i << std::endl; }
    S ha a vegrehalytas magan a for utasitason allt, akkor a debugger az i valtozora azt mondta, hogy nem letezik (gondolom azt feltetelezte, hogy kivulrol nezem a ciklust). Akar meg elfogadhato is lenne a dolog, csak azert nem a legpraktikusabb a dolog debug szempontbol.

    Van help a trialhoz, de az MSDN azert sokkal jobb (lehet hogy a boltiban jobb help van).

    Majd meg jatszadozom vele.


    A C++-os elit dologhoz csak annyit tok szondani, hogy a C++-osok kozt is vannak elvakultak ala linux, s vannak akik ertenek hozza azert osztjak az iget. Elobbiekre nem kell odafigyelni, utobbiak meg jo esetben eszerveket sorolnak fel (sajna sokat tanult embereknel megfigyelheto a szukszavusag, hisz pl. konyvekben sok tudas van, s hamar meg lehet unni, hogy egyesek lustak nekiugrani elolvasni par ezer oldalt magyarul/angolul = RTFM).
    Mutasd a teljes hozzászólást!
  • esemenyek kezzel bevakarasa: nekem szemely szerint a legjobban .net event-modellje tetszik. ott semmivel sem nehezebb 'kezzel bevakarni' egy esemenyt, mint IDE-bol, es raadasul a kodban is jobban latszik. de szamomra a c++ megoldasai sem zavarnak nagyon (akar sima WinAPI-val, MFC nelkul sem), ha ez ember hozzaszokik, akkor a kezdeti kenyelmetlensegek utan ugyanolyan gyorsan meg tudja csinalni ezeket.

    ..

    Aki olyanokat ír a Delphiről, mint Te, az nyilvánvalóan nem ismeri, így talán a véleménye sem mérvadó ebben a témában.

    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.

    ..

    az operator overloading valoban okozhat kaoszt is, de sok esetben azert nem art. es most ne csak a ++, /, meg hasonlokra gondoljal, hanem peldaul a cast-ok is operatorok. meg a -> is. ld. auto/smart pointerek. ha szerinted azok nem hasznosak, akkor nem tudom, hogy ez a fogalom szamodra mit jelent.

    template-k: legyszi, indokold mar meg, hogy szerinted miert csak alacsony szintu dolgokban lenyegesek. te szoktad hangoztatni, hogy milyen tipusos a Pascal (amivel egyebkent egyetertek). ha ezt a tipusossagot ki akarod hasznalni, akkor ugye nem fogsz altalanos ObjectList-et hasznalni, hanem megirod minden tipusra a megfelelo wrapperosztalyt... ugyanigy a map-eket. meg a teljes STL-t. nem hiszem, hogy valaha is volt olyan Pascal fejleszto aki vette volna a faradtsagot.
    ugyanez persze vonatkozik minden mas nyelvre is, ami nem tamogatja a generikus programozast (Java, c#, amik legalabb annyira tipusosak), es ott is rohadtul hianyoznak. persze meg lehet kerulni altalanos tipusokkal oket, de az nem az igazi.

    azt meg ugy nem mondod komolyan, hogy a c++ azert rosszabb, mert mondjuk ketszer annyi idot kell a forditora varni. a mai gepek teljesitmenye mellett ez elegge hulyeseg. ha ujrabuild-eled az egesz kodot minden alkalommal, akkor persze mas a helyzet, de arrol is meg van a velemenyem, aki ezt teszi.

    ..

    Btw. csak nekem van az az érzésem, hogy a C++ programozók is kicsit úgy vannak mint az átlag Linux-felhasználó, hogy ti. függetlenül tudásuktól, ismereteiktől csak attól tekintik magukat magasabb rendű "kasztba" tartózónak, amit használnak? Mert engem sokszor ez az érzés kerít hatalmába amikor ilyen emberekkel beszélgetek. Aztán általában kiderül, hogy azt amit kritizálnak (Windows, Delphi, VB) nem is ismerik eléggé, és a "feladathoz az eszközt" (ti. hogy nincs egyetlen tökéletes megoldás minden feladathoz, hanem a feladat típusától függően lehet egyik v. másik megoldás előnyösebb, mint a többi) elvvel sincsenek igazán köszönőviszonyban.

    pontosan errol pofaztam mar az elejetol fogva. megfelelo feladathoz a megfelelo eszkozt. amit ugy latszik nem ertettel meg, hogy szamomra az altalanos feladatok kozott csak minimalis szinten van UI birizgalas (eddigi projektjeimben idoaranyosan 15%-ban volt ilyenre szukseg, es ott sem azon volt a hangsuly, hanem az alatta levo logikan). ahogy tejfel is mondta: neki sem, es nekem sem a vizual resze a fontos. es azt sem tartom feltetlenul igaznak, hogy az atlag-feladatoktol nagyon elterne a mienk, hiszen eleg sok cegnel voltam mar viziten, es keves olyat lattam, hogy valaki UI-t turkalt volna.

    mellesleg az atlagos c++ programozok(-nak mondott) <-> linux felhasznalok osszehasonlitasa mogotti meggondolasoddal egyetertek, nekem is ez a velemenyem, hogy az ilyenek - ok nelkul - magasabbra tartjak magukat. csakhogy ezeket nem igazan tartom programozoknak. aki csak a c++-t ismeri, az a c++-t sem ismeri, legalabbis nem lattam meg olyat, aki igazan jo volt c++ alatt, es ne ismert volna meg legalabb 3-4 nyelvet eleg magas szinten (altalaban a Java es az Obj. Pascal benne volt). es raadasul egyik sem mondta azt, hogy a c++ a tokeletes nyelv. valoban sok hibaja van, de ha az ember ismeri ezeket, es vigyaz arra, hogy mit csinal, akkor egyutt lehet elni vele, es akkor egy eleg massziv eszkoz lesz a kezeben. en szemely szerint szivesen elfelejtenem a c++-t es a Delphi-t is, es csak Java/c#-ban dolgoznek, csak hat a nyilvanvalo teljesitmenybeli korlatjuk jelenleg meg nem engedi meg minden feladatnal.

    sztupi
    Mutasd a teljes hozzászólást!
  • Szerintem te teljes félreértésben vagy a dolgok lényegét illetően. Egy jó RAD eszköz (amilyen a Delphi is) csak megkönnyíti a munkát, de nem írja meg helyetted a programot. A feladatok 90%-a egy RAD eszköz használata esetében sem abból áll, hogy megírom az OnClick eseménykezelőt. A különbség csak annyi - szemben egy hagyományos Pascal v. C++ eszközzel -, hogy az eseménykezelő hozzárendelését, az ablakok elrendezését, stb. nem kell kézzel keservesen bevakarnod, hanem pillanatok alatt vizuálisan megszerkeszted. Ez jelentős könnyebbséget jelent a fejlesztésben, amiért a Delphi-ben nem kell semmilyen más területen megfizetned, mert utóbbi a VB-vel szemben nem a RAD IDE köré szerveződik, és teljes szabadságot biztosít neked a kód szerkesztése, szervezése, és az implementáció terén is.

    Aki olyanokat ír a Delphiről, mint Te, az nyilvánvalóan nem ismeri, így talán a véleménye sem mérvadó ebben a témában.

    Egyébként a szubjektumokra visszatérve: az operator overloading nem olyan hasznos dolog, mint amilyennek elsőre tűnik (nagyon kevés esetben spórol csak munkát vele az ember, a másik oldalon viszont könnyen értelmezhetetlen kódhoz juthat vele), és hasonló dolog a template is. A kettőt közül utóbbit még valóban hasznosnak is tartom, bár azt szintén le kell szögeznem, hogy nagyon ritkán és alapvetően viszonylag alacsony szintű (nem bonyolultságát, hanem a kódok rétegezettségét tekintve alacsony szintű) feladatok esetén van gyakorlatil jelentősége. Ezzel valóban munkát lehet megsprórolni, viszont ha hozzászámítjuk, hogy mondjuk egy C++ fordítóra mennyivel többet kell várni ugyanannak a kódnak a lefordításához, mint a Delphi-re, akkor már nem biztos, hogy valóban spórolást jelent a C++.

    Én egyébként nem akarok senkit meggyőzni arról, hogy Delphi-t használjon. Ha neki jobb a C++, akkor használja azt! De valótlanságokat már ne állítsunk a Delphi-ről!


    Btw. csak nekem van az az érzésem, hogy a C++ programozók is kicsit úgy vannak mint az átlag Linux-felhasználó, hogy ti. függetlenül tudásuktól, ismereteiktől csak attól tekintik magukat magasabb rendű "kasztba" tartózónak, amit használnak? Mert engem sokszor ez az érzés kerít hatalmába amikor ilyen emberekkel beszélgetek. Aztán általában kiderül, hogy azt amit kritizálnak (Windows, Delphi, VB) nem is ismerik eléggé, és a "feladathoz az eszközt" (ti. hogy nincs egyetlen tökéletes megoldás minden feladathoz, hanem a feladat típusától függően lehet egyik v. másik megoldás előnyösebb, mint a többi) elvvel sincsenek igazán köszönőviszonyban. (LC - ezt az utóbbi bekezdést ne vedd személyesen! Csak éppen most jutott eszembe... )
    Mutasd a teljes hozzászólást!
  • Szvsz hibás az összehasonlítás. A C++ és a Delphi teljesen másra való. A C++-t az ember elsősorban nem GUI-orientált dolgokra használja (adatbáziskezelő, Office csomag, stb). A Delphi-t pedig inkább RAD-orientált dolgokra, Pl. ügyvitel. A Delphi a C++ és a vizuális bézik között van, azaz egy jó kis általános dolog amivel sok mindent meg lehet csinálni, nem annyira bonyolult a lelkivilága mint a C++-é de nem is annyira primitív mint a VB. Én egyébként mind a C++-t, mind a Delphi-t elég sokat használtam/használom ma is, szvsz RAD jellegű feladatokra az Object Pascal kényelmesebb. Az olyan szépségeknek mint az operator overloading, template, stb úgy sem vennénk túl sok hasznát egy RAD-ban ahol a feladatatok 90%-a abból áll hogy megírod a pár tíz soros kis eseménykezelőt a nyomógomb OnClick-jére.
    C# ezt én is csak most tanulom, csak sajnos nagyon kevés időm van rá. És én inkább a mono-val foglalkozom ami a .NET szabad változata.
    Mutasd a teljes hozzászólást!

  • Némi derültséggel olvastam végig a topic-ot, mert már nagyon sok ilyen megnyilvánulás van láttam.

    Előre leszögezném: én C/C++ párti vagyok és mostmár C# is,
    de használok delphi-t is (igaz kényszerből ...)

    az szinte biztos, hogy könnyebb C/C++ - ról átállni delphi-re, mint fordítva ...

    Szinte kizárólag winfos környezetben és környezetre dolgozok,
    ennek fényében a hozzászólásom:

    szerintem önmagában egy prg. nyelv már nem túl lényeges szempont a választásnál,
    a lényeges dolog inkább a hozzáadott objektumkönyvtár és ez az,
    ami lenyegesen meghatározhatja egy fejl.környezet "jóságát".
    anno valamikor idegenkedtem az MFC-től, mert én még API-n nevelkedtem
    és kirázott a hideg, ha nem tudtam, hogy mi zajlik le a háttérben egy függvény hívásakor,
    aztán átrágtam magam az MFC-n és ma már problem nélkül használom minden részét.
    akkoriban nagyon tetszet az MFC, átgondolt, jól megtervezett objlib. - nek tartottam,
    ma már tudom, hogy ez így teljesen nem igaz ...
    majd megismerkedtem a VCL-l, nagyon tetszett, mert nagyságrenddel jobbnak tartottam,
    mint az MFC-t a kézreállás és a megoldások szempontjából.

    és most itt nem akarom összehasonlítani a VCL-t és az MFC-t, mert nem egy KATEGÓRIA!
    a VCL még pajzán gondolat sem volt, amikor a programozók már használták az MFC-t termékek készítésére,
    és alapvetőleg már magasabb tudási szintről indult a VCL fejlesztése, mint a MFC-é valamikor.

    és most a .NET Framework, véleményem szerint kenterben ver ezen a szintem minden objektum könyvtárat,
    a megalkotásával a Microsoft óriási dolgot hajtott végre, és ami részemről nem kérdés,
    ebből óriási haszna lesz a közel és a távoli jövőben a számára.
    igazából szerintem a .NET Framework már nem is egy egyszerű objektum könyvtár,
    ez már azon jóval túl mutat, ezek az egységek már beépülnek mélyen a rendszerbe.
    nagyon teszik az, hogy már minden egyes alkotó eleme objektum, az eddigi alaptípusok, mint pl. az int,
    már objektum, végre megértük ezt is ...

    C#:
    fantasztikus nyelv, sokkal magasabb tudással rendelkezik, mint a pascal, delphi vagy a C/C++,
    sokkal jobban követi a programozó gondolat menetét mint a más (általam ismert) nyelv, pl:
    - ha egy critical section-t akarok, akkor már nem kell a függvényekkel operálnom,
    hanem a szükséges blokra egyszerűen a lock-t adom meg ....
    - külön-külön lehet védett és nem védett blokkokat megadni, unsafe
    - foreach, no comment ...
    - stb, stb ...

    és ezek nem a .NET Framework által adott tulajdonságok, ezek a nyelv saját jellemzői!!

    persze a VCL-t és a .NET Framework-őt, valamint a C# és a delphi-t szintén badarság összehasonlítani,
    tegnap még nem volt alapszéria a légzsák, ma már igen az autókban.

    mindenki használja azt a nyelvet a feladatainak a megoldására,
    amelyet tapasztalati úton a legjobbnak talál az adott feladat megoldására,
    valamit amit előírnak neki!!! (legtöbbször sajnos a kettő nem egyezik meg!!!)

    Mutasd a teljes hozzászólást!
  • ilyen (es vszinu barmilyen) korulmenyek kozott asszem mindegy, melyik nyelvet valasztottad.
    talan a harom kerdes helyett inkabb azt kellett volna kerdeznem, mennyire erdekel, mennyire akarsz programozni, fejleszteni.

    amikor eszel, egyel
    amikor alszol, aludj
    amikor programnyelvet tanulsz, programnyelvet tanulj

    megirigyelhetnenek az oreg zen mesterek... hehe...
    Mutasd a teljes hozzászólást!
  • Jogos a felvetés de:
    .... nem akarok tanár lenni!!!!!! azért járok ide mert a gimi után 7évet elcsesztem és rájöttem hogy KELL egy (vagy több) diploma!Ezt volt az egyetlen egyszakos számteches levelező szak.
    Egyébként a hírek szerint majd lehet szakosodni:
    műszaki infó, gazd infó, vagy tanári szak. Mint írtam nem az a fő cél hogy tanár legyek, gazd infót tanultam a Számalkon (nagy ívben elekerülni azt a sulit) és baromira megutáltatták a járulékos tantárgyakar (számvitel, statisztika, stb) marad a műxaki!!!! A C mellet a részemről az szól hogy mint írtam a meló helyemen nagyon jó C programozók vannak, akiktől azt hiszem hogy lehet tanulni (Kedves Kollégák ez nem a segggnyalás helye! :))) már ha olvassátok ezt).
    Mutasd a teljes hozzászólást!
  • Hat nem tudom. ebben a helyzetben en Delphi-t tanulnek. Nem tartom vszinunek, hogy estin egy tanarkepzon olyan szinten tanitananak, mint ahogy azt te gondolod. Inkabb jatek lesz az. Nem leminositeni akarom igy latatlanban a fosulit, csak roszak a tapasztalataim. Masreszt meg tanar leszel. Gondolom a sracoknak is akarod majd tanitani. Arra meg alkalmasabb a Delphi. Bar a fene tudja, ha nem gimiben akarsz majd tanitani, akkor en a LOGO-t tanulnam
    Mutasd a teljes hozzászólást!
  • 3 válasz, Law
    - Berzsenyi D. Tanárképző F., Szombathely (levelező)
    -, hát ez jó kérdés!!!!!! Én is csak remélem ,hogy jó tanár fog tanítani jól!(na ez szép mondat volt) Bár (remélem az illetékesek nem olvasák) eddig egy-két előadástól eltekintve csalódás............
    - érdekel a programozás, Pascalt tanultam és szerettem is, de aztán nem használtam. Szeretnék programozni is akár idővel, bár ehhez nagyon nagyon sokat kell még tanulnom. Egyébként jelenleg rendszergazdaként dolgozom.
    Köszönöm az eddigi hozzászólásokat, nem gondoltam, hogy kisregényeket olvashatok a témában :))))))))))))))). Már tudom, hogy mit fogok választani, de még nem árulom el, nem akarom befolyásolni az esetleges hozzászólókat.
    Mutasd a teljes hozzászólást!
  • Ami azt illeti én már megtanultam egy pár nyelvet (Pascal,Assembly,C/C++,Delphi,Fortran) ebben a sorrendben. Én is azt tudom neked javasolni hogy előbb inkább a C/C++ -t tanuld meg és utána a Delphit. A Delphit szerintem is sokkal könnyebb megtanulni, ellenben elkényelmesíti a programozót.
    Mutasd a teljes hozzászólást!
  • 3 kerdes, takoca:

    - melyik foiskolarol van szo?
    - milyen szinten tanitjak a ket nyelvet? (ha klikkeljunk a File/New application... menupontra, akkor tok mindegy, mit valasztasz)
    - mihez akarsz kezdeni a megszerzett tudasoddal? vagyis mit akarsz csinalni az 'ELET'ben (hehe)
    Mutasd a teljes hozzászólást!
  • az oke, hogy az SDK nem a fordito tudasa, de igenis fontos, hogy mennyi nativ dolog van a nyelvhez - a Java es a .net semmit sem erne az sdk ill. a framework nelkul, azonkivul nagy elony a jopar plusz free cucc, ami kijott hozzajuk (pl. jakarta, aspectj, prevayler), amik annyira nem trivialis dolgokat oldanak meg. persze ez c++ es delphi kozott nem olyan lenyeges, mint mas nyelvek eseteben, hiszen ha ugyanazon a platformon hasznaljuk, akkor tobb lehetoseg van az atjarasara (bar azt megnezem, hogy hogyan hasznalsz egy olyan c++ libet, ami osztalyokat is exportal).

    ..

    freepascal: lehet, hogy akkor en nem ezt lattam. anno linuxon volt egy gnu-s pascal fordito package(talan gpc, vagy valami ilyesmi), arra gondoltam. az biztosan nem tudott ilyeneket, azert nem is hasznaltam.

    ..

    ha szerinted egy fejlesztes soran a make-file csak a forditast vegzi, akkor meg nem lattal eleg nagy es osszetett projektet: extrem eset ugyan, de nezd meg mondjuk egy linux kernel-hez adott make rendszert. nem olyan trivialis...

    ha pedig ugy gondolod, hogy a Delphinek a build szervezese mindent megcsinal, amire egy fejlesztonek szuksege lehet, akkor eloszor latogasd meg az Apache Ant - Welcome odalt, nezd vegig, hogy mit tud a kutyu (es milyen task-jai vannak), hasonlitsd ossze a kettot, es utana mondj velemenyt.

    ..

    a hello world-hoz c++-ban sem kell vegigolvasni nyolc lexikont.

    ..

    amikor azt mondtam, hogy nem GUI-s alkalmazas, akkor nem feltetlenul konzolosra gondoltam. inkabb mondjuk egy service-re, egy lib-re, egy framework-re. esetleg OpenGL/DX-re. sok olyan dolog van, ami mar tulmutat az IDE hataskoren, es olyankor elvreszted az elonyeit (azt nem mondtam, hogy ez hatrany, csak azt, hogy amiket en altalaban irok, ott nem lehet kihasznalni az altalad felsorolt elonyoket -> nem ezt hasznalom, hanem olyan nyelvet, aminek az elonyei a legjobbak az adott feladatra).

    a komponens-alapu programozasnak valoban hatalmas elonyei vannak, de a property-k vizualis beallitasat nem sorolom kozejuk. kenyelmes, az lehet, de semmivel sem hasznosab, mintha kodbol csinalnam.

    ..

    aruld el, hogy szerinted a template-k (avagy a generikus programozas) miert ellentetes a szigoru tipusossaggal? nezd meg az Ada-t. na az az igazan tipusos nyelv (imadtam is annak idejen, komolyan!), meg a Pascalnal is erosebben. megis van benne generic, op.overloading, es nagyon is beleillik.

    ugyanigy, miert ne lehetne const pascal-ban (marmint tagfuggveny minosites)? ha pl. egy framework-ot probalsz osszehozni, rengeteg szivast (amit a kepzetlen / lusta / hekker programozo okoz, aki hasznalja a rendszeredet) el tudsz kerulni vele.

    egyebkent meg a c++ is elegge tipusus nyelv, bar tenyleg van egy-ket olyan megoldasa, amit nem szeretek, pl. enum == int, nincs subtype, _minden_ operator overloadolhatosaga, meg meg par ilysmi dolog, amiket felaldoztak a hatekonysag oltaran.

    ..

    a for == a while ciklussal, mi olyan kulonleges benne? egyebenkent meg while cikluson kivul mas nem letezik.

    a template-k viszont igenis fontosak. sokkal kulturabb dolog szerintem pl. Map<Akarmi,SpeciObject>-et hasznalni mindenfele iteratorokkal, mint mindent StringList / ObjectList-tel tarolni. meg lehet oldani ugy is, de az STL nagysagrendekkel konnyeben hasznalhato eszkoz, es _tipusosabb_ lesz a megoldas

    ..

    Ezeknek a komponenseknek a minősége nem a fordítót/nyelvet minősíti, így nem értem miért jön egyáltalán fel itt ez a dolog. Szar kódot minden nyelvben lehet írni.

    nem a delphit akartam minositeni, ha ugy tunt, akkor bocs. csak azert mondtam, mert mas forumokon folyton ezzel probaltak meggyozni.

    ..

    1. talán várjuk meg mi lesz belőle mielőtt nyilatkozunk. szerintem egyébként simán megcsinálhatják a mostani osztályokat, mint wrappereket a .NET köré, és simán fordítható lesz a mostani Delphi kód alatta is. persze nem minden módosítás nélkül, de a lényeg, hogy csak apró finomításokat kell majd végezni. ez egy portolásnál normális

    ha megcsinaljak, akkor ugyanugy lehet hasznalni barmilyen mas nyelvbol is, nemcsak delhpi.net-bol, hiszen meg kell felelnie a CLS-nek. ennek ellenere nem hiszem, hogy lenne ertelme, mert a .net fw szerintem egy nagysagrenddel atgondoltabb, mint a vcl, es joval tobbet is tud.

    2. a mai fordítókban már eleve nem a nyelv számít, hanem az amit köré építenek. az RTL, a standard könyvtárak és az IDE az ami _elsősorban_ meghatározza, hogy egy adott feladatra egy adott eszköz mennyire jól használható. Nem pedig az, hogy milyen nyelvi szerkezettel írunk le egy ciklust, vagy egy elágazást.

    igen, de a keretrendszer joval tobbet szamit, mint barmilyen IDE. Java-t is lehet notepad-bol bogaraszni, nem az a lenyeg, hogy milyen editort hasznalok, hanem pl. a Reflection API, az i18n support, az RMI =, meg ilyen finomsagok, a j2ee-rol nem is beszelve. ugyanezek .net alatt is megvannak persze.

    3. a C# szvsz semmi extrát nem tud bármilyen más nyelvhez képest, ami nem a .NET-ből adódik. Magyarul bármilyen más nyelv amit a .NET-hez igazítanak pontosan ugyanolyan jó lesz meghajtani azt. A tudást nem a nyelv adja, hanem a kiterjedt .NET kódbázis alatt. Ez egyébként ugye összecseng a 2. pontban írottakkal.

    jelenleg a c# az egyetlen nyelv tudomasom szerint, ami a clr legbovebb lehetoseget engedi kihasznalni mas nyelvekhez kepest (ld: deletgate / event model, indexer, op. overloading, a using statement, unsafe / fixed ). ha a delphi.net is mindezeket nyujtani fogja, akkor oke, nem lesz hatekonysagbeli kulonbseg. de az mar akkor sem lesz ugyanaz a delphi.
    masreszt a Java sem tud semmi extrat, csak ami a JVM-bol adodik. a c++ sem tud semmit pluszt az alarakott proci utasitaskeszleten tul...

    sztupi
    Mutasd a teljes hozzászólást!
  • Hali!

    Én is személy szerint a c++ -t prefelálom , de szerintem az a legjobb ha mindegyiket tudod és eltudod dönteni, hogy az adott feladathoz melyik jobb.Most a c++-t tanuld és aztán a Delphit, mert az utóbbi szerintem könnyebb 1 picivel.Én könyvekből tanulom mind a kettőt és higgyél nekem, a Delphi 5 Mesteri Szinten sokkal érthetőbb könyv, mint amikor Bjarne Stroustrup elkezd a C++ Prog. Nyelv könyvében elvont és elméleti dolgokról zagyválni(persze, tudom, hogy ő írta a nyelvet és hogy sokkal okosabb, de hát egy kezdőnek elég rémisztőleg hat).

    Magyarul:szetintem, most a c++ -t válaszd, hogy azt ott rendesen magyarázzák el, és aztán a Delphit könyvből(vagy bárhogyan)megtanulni nagyon könnyű lesz.

    Remélem tudtam segíteni.
    Mutasd a teljes hozzászólást!
  • Maradva az eredeti kerdesnel.

    En szemely szerint a C++-ot javallanam. Az en programozoi logikamnak sokkal jobban megfelel mint a Delphi. En ugy erzem, hogy a C++-on keresztul az ember tisztabban ertheti meg a programozas mikentjet es hogyanjat. C-re ez meginkabb igaz, csak azt egyre kevesebbet hasznaljak. Szerintem a C/C++ sokkal kozelebb visz a hardware-hez mint a Delphi. Az OOP tekinteteben pedig a C++ nekem jobban tetszo erthetobb modellt ad, mint a Delphi. De hogy tisztabbat az biztos. Masreszrol a C++ raszoktat olyan dolgokra, amiket alapvetoen mindenhol hasznalni kene, de vannak kornyezetek, ahol nem szukseges (memoriakezeles).

    En annak idejen utaltam, hogy a Pascal-t meg a Delphit nyomattak nekunk. Persze erre mindenkor volt magyarazat, hogy tipusos, meg szigoru, meg egy kezdonek ez kell, viszont ez raszoktat arra, hogy mindig a kesz megoldast keres. Ezzel szemben a jo programozo (szvsz) ugyanarra a dologra, min. 2 megoldast tud.

    En kezdokent is konnyeben tanultam a C/C++ -t mint a Delphit. Hamarabb is jutottam benne ertelmes eredmenyre.

    A C++ mint nyelv szabadabb. Sokat remisztgettek annak idejen a pointer-ekkel, de nekem mindenkor egy teljesen magatol ertheto dolog volt. Sok emberrel talalkoztam, aki programozonak mondja magat; akik nem igazan ertettek meg a pointerek mibenletet. Ez szerintem egy nagyon alapveto dolog, bar egyre kevesebb szukseg van ra.

    Es egy kerdes. Lassan eljutottam oda, hogy a C-t es a C++-ot ket teljesen kulonbozo nyelvnek tekintsem. Igazabol csak szintaktikaban hasonlo a ketto, valojaban 2 !nagyon! kulonbozo nyelv.
    Mit gondoltok?
    Mutasd a teljes hozzászólást!
  • >Ebben nem egyezik a véleményünk. Szerintem egy megenged&#245;bb, "kiskapukat" nyújtó, rosszul karbantartható forráskód létrehozását támogató nyelv kevésbé jó programozókat nevel ki, mint egy szigorú, er&#245;sen konvenciókra épít&#245; nyelv. Ebben a relációban pedig a C++ az el&#245;bbi, és a Delphi az utóbbi.

    En tovabbra is fenntartom az allitasom. Nem hiszem hogy a nyelv az elsodleges ami befojasolja hogy milyen programozo lesz egy kezdobol. Persze itthon eleg korlatozottak a lehetosegek, de ha vki megtanult angolul, akkor a neten mar sok info van, vagy erdemes konyveket venni.
    S habar C++-ban megtanulni programozni kemeny dio, meg mindig lehet C-ben, amiben mar kicsit konyebb (teny hogy sok benne a hibalehetoseg).
    Autodidaktan sztem konyvekbol erdemes tanulni (sokszor sok ev tapasztalata van egy konyvben, erdemes belefektetni az energiat olvasasukba).

    Aki meg tessek lassek alapon akar megtanulni programozni, annak a stilusan egy nyelv kenyszerei
    sem igazan tudnak segiteni.


    En amugy C++ parti vagyok, ugy erzem tobb helyen el lehet adni mint a Delphit.

    (ui: Delphi-vel sincs amugy semmi bajom, de nem
    vagyom olyan munkara amit azzal lenne legcelszerubb megcsinalni)
    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