[elektro] Fw: C18 előfordító
Ábrahám Gábor
agabor2 at freemail.hu
Tue Jun 16 20:09:56 CEST 2015
Miért nem jó erre a külön tool?
Írsz egy programot, aminek bementet egy file, amiben a stringek vannak,
kimenete meg egy másik, amiben a string meg a hozzá tartozó hash van.
A tool meghívódik fordítás előtt, vagy közben.
Ha én csinálnám, bemenet file: strings.txt
"str1",
"str2",
"str3"
output:
stringtbl.h
struct Stringtbl
{
char str[],
unsigned long hash
} ;
struct Stringtbl stringtb[] =
{
{ "str1", 12345 },
{ "str2", 2347 },
{ "str3", 34521 }
};
Csak minta akart lenni, nem működő program!
Gábor
----- Eredeti üzenet -----
From: Lajos Rancz
Helló!
Ezt nem a preprocessor csinálja, hanem a fordító! De vonatkoztassunk el!
Tfh van egy olyan bonyolult számításod ami:
- fordítási időben számítható lenne
- futási időben túlságosan költséges a számítása (és felesleges is előző
miatt)
Ezekre az esetekre nagyon jól jön, ha tudod szavatolni, hogy a kifejezés
kiértékelése megtörténik fordítási időben. Azért nem jó külön toolba rakni,
mert az egy csomó felesleges problémát behoz és sok esetben nem is járható
út.
Példát is hozok: konstans stringek hash számítása.
- van vmi adat struktúrád, aminek elemeit stringekkel azonosítod mert
így kényelmes
- ennek az adatstruktúrának az elérését meg megint stringekkel szeretnéd
megoldani
- mindezt a lehető leggyorsabban
Ekkor három lehetséges irány van:
- enum/define: az vele a probléma, hogy egy darab headerbe kell raknod
az összes lehetséges értéket, nem tudod dinamikusan bővíteni
- egy dictionary string kulccsal: nem lesz túl optimális, mert string
compareket kell használni (vagy unordered_map-nél string hash számítást)
- compile time számítod a hasht és ezt használod a mapban. Ez jó, csak
szavatolnod kell, hogy compile time előáll a hash
üdv
More information about the Elektro
mailing list