Директива @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. Вероятно, лучше подходит для быстрого прототипирования идеи по сравнению с yacc и lex на основе C - в конце концов, это 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
