Pascal Compiler

Pascal Compiler
2006-05-08T21:51:21+02:00
2006-07-05T15:05:30+02:00
2022-10-31T03:41:52+01:00
  • Szerintem egyszerűbb a ^-os módszer. Azon tökéletesen látszik, hogy mi a cél típusa, és az is látszik, hogy az ott egy pointer. És még rövidebb is.

    T:= (Pointer)(WordBool)Variable;
    helyett:
    T:= ^WordBool(Variable);

    Ez a példa a "Variable"-t "WordBool" típusúnak értelmezi át, méghozzá azt is úgy, hogy az egy mutató ("^"). Vagy nem erre gondoltál?
    Mutasd a teljes hozzászólást!
  • Hi!

    MutatOK?

    ^T helyett castolással?
    T:=(pointer)(wordbool)Változó
    Olvashatóbb?
    Mutasd a teljes hozzászólást!
  • Nem. Ez itt nem egy már meglévő továbbfejlesztése (mégha annak is látszik), hanem egy teljesen saját Pascal lesz.
    Tudom én; arra akarsz kilyukadni, hogyha ez itt nem egy meglévő Pascal továbbfejlesztése, akkor miért kéne', hogy ennyire ragaszkodjak hozzá?
    A kérdés logikus. De szeretném leszögezni, hogy nem úgy akarok bizonyos problémákat megoldani, hogy egyszerűen kicserélem azokat valami egészen másra, ami reményeim szerint jobb lesz elődjénél, hanem úgy, hogy a már meglévőt kiegészítem eddig még nem támogatott dolgokkal, s így megmarad a Pascal "szaga" az egésznek, mégis egy merőben új "illata" lesz, ha hasznájla majd valaki.
    Remélem értesz engem...
    Mutasd a teljes hozzászólást!
  • Egyszerűen azért, mert ez itt PASCAL.


    Juteszembe: kiválasztottad már hogy melyik PASCAL lesz az alap amit tovább fogsz majd fejleszteni?
    Mutasd a teljes hozzászólást!
  • "Mert amit a gép is megcsinálhat, azt szerintem a gépnek kellene megcsinálnia, nem a programozónak ..."

    Ebben igazad van. De én azért szeretem tudni, hogy mi is zajlik a háttérben. Ezért megesik, hogy ha nagyon biztosra akarok menni, akkor inkább én magam megírom a kérdéses függvényt, pedig a rutinkönyvtárban már van olyan. (Na ez azért nem olyan sűrűn van így.)
    Mutasd a teljes hozzászólást!
  • "Miért is van szükség mutatókra? Visszamenőleges kompatibilitás miatt? Vagy hogy egyszerűbb legyen megírni a fordító programot ?"

    Egyszerűen azért, mert ez itt PASCAL.
    Mutasd a teljes hozzászólást!
  • "Ezt a kérdést SamBowrynak szántam, mivel ő akarta száműzni a mutatókat azzal, hogy mindent implicite mutatóként használ."

    Tudom, leesett nekem is, csak már nem módosíthattam a hozzászólásom. Bocs...
    Mutasd a teljes hozzászólást!
  • "A lényeg, hogy egy mutatóból készíthessek olyan mutatót is, ami ugyanoda mutat, de másmilyen típusú."

    Igen, LC már mutatta, hogy megy ez.

    "...támogatni kéne a getmem, freemem függvényeket is."

    Természetesen lehetőség lesz dinamikus memóriakezelésre, de ezek az eljárások csak implementálásra váró apró pontjai egy (vagy több) rutinkönyvtárnak. Maga a nyelv ettől még nem módosul.

    "De legyenek ám"

    Persze. Bár ezekkel még egy kicsit bajban vagyok. Nem tudom, hogy integráljam -e a nyelvbe, mint foglalt szavakat, vagy csak implementáljam be egy unitba. (Ahogy elnézem, ezekkel még bajom lesz...)

    A mutatókon végezhető műveletek valóban nem tartalmaznak kivonást. (Összeadást sem tudom, hogy van -e, mert sosem volt rá szükségem. Mindig volt "elegánsabb" magoldás.) Csakhogy egy "jólirányzott" mutatóművelettel "öntökönrúgásba" is eshetsz. (Lásd: Pascal filozófia.) Oké, hogy aki tud programozni, annak ez nem gond, de aki csak próbálkozik, annak meg inkább ajánlott ilyen "erőszakos mutogatásra" az Assembly...

    Ja, és az eljárás/függvény típusú mutató változó példádra azt kell, hogy mondjam, hogy ez így ahogy van működik. (Na jó, kifelejtetted a @ operátort.)
    Mutasd a teljes hozzászólást!
  • Mert amit a gép is megcsinálhat, azt szerintem a gépnek kellene megcsinálnia, nem a programozónak


    Ilyen pld a rekurzív adatstruktúrák kezelése. Ezeket a legegyszerűbb rekurzív programokkal leírni. Az meg a fordítóprogram feladata kell legyen, hogy a kódból iteratív implementációt fordít.
    Mutasd a teljes hozzászólást!
  • Aztán berakod a változót egy olyan ciklusba, ami másodpercenként félmilliószor futna, és máris látszik a különbség.


    Erre vannak kitalálva a regiszterek ...

    Szerintem nem kellene az irányítást kivenni a programozó kezéből valami rosszul értelmezett egyszerűsítés jegyében.


    Ezt mondták a Fortranra is ...

    A Pascalban viszont szerintem szeretnének, még akkor is, ha ehhez bonyolultabb nyelv kell...


    Vagy bonyolultabb fordítóprogram. Mert amit a gép is megcsinálhat, azt szerintem a gépnek kellene megcsinálnia, nem a programozónak ...
    Mutasd a teljes hozzászólást!
  • Pascal-ban időtlen idők óta lehet castolni (szvsz a TP3-ban is volt), csak a szintaktika más: ^PublicStuff(priv).
    Mutasd a teljes hozzászólást!
  • Borzasztó pazarlás


    Egy változónál nem tűnik soknak. Aztán berakod a változót egy olyan ciklusba, ami másodpercenként félmilliószor futna, és máris látszik a különbség. Szerintem nem kellene az irányítást kivenni a programozó kezéből valami rosszul értelmezett egyszerűsítés jegyében.

    Vagy, ha nagyon egyszerű változókezelésre vágysz, ott van a Lua nyelv. Csak egy szám típus van benne, a valós, mivel hogy abba egész számot is lehet tölteni. Igaz, a lebegőpontos számolás picit lassabb, dehát kit érdekel. Nincsenek benne tömbök sem, csak hash táblák, hiszen a tömb igazából a hash tábla egy speciális esetének tekinthető. Igaz, a hash táblából kicsit lassabb olvasni, mint egy tömbből, de kit érdekel?

    Persze a Lua egy szkriptnyelv, és senki nem ír benne sebességkritikus programokat. A Pascalban viszont szerintem szeretnének, még akkor is, ha ehhez bonyolultabb nyelv kell...
    Mutasd a teljes hozzászólást!
  • Őőő.. Miért is kellene átkeresztelni egy változót?


    Őőő.. Miért is van szükség mutatókra?

    Visszamenőleges kompatibilitás miatt? Vagy hogy egyszerűbb legyen megírni a fordító programot ?
    Mutasd a teljes hozzászólást!
  • No és mi van akkor, ha neked kétszeres indirekcióra van szükséged (azaz egy mutató címére)?


    Ezt a kérdést SamBowrynak szántam, mivel ő akarta száműzni a mutatókat azzal, hogy mindent implicite mutatóként használ.
    Mutasd a teljes hozzászólást!
  • Látom ez is húzós téma lesz


    Az nem biztos, jó rég nem dolgoztam pascallal. Lehet, hogy TP3.0 óta már vannak benne jó dolgok

    Mit értesz "cast"-ollás alatt?

    A castolást magyarul talán "típuskényszerítés"-nek (?) mondanám. Lényeg, hogy a T1^ típusú mutató odamutat valahova, amit később valamiért úgy szeretnék kezelni, mint egy T2-objektumot. Példa (bocs, ha kicsit C-s a syntax):
    type PublicStuff = record publicField1: integer; publicField2: integer; end; type PrivateStuff = record publicPart: PublicStuff; privateField: integer; end; function new_stuff(): PublicStuff var priv: ^PrivateStuff; begin getmem(priv, sizeof(PrivateStuff)); new_stuff := (^PublicStuff)priv; {EZ A CAST} end; ...

    És a unitodba csak a PublicStuffot teszed ki publikusnak, a developer nem fogja tudni, hogy valójában privatestuffot használt.
    Ami itt fent történik, az kb egy láthatóság-emuláció osztályok nélkül. Ugye egy osztálynak szoktak lenni publikus és privát (egyszerűség kedvéért adat-) tagjai; a privát tagokhoz nem akarunk közvetlen hozzáférést biztosítani.
    Ezt pl. úgy is meg lehet csinálni, hogy van egy PrivateStuff struktúrád, ami tartalmazza a publikus és a privát mezőket is, méghozzá úgy, hogy a publikus részek a memóriaterület elején foglalnak helyet. Amikor a felhasználó a fenti new függvénnyel kér egy példányt az osztályból, akkor egy olyan mutatót kap, ami egy ilyen memóriaterület elejére mutat ugyan, DE publicstuff típusú, vagyis csak a memóriaterület elején levő (publikusnak tervezett) részeket lehet elérni rajta keresztül.

    Ha ez a téma bővebben érdekel, nézd meg pl. a GTK forrását (plain C), az tele van ilyen kóddal A lényeg, hogy egy mutatóból készíthessek olyan mutatót is, ami ugyanoda mutat, de másmilyen típusú.

    Nem tudom, hogy osztályokat akarsz-e beletenni a pascalodba (visszaolvasom majd a threadet), de ha igen, akkor pedig azt mondanám, hogy egy (fúdesablonosleszek) ^Jármű mutatót lehessen ^Tank-ra castolni, ha futás közben valóban egy Tank osztályra mutat.

    Nem tudom, érthető voltam-e; ha nem, nekifutok máshogy.

    heap

    Csak annyira szerettem volna utalni, hogy támogatni kéne a getmem, freemem függvényeket is.

    Inc(ptr); Dec(ptr);
    Ha ezek vannak, az már tényleg elég. De legyenek ám

    kivonás

    var ptr1, ptr2: ^integer; tomb: array[0..9] of integer; diff: integer; begin ptr1 := @(tomb[2]); ptr2 := @(tomb[5]); {ha így kell} diff := ptr2 - ptr1; {eredmény: 3} end;
    Vagyis a memóriában a két terület közti különbség kéne (fenti példában: "hány int-nyi").

    ezeket még a TP is tudja

    Lehet. Kíváncsiságból megnyitottam a TP ref doksit. A 3A fejezet foglalkozik a mutatókkal. Amit lehet:
    típusos mutatózni;
    new, getmem, dispose, freemem, mark;
    összehasonlítás: = vagy <> (viszont pl. < nincs)
    a @ és ^ operátorokkal oda-vissza hivatkozni, akár függvény címét is kikérni;
    ..és ennyi.

    A mutatókra az inc,dec nincs ebben a referenciában specifikálva, persze attól működhet. A típuskonverzióra se láttam példát, persze attól lehet benne. Konstans hozzáadása/kivonása se látszik a doksiban. (mondjuk ha ptr mutat egy tömb elejére, akkor ptr+7 mutasson a 7. elemre - itt most 0-tól számozok).

    Akkor ez is működik?
    type MyClass = record Field: Integer; TheFunc: function( a: integer ): integer; (*erre vagyok kíváncsi*) end; ... Function f( i: integer) : integer; begin f := i + 1; end; ... var pmc: ^MyClass; begin getmem( pmc ); pmc^.TheFunc := f; (* erre vagyok kíváncsi*) ... end;

    Mert a TP specben nem leltem nyomát se, hogy ezt így szabad-e vagy sem.

    Ha már ez mint van a pascalban, akkor egész sokat fejlődött azóta, hogy utoljára láttam a TP-t

    ,
    --ajven
    Mutasd a teljes hozzászólást!
  • "No és mi van akkor, ha neked kétszeres indirekcióra van szükséged (azaz egy mutató címére)?"

    Semmi különös. A mutató is teljes értékű típusdefiníció, mely változóként példányosítva ugyan úgy megcímezhető. Vagyis semmi különbség nincs egy akármilyen típusú változó és egy Pointer típusú változó címzése között.

    Abban egyébként igazad van, hogy amit csak lehet, konstanssal kell megoldani. A "bedrótozás" sokat "gyógyít(hat)" a tempón.
    Mutasd a teljes hozzászólást!
  • Őőő.. Miért is kellene átkeresztelni egy változót? (Mert itt ugyebár ez történne, csak itt az átkeresztelés "láthatatlan klónozással" jár (vagyis példányosítás nélkül csak mutogatva))
    Mutasd a teljes hozzászólást!
  • Tyű! Látom ez is húzós téma lesz...

    "lehessen típusolni"

    type TMyStruct = record Field1: Integer; Field2: Integer; end; PMyStruct = ^TMyStruct;

    "lehessen castolni másmilyen mutatóra"

    Ezt most nem értem. Mit értesz "cast"-ollás alatt? Van itt előttem egy angol-magyar szótár, ami a "CAST" szóra 59 jelentést tartalmaz. Te melyikre gondolsz?

    "lehessen T^ típusú (ez a ^ a mutató a pacsalban, ugye?) mutatóval bármilyen T-re rámutatni"

    A "lehessen tipusolni" részben már mutattam rá példát.

    "tudjak vele dinamikus memóriakezelni a heapben"

    Magát a dinamikus memóriakezelést nem a mutatóval végzed, hanem például akkor, ha lefoglalsz/felszabadítasz/átméretezel. A mutatóval ugyan úgy kezelheted a Heap-ben lévő adataid, mint ami az adatszegmensben van "beégetve". Vagyis a "mutogatás" független annak céljától.

    "lehessen egy T-mutatót előre-hátra léptetni sizeof(T)-nyit (sőt inkább sizeof(T)-többszörösnyit)"

    A fenti példával élve:
    // Mutató inkremerntálása: Inc(PMyStruct, 3); // Ekvivalens ezzel: PMyStruct:= PMyStruct + 3 * (SizeOf(TMyStruct)); // Mutató dekrementálása: Dec(PMyStruct, 3); // Ekvivalens ezzel: PMyStruct:= PMyStruct - 3 * (SizeOf(TMyStruct)); // Ehhez Inc() & Dec() deklarációi: procedure Inc( var Data ); overload; procedure Inc( var Data; Stepping: LongInt ); overload; procedure Dec( var Data ); overload; procedure Dec( var Data; Stepping: LongInt ); overload;

    "rá lehessen állni egy T[] tömb elejére egy T^ mutatóval"

    var Arr: array[1..10] of Byte; Ptr: Pointer; begin Ptr:= @(Arr); // vagy Ptr:= Addr(Arr); end.
    Persze a mutató akármilyen tipizált is lehet.

    "azonos típusú mutatókat lehessen kivonni; az eredmény nem baj, ha sizeof(T)-ben mint egységben van kifeezve (ez azért nem létszükséglet)"

    Mármint miből lehessen kivonni azt az azonos típusú mutatót? Ez szintén nem egészen világos.

    "tömbre is akarok mutatni (egyszerűbb pl tömböket "kicserélni", ha csak két mutatót kell swappolni hozzá)"

    type TArr = array[1..10] of Byte; THalfArr = array[1..5] of Byte; var PArrStart, PArrHalf, TempPointer: THalfArr; begin ... TempPointer:= PArrStart; PArrStart:= PArrHalf; PArrHalf:= TempPointer; ... end.

    "függvényre és procedúrára is akarok mutatni"

    var MyProcedude: procedure( Parameter: Integer ); MyFunction: function( Parameter: Integer ): Integer;
    Ez esetben nem egy eljárás és egy függvény jött létre, hanem csak két ilyen típusú mutató. Ennek aztán a szokott módon (mondjuk a @ operátorral, vagy az Add() pszeudo-változóval) értéket adsz. Majd ugyan úgy hívhatod őket, mintha teljes értékű eljárás/függvény lenne. (Itt még a ^ sem kell.)

    "Így hirtelen ennyi, de lehet, hogy holnapra eszembe jut még ugyanennyi."

    Hajrá, jöhet. Még mindig nem tudok olyan "mutogatásról", amit a "pacal" ne tudna már ősidők óta (ugyanis ezeket még a TP is tudja (na jó, az overloadingot azt nem)).
    Mutasd a teljes hozzászólást!
  • Van tehát egy plusz utasításunk, négy bájt plusz memóriafoglalás a foo_cime mutatónak, és az eax regisztert a hivatkozás feloldása miatt nem használhatjuk közben másra.


    Borzasztó pazarlás

    Nem tetszik az "address", átírtam a példát:

    var i,j: integer; ... i := 12; j := alias(i); j := j + 1; if i = 13 then writeln( "megy ez " );
    Mutasd a teljes hozzászólást!
  • Ha nem módosítom is nyilván kell tartani ...


    Már miért kéne? Ha a futás alatt a cím végig konstans, akkor bele lehet drótozni a lefordított kódba, és nem kell hozzá plusz memória. (Illetve ha lokális változók esetén a távolság fix a veremkerethez képest, akkor azt is hatékonyan lehet "drótozni".)

    Nézzük példaként az x86 architektúrát.
    Ha tudod, hogy a bájt méretű foo változó címe fixen 0x123456, akkor például az alábbi kóddal növelheted meg kettővel:

    add byte [0x123456], 2

    Ha nem tudod fordításkor (pontosabban linkeléskor) a címet, akkor viszont egy ilyen kód kell:

    mov eax, [foo_cime] add byte [eax], 2

    (Ahol persze a foo_cime egy fix cím, mert mindenképp valami biztos címtől kell indulnunk). Van tehát egy plusz utasításunk, négy bájt plusz memóriafoglalás a foo_cime mutatónak, és az eax regisztert a hivatkozás feloldása miatt nem használhatjuk közben másra.

    Az ilyen hozzáállás legfeljebb akkor kifizetődő, ha a hivatkozott elemek sokkal nagyobbak egy mutató méreténél, és drága a másolásuk (pl. Object Pascal osztálypéldányai).
    Mutasd a teljes hozzászólást!
  • No és mi van akkor, ha neked kétszeres indirekcióra van szükséged (azaz egy mutató címére)?


    Nekem már egyszeres indirekcióra sincs szükségem, akkor miért lenne szükségem kétszeresre?

    Mert ugye ha módosíthatod futás közben egy objektum címét, akkor az aktuális címet valahol nyilván is kell tartani...


    Ha nem módosítom is nyilván kell tartani ...
    Mutasd a teljes hozzászólást!
  • No és mi van akkor, ha neked kétszeres indirekcióra van szükséged (azaz egy mutató címére)?

    Arról nem is beszélve, hogy mennyi memóriát pazarolna minden változóhoz egy mutatót is lefoglalni. Mert ugye ha módosíthatod futás közben egy objektum címét, akkor az aktuális címet valahol nyilván is kell tartani...
    Mutasd a teljes hozzászólást!
  • mert nekem egy-két apróságtól eltekintve nincs gondom a mutatók használatával Pascal alatt.


    Nekem csak egy "apróság" jut az eszembe, hogy mi szükség van mutatókra?

    A "var i : integer;" ugye azt jelenti hogy van valahol egy tárterület, aminek "i" a neve. Vagyis az "i" már eleve egy mutató.

    Ha akarnék egy másik "mutatót" ugyanerre a tárterületre, akkor az egy másik név lenne, ami ugyanazt a tárterületet nevezi meg:

    var i,j: integer; ... i := 12; address(j) := address(i); j := j + 1; if i = 13 then writeln( "megy ez " );

    Mutasd a teljes hozzászólást!
  • Én így hirtelen a következőket várom el egy mutatótól:
    - lehessen típusolni
    - lehessen castolni másmilyen mutatóra
    - lehessen T^ típusú (ez a ^ a mutató a pacsalban, ugye?) mutatóval bármilyen T-re rámutatni
    - tudjak vele dinamikus memóriakezelni a heapben
    - lehessen egy T-mutatót előre-hátra léptetni sizeof(T)-nyit (sőt inkább sizeof(T)-többszörösnyit) a memóriában (tömb bejárása végett)
    - rá lehessen állni egy T[] tömb elejére egy T^ mutatóval
    - azonos típusú mutatókat lehessen kivonni; az eredmény nem baj, ha sizeof(T)-ben mint egységben van kifeezve (ez azért nem létszükséglet)
    - amikor azt mondtam, hogy tetszőleges T típushoz lehessen T^ mutatót csinálni, akkor azt komolyan gondoltam
    - vagyis tömbre is akarok mutatni (egyszerűbb pl tömböket "kicserélni", ha csak két mutatót kell swappolni hozzá)
    - vagyis függvényre és procedúrára is akarok mutatni; a függvény típusa a bemenő paraméterek típusa, plusz az eredményé (így lehet ugyanis osztály nélkül dinamikus függvénykötést megvalósítani, úgy, hogy nem fog lookupolni az osztályhierarchiában minden híváskor a structom)

    Így hirtelen ennyi, de lehet, hogy holnapra eszembe jut még ugyanennyi.
    Most néztem egyébként, a gnu pascal egész sokat tud ezek közül.
    Mutasd a teljes hozzászólást!
  • XiX:
    "Szerintem legyen többdimenziós tömb."

    Igen, korábban már írtam, hogy lesz. Az, hogy mégse legyen, csupán annyiban merült fel bennem, hogy igazából a többdimenziós tömbtámogatás csak kényelmi ezköz; tömbök tömbjeivel (azaz egydimenziós tömbök egymásba ágyazásával) is megoldható ugyan az. De úgy látom, hogy a programozók kényelmes emberek...

    Ájven:
    "ugye a C filozófiája: N összméretű tömb X-ből == N*sizeof(X) méretű egybefüggő memóriaterület"

    Na ez az én Pascal-omban is szó szerint így lesz, ha statikus tömbről van szó. Dinamikus tömb esetén persze már más a helyzet. (Pl. talán furcsának tűnhet, de mivel nálam a dinamikus tömbök leíróit tartalmazó struktúrák is dinamikusan generálódnak/szabadulnak fel, így maguk a leírók is egy láncolt lista részei. Ezzel lehetőség nyílik arra, hogy a amíg a program várakozik pl. egy billentyűre, addig a háttérben szép csendesen rendet rakhat a Heap-en. És mindezt úgy, hogy a programozónak erről még tudnia sem muszály...)

    Mindenki: A tömbkezelésnek egyébként már a végén járok. Párhuzamosan ezzel szerkesztem a pszeudo-változók és a halmazok kezelését tárgyaló doksit. Ezekkel nincs különösebb gond. A következő "nagyobb lélegzetvételű" téma az lesz, ami miatt (szerintem emiatt) a legtöbb programozó a Pascal-t "pacal"-nak csúfolja: MUTATÓk. Lesz mit róla regélni...
    (Addig is mindenki szedje össze minden haragját a Pascal mutatókkal kapcsolatban, hogy részletesen írhasson róla, hogy mi nem tetszik benne. Hátha itt is akad jó ötlet. (Bár túlságosan nem bizakodom, mert nekem egy-két apróságtól eltekintve nincs gondom a mutatók használatával Pascal alatt.) De mondom: MINDENKI HÚZZA LE A SPENÓTOT, MINT POPEJ...)
    Mutasd a teljes hozzászólást!
  • A C is nagyon elvan a csak egydimenziós tömbjeivel...

    Ilyen [1..10][1..10] szinten C-ben is van többdimenziós tömb; ha megmondod - esetleg az utolsó kivételével - az összes dimenziót, mint pl. int a[3][4][] vagy hasonló, akkor használhatsz akárhányds tömböt.
    Ennek címzési okai vannak, így ki lehet számítani egy adott koordinátájú tömbelem offsetjét a (természetesen) egydimenziós memóriaterületen belül anélkül, hogy a tömbről egyéb plusz infót kellene eltárolni (ugye a C filozófiája: N összméretű tömb X-ből == N*sizeof(X) méretű egybefüggő memóriaterület. Nem tárolja el, hogy melyik dimenzión mekkora, stb; ez a programozó dolga, ha ilyet akar csinálni).

    Van egyáltalán aki még használ többdimenziós tömböt?

    Az Ájven pl igen. Persze nem pascalban

    --ajven
    Mutasd a teljes hozzászólást!
  • Hi!

    Asszem, a J nyelvben van ilyen (kútfő rulez, szal nem biztos, hogy igy néz ki)

    a/ = 7 1 2 3 4 5 6 7
    Na, ez egy 1 dim tömb és még fel is van töltve konstans értékekkel.
    Mutasd a teljes hozzászólást!
  • Hi!

    Többdimenziós tömb az eredeti Pascal-ban van, de itt már nincs.

    Egy nyelv elemi készletéhez hozzátartozik (vagy nem)
    Szerintem legyen többdimenziós tömb.
    Mutasd a teljes hozzászólást!
  • Szia Csaboka2!

    "...nem lenne olyan nehéz a mostani többdimenziós tömb szintaxist belsőleg "array of array" szintaxisra alakítani fordítás közben."


    Pontosan úgy van, ahogy mondod. A fordító úgy fordít, hogy miután a szintaxis-, tipus-, és túl/alaulcsordulási hibakeresést elvégezte, a "túl magasszintű" dolgokat leegyszerűsíti valami "primitívebb" formájúvá. Például az osztályokat lecseréli rekordokra (persze figyelve az öröklésre, stb...), vagy a pszeudo-változók kódjait behelyettesíti a hivatkozási helyekre (inline). Illetve az overload-olt rutinoknak csinál átmenetileg annyi példányát, ahány overload formája volt, csak mindegyiknek más-más nevet ad, ezzel eltűntetve a "túlterhelést".

    A többdimenziós tömbök ilyen módon szintén "butíthatóak", és nem is mondtam azt, hogy ezt nem lehet megcsinálni. Csupán egyszerűen kihagyhatnám a többdimenziós tömbök leegyszererűsítését, de most így jobban belegondolva végülis nem olyan nehéz plusz meló az. Csak egyszerűen úgy voltam vele, hogy ha senki sem használ többdimenziós tömböket, akkor minek legyen a fordítóm része. De már látom, hogy ez egy kicsit "túlkapás" volt részemről...
    Mutasd a teljes hozzászólást!
  • Hát nem tudom, szerintem a többdimenziós tömbök tipikusan a szintaktikus cukor kategóriába tartoznak: bár mindent meg lehet csinálni nélkülük is, egy átlagos programozó nem szereti háromszor begépelni az "array of" szavakat egy háromdimenziós tömbhöz. A C-ben ez kicsit más, mert ott alig kell plusz szöveget begépelni a "tömbösítéshez".

    Persze a te dolgod, hogy mit raksz bele a fordítódba, de szerintem nem lenne olyan nehéz a mostani többdimenziós tömb szintaxist belsőleg "array of array" szintaxisra alakítani fordítás közben.
    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