opencxx-users

[Opencxx-users] Re: [opencxx] patch by Jean-Sebastien Mouret

[Grzegorz J. <ja...@he...>]

Hi,

> From: Jean-Sebastien Mouret <js at lrde.epita.fr>
> Date: 22 Oct 2002 05:01:54 +0200
>
> Hi,
>
> Here is a very small patch to fix struct's members default access.
> As seen somewhere in the iso c++ standard:
> "Members of a class defined with the keyword class are private by
>  default. Members of a class defined with the keywords struct or
>  union are public by default."
>
> Let me know if this helps,

Big thanks for submitting this patch. The only thing I would suggest is to
use constants like 'Ptree* Class::class_t' (see mop.h), instead of char*.

> and if this is the correct way of
> submitting such tiny patches.

The desired way of submitting the patches is:

(1) Get yourself account on SourceForge.net (free).
(2) Send your SourceForge id to me, so that I can set up CVS access for you.
(3) Check out HEAD revision from CVS (http://sourceforge.net/cvs/?group_id=40789)
(4) Write a testcase which would fail without your patch, but passes
    when your patch is applied (step-by-step HOWTOs on adding testcases
    can be found in subdirs of 'testsuite/'; it's easy),
(5) Build and run testsuite (./configure; make; cd testsuite; make tests).
(6) Apply your patch.
(7) Again build and run testsuite.
(8) If everything is ok, commit (cvs commit).

I am ready to help with all these steps (however I will be traveling
during the next week and I am not sure if I will be able to access
internet; I should be back on Monday, Nov 4th).

Alternatively, you may try to find somebody on this list who already has
CVS access and try to convince that person to commit your changes. However
it seems not to be easier than committing the changes yourself :-)

Thanks again for the patch. Hope to hear from you again.

Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] [opencxx] (non member submission) another patch

[Shigeru C. <ch...@is...>]

From: Jean-Sebastien Mouret <js...@lr...>
Date: 22 Oct 2002 06:57:25 +0200

 From: Jean-Sebastien Mouret <js...@lr...>
 Date: 22 Oct 2002 05:01:54 +0200

 > Here is a very small patch to fix struct's members default access.
 > As seen somewhere in the iso c++ standard:
 > "Members of a class defined with the keyword class are private by
 >  default. Members of a class defined with the keywords struct or
 >  union are public by default."

Oups, sorry. First patch, first mistake. Here follows the correct
code to handle both struct and union properly.


--=-=-=
Content-Disposition: attachment; filename=member.cc.diff

--- src/member.cc	2001-12-10 05:23:25.000000000 +0100
+++ src/member.cc.new	2002-10-22 02:17:21.000000000 +0200
@@ -553,7 +553,7 @@
 
 void MemberList::AppendThisClass(Class* metaobject)
 {
-    int access = PRIVATE;
+    int access = (Ptree::Match(metaobject->Definition()->First(),"class") ? PRIVATE : PUBLIC);
     Ptree* user_access = nil;
     Ptree* members = metaobject->Members();
     while(members != nil){

--=-=-=--


-- 
js...@lr...
"creating the future" (c) framfab

[Opencxx-users] [opencxx] patch by Jean-Sebastien Mouret

[Shigeru C. <ch...@is...>]

 *** forwarded message - chiba ***

From: Jean-Sebastien Mouret <js...@lr...>
Date: 22 Oct 2002 05:01:54 +0200

Hi,

Here is a very small patch to fix struct's members default access.
As seen somewhere in the iso c++ standard:
"Members of a class defined with the keyword class are private by
 default. Members of a class defined with the keywords struct or
 union are public by default."

Let me know if this helps, and if this is the correct way of
submitting such tiny patches.


-- 
js...@lr...
"creating the future" (c) framfab


--=-=-=
Content-Disposition: attachment; filename=member.cc.diff

--- src/member.cc	2001-12-10 05:23:25.000000000 +0100
+++ src/member.cc.new	2002-10-22 02:17:21.000000000 +0200
@@ -553,7 +553,7 @@
 
 void MemberList::AppendThisClass(Class* metaobject)
 {
-    int access = PRIVATE;
+    int access = (Ptree::Match(metaobject->Definition()->First(),"struct") ? PUBLIC : PRIVATE);
     Ptree* user_access = nil;
     Ptree* members = metaobject->Members();
     while(members != nil){

--=-=-=--

[Opencxx-users] (no subject)

[Shigeru C. <ch...@is...>]

(Another forwarding. -- chiba)

 From: James Michael DuPont <mdu...@ya...>

> > I think a real problem is that the SF ML does not seem to provide a
> > way to register a list of subscribers at a time.  Every subscriber
> > must register herself to the SF ML manually.
> 
> I think we should proceed as Michael suggests, i.e. send the list of
> e-mail addresses to the support at SF and see if they can do the work
> for
> us. Chiba, could you? My only suggestion is that we state clearly,
> that
> those e-mail addresses are not to be disclosed. Generally I assume
> the
> folks at SF to be reasonable, but one cannot be paranoid enough. (I
> have
> lost one of my addresses to spam.)

Support page for opening tickets :
https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001

Jacob Moorman is the Support GURU, just open a ticket,
and send him a mail with the ID of the ticket, supplying the list
privatly and also asking him to help get it done quickly.

Email Addr:  mo...@us...  


Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

[Opencxx-users] [opencxx] non-member submission

[Shigeru C. <ch...@is...>]

Again, majordomo claimed non-member submission.  I forward it.

 From: Grzegorz Jakacki <ja...@he...>

On Mon, 14 Oct 2002, Shigeru Chiba wrote:

> Currently, while the TITECH ML sends a post to all the subscribers, it
> also forwards the post to the SF ML.  The SF ML does not re-send it to
> anybody but just archives it.  None can subscribe or directly post a
> message to the SF ML since it is moderated by me.

OK, that's smart.

> So we don't have to hurry but I think we should move.
>
> > Chiba, would that be possible to set-up autoresponder at current ML
> > address that would reply with something like "This list has moved to..."
> > etc. ?
>
> It should be possible if I write a few lines of Perl script. ;)

Great. That would assure, that we do not leave anybody over the board when
moving.

> I think a real problem is that the SF ML does not seem to provide a
> way to register a list of subscribers at a time.  Every subscriber
> must subscribe the SF ML manually.

I think we should proceed as Michael suggests, i.e. send the list of
e-mail addresses to the support at SF and see if they can do the work for
us. Chiba, could you? My only suggestion is that we state clearly, that
those e-mail addresses are not to be disclosed. Generally I assume the
folks at SF to be reasonable, but one cannot be paranoid enough. (I have
lost one of my addresses to spam.)

If anybody has any objections wrt. moving the list, please post them ASAP.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] [opencxx] non member submission?

[Shigeru C. <ch...@is...>]

(I forward this message. -- chiba)

 Date: Mon, 14 Oct 2002 08:26:51 -0700 (PDT)
 From: James Michael DuPont <mdu...@ya...>
 Subject: Re: [opencxx] Re: OpenC++
 To: op...@cs..., ja...@he...

> It should be possible if I write a few lines of Perl script. ;)
> 
> I think a real problem is that the SF ML does not seem to provide a
> way to register a list of subscribers at a time.  Every subscriber
> must subscribe the SF ML manually.

The people at SF have a pretty good attitude, if you register as
support request, most of the time they will help out in a few days.

Just send in the file with the user list to them and ask them to add it
in....

:)

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Shigeru C. <ch...@is...>]

From: Grzegorz Jakacki <ja...@he...>
Subject: Re: [opencxx] Re: OpenC++
Date: Mon, 14 Oct 2002 16:07:38 +0800 (CST)

> From the test I made this morning it looks like mail sent to ML at
> SourceForge is not propagated to ML at TITECH. Thus if somebody is unaware
> of existence of TITECH ML and posts messages to SF ML, his/her messages
> simply do not make it to the subscribers (which are still using TITECH
> ML).

Currently, while the TITECH ML sends a post to all the subscribers, it
also forwards the post to the SF ML.  The SF ML does not re-send it to
anybody but just archives it.  None can subscribe or directly post a
message to the SF ML since it is moderated by me.

So we don't have to hurry but I think we should move.

> Chiba, would that be possible to set-up autoresponder at current ML
> address that would reply with something like "This list has moved to..."
> etc. ?

It should be possible if I write a few lines of Perl script. ;)

I think a real problem is that the SF ML does not seem to provide a
way to register a list of subscribers at a time.  Every subscriber
must subscribe the SF ML manually.

Chiba

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Grzegorz J. <ja...@he...>]

On Fri, 11 Oct 2002, Shigeru Chiba wrote:

>
> From: Grzegorz Jakacki <ja...@he...>
> Subject: Re: [opencxx] Re: OpenC++
> Date: Fri, 11 Oct 2002 16:11:53 +0800 (CST)
>
> > I noticed there is now an archive on Sourceforge. And with spam protection
> > even :) Thanks!
> >
> > Wow, I did not realize that. It looks like Chiba did it. Thanks!
>
> Yes, I modified the original ML setting so that it forwards all
> submissions to the archived ML on Sourceforge.
>
> I think now we can move the ML onto sourceforge.  Do you move?

From the test I made this morning it looks like mail sent to ML at
SourceForge is not propagated to ML at TITECH. Thus if somebody is unaware
of existence of TITECH ML and posts messages to SF ML, his/her messages
simply do not make it to the subscribers (which are still using TITECH
ML).

I think this is the major reason to move ML to SF. I vote for moving ASAP.

Chiba, would that be possible to set-up autoresponder at current ML
address that would reply with something like "This list has moved to..."
etc. ?

Looking forward to hear your opinions.

Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Grzegorz J. <ja...@he...>]

On Fri, 11 Oct 2002, Carsten Pfeiffer wrote:

> > They look ok, please go ahead. Also please commit your testcase into the
> > test suite (there is HOWTO in 'testsuite/' dir on how to do it quickly).
>
> Ok will commit. The testcase is already in CVS, I committed it a few days ago,
> before I had the fix.

Thanks much.

Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Test

[Grzegorz J. <ja...@he...>]

This is test, please disregard.

I am trying to find out if messages sent to ML at SourceForge make it to
the list at csg.is.titech.ac.jp.

Grzegorz

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Carsten P. <car...@ce...>]

-----BEGIN PGP SIGNED MESSAGE-----

On Friday 11 October 2002 10:11, Grzegorz Jakacki wrote:

> > On Thursday 29 August 2002 13:14, Shigeru Chiba wrote:
>
>                                     ^^^^^^^^^^^^^
> I think it was me...

Ah, yes, he forwarded your mail, because it was rejected by majordomo for some 
unknown reason.

> They look ok, please go ahead. Also please commit your testcase into the
> test suite (there is HOWTO in 'testsuite/' dir on how to do it quickly).

Ok will commit. The testcase is already in CVS, I committed it a few days ago, 
before I had the fix.

Best wishes
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPaaiIqWgYMJuwmZtAQGAVQgAj+GWz/ea09p6oRz8Bl83hQ+G4KORK+xq
ShqC+8iVn4tFzyjJV3ZPDimHuUzTlFXRkO4HBXrGyUYbfCaELo0yzBOBRNyZyNVJ
3lKdAbJEbZOTcVyIc1NXfCpP5mRHSHqoF87pNUfGWZrZNgktgFMT1u0/E7Qi29mY
6QYiWPFWodqgKPdB9JfSUVlhHjzhu4WCEVvdBYOzMiDts/62y3y5KTRZbfWDGBF9
QUJiTW962om6PE6xFv13wa7SW4bWy1tRbG/fQY5roh0iSw6z6uf3pomdBNhBuYHY
a9O0cyHb5OXcauEfSoVLzOjy2Gicp1rliKwUOzC4h2UtlqxWxrSu2Q==
=DFSV
-----END PGP SIGNATURE-----

[Opencxx-users] [opencxx] Re: OpenC++

[Shigeru C. <ch...@is...>]

From: Grzegorz Jakacki <ja...@he...>
Subject: Re: [opencxx] Re: OpenC++
Date: Fri, 11 Oct 2002 16:11:53 +0800 (CST)

> I noticed there is now an archive on Sourceforge. And with spam protection
> even :) Thanks!
> 
> Wow, I did not realize that. It looks like Chiba did it. Thanks!

Yes, I modified the original ML setting so that it forwards all
submissions to the archived ML on Sourceforge.

I think now we can move the ML onto sourceforge.  Do you move?

Chiba

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Grzegorz J. <ja...@he...>]

On Thu, 10 Oct 2002, Carsten Pfeiffer wrote:

> On Thursday 29 August 2002 13:14, Shigeru Chiba wrote:
                                    ^^^^^^^^^^^^^
I think it was me...

[snip]
> I noticed there is now an archive on Sourceforge. And with spam protection
> even :) Thanks!

Wow, I did not realize that. It looks like Chiba did it. Thanks!

[snip]
> I have done the former, checking the environments and only overwriting the
> existing metaobject if they differ. That seems to suffice to fix the wrong
> lookup (the testcase that I checked in meanwhile passes).
>
> All testcases now pass -- please have a look and tell me if those patches
> should be committed.

They look ok, please go ahead. Also please commit your testcase into the
test suite (there is HOWTO in 'testsuite/' dir on how to do it quickly).

Thanks much!!!

Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] OpenC++ , can serve to my goal?

[Grzegorz J. <ja...@he...>]

On 8 Oct 2002, Bernardi Mario Luca wrote:

[intro snipped]
> I'd like to know if it is suitable as
> a analysis platform to extract from code the info i require ( for
> example list of Methods , Class Hierarchy , Symbols informations and
> the capability of identify some particular type of statements[like I/O
> statements] to record in witch method a MM-Path start and/or die).

Yes. Observe however, that there are two major modes of using OpenC++:

(1) Deriving classes from "Class" in order to customize the
    source-to-source translation.

(2) Taking OpenC++ source code as a code base to build your own
    application of top of it (it usually means deriving from "Walker"
    and/or making modifications to existing code).

From what you wrote about your requirements it looks like you should be
looking at mode (2).

> If someone who has a certain degree of practice with it can summarize me
> the features that the reflective approach can give to my goal i would
> thank him a lot! I've read some papers from the OpenC++ site but i need
> to better understand what openc++ can do and what remains on my
> shoulder :)

> i need to do some analysis on c++ code
> such as parsing

Probably OpenC++ has almost all of the things you need wrt. parsing C++.
There are some issues with new C++ constructs, like 'template' keyword
inside scoped identifier, 'explicit' or 'typename'. However fixing a parser
should not be a big problem.

> , symbol table management ,

The symbol table in OpenC++ is somewhat distributed. It is fundamentally
implemented by objects of "Environment" and "Class" connected through
miscellaneous pointers. The information on variables is not stored, i.e.
once the translator leaves the block of function scope it forgets what types
or variables were defined within. Thus if you want to have this information
available after parsing, you have to implmenet some storage mechanism by
yourself. Also OpenC++ does not remember the types it derives for symbols or
expressions. If you want to annotate the parse tree with types, you have to
implement this by yourself. I am told that Synopsis project, which is
reusing OpenC++ source, implemented the parse tree type annotations.

> control flow analysis and
> data flow analysis.

I am not sure what exactly you mean, but I think that OpenC++ does not
provide any data structures or algorithms to perform this kind of analysis.
However e.g. in my project I have implemented simple intra-procedural data
flow analysis and it went quite easy, I just derived my analyzer from
"Walker" class.

To give you full picture, this is a list of current issues with OpenC++:

* tampering with parse tree is difficult; parse tree is very verbose,
  every C++ construct is encoded (roughly) using lisp-like list
  constructors. The problem is that this structure is exposed to clients, in
  particular to the methods of Walker (or its derivatives) which perform
  translation. In other words your walker is given a pointer 'p' to the tree
  representing function definition, and in order to get function name you
  have to call 'p->Cdr()-Car()', in order to get function body you call
  'p->Cdr()->Cdr()->Cdr()->Car()', which again you will access with Cdr's
  and Car's (or other similar functions, which are nevertheless just
  shortcuts for some combinations of Cdr's and Car's). Your program works on
  lists, and you have to know how C++ constructs map into those lists (you
  can learn it from parser or from tree dumps). Also, when you write your
  code, you are hard-coding this knowledge. Thus if you want to change the
  parse tree, e.g. to add type annotation node (so-called 'Decorator'), you
  cannot simply change the representation of parse tree slightly, because
  you would break all the existing code, *including* the code in Walker on
  which you build your system. I think this is the major design problem at
  the moment, since it makes playing with existing OpenC++ very unsafe and
  difficult (however possible, as Synopsis example shows). I am thinking
  about a solution to this problem, but I do not expect to have any working
  solution soon. And even if I had I probably would not have time to
  implement it all by myself.

* templates are not fully supported. Templates were not in a language when
  OpenC++ was designed, so the support was added latter and is a kind of
  a patch. I was trying to fix it some time earlier this year and now HEAD
  branch can instantiate templates and identify types of the form
  'tmpl<args>::type'. However this implementation is far from being perfect,
  it does not take default arguments into account (this is easy to fix)
  nor does it understand templates specializations. Probably it is also
  going to be slow, as it does not cache instantiations (I left this issue
  for later, as for now it is not a problem for me).

* there is a quite low limit on the length of type identifiers; all type
  names are encoded and stored as strings. The length of those strings
  cannot exceed 256 or something. With template arguments it may be a
  problem, since type names may be arbitrary long, and the problem is that
  they really are even in Standard Library. This is a technical issue, but
  may require many modifications in the code if you really hit it.

* OpenC++ has problems with compiling Standard Library comming with newer
  compilers, like g++ versions 3.0 and above. This is not a big problem
  at the moment, since e.g. g++ 2.95 is quite a solid version and it is
  going to be around for a while, but eventually those problems need
  to be addressed. As I remember the problems arise due to some of the
  limitations listed above.

* The type evaluation is not completely implemented, i.e. typing of some
  expressions is simplified (e.g. operators). I remember that I had to
  augment the typing algorithm in several places and that it went quite
  smoothly. While this is some work due to many different cases, it
  should be generally easy to do.

* Overload resolution in type evauation is not implemented (this should be
  moderately difficult to implement). However OpenC++ correctly recognizes
  overloaded function/method definitions.

* OpenC++ use model needs a face-lift, e.g. on this list we agreed at some moment
  that "driver" functionality should be eventually moved out of the main
  executable, so that the translation is separated from other housekeeping
  tasks (calling preprocessor, linker, compiler etc.).

Those are the bad things. Remember however, that the list of good things
that OpenC++ provides is much longer. The work already accumulated in the
OpenC++ project is substantial and I doubt that you can quickly write
similar product from scratch, or even if you begin with yacc C++ grammar.
And even despite what I wrote about syntax tree, OpenC++ has object-oriented
design and is quite well structured.

Let me know if you have any other questions.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] Re: OpenC++

[Carsten P. <car...@ce...>]

-----BEGIN PGP SIGNED MESSAGE-----

On Thursday 29 August 2002 13:14, Shigeru Chiba wrote:

Hi,

I returned from vacation and found some time for OpenC++ again.

> I had a look. Indeed, that would work, however they are missing one thi=
ng,
> which I deem essential. They do not provide spam protection for e-mail
> adresses, so sooner or later everybody is going to start getting tons o=
f
> spam. I went through this and this is quite a lot of trouble and wasted
> time, belive me. I think that spam protection is cruicial.

I noticed there is now an archive on Sourceforge. And with spam protectio=
n=20
even :) Thanks!

> I can send you my private archive of OpenC++ mailing list (since around
> July 2001), but it is not complete. Let me know if it is ok to send you
> about 1MB in e-mail.

Yes, that would be great!

> > But this linking fails for me, if occ was not compiled with
> > - -export-dynamic, which is apparently necessary for GNU ld.
> > I'm unfortunately not too experienced with libtool and shared/static
> > libraries (nor with autoconf/automake).
>
> Try if `./configure --enable-shared' works for you. Libtool should take
> care of flags passed to the linker, no matter if it is GNU one or not.

That worked (after I modified Makefile.gc.in a bit to make it compile --=20
otherwise I got a symlink mark_rts.lo pointing to itself and ar complaini=
ng=20
about that).

I also had to add the tmplib directory to LD_LIBRARY_PATH so that libocc.=
so=20
was found.

> This is what I have learnt so far: Environment in OpenC++ is more or le=
ss
> what Standard calls a "scope". Class has its environment, function has =
its
[more helpful stuff snipped]

Thanks a lot for those explanations, they certainly helped me understand =
the=20
code better.

> Perhaps the code you are showing was supposed to handle cases like
>
>     class Foo;
>     class Foo { ... };
>     class Foo;

Yes, it indeed looks like this was the reason.

> To my understanding the correct version should check if the "Inner" cla=
ss
> found by the lookup is from the same environment as currently elaborate=
d
> "Inner" class. If not, then it should introduce a class into the curren=
t
> environment. AFAIR classes are "registered"  in two places --- in the
> environments where they are defined and in a global data structure (see
> `Class::AllClasses()').

I have done the former, checking the environments and only overwriting th=
e=20
existing metaobject if they differ. That seems to suffice to fix the wron=
g=20
lookup (the testcase that I checked in meanwhile passes).

All testcases now pass -- please have a look and tell me if those patches=
=20
should be committed.

Best wishes
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPaXYWqWgYMJuwmZtAQEqeAf+LxB3oBohS2CCIYYnkNQZ/KCyMkUxUj0u
7QbDBMLhD65gricRLUx6tXluCBRDDKud1iStNOGCp4YUHhcqUmPPBtLZQ4ychcaf
v0MeNdJ19b5As9zk4qWtOiwbUsywAajS4uuRvhJLgwPRvQIwBRaX0gl5UQGl1BX4
ikQwR8z3nqTiIQI33S5uRM8uqocoPJoca+qsw2AP5zSlxKxUkP0cLYi0bW0ov3tZ
Xi/dvX4HdLzEJHAWghv4cKDTRdZEzKCfzIMy+5ZjoHpUntE/TyV7FgU1IHVxn6Gq
rYuoM2YEf3Fj6hL9wBe2SUQKeE3KNrZira/gFFqWeQctORWxvuajkQ=3D=3D
=3DLkjV
-----END PGP SIGNATURE-----

[Opencxx-users] [opencxx] OpenC++ , can serve to my goal?

[Bernardi M. L. <mar...@in...>]

Hi all , 
I'm a Computer Science Engineering Student. I'm working at my master
thesis on the subject of Reverse Engineering. To be precise my thesis
is about the recovering of scenarios ( use cases view ) from C++ source
code. I've studied some methodologies about this recovering process
as MM-Path and ASF ( Atomic System Function ). To implement a software
tool that use these methodologies i need to do some analysis on c++ code
such as parsing , symbol table management , control flow analysis and
data flow analysis. I've not already done a deep analysis on *all*
information i must to extract from code but reading of OpenC++ it 
has interested me in some ways. I'd like to know if it is suitable as
a analysis platform to extract from code the info i require ( for
example list of Methods , Class Hierarchy , Symbols informations and
the capability of identify some particular type of statements[like I/O
statements] to record in witch method a MM-Path start and/or die).
If someone who has a certain degree of practice with it can summarize me
the features that the reflective approach can give to my goal i would
thank him a lot! I've read some papers from the OpenC++ site but i need
to better understand what openc++ can do and what remains on my 
shoulder :)
 
Cheers , 
Mario Luca Bernardi

[Opencxx-users] Re: [opencxx] Q: how to get the line# for class, member, or user specified modifier?

[Grzegorz J. <ja...@he...>]

Hi,

On Thu, 26 Sep 2002, Gang Wang wrote:

> I need the line # in the original .mc file to output more meaningful
> error messages, in order to show the user the exact location where
> error happens. I tried several methods and read through the doc
> several times. Still no clue about how to do it. Does anybody has any
> examples or tips?

Does

    Ptree* Environment::GetLineNumber(Ptree* expr, int& number)

work for you?

It is described in 'ref-appendix.html' which for some obscure reasons is
not part of the main documentation.

If the above is what you were looking for, please take half an hour of
your time and:

(1) send me your SourceForge userid
(2) checkout the opencxx source
(3) copy-paste 'ref-appendix.html' into main part of documentation.
(4) commit the changes into CVS

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] [opencxx] Q: how to get the line# for class, member, or user specified modifier?

[Gang W. <vis...@ho...>]

Hi,=20

I need the line # in the original .mc file to output more meaningful =
error messages, in order to show the user the exact location where error =
happens. I tried several methods and read through the doc several times. =
Still no clue about how to do it. Does anybody has any examples or tips?

Thanks a lot and have a good day. OpenC++ is great!!!

G. Wang

[Opencxx-users] [opencxx] Robert's code to be comitted into CVS

[Grzegorz J. <ja...@he...>]

Hi Everybody,

I would like to thank again Robert Stepanek for his last contribution.
Apart from patch for 2.5.12 already posted here, Robert prepared the patch
for CVS HEAD and I expect that we can have it in CVS within a week. I
would like to stress that Robert's contribution is extremely well-prepared
in that it also extends the existing html documentation wrt. to the new
functionality and provides the testcases for each new feature.

I can only wish that we have more contributions like this one.

Thanks
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] changes/occ2.5.12

[Grzegorz J. <ja...@he...>]

On Tue, 24 Sep 2002 ro...@lo... wrote:

> Hi,
>
> On Tue, 24 Sep 2002, Grzegorz Jakacki wrote:
>
> > > - I added a new suffix as an indicator for C++ source (.eti, it's really an
> > >   internal thing but I don't have the time to clean up my patch at the moment).
> >
> > This one I do not understand. Could you explain?
>
> Sure, to distinguish between files to be run through occ despite just
> being compiled "normally" we came up with a corresponding suffix to ease
> integration into our make environment. This really isn't useful for
> anybody outside our lab and will remove this patch from the patch for
> HEAD, should have done this anyway...

Thanks much.

Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] Re: [opencxx] changes/occ2.5.12

[<ro...@lo...>]

Hi,

On Tue, 24 Sep 2002, Grzegorz Jakacki wrote:

> > - I added a new suffix as an indicator for C++ source (.eti, it's really an
> >   internal thing but I don't have the time to clean up my patch at the moment).
>
> This one I do not understand. Could you explain?

Sure, to distinguish between files to be run through occ despite just
being compiled "normally" we came up with a corresponding suffix to ease
integration into our make environment. This really isn't useful for
anybody outside our lab and will remove this patch from the patch for
HEAD, should have done this anyway...

cu,
Robert
---
GPG: gpg --keyserver wwwkeys.pgp.net --recv-keys CCFDEB89

[Opencxx-users] Re: [opencxx] changes/occ2.5.12

[Grzegorz J. <ja...@he...>]

Robert,

First, big thanks for contributing your patch. Really decent piece of work
I must say! My comments follow:

On Fri, 20 Sep 2002 ro...@lo... wrote:

> In all the changes I thought about backward-compatibility so even I you wrote
> code which depends heavily on the occ internal object implementations this
> shouldn't break anything:
>
> - for all pure virtual functions you can remove the pure specifier with
>   Member::RemovePureSpecifier(). Had to do this, since the member's declarator
>   is private and I didn't want to mess around with the access specifiers.

Right.

> - I had to set MaxNameLen in encoding.h to 1024, due to some complicated
>   namespace nestings, which exceeded the 512 character limit. I personally
>   would prefer to make this limit unnecessary at all but what I understand
>   from the source it seems that this might mean to change code at various,
>   essential places so I am not sure if I will do it.

I think that indeed it would take a substantial effort. The general
comment, not pertaining specifically to your patch, is that it is
inevitable. AFAIR with current encoding scheme the encoding of any
component of scoped identifier cannot exceed 255, which is not much if the
component is a template instance.

> - I added a new suffix as an indicator for C++ source (.eti, it's really an
>   internal thing but I don't have the time to clean up my patch at the moment).

This one I do not understand. Could you explain?

> - I added a new command line switch (-T) which let's occ output the
>   translated parse tree on stdout in addition to writing it to an .ii file.
>
> - last, but not least: I added a method similar to CopyList to ptree-core.
>   CloneList has some advantages over CopyList which I found to be very
>   useful:

Makes sense. I remember that I needed something like that once.

Let me contact you directly wrt. committing changes to the repository.

Regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################

[Opencxx-users] [opencxx] changes/occ2.5.12

[<ro...@lo...>]

Hi List,

over the last month I've worked with OpenC++. Now there is the end of my project
near and I would like to share the changes I've made on occ with you in case
someone else might find useful what I did. Please note that this patch
is for version 2.5.12, I haven't found time to tweak the source to
work with the daily snapshots and 2.5.12 fit my needs most of the time.

In all the changes I thought about backward-compatibility so even I you wrote
code which depends heavily on the occ internal object implementations this
shouldn't break anything:

- for all pure virtual functions you can remove the pure specifier with
  Member::RemovePureSpecifier(). Had to do this, since the member's declarator
  is private and I didn't want to mess around with the access specifiers.

- for all array declarations you can get a PtreeList of the array range
  expressions by calling Member::GetArrayRange (e.g. int a[3][b][4] would
  get [[3],[b],[4]]). Had to do this since the declarator is private.

- as mentioned in another mail about 1 month ago: member variables of
  type array of builtin-type weren't treated as member variables in respect
  to the various TranslateMember(Write/...) routines. I fixed that with
  that a rudimentary patch, which handles these cases as special cases, so
  you would have to define new methods (TranslateArrayMemberWrite,
  TranslatePostfixOnArrayMember, etc.) to get the corresponding hooks in
  the translation. The added member methods are:

    virtual Ptree* TranslateMemberSubscript
    virtual Ptree* TranslateArrayMemberWrite
    virtual Ptree* TranslateUnaryOnArrayMember
    virtual Ptree* TranslatePostfixOnArrayMember

- I had to set MaxNameLen in encoding.h to 1024, due to some complicated
  namespace nestings, which exceeded the 512 character limit. I personally
  would prefer to make this limit unnecessary at all but what I understand
  from the source it seems that this might mean to change code at various,
  essential places so I am not sure if I will do it.

- I added a new suffix as an indicator for C++ source (.eti, it's really an
  internal thing but I don't have the time to clean up my patch at the moment).

- I added a new command line switch (-T) which let's occ output the
  translated parse tree on stdout in addition to writing it to an .ii file.

- last, but not least: I added a method similar to CopyList to ptree-core.
  CloneList has some advantages over CopyList which I found to be very
  useful:
    1.) in contrast to CopyList CloneList creates a copy of *each* node
        in the parse tree. CopyList on the contrary just makes a copy
	of the topmost list of nodes and let's the corresponding nodes
	Car fields stay the same (at pointer equality) so you won't really
	get a totally independent list of Ptree.

	CloneList on the other hand resembles the exact structure of the
	original tree but with copies of each node (either non-leaf or
	leaf).

     2.) CloneList uses a kind of a virtual constructor which I added to
         every subclass of (and including) Ptree. It therefore is possible
	 to do something like this:

	   ClassWalker walker(env);
	   Ptree* body = Ptree::CloneList(member.FunctionBody());
	   body = walker.Translate(body);

	 where Translate will call the corresponding TranslationHooks
	 of your method class *without* relexing and parsing the created
	 parse tree, since a Ptree-subclass will stay of the same type as the
	 original nodes one. (thanks to Grzegorz Jakacki for pointing me in the
	 right directions).

I thought this might be interesting to others so I will make my patch
available here:
http://lo-res.org/~rost/patch-openc++2.5.12-changes.rost.19092002.gz

Any comments are welcome,
cu,
Robert

---
GPG: gpg --keyserver wwwkeys.pgp.net --recv-keys CCFDEB89

[Opencxx-users] test (2)

[Shigeru C. <ch...@is...>]

This is the second test.

[Opencxx-users] test

[Shigeru C. <ch...@is...>]

This is a test message.