[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