[cfe-dev] Custom C++ extension
Nikola Smiljanic
popizdeh at gmail.com
Sat Jun 13 19:17:37 PDT 2015
I guess it all depends on how localized you changes are. But you pretty
much answered your question, develop against trunk and merge often. I
remember a talk from someone at Embarcadero complaining about pain of not
doing this.
On Sun, Jun 14, 2015 at 11:53 AM, rzaghi at mosaic3dx.com <rzaghi at mosaic3dx.com
> wrote:
> Hey everyone on cfe-dev
>
> New list member but an old admirer of your great work here.
>
> I am planning the implementation of a set of C++ language extensions which
> we hope to be used in a [non-compiler related] research project at the
> University of Cambridge next year.
>
> Naturally, I chose Clang to do this. However, I have an "engineering"
> question.
>
> The extensions are, as you would imagine, not part of the standard - and I
> had like to add the word "yet", hehe.
>
> Given the potential invasiveness of some of the features and the pace of
> changes to the code base, I am left with no answer as to how I can keep up
> with the pace of the change and whether such requirements have been taken
> into account in the internal design of the front end, by any chances?
>
> Basically, I do not want to be in a position where we have working version
> of the extensions next year but based on a version of the front end which
> is one year old.
>
> It may help to give you a flavour of what some of these changes may look
> like.
>
> 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.
>
> So what is the best practice here? Other than rebasing every so often?
>
> Appreciate your input and advice.
> - Ramin
>
>
> (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!).
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150614/18eff64d/attachment.html>
More information about the cfe-dev
mailing list