[cfe-dev] Type Information for C++ classes

Manuel Klimek klimek at google.com
Fri Oct 12 01:13:06 PDT 2012


On Fri, Oct 12, 2012 at 7:38 AM, Mohammad Adil <madil90 at gmail.com> wrote:

> Also, Is it better to use libclang for doing this. My complete purpose is
> to refactor source code to find all functions, their arguments, return
> statements, all class members and methods. Can I find all this using
> libclang? I've heard that clang is unstable while libclang is stable. Which
> one should I use? I am currently using clang's internal API.


 http://clang.llvm.org/docs/Tooling.html

I don't have too much experience with using libclang for something like
this; what you want to do is definitely possible with LibTooling. And while
the internal clang AST interface is going to change more often than
libclang, in practice it is stable enough that you usually don't care
unless you want to ship a product (like an IDE) to end users. I'd try to
decide more on how much power you need, or what language you'd like to
write your integration in.

One good way is to try to start with libclang, and if you see that you're
hitting a missing feature, switch to using libtooling.

Cheers,
/Manuel


> On Fri, Oct 12, 2012 at 10:16 AM, Mohammad Adil <madil90 at gmail.com> wrote:
>
>> My purpose is to overload the << operator for all classes if they don't
>> already have one. The basic goal is to make all classes serializable over
>> some stream (ideally a network stream). Is that possible with clang? If
>> yes, How do I find all the member variables and functions of a class or
>> struct?
>>
>> On Thu, Oct 11, 2012 at 5:13 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> +cfe-dev
>>>
>>> On Thu, Oct 11, 2012 at 12:13 PM, Mohammad Adil <madil90 at gmail.com>wrote:
>>>
>>>> Sorry about that. I wasn't correctly changing my language from C to
>>>> C++. I figured that out. It's working now. I wanted to ask you one more
>>>> thing. I am trying to find all the return statements in the file. I can do
>>>> that easily but I know want to find out which function does this return
>>>> statement belong to? Since funcdecl and return statements are de-coupled, I
>>>> can't find a way to do so. Is there an easy way to do it?
>>>
>>>
>>> If you're using RecursiveASTVisitor, you can intercept the Traverse*
>>> calls to figure out AST child relations. Or you can use the AST matchers
>>> (functionDecl(hasDescendant(returnStmt()))).
>>>
>>> Cheers,
>>> /Manuel
>>>
>>>
>>>> On Wed, Oct 10, 2012 at 8:29 PM, Manuel Klimek <klimek at google.com>wrote:
>>>>
>>>>> On Wed, Oct 10, 2012 at 2:05 AM, madil90 <madil90 at gmail.com> wrote:
>>>>> > Hi,
>>>>> >    I am trying to find the type of a VarDecl. I am currently using
>>>>> the
>>>>> > VarDecl->getOriginalType(). This function does not work for C++
>>>>> classes.
>>>>> > Consider the code below:
>>>>>
>>>>> Does getType() not work for you for some reason?
>>>>>
>>>>> Cheers,
>>>>> /Manuel
>>>>>
>>>>> >
>>>>> > class Foo
>>>>> > {
>>>>> >     int a;
>>>>> > };
>>>>> >
>>>>> > int f( Foo foo);
>>>>> >
>>>>> > When I try to find the type for "foo" in the function decleration, it
>>>>> > returns "int", while the actual type is Foo. If Foo is a structure,
>>>>> this
>>>>> > works perfectly fine but not for C++ classes. Can some one please
>>>>> explain
>>>>> > where the type information for C++ classes is stored?
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > View this message in context:
>>>>> http://clang-developers.42468.n3.nabble.com/Type-Information-for-C-classes-tp4027266.html
>>>>> > Sent from the Clang Developers mailing list archive at Nabble.com.
>>>>> > _______________________________________________
>>>>> > cfe-dev mailing list
>>>>> > cfe-dev at cs.uiuc.edu
>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mohammad Adil
>>>> LUMS SSE
>>>>
>>>>
>>>
>>
>>
>> --
>> Mohammad Adil
>> LUMS SSE
>>
>>
>
>
> --
> Mohammad Adil
> LUMS SSE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121012/beb773e7/attachment.html>


More information about the cfe-dev mailing list