Директивата @encode връща const char *, който е дескриптор на кодиран тип на различните елементи от типа данни, който е предаден. Следва пример:
struct test
{ int ti ;
char tc ;
} ;
printf( "%s", @encode(struct test) ) ;
// returns "{test=ic}"
Виждах използването на sizeof() за определяне на примитивни типове - и ако беше пълен обект, можех да използвам методите на класа, за да направя интроспекция.
Как обаче се определя всеки елемент от непрозрачна структура?
Отговорът на @Lothars може да е „циничен“, но за съжаление е доста близо до целта. За да приложите нещо като @encode(), имате нужда от пълен анализатор, за да извлечете информацията за типа. Е, поне за нещо различно от "тривиални" @encode() твърдения (т.е. @encode(char *)). Съвременните компилатори обикновено имат два или три основни компонента:
Предният край трябва да анализира целия изходен код и основно преобразува текста на изходния код във вътрешна, „машинно използваема“ форма.
Задната част превежда вътрешната, „използваема от машината“ форма в изпълним код.
Компилаторите, които имат "междинен край", обикновено го правят поради някаква нужда: те поддържат множество "предни части", вероятно съставени от напълно различни езици. Друга причина е да се опрости оптимизацията: всички пасове за оптимизация работят върху едно и също междинно представяне. Компилаторният пакет gcc е пример за "тристепенен" компилатор. llvm може да се счита за компилатор на етап "междинен и заден край": "Виртуалната машина от ниско ниво" е междинното представяне и цялата оптимизация се извършва в тази форма. llvm също може да го запази в това междинно представяне до последната секунда - това позволява "оптимизиране на времето за връзка". Компилаторът clang наистина е "преден край", който (ефективно) извежда llvm междинно представяне.
Така че, ако искате да добавите @encode() функционалност към „съществуващ“ компилатор, вероятно ще трябва да го направите като „компилатор/препроцесор“ от „източник към източник“. Това беше начинът, по който бяха написани оригиналните компилатори на Objective-C и C++ - те анализираха входния изходен текст и го преобразуваха в "обикновен C", който след това беше въведен в стандартния C компилатор. Има няколко начина да направите това:
yacc и lex, за да съставите анализатор на ANSI-C. Ще ви е необходима граматика - ANSI C граматика (Yacc) е добро начало. Всъщност, за да бъде ясно, когато казвам yacc, наистина имам предвид bison и flex. И също така, свободно, другите различни yacc и lex подобни на C-базирани инструменти: lemon, dparser и др...perl с Yapp или EYapp, които са псевдо-yacc клонинги в perl. Вероятно по-добре за бързо прототипиране на идея в сравнение с базираните на C yacc и lex - все пак е perl: регулярни изрази, асоциативни масиви, без управление на паметта и т.н.Забележка: Нямам личен опит с използването на който и да е от тези инструменти, за да направя нещо като добавяне на @encode(), но подозирам, че биха били голяма помощ.
@Lothar прави добра точка в коментара си. Всъщност възнамерявах да включа lcc, но изглежда, че се е загубил по пътя.
lcc C компилаторът. Това е C компилатор, който е особено малък, поне по отношение на размера на изходния код. Освен това има книга, която силно препоръчвам.tcc C. Не е толкова педагогически като lcc, но определено все пак си заслужава да бъде разгледан.poc Objective-C. Това е Objective-C компилатор от източник към източник. Той анализира изходния код на Objective-C и излъчва изходния код на C, който след това предава на gcc (е, обикновено gcc). Има редица разширения/функции на Objective-C, които не са налични в gcc. Определено си заслужава да се разгледа.Бихте приложили това, като първо внедрите ANSI C компилатора и след това добавите някои специфични за изпълнението прагми и функции към него.
Да, знам, че това е циничен отговор и приемам отрицателните гласове.
Един от начините да го направите е да напишете препроцесор, който чете изходния код за дефинициите на типове и също така замества @encode... със съответния низов литерал.
Друг подход, ако вашата програма е компилирана с -g, би бил да напишете функция, която чете дефиницията на типа от информацията за отстраняване на грешки на програмата по време на изпълнение, или да използвате gdb или друга програма, за да я прочете вместо вас и след това да я преформатира по желание. Командата gdb ptype може да се използва за отпечатване на определението на конкретен тип (или ако това не е достатъчно, има и maint print type, която със сигурност ще отпечата много повече информация, отколкото бихте искали).
Ако използвате компилатор, който поддържа плъгини (напр. GCC 4.5), може също да е възможно да напиша плъгин за компилатор за това. След това вашият плъгин може да се възползва от информацията за типа, която компилаторът вече е анализирал. Очевидно този подход би бил много специфичен за компилатора.
@encode препроцесор трябва да работи след C препроцесора, така че типовете, дефинирани между макросите #ifdef на C препроцесора, също да бъдат тези, анализирани от @encode препроцесора .
- person dreamlax; 13.02.2010
