[cfe-dev] Custom C++ extension

[rzaghi at mosaic3dx.com]

Thanks guys. Your suggestions are interesting I will consider how much of the work I can get done with these.

Can I just copy paste another question I had asked earlier which I think was not noticed much?
"
What I am working on has many similarities to the way C++ Templates work.
There needs to be a declaration+definition and an instantiation phase.
My original prototype which didn’t use Clang produced standard C++ (source to source).
I would still like to have that option. However, I would also like to be able to go from
the source directly to the backend.
I think if I implement them the way C++’s Templates are implemented
in Clang then I would get the source to backend part.
But I had a quick look and it seems like the template instantiation
happens internally (i.e. only ASTs are produced).
So if I implemented these the way Templates work now, then is there
any ways to switch it to a source-to-source mode?
Can Clang, for example, emit C++ code after Template instantiation, somehow?
"


Regards
- Ramin


________________________________________
From: Jonathan Roelofs <jonathan at codesourcery.com>
Sent: 17 June 2015 18:37
To: rzaghi at mosaic3dx.com
Cc: Philip Reames; cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] Custom C++ extension

On 6/17/15 11:15 AM, Philip Reames wrote:
> On 06/15/2015 06:48 AM, Jonathan Roelofs wrote:
>>
>>
>> On 6/13/15 7:53 PM, rzaghi at mosaic3dx.com wrote:
>>>
>>> As an example, the extension would allow us to "tag" some identifiers
>>> in the code as follows:
>>>
>>> class CLXYZ { public: int <tag1> x; };
>>>
>>> The identifier tagged as such is later picked at one of the phases
>>> and operated on.
>>
>> For this particular example, have you considered using __attribute__
>> syntax [1], [2]?
>>
>> i.e. something like:
>>
>>   class CLXYZ { public: int x __attribute__((tag("1"))); };
>>
>> If you're able to leverage existing infrastructure, that will
>> significantly reduce your patch burden and make following trunk _much_
>> easier.
> You've already responded that you don't like the syntax, but I'd

Also, the syntax doesn't have to be so ugly while you're prototyping it,
provided you hide the attribute itself in a macro:

   #define TAG(x) __attribute__((tag(#x)))

   class CLXYZ { public: int x TAG(1); };

> strongly suggest considering attributes as an implementation mechanism.
> If you can reduce your patches to a custom bit of parsing which adds an
> attribute to the appropriate AST nodes and then phrase everything in
> terms of attributes, your merging/support is going to be much easier. It
> also gives you the possibility of pushing bug fixes and small extensions
> to the attribute mechanism upstream with standalone test cases.

+1

I wholeheartedly agree.


Cheers,

Jon

>
> I played with an extension a while back for supporting pre and post
> conditions on methods + object invariants.  I went through a couple of
> designs before setting on a "syntactic sugar" + "attributes" design and
> that really was the simplest to maintain.  (Mind you, this was strictly
> a hobby project so I wasn't that worried about perfection in the syntax
> or semantic analysis.)
>>
>>>
>>> (ps, not so related to my question but we call this
>>> "tagged-programming" paradigm. Actually we hope that the combination
>>> of these extensions can eventually help programmers in scenarios as
>>> the very question I am asking above!).
>>
>> How so?
>>
>>
>> Cheers,
>>
>> Jon
>>
>>
>> 1:
>> https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Variable-Attributes.html#Variable-Attributes
>>
>>
>> 2:
>> http://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attribute
>>
>>>
>>>
>>>
>>> _______________________________________________ cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

--
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded