Scripting C++ -- Boost.Python vs CORBA vs ???

Craig Maloney cmaloney at physics.ucsb.edu
Tue Feb 26 18:57:57 CET 2002


Craig Maloney wrote:
> Hi David.
> 
> Since I'm not a "computer guy" per se, I was wondering if you could 
> clear up some more of my confusion.  I don't know much about how 
> compilers work, but I would presume that any compiler (eg g++) would
> create some internal representation, similar to the .cil file, after
> parsing but before compiling.  
> 
> Presumably the EDG front end is geared toward producing this information
> in a format more suited to being used by the "wrapper generators" in contrast 
> with a compiler which produces this information only for itself and with 
> the sole goal of compiling an object file?  
> 
> What I'm getting at is that I'm confused as to why people wouldn't have
> used information from the compiler *itself* to automate the process of
> wrapper generation.  Obviously the compiler writer people would have to
> collaborate with the wrapper generator people... but there must be technical
> obstacles?
> 
> Cheers,
> Craig 

Actually, after doing a little more digging, I found this:

http://public.kitware.com/Cable/
http://public.kitware.com/GCC_XML/

Does anyone know anything about this project?

This is what I would have guessed would be the "right" way to go about 
things (having known nothing about the EDG front-end).  Presumably gcc 
gets the parsing right if it can compile ;)

What do people think?

--Craig

> 
> "David Abrahams" <david.abrahams at rcn.com> wrote in message news:<a5ekpq$n83$1 at bob.news.rcn.net>...
> 
>>I've been interested in systems for automatically wrapping C++ and
>>generating documentation for a while, so I downloaded the PDT (the parser
>>toolkit used by SILOON) and tried it on one of my source files. After lots
>>of hacking, I was able to get the EDG front-end component to parse my source
>>and generate an intermediate language (.cil) file, but the PDT executable
>>which is supposed to interpret the .cil and produce a high-level description
>>of the code crashed with an assertion:
>>
>>Assertion failed: ptr->assoc_template, file c:\documents and
>>settings\bertie\desktop\finalwinstuff\taucpdisp\src\disp-tau\il_display_tau.
>>c, line 3047
>>
>>Since the PDT doesn't come with source, there was no way for me to debug/fix
>>the problem.
>>Furthermore, the PDT developers don't seem to want to be reached. Their
>>contact page (http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/) says:
>>
>>    To contact the developers of PDT, please use the "Comments" section in
>>the download page.
>>
>>But of course, there is no "Comments" section on the download page. :=(
>>
>>-Dave
>>
>>"Craig Maloney" <cmaloney at physics.ucsb.edu> wrote in message
>>news:3C7A751D.1080703 at physics.ucsb.edu...
>>
>>>Hi Craig.
>>>
>>>Since your site specifically lists g++ 2.95 and NOT 3.x, am I to infer
>>>that there will be problems with the new ABI?  -- Or any problems that
>>>will, in practice or principle, cause conflicts with g++ 3.0?
>>>
>>>*Holds breath... and crosses fingers...*
>>>
>>>--Craig
>>>
>>>rasmussn at lanl.gov wrote:
>>>
>>>
>>>>On Wednesday, February 20, 2002, at 04:48 PM, David Abrahams wrote:
>>>>
>>>>
>>>>>>As I understand it, the SILOON project uses a commercial parser known
>>>>>>
>> as
>>
>>>>>>PDT from uoregon.  Have you, or has anyone else had any experience
>>>>>>
>> with
>>
>>>>>>the SILOON/PDT project?  On the face of it, my guess would be that you
>>>>>>would be somewhat skeptical of their claims?
>>>>>>
>>>>>
>>>>>I haven't had any experience with it. I just found that site. My
>>>>>skepticism
>>>>>just dropped by a factor of 8. If they are really using the EDG
>>>>>front-end as
>>>>>they claim to, then I am sure the parser is excellent. I do have to
>>>>>wonder
>>>>>who is paying for the FE. The issues of dealing with the semantics of
>>>>>what
>>>>>they've parsed remain, but these guys at least seem to be doing the
>>>>>parsing
>>>>>part right.
>>>>>
>>>>
>>>>It is my understanding that an educational or research license to the
>>>>
>> EDG
>>
>>>>front end is fairly easy to obtain.  The University of Oregon has
>>>>
>> obtained
>>
>>>>the right to distribute the EDG front-end as binaries and does so for
>>>>several
>>>>platforms in the Program Database Toolkit (PDT).  So for anyone wanting
>>>>interface level information from C++ or Fortran 90 source files, the PDT
>>>>is an excellent tool.  We use it in several projects.
>>>>
>>>>See http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/ and
>>>>http://www.acl.lanl.gov/siloon/ for more information.
>>>>
>>>>Craig
>>>>
>>>>
>>>>
>>>





More information about the Python-list mailing list