October 2005 - Transformers

Un Concurrent de Transformers ?
by Johan 31 Oct '05

31 Oct '05

Je me promenais sur comp.lan.c++.moderated quand je suis tombé sur ce thread (cf ci-dessous) qui devrait intéressé quelques Transformeux. Je n'ai jamais entendu parler de Semantic Designs auparavant, mais ce n'était peut-être pas votre cas... Malheureusement ce n'est pas du libre, mais je me demande quand même si ils font réellement tout ce qu'ils annoncent ? > ============================================================================== > TOPIC: C++ to XML parser - does one exist? > http:°groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9c0c41421249f04d > ============================================================================== > > == 1 of 1 == > Date: Sun 30 Oct 2005 08:21 > From: Ïra Baxter" > > > "John Nagle"<nagle(a)animats.com> wrote in message > news:aj86f.17908$6e1.13627@newssvr14.news.prodigy.com... >> I'm looking for a tool to simplify program manipulation. >> I need something that parses C++ into a tree format, >> INCLUDING the comments and line breaks, and which can >> also turn that tree format back into source text. >> The parse tree must identify the syntatic elements of C++, >> with function calls and type declarations correctly parsed. >> >> Ideally, the parser would generate the tree as an XML >> file, for ease of handling. But that's optional. >> >> The idea is to allow writing simple tools that check >> or modify declarations and function calls to add some >> safety checks. >> >> Does anything like this exist? > > See http:°www.semdesigns.com/Products/FrontEnds/CppFrontEnd.html > > This is a C++ front end built on top of DMS, > general-purpose program transformation machinery, > and is offered as an industrial strength > commercial product. > > It has a full C++ preprocessor and parser (for most commonly > used dialects including ANSI, GNU, and the various MS dialects), > automatically builds trees as it parses, capturing comments > and lexical formats (indentation, number radix, ...) > and builds a full symbol table. > It makes those trees/symbol table available to custom code > you write to accomplish your task, including arbitrary analysis > and or serious automated transformation of the code. > You can regenerate complete source text from the trees, > including preprocessor directives (with some limitations) > the comments and other lexical formats as undisturbed, > or programmatically change that lexical information. > > A trivial custom task is to call the XML export > function in the supplied AST management API > to dump out the tree as XML ;-}. While you > can do this, when you discover how big trees > are, you may find this isn't the best option, > especially considering that DMS provides > extremely good facilities for transforming trees. > > This tool has been used for massive C++ source-to-source > transformations. See the DoD Crosstalk article on > automate C++ component reengineering at > http:°www.semdesigns.com/Company/Publications/CrosstalkArticle/Crosstalk-05-2005.html > > >-- >Ira D. Baxter, Ph.D., CTO 512-250-1018 >Semantic Designs, Inc. www.semdesigns.com -- Johan Lunsford's Rule of Scientific Endeavor: The simple explanation always follows the complex solution.

2 1

Next release
by Akim Demaille 20 Oct '05

20 Oct '05

Please, use consistent name conventions. For instance I read `c-condition', and then ContractC.sdf, and then, prepost.str etc. I suggest to rename everything as ContractC (contractc) consistently with the paper.

2 2

Re: [Transformers] Aaaaaaaaaaaaaarg !
by Akim Demaille 10 Oct '05

10 Oct '05

>>> "Nicolas" == Nicolas Desprès <nicolas.despres(a)gmail.com> writes: > On 9/20/05, Akim Demaille <akim(a)lrde.epita.fr> wrote: >> - Ne pas utiliser argv[0] dans les messages d'erreur. >> Ne surtout *jamais* coder un nom en dur, du genre SdfChecker, >> dans les messages d'erreur, les logs, etc., mais bel et bien >> argv[0]. Sinon, ceux qui debuggent vous maudissent ! > Je ne comprend ce point. Tu dis d'abord de "ne pas utiliser argv[0] > dans les message d'erreur". Ensuite, tu dis de "ne surtout *jamais* > coder un nom en dur [...] dans les messages d'erreur [...], mais bel > bien argv[0]". J'ai l'impression que ces deux phrases sont > contradictoires. Peux-tu m'aider, car c'est une question pour laquelle > je n'ai toujours pas trouvé de réponse: "argv[0] ou pas" ? > PS: Peut-être suis-je stupide et ai-je mal interprété ton post... Oui, il te manque la tête de l'énumération, que je reproduis ici : | Il y a deux choses *interdites* qui ont l'air d'être faites très | souvent dans Tfers : | | - Utiliser @ pour cacher les commandes dans un Makefile. | | - Ne pas utiliser argv[0] dans les messages d'erreur.

1 0

Aaaaaaaaaaaaaarg !
by Akim Demaille 08 Oct '05

08 Oct '05

Il y a deux choses *interdites* qui ont l'air d'être faites très souvent dans Tfers : - Utiliser @ pour cacher les commandes dans un Makefile. C'est une erreur grave ! - Ne pas utiliser argv[0] dans les messages d'erreur. Ne surtout *jamais* coder un nom en dur, du genre SdfChecker, dans les messages d'erreur, les logs, etc., mais bel et bien argv[0]. Sinon, ceux qui debuggent vous maudissent ! Merci d'en tenir compte et de réparer tous les endroits malades de Tfers.

2 1