Delphi VS C++
2002-10-28T22:01:19+01:00
2002-11-19T15:05:21+01:00
2022-07-27T21:31:51+02:00
  • > Eddig MWindows alá fejlesztettem VS C++-ban. Szeretnék áttérni a Linuxra. Van ehhez is valami hasonló C++ fejlesztõi környezet? Ha igen mi és hol lehet beszerezni.

    Ha nem akarsz Borland fuggove valni, akkor ajanlom a kdevelop-ot.
    A cross-platform IDE for C, C++, Python, QML/JavaScript and PHP
    Mutasd a teljes hozzászólást!
  • Kylix 3, az open edition ingyen letölthető a borland honlapjáról. Egyaránt lehet benne c++ és delphi nyelven programozni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Eddig MWindows alá fejlesztettem VS C++-ban. Szeretnék áttérni a Linuxra. Van ehhez is valami hasonló C++ fejlesztői környezet? Ha igen mi és hol lehet beszerezni.
    csákó
    Mutasd a teljes hozzászólást!
  • Akit érdekel, van olyan hogy C++ Builder...
    Olyan mint a Delphi, csak C-ben, szal jobb.
    Mutasd a teljes hozzászólást!
  • bocccccccs:
    'y' helyett 'i'-vel írtam a neved...
    na üdv mindenkinek: Czappa G
    Mutasd a teljes hozzászólást!
  • Dinarnixnek, raptornak és persze mindeni másnak
    aki segített köszönöm. Asszem megnézem a developert és a Chip-et is.
    Üdv mindenkinek: Czappa G
    Mutasd a teljes hozzászólást!
  • keress mar meg pls. titkos a mailed...
    Mutasd a teljes hozzászólást!
  • nem azt mondtam, hogy nem hasznalhato, hanem csak annyit, hogy jelenleg van olyan kutyuje az 'ellenplatform'-nak, amit en hasznalhatobbnak talalok, es csak azert nem fogok atterni a #devel-re, mert az c#-ban keszult. (pedig egyebkent nem vagyok egy kimondott Java fan).

    a sajat projektfile-rol: lehet, hogy en nem hasznalom, de mas igen, es roppant idegesito, amikor a sourceforge-rol leszedett projekthez nincsen mas build file, mint egy .cmbx (asszem ez a neve). basszus, annyira nem maceras megirni egy (n)ant filet. az .sln-ekkel azert nincs olyan nagy bajom, mert slingshoton keresztul a nant megeszi.

    esemenykezeles: na ez pont az egyik olyan dolog, amit szeretek kezzel csinalni, es nem tetszik, amikor az IDE berakja a kod olyan helyere, amire nem is gondolok, ha keresgelem.

    na mindegy, ez csak a pszichozisom eredmenye, de egyebkent tenyleg egesz jo a #develop.

    sztupi
    Mutasd a teljes hozzászólást!
  • A form editor használata opcionális. Projectfájlt meg valamilyet csinálnia kell minden IDE-nek (elvégre valahonnan tudnia kell hogy az adott fájl része-e a projectnek van nem) de ez is választható, nem kell feltétlenül projectet használnod, nyitogathatsz / fordítgathatsz vele fájlokat is. Az meg hogy szívességből megcsinálja a formodat is szerintem külön pozitívum, még jobb lesz ha majd eseményeket is lehet vele kezelni. A lényeg hogy ami a végén kijön az tiszta C# kód (azaz nem valamilyen saját frm vagy más fájlból szedi a property-k értékét).
    Mutasd a teljes hozzászólást!
  • mar lattam a #developot, de maradt a jEdit. az ugya csak egy egyszeru editor, de a fejlesztesi munkat nagyon tamogatja. nekem nem kell olyan IDE, aminek nem hordozhato az outputja (peldaul a projektfile (vagy combine, asszem az volt a neve) vagy az, ahogy a Form editor-nak az adatait tarolja, es meg volt par ilyen nyigom vele).

    masik: a jEdit-nek ami az elonye, az a - nekem legalabbis nagyon szimpi - plugines rendszer, eleg jol ki van talalva, konnyu sajat dolgokat hozzavagni, ha szeretnel.

    nagyon szeretnek latni valami hasonlot .net ala is, de amikor keresgeltem a sourceforge-on meg hasonlo helyeken - ez ugy 1-2 honapja volt -, nem nagyon lattam semmit.

    sztupi
    Mutasd a teljes hozzászólást!
  • Végül is tökmind1 mi a neve, a lényeg hogy a felület, a CLX, a Pascal, C++ megmaradjon, ha mellé még bejönne a C# az külön jó, pláne jó lenne ha mindez linux alól is elérhető lenne...
    Mutasd a teljes hozzászólást!
  • Időközben kiderült, hogy Delphi.NET nem lesz. Borland-os .NET fejlesztőeszköz persze lesz, csak nem Delphi.NET-nek fogják hívni, hanem valami másnak (egyelőre nem tudni minek), és lehet majd Delphi meg C++ nyelven is "hergelni". (Kb. úgy ahogy a Kylix-ot is Kylix-nak hívják, és van benne Delphi és C++ front-end is.)

    Legalábbis ezt hallottam megbízható forrásból...
    Mutasd a teljes hozzászólást!
  • A világ a saját tükörképe alapján műkszik: ha azt mondjuk, nem lesz Delphi és irány a Java, akkor nem lesz Delphi. Ha maradunk a Delphi mellett, akkor lesz Delphi (hacsak a Borland valamit alaposan el nem izél).
    Mutasd a teljes hozzászólást!
  • Delphi akkor is lesz, már készül a Delphi .NET, sőt állítólag a mono project segítségével a linuxos Kylix is tud majd .NET-et.
    Mutasd a teljes hozzászólást!
  • Akkor szvsz nézd meg a sharpdevelop-ot a sourceforge.net-en.
    Mutasd a teljes hozzászólást!
  • nem mondom, en is lattam mar nagyon popecul megirt HTA-t, de akkor se bizok meg egy JScript kodban. script-nyelvekben a gyenge tipusossag miatt es az interpretaltsag miatt (is) valoban gyorsan lehet fejleszteni, de pont ezek miatt rengeteg hibalehetoseg van (az erosen tipusos nyelvekkel szemben), ami egyszeru alkalmazsoknal esetlegesen meg belefernek, de ugyviteli rendszert... hat, en biztos nem biznek benne olyan nagyon.

    ..

    a .net interpretalt? ha arra gondolsz, hogy byte-kod alapu, amit (legalabbis ngen hasznalata nelkul) runtime fordit le nativ kodra, az igaz, de nem folyamatosan, hanem kodreszenkent egyszer, utana mar az elore forditott kodot futtatja. es egyebkent is, mar a forassbol az MSIL-re forditas kozben _is_ optimalizal - foleg a managed c++ fordito -, bar ennek lehetnek elvileg hatranyai is, de amig nem nagyon multiplatform, addig nem valoszinu.

    szoval nem egeszen ugyanaz a helyzet, mint scriptnyelvek eseteben

    ..

    tenyleg eleg lenne egy editor a .net-es fejlesztesekhez, mazochizmus nelkul is - csak nem nagyon van normalis (en meg mindig az 'ellenseg' jEdit-jet tartom a leghasznalhatobbnak). a VS.NET text editornak kisse draga, masra meg nem nagyon hasznalnam. nem vagyok oda a klikkelgetos, wizardos dolgokert, foleg .net alatt nem, hiszen szinte mindent meg lehet mar csinalni kodbol is, max 10%-os idoveszteseg aran (ami egyre javul, ahogy belejon az ember).


    sztupi
    Mutasd a teljes hozzászólást!
  • így sok dolgot inkább java-ban írnak meg akkor is ha lassabb, [...] így ha mondjuk 10 év múlva már nem lesz x86 és win akkor sem kell az egészet újraírni, míg egy win32 API-ra alapozott VC6-os programra ezt már nem biztos hogy el lehet mondani.


    En is pont ezt mondom, es nem azt, hogy ugyviteli programot VC6-ban kell irni. Ha 10 ev mulva mar nem lesz x86, akkor a mai delphi programok sem lesznek. Ha hosszu tavra terveznék, akkor biztos, hogy a java es a .NET kozott valasztanek.

    HTA: En mar lattam ugyviteli HTA-t elesben, az allam majd leesett. Es 1-2 honap alatt csinaltak meg osszesen harman jscript-ben. Azzal, hogy lassu vitatkoznek, es nem intranetes vagy internetes dologra gondoltam (application). Epp ez az, hogy ma mar a sebesseg nem kritikus tenyezo. Tbk. kozott erre epit a .NET is, hisz a cl kod interpretalt. Ja, es alapbol nem kell hozza semmi, csak egy editor (bar ehhez egy kis megszallotsag nem art). Vannak meg vele problemak, hisz gyerekcipoben jar, de nekem tetszik es jo otletnek tartom mindenkeppen.
    Mutasd a teljes hozzászólást!
  • Az igazán óriásoknak persze tényleg nem. Ők ugyanis ritkán foglalkoznak ügyvitellel. Akik meg igen azoknak a forráskódjuk nagy része még jóval a RAD feltalálása előttről származik, így egyszerűbb volt csinálni föléjük egy win-es felszínt mint újraírni az egészet Delphiben. Ráadásul egy igazán nagy cégnek nem jó ha egy platformnak van kiszolgáltatva, így sok dolgot inkább java-ban írnak meg akkor is ha lassabb, ez ugyanis elég jól hordozható és a forráskódja is rendelkezésre áll, így a cég pár millió dollárból létrehozott szoftvere nem függ annyira a környezettől, így ha mondjuk 10 év múlva már nem lesz x86 és win akkor sem kell az egészet újraírni, míg egy win32 API-ra alapozott VC6-os programra ezt már nem biztos hogy el lehet mondani.
    Az alap html egy rakat kaki. Kb 10%-át tudja annak amit egy Delphi-ben írt program csinálni tud az alap komponenskészlettel, anélkül hogy hozzáfejlesztenék valamit. És kb 20x olyan lassú és 5x annyi időbe telik kifejleszteni és 10x olyan nehéz használni (nem tanulni hanem napi rendszerességgel dolgozni vele) a felhasználónak. Na most ezt mindenféle sz*rokkal lehet gányolni, csak az már nem html (nem böngészőfüggetlen, nem OS független, nem szabványos, plusz potenciális biztonsági lyuk a kliens gépén). A másik út a javascript, azzal sok mindent meg lehet csinálni de erős korlátai vannak, plusz a fejlesztési időnek sem tesz túl jót. A java egy böhönc, mire feljön a user gépén lemegy a nap. Hosszú távon az lenne megoldás hogy .NET alatt lehessen programozni a böngészőt, bár ez is meglehetősen win32 only, max. abban lehet bízni hogy mire ez elterjed addigra a mono segítségével a mozilla és a többi platformfüggetlen böngésző is .NET kompatiblis lesz. Szvsz ugyanis ez 4-5 évnél korábban nem fog elterjedni a klienseken, így addig van ideje a mono-nak is összeszedni magát.
    Mutasd a teljes hozzászólást!
  • >a HTA komoly kis alternativa lehet sok esetben
    egyetlen borzalmas nagy hibaja van: csak Explorer, es abban is csak a X+ verziok.

    amugy igazat adok neked, de akkor mar inkabb .NET. elvileg meg crossplatform is.

    >Ja, a windows-ban ma mar 'minden' UI HTML alapu, ez a jovo es a jelen is.

    meg is van a haszna! szvsz az Explorer HTML != mas HTML

    de hagyjuk, inkabb vissza az eredeti thread-hez.
    Mutasd a teljes hozzászólást!
  • ez azért szvsz messze nem RAD.


    Hat persze, hogy nem RAD. Arra az MS-nek ott a VB. A RAD meg a szamomra egy kicsit sejtelmes dolog: jo nekem, jo neked, jo egy csomo piti szoftverfejleszto cegnek, de nem igazan fontos egy oriasnak. Tehat meg van a helye, hogy hol celszeru alkalmazni (ugyvitel). A "Visual" nev meg egy csalad gyujtoneve: A Visual Studio egy kozos fejlesztorendszer (Java, C++, Basic, FoxPro, InterDev). Ennyi.

    Apropo RAD es formok: a mostanaban szarnyait bontogato kis huszar, a HTA komoly kis alternativa lehet sok esetben! Es ha jol megnezzuk meg IDE se kell hozza, bar ez ma meg az egyik nagy hatranya, hogy nincs is hozza. Szerintem egyfajta kozeputnak tekintheto es egyre torekszik felfele. HTML-ben mindent (sot meg tobbet is) meg lehet csinalni, ami egy design-os formtol elvarhato. A WebBrowser segitsegevel pedig az alkalmazasokba beepitheto WEB-technologiahoz jutunk. Ja, a windows-ban ma mar 'minden' UI HTML alapu, ez a jovo es a jelen is. Hajra.
    Mutasd a teljes hozzászólást!
  • Én igazából a wxWindows-zal dolgoztam huzamosabb ideig, GNU C++ alatt. De játszogattam a VC6-tal is, megmondom őszintén túlzottan nem tetszett, legalábbis ha RAD-ként néztem rá. Ha viszont mezei C++ fejlesztőkörnyezetként (azaz nem a C++ Builder-hez hasonlítom hanem mondjuk a KDevelop+wxWindows+GCC triumvirátushoz) akkor a VC6+MFC sem rossz kis rendszer. Csak szvsz az a Visual szó a neve elején enyhe túlzás, ez azért szvsz messze nem RAD.
    Mutasd a teljes hozzászólást!
  • Ugyanitt, ugyanilyen feltételek mellett érdekelne VisualC is, bár C-t csak alig-alig ismerem.


    Regisztrald magad a www.developer.hu-n es rendelj meg egy starter kit-et .NET-bol. Sajnos ez is csak egy 60 napos probaverzio, de tartalmazza a VC++.NET-et is. Tapasztalat szerint kb. 3-4 heten belul kuldik MS-ek a DVD-ket, amelyen sok mas hasznos info is megtalalhato.
    Mutasd a teljes hozzászólást!
  • 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.


    Ez igaz egy RAD, mint pl. a Delphi eseteben, de a VC++ -nal messze nem ennyire egyertelmu, sot en a nagyobb szamitasi igenyu feladatokat szivesebben valositom meg C,C++ -ban, mint barmely mas nyelven, pont azert, mert egyszeru elemi muveletekbol is nagyobb valasztekom van.

    Sting, dehat te szoktad hangsulyozni, hogy a megfelelo eszkozt a megfelelo celra.

    En egyebkent a C-bol a null pointert hianyolom, sajna nincs szintatikai null, csak szemantikai (vagy tan meg szemantikai sincs a szabvanyban...) :/

    Es az is igaz, hogy az LL(k) nyelvtanok reszhalmaza az LR(k)-nak, dehat ezen csak a szintatikai elemzes 'nehezsege' mulik, ez viszont csak egy resze a compiler 'josagat' jellemzo osszetevoknek, ott van meg a szemantikai analizis, optimalizalas (globalis, lokalis), kodgeneralas, regiszter allokalas, becimzes, celkod kivalasztas, stb, amely dolgok nagyresze nagyban fugg a cel nyelvtantol is.
    Azaz, hogy mit konnyebb es mit nehezebb forditani, azon nem erdemes ezen a szinten, tobb informacio nelkul vitatkozni.

    Itt max azon lehet, hogy a forras nyelvek absztrakcios szintje hogyan viszonyul egymashoz, bar ezen sem erdemes, hiszen ez mar nagyon szubjektiv dolog...
    Mutasd a teljes hozzászólást!
  • Sza,

    A mostani CHIP magazinban - november - van egy Delphi 7 Architect próba verzió, igaz csak 30 napig OK ...

    dj
    Mutasd a teljes hozzászólást!
  • Üdv mindenkinek!
    Egy ideje foglalkozom Pascallal és úgy gondoltam megismerkednék a Delphivel. A kérdésem az, hogy van e olyan ingyenes verzió ami meg van vkinek és át tudná nekem írni (persze fizetnék érte, 1e HUF-t, vagy 750 HUF-t + CD-t viszek).
    Legálisan gondoltam, pl. netről hivatalosan letölthető verzió, stb.(Én azért nem tudok letölteni, mert elég silány a net kapcsolatom).
    Ugyanitt, ugyanilyen feltételek mellett érdekelne VisualC is, bár C-t csak alig-alig ismerem.
    Szóval ha valaki tud segíteni kérem írjon:
    czappag@freemail.hu
    Czappa G
    Mutasd a teljes hozzászólást!
  • AFAIK az inc()/dec() és még néhány hasonló alapfüggvény nem függvényhívásként értékelődik ki, hanem a fordító helyben optimalizál, nincs klasszikus értelemben vett függvényhívás a fordított image-ben.

    A C elképzelés egy más megközelítés. Ők a hatékonyságot és tömörséget az olvashatóság ellenében jobban preferrálták, mint Wirth, csak ennyi a különbség. Részemről elég gyorsan gépelek, hogy a shift-4 helyett a "not"-ot időveszteség nélkül be tudjam helyezni a kódba meg ismerem a keyboard clipboard shortcut-okat :) Szóval szerintem erről már badarság vitatkozni, teljesen lényegtelen kérdés.

    A beágyazott eljárásokat én sem szeretem, fúdeútálom, ha valaki olyat ir :) Szigorúan _elvileg_ jó dolog, gyakorlatilag meg a hideg ráz tőle.

    A végkövetkeztetéssel pedig egyetértek.
    Mutasd a teljes hozzászólást!
  • Elméletileg ez azért van így az ObjectPascal-ban is, mert olvashatóbb forráskód írására kötelezi a programozót (ha már itt járunk, talán van ilyen tendencia -- ld. Python blokkszervezés).

    Ennek ellenére el tudnám fogadni, hogy alternatíva legyen a ? : és a prefix/postfix increment/decrement, ezt hiányolom én is. A JCL ad egy iif() függvényt (de az már third-party) én meg nem irok rá külön rutinkönyvtárat.

    Mindenesetre tartható, hogy olvashatóbb így a kód (kevesebb a nyelv alapkészlete).
    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...

    Az emlitett alkalmazasasok nem csak egypolatformosak, ezert irjak oket C-ben. Igy le tudjak redukalni a platformspecifikus reszeket a leheto legszukebb keresztmetszetre. Persze, en sem mondom, hogy mindent VC-ben kell megirni, ez evidens. En csak kotelessegemnek erzem, hogy kialljak a VC mellett, ha degradaljak.
    MS-ek is szeretik, mert szinte mident abban kodolnak, persze nekik biztos van sajat bejaratu osztalykonyvtaruk, amik le-wrapper-elik a nem publikus API-kat is.
    Mutasd a teljes hozzászólást!
  • Utoljara:
    Egy kis automata elmelet (diohejben): akit nem erdekel, nyugodtan ugorja at! Amibol ki kell indulni (megegyszer) az az, hogy a P compiler top-down elemzest alkalmaz, a C pedig bottom-up-ot. Ez teny, vitatni nem lehet. A compiler bonyolultsagat a szintaxis elemzes ordo bonyolultsaga hat. meg, a kodgeneralas bonyolultsaga ezt nem befolyasolja(nagysagrendileg alacsonyabb). Az elemzes azert top-down, mert a parser a szabalyhalmaz kezdoszimbolumabol, mint egy fa gyokerebol ("Program|Unit" terminalisok) probal meg eljutni a
    szabalyokon vegiglepkedve a szoig (forras). Ha sikerul neki, akkor nincs szintaxis hiba, ha nem, akkor van. A folyamat azert determinisztikus, mert minden egyes allapotbol a kovetkezo allapotba torteno lepes "iranya" egyertelmuen eldonthato az adott ponton. A folyamat vegen felepul az un. derivacios fa.
    Bottom-up elemzes: Pont forditott. Nevezik meg shift-reduce elemzesnek is (veremautomata muveletek). Itt a szobol (forras) probal meg a parser eljutni a szabalyhalmaz kezdoszimbolumaig, ekozban a szabalyokat visszafele alkalmazza. Nemdeterminisztikus, mert elofordulhatnak olyan szituaciok, amikor egyszerre tobb szabaly jobboldalat is megtalalja a parser es el kell dontenie, hogy melyiken lepjen vissza a kezdo
    szimbolum fele. Ekozben elofordulhat, hogy elakad es nem biztos, hogy azert, mert a program szintaktikusan rossz, hanem azert, mert nem a megfelelo agon probalt eljutni a kezdoszimbolumig. Ezert nehezebb megcsinalni.
    Egyebkent nem passziobol kell a C-nek a bottom-up elemzes, hanem mert a nyelvtana (LR(k)) tobbet tud
    az LL(k) nyelvtanoknal. Ha megnezed a szakirodalomban, akkor azt talalod, hogy LR(k) elemzot kesziteni sokkal bonyolultabb, mint LL(k)-t.
    A pascal LL(k) nyelvtanara eszmeletlen jo pelda az if-else utasitas, amikor is ha van else agatok, akkor
    az if utan nem lehet kitenni a semicolon-t (;). Ha kitennetek, akkor a szabaly terminalodik az adott ponton az else pedig "logva" marad a levegoben, kulonallo else utasitas pedig nincsen, igy syntax error.

    Az MSVC-nek azert van kissebb tabora, mert nem eleg odaulni ele, kattintgatni, belenezni egy kicsit a helpbe es mar ossze is dobtunk valamit, ami megy is, meg annal egy kicsit tobb is. Akik megprobaljak, sokan feladjak. En is igy kezdtem, szidtam is egeszen addig, amig ra nem ereztem az izere, pedig elotte mar sok eve programoztam C/C++-ban. Sajnos-nemsajnos a VC rutinos hasznalatahoz vezeto ut hosszu es veres verej tekkel atitatott, de aki megjarja arra szerintem nyugodtan rafer a "tisztelet", mert biztos, hogy
    tudas is van mogotte. A tudas pedig a dolgok lelkebe latas tudasa. VC-ben nincs titok a programozo elott. Az latja, tudja mit csinal, a memory view-neki sokat elarul. Persze VC-ben is vannak koca programozok, de nagysagrendekkel kevesebben, mint D-ben. Az MFC-rol meg annyit, hogy egy nagyon jol kidolgozott osztaly konyvtar, sokat segit, de eljart felette az ido es az MS sem fejleszti tovabb. Mint mar mondottam .NET
    van mar csak. Egyebkent VC-ben nem csak az MFC van, ott van meg az ATL-is. A nagy szoftvercegeknek pedig megvan a sajat fuggveny es osztalykonyvtaruk. (egy VC-s az exe-bol vagy a dll-bol megmondja, hogy mi van benne )
    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), másrészt ez a kivétel ami erősíti a szabályt.

    - nem értem miért kellene eljárás hívás egy változó növeléséhez v. csökkentéséhez?, ennyire hozzászoktál az inc-dec pároshoz, vagy netán külön függvényeket írsz egy változó értékének megváltoztatásához , ahogy előttem írták, a C nyelvet programozók készítették programozóknak, s mivel a programozó eleve lusta emberke[]
    ezért is találták ki többek között a += operátort, szerintem sokkal kényelmesebb mint az inc(i) v. a i:=i+1;
    Különben is "C. Kerninghammal és Ritchie" féle alapelképzelések egyike az volt, hogy tömör, mindenféle sallangoktól mentes forráskódot legyen lehetőség írni, figyeld csak ezt a különbséget: not v. !.
    - az azért badarság, hogy át kell nézned az egész programot, hogy megértsd egy "*" jelentését, remélem ezt te sem gondoltat komolyan , ha valakinek van gyakorlata, akkor pillanatok alatt rájön, hogy mit is szeretne kifejezni az alkotó.

    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ó.

    - szerintem is kevered a dolgokat, pont hogy a C/C++ kód értelmezése a nehezebb, ergo a fordító készítése is egy fokkal nehezebb hozzá, kaptál linkeket, légyszi nézd át és csak utánna nyilvánits vélemény ebben az ügyben, bár ha nagyon kötöd az ebet a karóhoz, akkor jöhetnek az tény: előszedem a jegyzeteimet és idézek belöle, bár félek, hogy akkor kiutálnak innen (ha már nem )

    Hogy azért valami pozitívat is mondjak a pascalról, szvsz nagyon jó ötlet a beágyazott eljárás.

    júj, de nem szeretem!!, számomra így már olvashatatlan a kód, ha valami miatt bedöglik az indent, akkor aztán lehet bogozni ... de ez már az én problémám ...

    ui: tök értelmetlen vitázni, hogy ez a jó vagy az a jó, szerintem a Delphi-Pascal is frankó nyelv, melynek nagy erőssége az objektum könyvtárak, azért a C/C++ szintaktika hozzám sokkal közelebb áll és szeretem is az egyszerüségét, dehát ez az én szubjektív véleményem ...
    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