Using compiler error information to check undocumented prototypes and structures?

Qian Hong fracting at gmail.com
Fri Mar 6 01:03:24 CST 2015


Thanks Dmitry and Piotr for comments.

You are write, compiler is not enough in this case.

On Fri, Mar 6, 2015 at 1:04 AM, Piotr Caban <piotr.caban at gmail.com> wrote:
> The problem is that person that implements it in wine can't see native
> implementation. And parts of it are in the headers. In this case the names
> mangling gives us function prototype. The problem are class size, virtual
> functions table, public class members.
>
> Someone else can look on headers and document it for person that writes the
> implementation.

I have feeling that using libclang to write a customer parsing tool
can solve the problem in machine way rather than in human way.

I wrote a proof of concept using libclang pythong binding, see get_class.py.

Example:

$ python get_class.py test.cpp Room
Translation unit: test.cpp
class Room {
public:
    void add_person(Person)
    {
    }
    Person get_persons()
    {
    }
    int index;
}


find_classdecl firstly search for the class match the name we input,
then strips all methods and fields except public method and public
field, then strips the implementation details of the method, prints
only stub implementation of public methods, also prints the
declaration of public fields.



-- 
Regards,
Qian Hong

-
http://www.winehq.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cpp
Type: text/x-c++src
Size: 399 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150306/d545bd85/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: get_class.py
Type: text/x-python
Size: 1121 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150306/d545bd85/attachment.py>


More information about the wine-devel mailing list