Compare commits
2 Commits
37872eb496
...
9212dfc814
| Author | SHA1 | Date | |
|---|---|---|---|
|
9212dfc814 | ||
|
|
c3001c4d52 |
114
BASED.md
114
BASED.md
@ -62,9 +62,9 @@ Meg ez is (basic block-os módszer):
|
||||
^^Ezek "kezelik" a memóriákat és resource-okat RAII-módon, konstruktorral és destruktorral.
|
||||
Szerintem a struct-hoz és class-hoz képest is jobb szó.
|
||||
|
||||
Lesz továbbá tagged union is - lásd lejjebb - és interfészek (ami tagged union-á fordul le, hacsak ki nem optimizálja a fordító).
|
||||
Lesz továbbá tagged union is - lásd lejjebb - és interfészek.
|
||||
|
||||
Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni???
|
||||
Szerintem itt a 'T' helyett talán érdemes csak egy interfész-nevet megengedni??? Esetleg nem is ilyen <..> stílusban?
|
||||
|
||||
# Placement new
|
||||
|
||||
@ -414,6 +414,10 @@ Lásd még:
|
||||
|
||||
ui.: Ha nem lesz operátor overload, akkor szerintem legyen több dimenziós tömb (nem a tömbök tömbje, hanem: matrix[15, 10, 42] = 5;
|
||||
|
||||
### restrict-ált tömbök
|
||||
|
||||
A tömbökre is kell a pointerekhez hasonló restrict.
|
||||
|
||||
## Típusos indexek
|
||||
|
||||
Egy pointer a modern gépen 64 bit, sokszor tömörebben tudsz tárolni "referencia-szerűséget" ha indexet tárolsz rá!
|
||||
@ -779,68 +783,24 @@ minden esetre kell legyen definíciója, vagy az únió eseteitől függetlenül
|
||||
Zsolt vetette fel, hogy neki azért öröm töltené el a szívét, ha lehetne egy "kicsit OO style" azért annyiban, hogy egy tömbben tud
|
||||
keverni különböző típusú dolgokat, amiknek közös az interfésze és kapni ilyeneket függvény paraméterként...
|
||||
|
||||
Ez valamilyen szinten jogos elvárás és az únió részben tudja is ezt, mert csinálhat az ember egy tagged union-t amiben ő maga
|
||||
sorolja fel így a típusait amik a tömbben lesznek és a fun() függvényeikben simán this->fun() átírányít / delegál akkor.
|
||||
|
||||
No de! Ennél tudunk jobbat is! Mert ez nem kezeli azt az esetet, ha egy library-t akarok írni és ezt forrással együtt kiadni!
|
||||
Ugyanis olyankor a lib írójaként én megszabom mely dolgokat veheti fel a tagged union - tehát előre kéne tudnom a use case-eket!
|
||||
Ez nincs így! Ellenben a fordítót kihasználhatjuk arra, hogy generálja ezeket a tagged union-okat le, az alapján, hogy kik
|
||||
implementálnak egy interfészt!
|
||||
|
||||
Első változat:
|
||||
|
||||
interface IStringifyable {
|
||||
string stringify();
|
||||
}
|
||||
|
||||
handle A implements IStringifyable {
|
||||
...
|
||||
}
|
||||
|
||||
handle B implements IStringifyable {
|
||||
...
|
||||
}
|
||||
|
||||
// Ez ilyenkor egy tömb, aminek az elemei igazából tagged union elemek,
|
||||
// a build-ben meglévő összes azt implementáló dolog alapján...
|
||||
void process(IStringifyable arr[]) {
|
||||
...
|
||||
}
|
||||
|
||||
Megj.: Szerintem ettől generic-szerűbb lesz a dolog, ha típusnak generik paraméternek adható egy "interfész"!
|
||||
Olyankor csak konkrétan az interfész nevével (vagyis nem T implements IAkarmi, csak simán IAkarmi, de kiírható (ha 2 kell).
|
||||
Továbbá simán amikor függvény paraméternek használjuk, akkor lehessen rajta "constexpr elágazni" a típusán!
|
||||
|
||||
Vagyis írhatunk ilyeneket:
|
||||
|
||||
handle<IStringifyable, IStringifyable2 implements IStringifyable> {
|
||||
...
|
||||
}
|
||||
|
||||
Vagy akár ilyet is (bár ezt kevéssé javaslom, de hasznos lehet):
|
||||
|
||||
void process(IStringifyable arr[]) {
|
||||
switch(add.elemtype) {
|
||||
case A:
|
||||
...
|
||||
case B:
|
||||
...
|
||||
}
|
||||
}
|
||||
|
||||
Ifelni is lehet - olyankor például csak egy adott típusra valami speciális pluszt adni, kezelendő esetet...
|
||||
|
||||
Második változat:
|
||||
**Megoldás**
|
||||
|
||||
Lásd tagged union-oknál a "negyedik változat". Szerintem ez a legszebb!!! A tagged union tud implementálni interfészt és így
|
||||
sokkal egzaktabban történik ugyanez "háttérben titkos tagged union generálás nélkül" - na így lett letisztult!
|
||||
|
||||
+ ha nem tömbről van szó, akkor a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is (kell-e vajon?)
|
||||
+ a hívási ponton az egy lightweight generic támogatás / ad-hoc polimorfizmus is! Emiatt elvileg generic se kéne!
|
||||
|
||||
Az interfészekre lehet többszörös öröklődés (egymás közt is, meg itt is).
|
||||
|
||||
FONTOS: A shared object-ek között NEM ajánlódnak ki ilyen jellegű típusok! Csak rekordok!
|
||||
|
||||
Megj.: A második változat (tagged union-os megoldás) kell szerintem + lehessen handle interfészelés!
|
||||
Tehát egy handle is "implementálhat" interfészt és olyankor generikus kód keletkezik majd.
|
||||
Ennél azt is szeretném, ha "tömbre" is működne, tehát IGameObject stuff[] paraméterrel a függvény
|
||||
a hívási pontok alapján többféle módon is generatívan generálódik. Szerintem talán ki kell írni
|
||||
ott, hogy IGameObject-like és interfész "like-olása" mindig ezt jelentené?
|
||||
FONTOS: Adattagnak így nem lehet "interfész" típusa, csak tagged union-os esetben ugyebár...
|
||||
|
||||
## Láthatóság
|
||||
|
||||
TODO: Egyszeűsítendő?
|
||||
@ -1528,20 +1488,20 @@ Máshonnan elérni így lehet, namespace-elés szerűen:
|
||||
|
||||
Ha nem szerepel több szó a definíciós első sorban az enter előtt / zárójelek előtt, akkor csak kódot tartalmazó "funkcionális" szó:
|
||||
|
||||
#: #just_code
|
||||
#: just_code
|
||||
#dup
|
||||
#inc
|
||||
#swap
|
||||
#
|
||||
|
||||
#push(12)
|
||||
#just_code
|
||||
just_code
|
||||
#intprint // 12
|
||||
#intprint // 13
|
||||
|
||||
Vagy:
|
||||
Vagy(zárójelen belüli futásra):
|
||||
|
||||
#: #just_code (
|
||||
#: just_code (
|
||||
#dup
|
||||
#inc
|
||||
#swap
|
||||
@ -1657,6 +1617,7 @@ Ezt követően hívható a szó prefixelt változata
|
||||
#intprint // 4
|
||||
|
||||
Megj.: A #builtin esetben mindig van elég byte hely majd a parzernek helyben átírni a szót a megfelelőre (whitespace-es törléssel)
|
||||
Megj.: Erre nem kell külön runtime type - ezt lehet simán a deklarációkor helyben átfordítani!
|
||||
|
||||
## Névtelen szó - mégsem lesz!!!
|
||||
|
||||
@ -1743,6 +1704,7 @@ szöveges interfésszel, hanem simán csatornákkal és egy DAG-ot leírva, azé
|
||||
char name[]; // inline! Tehát nem egy pointer! Zero terminált a whitespace / zárójel felülírásával.
|
||||
char vars[]; // inline! Maga a tárhely is itt lesz! Elfér 4 byte ' @i,' vagy ' @j<EOL>' miatt!
|
||||
char data[]; // inline! Előbb a változók, aztán a kód - így írható primitív forth-szavakkal is kódszó (pl. outputra).
|
||||
char ender[]; // inline!
|
||||
};
|
||||
|
||||
A szavakat az "ender" string terminálja, a hosszt itt alapból nem tároljuk. Amikor a parzer látja
|
||||
@ -1765,34 +1727,38 @@ hasonló dolgokon túl! Amikor az első hívás történik, akkor megpróbáljuk
|
||||
ideiglenes tárhely sem szükséges, csak egy plusz számítási menet, amikor még NEM csináljuk meg, csak kiszámoljuk mibe
|
||||
kerülne és mennyi ram kell hozzá - kifér-e majd a jelen dolog helyére! Ha igen, akkor átírjuk + használjuk a stack-et.
|
||||
|
||||
Flag-ek:
|
||||
Flag-ek (flags):
|
||||
|
||||
0. offset_top
|
||||
1. offset_top
|
||||
2. offset_top
|
||||
3. offset_top
|
||||
4. DEF_TYPE0: definíciós típus első bitje
|
||||
5. DEF_TYPE1: 00: reguláris szó, 01: insertálóként definiált szó
|
||||
6. TYPE0: a típus első bitje
|
||||
7. TYPE1: a típus második bitje (00 - szöveg és futtatatlan, 01 - szöveg és futtatott, 10 - THREADED, 11 - internal (C ptr)
|
||||
4. offset_top
|
||||
5. offset_top
|
||||
6. WORD_TYP0: a típus első bitje
|
||||
7. WORD_TYP1: a típus második bitje
|
||||
|
||||
EDIT:
|
||||
enum SLC_WORDTYP {
|
||||
SLC_WORDTYP_TEXT = 0,
|
||||
SLC_WORDTYP_NATIVE = 1,
|
||||
SLC_WORDTYP_THREADED_SESSION = 2,
|
||||
SLC_WORDTYP_THREADED_INLINE = 3,
|
||||
};
|
||||
|
||||
Jelenleg úgy néz ki, hogy itt hét bitet is használhatnék - kérdés kéne-e vagy legyen még valami flag ott, mondjuk
|
||||
egy továbbfejlesztési lehetőségként. Szerintem az utóbbi és akkor a data[] inline helyett a hossz után ptr lesz!
|
||||
|
||||
Mi az a "threaded kód"?
|
||||
|
||||
A "threaded kód" lényegében karaktersorozat helyett egy uint32/64_t-sorozat, ahol szavak helyett indexek vannak
|
||||
az adott szavak definíciós pontjaira - DE! Viszont a zárójelek is el vannak kódolva. Alapvetően uint32_t, de
|
||||
a felső bit ha beáll akkor uint64_t kell két egymást követőt értelmezni (alsó 32 bit jön előbb módon!)
|
||||
A "threaded kód" lényegében karaktersorozat helyett egy uint32_t-sorozat, ahol szavak helyett indexek vannak
|
||||
az adott szavak definíciós pontjaira - DE! Viszont a zárójelek is el vannak kódolva (spéci uint32_t-ként)
|
||||
|
||||
Ettől jellemzően tömörebb és hatékonyabb lesz az interpretálás hiszen nem kell szöveget parzolni, nincs szótár lookup!
|
||||
Viszont megeshet, hogy "nincs elég hely" tárolni az adatokat a forrás szöveg helyén és nem optimalizálható olyankor...
|
||||
Ettől jellemzően tömörebb és hatékonyabb lesz az interpretálás hiszen nem kell szöveget parzolni,
|
||||
nincs szótár lookup, viszont megeshet, hogy "nincs elég hely" tárolni az adatokat a forrás szöveg helyén
|
||||
és vagy nem optimalizálható olyankor, vagy amit mi csinálunk: a session storage-be tesszük az adatot...
|
||||
|
||||
Érdekes elképzelés lehet egy kifejezetten UTF8-szerű encoding is, hogy lehetőleg 8-16-32 bitet használjunk csak / szó!
|
||||
|
||||
Érdekes elképzelés lehet egy kifejezetten UTF8-szerű encoding is, hogy lehetőleg 8-16-32-64 bitet használjunk csak / szó!
|
||||
Szerintem ez fontos lenne, hogy az optimalizációt többször hajthassuk végre és ne csak hosszú szavakat használó esetben!
|
||||
FONTOS: A threaded kódot megpróbáljuk a lehető leghamarabb "process-álással" generálni a session-be, de ha nem tudjuk azonnal
|
||||
a függőségek miatt, akkor ugyebár valamit tennünk kell, addig marad ahogy van...
|
||||
|
||||
Mint az egyértelmű, a szó deklaráció a kód szövegben legalább 4 byte-ot igénybe vesz és minden változó-deklarálás is!
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user