Easy way to get function prototypes?_问答_开发者

A friend and I were discussing imaginary and real languages and a question that came up was if one of us wanted to generate headers for another language (perhaps D which already has a tool) what would be an easy and very good way to do this?

One of us said to scan C files and headers and ignore function bodies and only count the braces within to figure out when a function is finished. The counter to that was typedefs, defines (which braces but defines were considered as a trivial problem) and templates + specialization.

Another solution was to read binaries produce, not the actual exe but the object files the linker uses. The counter to that was the format and complexity. None of us knew anything of any object format so we couldnt estimate (we were thinking of gcc and VS c++).

What do you guys think? Which is easier? This should be backed up with reasonable logic and fact.

If someone can link to a helpful project, one that parses C files/headers and outputs it or one that reads in elf data and displays info in an example project would be useful. I tried googling bu开发者_开发问答t I didnt know what it would be called. I found libelf but at this moment I couldn't get it to compile. I might be able to soon.

You can use clang libraries to parse C/C++ source code and extract any information you want in particular function prototypes.

Due to library-based architecture it is easy to reuse parts of clang that you need. In your case these are frontend libraries (liblex, libparse, libsema). I think this is a more feasible approach then using hand-written scanner considering the difficulties that you mentioned (typedefs, defines, etc).

clang can also be used as a tool to parse the source code and output AST in XML form, for example if you have the file test.cpp:

void foo() {}

int main()
{
    foo();
}

and invoke clang++ -Xclang -ast-print-xml -fsyntax-only test.cpp you'll get the file test.xml similar to the following (here irrelevant parts skipped for brevity):

<?xml version="1.0"?>
<CLANG_XML>
  <TranslationUnit>
    <Function id="_1D" file="f2" line="1" col="6" context="_2"
              name="foo" type="_12" function_type="_1E" num_args="0">
    </Function>
    <Function id="_1F" file="f2" line="3" col="5" context="_2"
              name="main" type="_21" function_type="_22" num_args="0">
    </Function>
  </TranslationUnit>
  <ReferenceSection>
    <Types>
      <FunctionType result_type="_12" id="_1E"/>
      <FundamentalType kind="int" id="_21"/>
      <FundamentalType kind="void" id="_12"/>
      <FunctionType result_type="_21" id="_22"/>
      <PointerType type="_12" id="_10"/>
    </Types>
    <Files>
      <File id="f2" name="test.cpp"/>
    </Files>
  </ReferenceSection>
</CLANG_XML>

I don't think that extracting this information from binaries is possible at least for symbols with C linkage, because they don't have name mangling.

ctags' output is quite easy to read/parse

if you want to simply generate a binding, try swig

What you're talking about is compiling: The act of transforming code in one formal language to another. There's a good solid science behind this that, if followed carefully, will guarantee your program halts with a correct analogous code.

Granted, you don't want to parse the whole of the C++ language (hooray for that!), so you just need to define the relevant grammar and define everything else as acceptable noise or comments.

Don't use regular expressions. These won't do because C++ is not a regular language.

One way to do this is to define your interfaces in an abstract language (an IDL), and generate headers for all languages that you're interested in. You can limit the scope of your IDL to those features that are possible in each target language.

Windows takes this approach in its MIDL language, for example.

Doxygen can help with this. It's an advanced topic, and somewhat documented.

In a perfect world...

Each compiler of any programming language would emit such information as part of its output. It could be an ELF extension or a new generally accepted file format, which contains an ELF/COFF/whatever section.

This would spare the (across the globe) thousands of man hours to generate "language bindings" for dozens of languages. Dynamic languages, such as Common Lisp would not need FFI libraries - as it all would happen under the hood and loading a shared library in that new format could automatically be inspected and functions in it could be made available on the fly, without any further ado.

And all, which actually would have to be stored as extra information for each (exported) function is:

Generic name
Return type
Argument list
calling convention (there are not that many in practice)
A reference to the symbol table entry, referred to.

Why has it not been done during the past 30 years?

Because language designers still see the compiler output as their "private affair", whereas IMHO, this should be part of the OS/Runtime/Loader.

Many workarounds exist, some listed here in other answers (IDL, binding generators, such as SWIG and a myriad of others, mostly ad hoc and of varying and typically insufficient quality).

The ELF guys are Unix guys and as such C guys, who still live in a bubble, thinking C is some sort of "golden standard". But even they would not have any problems, using the information to generate their beloved header files.

RUST might not have invented crates in that perfect world and you would not even care if some shared library had been written in C or C++ or Rust or Zig or Haskell - anyone could just use it.

This domain is still dominated by "computer scientists", not engineers; while in theory, there could be an infinite number of calling conventions, in fact, those in active use are very countable few (LLVM supports many of those actually relevant).

Another reason, it has not been done yet, is that there is a danger, some committee would create a monster, trying make it "open, flexible, ..." and no one would eventually dare using it. DCE (distributed computing environment) gives that idea.