Простая библиотека-парсер C/C++

[ilovb]

Существует ли такое в природе? Чем проще, тем лучше.
Т.е. чтобы были например итераторы по списку функций, типов, переменных и т.д.

Хочу написать на Lua тузлятину для конвертации сишных хидеров в бинд для CP.

[valexey_u]

Существует ли такое в природе? Чем проще, тем лучше.
Т.е. чтобы были например итераторы по списку функций, типов, переменных и т.д.

Хочу написать на Lua тузлятину для конвертации сишных хидеров в бинд для CP.

В общем случае это сделать не возможно (даже руками это сделать не всегда возможно в полной мере).

А вообще, я бы взял clang для парсинга. Я хм.. Не помню, но вроде бы у clang'а даже была опция - обработать исходник и выплюнуть дерево разбора в виде xml (или чего-то еще на s-выражениях).

[ilovb]

Я знаю что невозможно. Но можно хоть полуавтоматический режим сделать. Руками уж больно муторно кучу простых операций делать. Даже в ST2 

Для clang я нашел даже бинд к Lua. Но что-то оно мне показалось слишком низкоуровневым.
https://github.com/mkottman/luaclang-parser

Хотя может и подойдет. Сейчас как раз пытаюсь собрать эту штуку.

[Valery Solovey]

а может, лучше выковыривать список экспорта сразу из бинарника? Это ж, наверное, возможно?

[valexey_u]

а может, лучше выковыривать список экспорта сразу из бинарника? Это ж, наверное, возможно?

Там нет информации о типах и сигнатуре функций (если мы про Си говорим а не С++).

[Valery Solovey]

А чем тогда помогают биндинги? Вот, например, есть у нас длл-ка. Как биндинг поможет вызвать правильную функцию, если компилятор другого языка не знает смещения продпрограмм внутри dll?

[valexey_u]

А чем тогда помогают биндинги? Вот, например, есть у нас длл-ка. Как биндинг поможет вызвать правильную функцию, если компилятор другого языка не знает смещения продпрограмм внутри dll?

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

Так вот, когда ты пишешь биндинг, ты убеждаешь именно СВОЙ компилятор чтобы он правильно вызывал функцию сторонней этой либы. Чтобы он нужное число аргументов скажем положил на стек.

[ilovb]

Чей-то не могу собрать. CMake вроде отрабатывает нормально. Но в результате ничего не собирается.

[ilovb]

Ненавижу с++. Ненавижу мэйкфайлы. Ненавижу бесконечные ошибки и окошки с исключениями в программах, написанных на с++.

Пока пытался собрать эту хрень ТРИ РАЗА ПАДАЛ Cmake. Раз 20 он выдавал полную ахинею. И в итоге нормальный результат так и не выдал.
ДВА РАЗА ПАДАЛ FAR во время набора текста во встроенном редакторе.
В итоге пришлось компилить и линковать все ручно. Указал при линковке все либы clang И ОНО СУКА НЕ ЛИНКУЕТСЯ.
вываливает том воины и мира с таким содержанием:

Код: [Выделить]

libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x2d): undefined reference to `_imp__pthread_mutexattr_init'               
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x40): undefined reference to `_imp__pthread_mutexattr_settype'           
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x51): undefined reference to `_imp__pthread_mutexattr_setpshared'         
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x5e): undefined reference to `_imp__pthread_mutex_init'                   
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x67): undefined reference to `_imp__pthread_mutexattr_destroy'           
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0x87): undefined reference to `_imp__pthread_mutex_destroy'               
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0xa6): undefined reference to `_imp__pthread_mutex_lock'                   
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0xc2): undefined reference to `_imp__pthread_mutex_unlock'                 
libLLVMSupport.a(Mutex.o):Mutex.cpp:(.text+0xde): undefined reference to `_imp__pthread_mutex_trylock'               
libLLVMSupport.a(Threading.o):Threading.cpp:(.text+0xfa): undefined reference to `_imp__pthread_attr_init'           
libLLVMSupport.a(Threading.o):Threading.cpp:(.text+0x123): undefined reference to `_imp__pthread_create'             
libLLVMSupport.a(Threading.o):Threading.cpp:(.text+0x130): undefined reference to `_imp__pthread_attr_destroy'       
libLLVMSupport.a(Threading.o):Threading.cpp:(.text+0x145): undefined reference to `_imp__pthread_attr_setstacksize'   
libLLVMSupport.a(Threading.o):Threading.cpp:(.text+0x169): undefined reference to `_imp__pthread_join'               
libLLVMSupport.a(Signals.o):Signals.cpp:(.text+0x31f): undefined reference to `_imp__SymSetOptions@4'                 
libLLVMSupport.a(Signals.o):Signals.cpp:(.text+0x339): undefined reference to `_imp__SymInitialize@12'               
libLLVMSupport.a(Process.o):Process.cpp:(.text+0xa4): undefined reference to `GetProcessMemoryInfo@12'               
libLLVMSupport.a(ThreadLocal.o):ThreadLocal.cpp:(.text+0x12): undefined reference to `_imp__pthread_key_delete'       
libLLVMSupport.a(ThreadLocal.o):ThreadLocal.cpp:(.text+0x63): undefined reference to `_imp__pthread_key_create'       
libLLVMSupport.a(ThreadLocal.o):ThreadLocal.cpp:(.text+0x78): undefined reference to `_imp__pthread_setspecific'     
libLLVMSupport.a(ThreadLocal.o):ThreadLocal.cpp:(.text+0x8c): undefined reference to `_imp__pthread_getspecific'     
Сегодня на работе 1С падала тоже раза 3 с исключениями.

ДОПОТОПНОЕ ДЕРЬМО ЭТОТ ВАШ с++.

[valexey_u]

Чо-то походу оно cygwin'овое хочет :-)

[Berserker]

Борис, как я Вас понимаю...У самого такое же чувство было.
Всё-таки приятно открыть чужой присланный делфийский проект и щелчком его собрать весь без плясок с бубном.

[vlad]

Борис, как я Вас понимаю...У самого такое же чувство было.
Всё-таки приятно открыть чужой присланный делфийский проект и щелчком его собрать весь без плясок с бубном.

Плата за кроссплатформенность. Я сам содрогаюсь когда дело доходит до сборки чего-то третьестороннего.

[ilovb]

Песец. Скачал вот эту хрень https://github.com/gccxml/gccxml

Натравил на нее CMake под MinGW.
Со второй попытки желанный мейкфайл таки сформировался.
Запустил сборку. Собирается!... собирается... соб.... ННННАА!

...
[ 33%] Building CXX object KWSys/CMakeFiles/gxsys.dir/Directory.cxx.obj                                                                 
[ 38%] Building CXX object KWSys/CMakeFiles/gxsys.dir/RegularExpression.cxx.obj                                                         
[ 42%] Building CXX object KWSys/CMakeFiles/gxsys.dir/SystemTools.cxx.obj                                                               
Linking CXX static library libgxsys.a                                                                                                   
[ 42%] Built target gxsys                                                                                                               
Scanning dependencies of target gccxml_vcconfig                                                                                         
[ 47%] Building CXX object VcInstall/CMakeFiles/gccxml_vcconfig.dir/vcInstall.cxx.obj                                                   
[ 52%] Building CXX object VcInstall/CMakeFiles/gccxml_vcconfig.dir/__/GXFront/gxSystemTools.cxx.obj                                   
C:\BUILD\gccxml\GCC_XML\GXFront\gxSystemTools.cxx: In static member function 'static bool gxSystemTools::RunCommand(const char*, std::st
ring&, int&)':                                                                                                                         
C:\BUILD\gccxml\GCC_XML\GXFront\gxSystemTools.cxx:56:12: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings
]                                                                                                                                       
Linking CXX executable ..\gccxml_vcconfig.exe                                                                                           
[ 52%] Built target gccxml_vcconfig                                                                                                     
Scanning dependencies of target vcInstallPatch                                                                                         
[ 57%] Generating ../vcInstall_stamp.c                                                                                                 
None of MSVC 6, 7, 7.1, 8, 9 or 10 is installed.                                                                                       
[ 57%] Built target vcInstallPatch                                                                                                     
Scanning dependencies of target gccxml                                                                                                 
[ 61%] Building CXX object GXFront/CMakeFiles/gccxml.dir/gxSystemTools.cxx.obj                                                         
C:\BUILD\gccxml\GCC_XML\GXFront\gxSystemTools.cxx: In static member function 'static bool gxSystemTools::RunCommand(const char*, std::st
ring&, int&)':                                                                                                                         
C:\BUILD\gccxml\GCC_XML\GXFront\gxSystemTools.cxx:56:12: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings
]                                                                                                                                       
[ 66%] Building CXX object GXFront/CMakeFiles/gccxml.dir/gxConfiguration.cxx.obj                                                       
[ 71%] Building CXX object GXFront/CMakeFiles/gccxml.dir/gxDocumentation.cxx.obj                                                       
[ 76%] Building CXX object GXFront/CMakeFiles/gccxml.dir/gxFlagsParser.cxx.obj                                                         
[ 80%] Building CXX object GXFront/CMakeFiles/gccxml.dir/gxFront.cxx.obj                                                               
C:\BUILD\gccxml\GCC_XML\GXFront\gxFront.cxx: In function 'int main(int, char**)':                                                       
C:\BUILD\gccxml\GCC_XML\GXFront\gxFront.cxx:179:27: error: '_putenv' was not declared in this scope                                     
make.EXE[2]: *** [GXFront/CMakeFiles/gccxml.dir/gxFront.cxx.obj] Error 1                                                               
make.EXE[1]: *** [GXFront/CMakeFiles/gccxml.dir/all] Error 2                                                                           
make.EXE: *** [all] Error 2                                                                                                            

Видимо в создании с++ замешаны наци

[valexey_u]

Борис, как я Вас понимаю...У самого такое же чувство было.
Всё-таки приятно открыть чужой присланный делфийский проект и щелчком его собрать весь без плясок с бубном.

Гг. А вот если тебе прислали делфевый проект под винду а ты его собираешь во фрипаскале под линуксом - тоже все хорошо будет? :-)

Собственно когда собираешь юниксовыми тулзами проект созданный под юникс скажем в линуксе, то все ок. Да даже в OS X более-менее ок. А вот как в винде - сразу жесть, содомия и фиг знает что. Просто потому, что винда не следует каким-либо стандартам.

Если в винде тебе прислали студийный проект (то есть не автогенереный тулзами студийный, а человек реально в студии все это собирал и разрабатывал), то все опять ок.

В общем то это все от языка не зависит. Знаю товарищей которые вообще все (вне зависимости от языка) собирают например maven'ом. Система сборки она сбоку от языка. Обычная автоматизирующая штука.

[ilovb]

Однако в с++ такая система сборки именно благодаря особенностям идеологии самого с++