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.
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.
>>> "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.
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.
