optional warning on member access without this

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

optional warning on member access without this

Jochen Wilhelmy
Hi!

when accessing members, I use this-> since it shows the
member access in terms of the language. other common
ways are e.g. using a prefix like m_.

it would be cool if there is an optional warning if a member
is accessed without this->

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: optional warning on member access without this

Douglas Gregor

On Jan 15, 2010, at 2:19 PM, Jochen Wilhelmy wrote:

> Hi!
>
> when accessing members, I use this-> since it shows the
> member access in terms of the language. other common
> ways are e.g. using a prefix like m_.
>
> it would be cool if there is an optional warning if a member
> is accessed without this->


It would be easy to implement, although we would get strangled if it  
wasn't completely opt-in :)

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: optional warning on member access without this

Dan Villiom Podlaski Christiansen-2
In reply to this post by Jochen Wilhelmy
On 15 Jan 2010, at 23:19, Jochen Wilhelmy wrote:

> Hi!
>
> when accessing members, I use this-> since it shows the
> member access in terms of the language. other common
> ways are e.g. using a prefix like m_.
>
> it would be cool if there is an optional warning if a member
> is accessed without this->

If you implement this, you might want to consider implementing it for Objective-C as well :) (Objective-C uses ‘self’ instead of ‘this’, but otherwise the usage is similar.)

--

Dan Villiom Podlaski Christiansen
[hidden email]


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

getting module of backend consumer

Jochen Wilhelmy
In reply to this post by Douglas Gregor
Hi!

is it possible to get the module out of a backend consumer for linking?

At first I create a backend consumer with no output:

  clang::CreateBackendConsumer(clang::Backend_EmitNothing...

Then I do clang::ParseAST

Is it then possible to get the module for linking?
Or do I have to save as BC and then link from files?

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] getting module of backend consumer

Daniel Dunbar-2
Hi Jochen,

Currently we don't have any API for this. It should be easy to add,  
though, and definitely makes sense.

  - Daniel


On Jan 20, 2010, at 11:03 AM, Jochen Wilhelmy <[hidden email]>  
wrote:

> Hi!
>
> is it possible to get the module out of a backend consumer for  
> linking?
>
> At first I create a backend consumer with no output:
>
>  clang::CreateBackendConsumer(clang::Backend_EmitNothing...
>
> Then I do clang::ParseAST
>
> Is it then possible to get the module for linking?
> Or do I have to save as BC and then link from files?
>
> -Jochen
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] getting module of backend consumer

Jochen Wilhelmy
On 21.01.2010 01:27, Daniel Dunbar wrote:
> Hi Jochen,
>
> Currently we don't have any API for this. It should be easy to add,
> though, and definitely makes sense.
>
>  - Daniel
is there a chance that it will be done by one of the experts?
I don't have enough insight yet.

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Reference counting

Jochen Wilhelmy
In reply to this post by Daniel Dunbar-2
Hi!

when developing with clang/llvm I have quite a mess with
pointers, references, llvm::OwningPtr and get()

My suggestion would be (which won't get accepted due to the huge
code base) to have a llvm::Object that has a reference counter and
then a llvm::Pointer that increments/decrements the ref-count inside
the object.
Then for every class there has to be decided if it derives from Object and
always allocated with new and always passed as Pointer<>
or a struct and never allocated with new.

I use this scheme quite long now and never have problems except ring
references in complex graphs which have to be broken manually.

- Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reference counting

Chris Lattner

On Jan 21, 2010, at 8:10 AM, Jochen Wilhelmy wrote:

> Hi!
>
> when developing with clang/llvm I have quite a mess with
> pointers, references, llvm::OwningPtr and get()
>
> My suggestion would be (which won't get accepted due to the huge
> code base) to have a llvm::Object that has a reference counter and
> then a llvm::Pointer that increments/decrements the ref-count inside
> the object.
> Then for every class there has to be decided if it derives from  
> Object and
> always allocated with new and always passed as Pointer<>
> or a struct and never allocated with new.
>
> I use this scheme quite long now and never have problems except ring
> references in complex graphs which have to be broken manually.

The major reason we don't use reference counting in clang the clang  
AST (or llvm IR) is that it is a) expensive, and b) we have (or aim to  
have) very simple ownership policies that make it unnecessary.  For  
other heavier objects (e.g. ASTContext itself), it might make sense  
though.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] Reference counting

Jochen Wilhelmy

> The major reason we don't use reference counting in clang the clang
> AST (or llvm IR) is that it is a) expensive, and b) we have (or aim to
> have) very simple ownership policies that make it unnecessary.  For
> other heavier objects (e.g. ASTContext itself), it might make sense
> though.
Yes, I also think it the reference counting should be used only for
heavier objects, e.g. Module, Preprocessor,
Linker etc., of which you only have one or just a few.
If you use clang/llvm only as a blackbox library without looking into
the internals (like AST)  then
refcounted objects would be cool.

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Native llvm integer types in clang

Jochen Wilhelmy
In reply to this post by Dan Villiom Podlaski Christiansen-2
Hi!

is there a way to access the native llvm fixed width types in clang?

there is of course stdint.h which maps e.g.int32_t to int if int
has 32 bit. But is there a way to access the native types
like i32? perhaps via __i32 or __int(32) or whatever,
ranging from i1 to i256 ;-)
This also would simplify stdint.h.

But I guess this makes internal problens e.g. in the
name mangling.

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Native llvm integer types in clang

Chris Lattner

On Feb 1, 2010, at 9:35 AM, Jochen Wilhelmy wrote:

> Hi!
>
> is there a way to access the native llvm fixed width types in clang?
>
> there is of course stdint.h which maps e.g.int32_t to int if int
> has 32 bit. But is there a way to access the native types
> like i32? perhaps via __i32 or __int(32) or whatever,
> ranging from i1 to i256 ;-)
> This also would simplify stdint.h.
>
> But I guess this makes internal problens e.g. in the
> name mangling.

Many CPUs support many different integer types, for example x86-64 supports i8, i16, i32, i64, i128.

Your best bet is to use the int_fast*_t typedefs from <stdint.h>

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev