Получить параметры функций

#cpp #функции

Использую в программе систему перевода с применением функции Lang("Text"), которая
возвращает найденный перевод строки, либо переданный текст. По ходу вызовов Lang()
программа заносит новые слова в файл.
Как бы получить сразу все тексты во всех Lang()? Подозреваю, вариант с применением
#define и хитрым кодом. Хотя как вариант можно прогнать код программы через парсер.    

Ответы

Ответ 1

Для Windows, я бы решил эту проблему аналогично, как в ситуации: "Построение цепочки
потомков для каждого скомпилированного символа", при условии, что макрос _D выглядел
бы как-то так:

#define ___D( x ) #x
#define __D( marker, x ) ___D( marker ## x )
#define _D( x ) __D( LangMarker, x )


при том, что marker более ни где по коду в тексте встречаться не будет. И, соответственно,
использовался бы он так:

Lang( _D( someone save us ) );


Хотя, именно для такой задачи, "овчинка выделки не стоит".

Можно даже вырезать из всех этих строк сам маркер! Т.е. маркер будет выступать в
роли compile-time-атрибута, предписывающего размещение строки в таком массиве, но это
реализовать уже сложнее, т.к. потребует модификации всех ссылок на эти строки.

Можно в самом маркере закодировать переменную, в которую будет сливаться такой массив.
Т.е, на самом деле, вариантов, как это реализовать в compile-time достаточно много
и может ограничиваться только фантазией и возможностями самого языка.

Мои комментарии везде позаканчивались, поэтому я выбрал из своих ответов тот, который
бы решал поставленную задачу. Некоторые зависимые от него комментарии я так же переместил
в тело ответа, чтобы была понятна их связь. Следите, пожалуйста, за моими новыми комментариями
при редактировании ответа. К сожалению, более подходящего решения оставлять сообщения
в форуме я пока не вижу. Думаю, стоит этот вопрос вынести на рассмотрение администрации.

Комментарии:


  как это решение привязать к моей задаче


@mikelsv, это решение включает в себя "посткомпилятор", который найдет все строки
в объектных файлах и выделит из них только те, которые помечены маркером. Организует
из них список или вектор и поместит адрес его первого элемента в какую-нибудь статическую
переменную. Все это он сделает на этапе компиляции, поэтому в программе вектор/список
строк будет известен заранее, можно даже знать его размер заранее.


  Если вы говорите о синтаксисе времени выполнения, то не гарантировано, что любая
из конструкций Lang() вообще когда-либо сработает или вообще произведёт код


Я не говорю о синтаксисе времени выполнения, я говорю о compile-time выражениях,
которые допустимы в statement'е параметра функции.


  компиляция может до макроса Lang вообще не добраться. Например:


#ifdef SOMETHING
    Lang("1")
#else
    Lang("2")
#endif


Тогда это будет зависимая конструкция. Значит, в реальной программе эта конструкция
и не встретится никогда без перекомпиляции с SOMETHING.


  Так что рантайм и компиляция не кажется мне адекватным решением


Не уверен, что в адекватности дело.


  @mega: не, так нельзя рассуждать. Потому что если я перед функцией main напишу


int doexit() { exit(0); return 0; }
int i = doexit();



  то рантайм ни до одного Lang не доберётся. Чем это отличается от #ifdef? Ничем,
просто другой синтаксис.


@VladD, как это соотносится с условием задачи? От #ifdef это отличается тем, что
до Lang исполнение просто не доберется. Поэтому, если компилятор учитывает особенности
ОСи, он и формировать не будет "недосягаемый" код.


  Ergo: в рантайме вы не можете гарантированно добраться до содержимого Lang.


У меня другой вопрос: а зачем Вам "недосягаемый" Lang?
Ведь Вы можете написать:

#define MyLng( x ) Lang( x )


и везде в программе использовать MyLng, что в таком случае будете делать? Очевидно,
будете править свой фильтр, "раздувать" regexp для Lang, и возможно, все будет хорошо,
если не забудете, о каком-нибудь еще аналоге MyLng :)

Или можете поступить интереснее:

#define __Depend( x ) #x
#define _Depend( x, y ) x ##<-depend <-## y
#define Depend( x, y ) __Depend( _Depend( x, y ) )

Lang( Depend( head, neck ) )
Lang( Depend( head, _Depend( neck, body ) ) )


Очевидно, в такой ситуации очередное "раздувание" regexp будет частично включать
код самого макроса Depend, все его возможные вложения и, соответственно все зависимости,
которые из него вытекают. Т.е., у Вас и с досягаемым-то кодом уже проблемы, а Вы о
недосягаемом думаете, странно :)

По моему, один парсер ( а в нашем случае, лучше сказать - "сканер" ) эту задачу не
решит. Вернее, суть его решения всегда будет заключаться в том, как бы переписать фильтр
под конкретный код. А это означает, что человек, который его использует, при изменении
кода, всегда будет сталкиваться с исходной проблемой, т.е. он ее так и не решит.

Периодически, я с такими решениями тоже сталкиваюсь. Тот же doxygen - полезнейший
продукт, но абсолютно "тупой" парсер. Вот и ему приходится расписывать в PREDEFINED
десятки элементарных фильтров и следить за их обновлениями.


  Не знаю, как с макросами. Насколько я понял их надо вставить всюду в текст программы
внуть Lang? Такая идея мало кому из пишущих код понравится.


@avp, макрос нужен только для фильтрации строк, т.е., чтобы в массиве были только
определенные константные строки, а не все, что были скомпилированы. Ну, допустим, самый
простой вариант: все строки в Lang будут начинаться с ##, например: Lang( "##someone
save us" ). Т.е. нужна какая-то идентификация самих строк. Если она уже есть, значит
и код менять не потребуется.

Либо, как вариант: все эти строки будут находиться в определенном сегменте памяти
(секции), тогда модификации кода будут вообще минимальны. Я сейчас не могу сказать,
в каком классе данных находятся константные строки VS, надо разобрать для примера какой-нибуть
*.obj, со строками. Но в любом случае, это контролируется прагмой data_seg или code_seg,
поэтому, заключив функцию/класс/заголовок и т.п., который содержит массовые вызовы
Lang в определенный сегмент, его можно будет использовать в качестве фильтра, который
будет отделять обычные строки от искомых.


  Поэтому без парсера тут не обойтись.


Во во, и я о том же. А что может быть лучше парсера от VS? Наверное только парсер
от VS, его-то мы и используем. Нам ведь не сам парсер нужен. Нам нужны результаты его
работы. В *.obj и находятся результаты его работы.


  @mega: какой из примеров вы имеете в виду? #define MyLng( x ) Lang( x )? Это противоречит
заданию -- искать надо текст Lang(...)


MyLng как раз и делает вызов Lang(...). Как это может противоречить заданию?


  Но представьте себе, что у нас есть код:


if (random(4) < 0) { cout << Lang("1") }



  Компилятор знает, что значение random положительное, и выкидывает код при оптимизации.
Завтра приходит разработчик, находит ошибку и исправляет её. Запускать анализ снова?


Даже если представить, что Компилятор делает какие-то предположения по поводу этой
функции. Разработчик, исправив ошибку запустит процесс сборки заново. Т.е. запустит
всю цепочку утилит компоновки, в которую входят все задействованные компиляторы, мой
"посткомпилятор" (или "прелинкер"), и, непосредственно линковщик. Что с того? Будет
массив на один элемент длиннее, что от этого изменится? Или Вы переживаете на счет
того, что количество "билдов" программы увеличится? Не совсем я понимаю Вашу позицию.
Вы ее проясните пожалуйста, а то, подозреваю, ее не только я не понимаю.


Ответ 2

Если я все-таки правильно понял задачу. Сделать синглетон-обертку для контейнера,
например, множества std::set (или наследовать его)  и заносить туда в функции Lang()
все тексты, которые были переданы ей. Всегда можно прочитать содержимое этого контейнера.


Ответ 3

Вы под Юниксом? Попробуйте просто
grep -rh 'Lang(' projectDir/ | sed 's/Lang(/\n\0/g' | grep 'Lang(' | sed 's/^.*Lang(\([^)]*\)).*$/\1/'
| sort -u >out.txt

(Надеюсь, нигде не напутал. Пусть гуру шелла поправят.)