opencxx-users

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

On Thu, 13 Mar 2003, Alexandre Tolmos wrote:

>
> Le jeudi, 13 mar 2003, =E0 17:28 Europe/Paris, Michael Hohmuth a =E9cri=
t :
>
> > Grzegorz Jakacki <ja...@he...> writes:
> >
> >> When you wrote, that you checked in patch for gcc-3.2 I just checked
> >> out
> >> and it did not compile. Thus I assumed that you forgot to checkin
> >> the new version of gc. I thought that you send the patch just for my
> >> convinience, while CVS already contains the correct version of gc.
> >
> > I see -- sorry for the confusion.  As I wrote in another email, I use
> > the new GC only privately, and I have to expertise for merging
> > `libtool'd projects.
> >
> > I noticed that Alexandre has checked in parts of GC 6.2.alpha4.  The
> > CVS tree currently is in an unbuildable state; I assume he is
> > currently working on merging the new GC?
>
> Ooops sorry, my bad. I wanted to checkin in my own branch. I made a
> mistake somewhere.

This happens once in a while. Just if you can rollback to the version fro=
m
before you checkin and test. "-D" option may help.

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] Member::Name()

[Stanislav K. <st...@uc...>]

when calling Member::Name() on a member function object
I get a ptree with the name of the method, but when I try to
call Environment::GetLineNumber on this ptree, I get a:
file: unknown

// code:
// m is a Member object representing a method
env -> GetLineNumber(m.Name())->Display();

Output:
unknown


If I call Environment::GetLineNumber on a member.FunctionBody()
I get a valid file and line number.

any ideas?
thanks

I am using:
OpenC++ 2.5.12
gcc 2.96

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Alexandre T. <kt...@fr...>]

Le jeudi, 13 mar 2003, =E0 17:28 Europe/Paris, Michael Hohmuth a =E9crit =
:

> Grzegorz Jakacki <ja...@he...> writes:
>
>> When you wrote, that you checked in patch for gcc-3.2 I just checked =20
>> out
>> and it did not compile. Thus I assumed that you forgot to checkin
>> the new version of gc. I thought that you send the patch just for my
>> convinience, while CVS already contains the correct version of gc.
>
> I see -- sorry for the confusion.  As I wrote in another email, I use
> the new GC only privately, and I have to expertise for merging
> `libtool'd projects.
>
> I noticed that Alexandre has checked in parts of GC 6.2.alpha4.  The
> CVS tree currently is in an unbuildable state; I assume he is
> currently working on merging the new GC?

Ooops sorry, my bad. I wanted to checkin in my own branch. I made a =20
mistake somewhere.

------------------------------------------------------------------------=20
-
Alexandre Tolmos
E-mail:=A0...@fr...
ICQ: 92964905
------------------------------------------------------------------------=20
-
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
------------------------------------------------------------------------=20
-

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Michael H. <ho...@sa...>]

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

> When you wrote, that you checked in patch for gcc-3.2 I just checked out
> and it did not compile. Thus I assumed that you forgot to checkin
> the new version of gc. I thought that you send the patch just for my
> convinience, while CVS already contains the correct version of gc.

I see -- sorry for the confusion.  As I wrote in another email, I use
the new GC only privately, and I have to expertise for merging
`libtool'd projects.

I noticed that Alexandre has checked in parts of GC 6.2.alpha4.  The
CVS tree currently is in an unbuildable state; I assume he is
currently working on merging the new GC?

Kind regards,
Michael
-- 
ho...@sa..., ho...@in...
http://www.sax.de/~hohmuth/

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

[Michael H. <ho...@sa...>]

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

> Conceptually OpenC++ consists of three sybsystems:
>
>     Frontend --- reads preprocessed sources, makes parse tree
>         out of them; possibly OpenC++ static analyzer also belongs
>         in this subsystem
>
>     Translator --- traverses syntax tree and transforms it
>         according to rules described by metaclasses
>
>     Driver --- runs preprocessor, Frontend, Translator,
>         native compiler and linker.
>
> As I understand Michael and Stefan work with Frontend and are not interested
> in the rest of the system. I believe, that this is the most frequently
> reused part of OpenC++ and I know of at least three more projects that
> reuse just this part.

(Just as an aside: Would you mind posting a list of the projects you
know that use OpenC++ to this list or the project's homepage?  I would
like to have a look at them, and I really learned a lot from looking
at the Synopsis source code, for example.)

> Thus I suggest that we take it out and make it a separate library.

There is a fourth part that lives somewhere in the middle between
Frontend and Translator (maybe that's what you mean by ``static
analyzer''): OpenC++'s symbol-table implementation, encapsulated in
classes Environment, Encoding and friends.  We had trouble
understanding and reusing particularly this part, and in the end
decided not to use it, so it should be separable as well.

> Otherwise I can see serious problems with testing.
[...]
> With separate Frontend library, we can test the library on its own, and
> this is what we need at the moment, because we somehow have to add tests
> for the new features implemented by patches from Fiasco project.

I think what you are proposing can be achieved by some
build-infrastructure (and maybe some terminology and documentation)
changes, plus very little.  You actually do not need complete
separation of the four parts comprising OpenC++ in order to facilitate
testing -- separation would just be convenient for reuse.

In my opinion, what's needed is just:

1. An abstract base class for Walker, which just provides the
   interface for visiting a Ptree hierarchy and is completely
   independent from the Translator and symbol-table parts.  (As an
   added bonus, its visit functions should support return types other
   than Ptree*, so it probably should be a template.)

2. A simple unit-testing framework, to which tests for new
   functionality (on a per-module level) can be added easily

For our VFiasco project <http://www.vfiasco.org>, we use a wrapper
around Walker which provides (1), and (2) consists of a set of
unit-test programs that output test data and a simple Makefile (for
GNU Make) that tests for regressions.

All in all, I think that the changes I proposed should be gradually
added to the source base, but nothing more.  Frequent changes to the
build system and library interface actually make reuse harder, not
easier, and besides the points I mentioned, there isn't really that
much of an itch to scratch.

> BTW: Over a year ago there was a resolution on this forum to factor out the
> Driver subsystem and make it a shell script (for easier maintenance
> and to make underlying compiler/preproc/linker settable with Autoconf).

I don't really care about the driver, but I don't understand how
completely replacing a perfectly-well-working part makes anything more
maintainable.  It certainly is no problem to make the underlying tools
configurable for the existing C++ driver, is it?

Kind regards,
Michael
-- 
ho...@sa..., ho...@in...
http://home.pages.de/~hohmuth/

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

[Stefan R. <sr...@ma...>]

Hello,

On Thu, Mar 13, 2003 at 01:48:52PM +0800, Grzegorz Jakacki wrote:
> On Wed, 12 Mar 2003, Stefan Reuther wrote:
> > I have been writing a program which takes an OpenC++ parse tree,
> > and translates it into a more regular output, i.e., user-defined
> > operators are turned into function calls, overload resolution
> > being done, etc... I have used OpenC++ only as a parser library
> > (I'm working with Michael Hohmuth).
> 
> That's a pity that you do not implement it in OpenC++ itself.

The decision was to not change OpenC++ for the moment, and do
everything from the outside. This is advantageous from a
modularity point-of-view, but some of "my" code is a bit more
complicated than it could be. For example, as far as I can tell,
OpenC++'s symbol management doesn't do everything we need (like
overloading functions, "int stat()" vs "struct stat", ...; but
feel free to prove me wrong :-), so the solutions would be
either to change OpenC++, or to implement our own symbol table.
We decided to pick the latter choice, and leave the former as an
option for the future.

> You are working on Fiasco project, right? Are your sources open?

VFiasco, right. Sources are not yet open, because we did not yet
package them up nicely, and because the project is far from
complete. Other than that, there's no problem.

> > OpenC++ also does not recognize di- and trigraphs, nor does it
> > support replacement keywords (i.e. "and_eq" instead of "&="). I
> > think these are better in a preprocessor.
> 
> I do not quite understand where is the problem here. OpenC++ works on
> preproc output, so it has no chance to see trigraps&co, right?

gcc's preprocessor doesn't do digraphs ("<%" instead of "{"). It
also doesn't do replacement keywords, but at least these can be
worked around using some #defines, like C99 does it. I think
there are some subtle gotchas in these, but I would just declare
that these things are out of OpenC++'s scope (I don't care
whether "<%" stringifies as "<%" or "{"). And, honestly, I've
never seen anyone use them.

> > Another problem which I found quite hard to solve: take an
> > expression like this: "(name) + x * y". Depending upon whether
> > the "name" is a type or a variable, this either means
> >    ((name) +x) * y
> > (cast +x, then multiply) or
> >    (name) + (x * y)
> > (multply, then add).
[...]
> The honest solution would be to have node type that makes it
> obvious, that parser does not know what it is. Further analysis
> would change the node to one or another form, based on the
> relevant identifiers bindings. I am not sure if this scheme
> is currently implementable without seriously compromising backward
> compatibility.

Okay, I had some similar things in mind. For compatibility, the
"Walker" could have a routine "TranslateAmbiguousCast" or
somesuch, whose default implementation calls
"TranslateCastExpr", "TranslatePrefixExpr" and
"TranslateInfixExpr".

Other than that, my (implicit) question was how many people
would cry when I change the parse tree somehow :-) At least, the
addition of "typeid" broke one of our regression tests. I think,
static_cast & co should have their own PtreeCxxStyleCast node,
which would probably change someone else's tests. Addition of
new productions wouldn't break immediately, but someone who
implements their own Walker might accidentially miss some nodes.
That problem could at least be solved by making an abstract
Walker base class where all the TranslateFooBar functions are
pure virtual.

> > The program which we finally want to run through the OpenC++
> > parser is an operating system kernel. Kernel hackers tend to use
> > gcc extensions a lot. What is your opinion on adding these to
> > OpenC++ (i.e., if I made a patch for them, would it make it
> > into OpenC++?). I'm talking about...
[...]
> 
> I do not see any problems with letting those in, but perhaps under
> a switch.

Okay.

> > - maybe some __attribute__ should be handled? OTOH, it can
> >   simply be #defined out.
> 
> This one I would leave out at the moment, especially if you do not have
> clear requirement for it. Again, if you need it, go ahead and put
> it under the switch.

Maybe this can be solved more generally, as a parameterized user
keyword. If I recall correctly, such a thing is on the wishlist?
(haven't yet digged through all of Michael's archive)


  Stefan

[Opencxx-users] Re: [opencxx] Let's break OpenC++ up

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

On Thu, 13 Mar 2003, James Michael DuPont wrote:

> Yes this is a good idea.
> there is an open task for Stefan

Stefan Seefeld, that is

> and I to modularize openc++.
>
> To be honest, this has not been done. If someone want to take that
> over, that would be fine.
>
> The only issue that I see is the replacing of constants like "4" with
> things like OPEN_CXX_PARAMETER_NAME so that the code is more reable.

Could you explain what do you mean? I think I have much cleaner solution,
but I am not sure if this is the solution to the problem you mention :-)

Best regards
Grzegorz

>
> mike
>
> --- Grzegorz Jakacki <ja...@he...> wrote:
> >
> > Hi,
> >
> > In his e-mail Stefan Reuther offered several patches to OpenC++
> > parser.
> > Those patches are welcome, however I think we again hit recurring
> > problem:
> >
> > Conceptually OpenC++ consists of three sybsystems:
> >
> >     Frontend --- reads preprocessed sources, makes parse tree
> >         out of them; possibly OpenC++ static analyzer also belongs
> >         in this subsystem
> >
> >     Translator --- traverses syntax tree and transforms it
> >         according to rules described by metaclasses
> >
> >     Driver --- runs preprocessor, Frontend, Translator,
> >         native compiler and linker.
> >
> > As I understand Michael and Stefan work with Frontend and are not
> > interested
> > in the rest of the system. I believe, that this is the most
> > frequently
> > reused part of OpenC++ and I know of at least three more projects
> > that
> > reuse just this part.
> >
> > Thus I suggest that we take it out and make it a separate library.
> > Otherwise I can see serious problems with testing.
> >
> > As you now, out present methodology is regression testing, e.g. we
> > run
> > 'make test' each time we modify anything.
> >
> > This is very important, as this allows somebody who is not a guru to
> > come
> > and commit some fixes without fear that he/she breaks some distant
> > parts
> > of the package. Our testsuite is pathetically small at the moment,
> > but
> > it already helps and I believe that it can grow.
> >
> > But now comes the problem: when we just extend Frontend itself,
> > without
> > proper support in Translator (e.g. your patches will make 'if ({...})
> > '
> > parse, but Translator will choke on it), we do not have way to add
> > tests
> > that make sure the new Frontend functionality works.
> >
> > With separate Frontend library, we can test the library on its own,
> > and
> > this is what we need at the moment, because we somehow have to add
> > tests
> > for the new features implemented by patches from Fiasco project.
> >
> > BTW: Over a year ago there was a resolution on this forum to factor
> > out the
> > Driver subsystem and make it a shell script (for easier maintenance
> > and to make underlying compiler/preproc/linker settable with
> > Autoconf).
> >
> > Let me know what you think.
> >
> > 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. #
> > ##################################################################
> >
>
>
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online
> http://webhosting.yahoo.com
>
>

##################################################################
# 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] Let's break OpenC++ up

[James M. D. <mdu...@ya...>]

Yes this is a good idea. 
there is an open task for Stefan and I to modularize openc++.

To be honest, this has not been done. If someone want to take that
over, that would be fine.

The only issue that I see is the replacing of constants like "4" with
things like OPEN_CXX_PARAMETER_NAME so that the code is more reable.

mike

--- Grzegorz Jakacki <ja...@he...> wrote:
> 
> Hi,
> 
> In his e-mail Stefan Reuther offered several patches to OpenC++
> parser.
> Those patches are welcome, however I think we again hit recurring
> problem:
> 
> Conceptually OpenC++ consists of three sybsystems:
> 
>     Frontend --- reads preprocessed sources, makes parse tree
>         out of them; possibly OpenC++ static analyzer also belongs
>         in this subsystem
> 
>     Translator --- traverses syntax tree and transforms it
>         according to rules described by metaclasses
> 
>     Driver --- runs preprocessor, Frontend, Translator,
>         native compiler and linker.
> 
> As I understand Michael and Stefan work with Frontend and are not
> interested
> in the rest of the system. I believe, that this is the most
> frequently
> reused part of OpenC++ and I know of at least three more projects
> that
> reuse just this part.
> 
> Thus I suggest that we take it out and make it a separate library.
> Otherwise I can see serious problems with testing.
> 
> As you now, out present methodology is regression testing, e.g. we
> run
> 'make test' each time we modify anything.
> 
> This is very important, as this allows somebody who is not a guru to
> come
> and commit some fixes without fear that he/she breaks some distant
> parts
> of the package. Our testsuite is pathetically small at the moment,
> but
> it already helps and I believe that it can grow.
> 
> But now comes the problem: when we just extend Frontend itself,
> without
> proper support in Translator (e.g. your patches will make 'if ({...})
> '
> parse, but Translator will choke on it), we do not have way to add
> tests
> that make sure the new Frontend functionality works.
> 
> With separate Frontend library, we can test the library on its own,
> and
> this is what we need at the moment, because we somehow have to add
> tests
> for the new features implemented by patches from Fiasco project.
> 
> BTW: Over a year ago there was a resolution on this forum to factor
> out the
> Driver subsystem and make it a shell script (for easier maintenance
> and to make underlying compiler/preproc/linker settable with
> Autoconf).
> 
> Let me know what you think.
> 
> 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. #
> ##################################################################
> 


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

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

[Opencxx-users] [opencxx] gcc-3.2 frontend patch comitted

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

Hi,

Big thanks to Michael Hohmuth who provided us with gcc-3.2 compatibility
patches for OpenC++ parser.

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: ANSI C++/Gcc 3.2 compatibility patches

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

On Wed, 12 Mar 2003, Michael Hohmuth wrote:

> Grzegorz Jakacki <ja...@he...> writes:
> > On Tue, 11 Mar 2003, Michael Hohmuth wrote:
> >> Alexandre Tolmos <kt...@fr...> writes:
> >>
> >> > Btw, Grzegorz has got problems compiling with Gcc 3.2.1 (errors in
> >> > "buffer.cc" pertaining to the "placement new" operator). On my Mac I
> >> > only have Gcc 3.1. Did you encounter such problems with Gcc 3.2?
> >>
> >> No, I did not.  Then again, so far I've only tried using Gcc-3.2
> >> together with a version 6.0 of the garbage collector.
> >
> > Have you run 'make test' ?
> >
> > Most likely I did not supply you with enough info on the check-in
> > procedure (I posted the draft some like two (?) weeks ago, I assumed you
> > got it). We try to work in branches, tagged sandbox_USERID or
> > sandbox_USERID_SOMETHING, and test before we merge to the trunk. 'make
> > test' does testing. Perhaps you were not aware of it, otherwise you would
> > not be able to successfully run 'make test', as your GC differs from CVS
> > GC.
> >
> > I am very sorry about this confusion, I am planning to put such info on
> > the website, I am working on this now. It should be ready before the end
> > of this month.
>
> Dear Grzegorz,
>
> I am at loss here: I lost track of what we are discussing about.

I am sorry, let me clarify.

> Just to clear up some confusion:
>
> Are you commenting on (1) the issue at hand (problems with
> placement-new operator) or (2) on the Gcc patch I committed?
>
> If (1):
>
> I have not checked in any patches related to the garbage collector.  I
> just proposed a GC patch for the old garbage collector (which I did
> not check in) to you in case you would like to experiment with it.

When you wrote, that you checked in patch for gcc-3.2 I just checked out
and it did not compile. Thus I assumed that you forgot to checkin
the new version of gc. I thought that you send the patch just for my
convinience, while CVS already contains the correct version of gc.

> If (2):
>
> I have checked in my patch to the main trunk of the CVS, as you
> advised in another post.

They do not break anything, so it's ok.

> Yes, I did run "make test".  Before I applied my patch, it worked for
> Gcc 2.95, but OpenC++ did not even compile for Gcc 3.0 and Gcc
> 3.2 because of the garbage collector's operator-new issue.
> After my patch, the situation remained the same.  I am quite positive
> that my changes do not break anything that was not broken before I
> committed them.

Sure.

> However, using my experimental GC patch mentioned above, OpenC++
> compiles.  The testsuite had to be adopted to ANSI C++ because of
> namespace issues and "void main()", and I have committed the
> corresponding changes now.  It now seems to work with Gcc 3.0, but
> fails with Gcc 3.2, apparently because `occ' cannot parse a number of
> STL header files coming with that compiler version.
>
>
> Please note that `occ' currently assumes that you C++ compiler is
> called `g++' (or `CC' on IRIX), and there does not seem to be an
> option to change this.  Therefore, if your compiler has a different
> name (for example, Gcc 3.2 is called `gcc-3.2' on Debian Linux), you
> need to edit the line containing "compilerName" in driver2.cc.

I assumed that 'gcc-3.2' patch means all modifications that will make
testsuite work with gcc-3.2 . Now I see what you meant.

I think this is precisely the problem that calls for separation of
Frontend library. Your patch is a patch for a Frontend and it does
not apply to the testsuite, which tests the whole thing.

> As an aside: I subscribed to <ope...@li...>,
> but it looks like commit messages are not reflected to this list.  Is
> this intended?

No. To make CVS spit e-mails to this mailing list we have to setup a
script in CVSROOT module of CVS. It is all described in SF SiteDocs.
This should take 45mins. including reading the docs. If you can get
it off my TODO list, that would be great.

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] some OpenC++ experience

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

Hi Stefan,

On Wed, 12 Mar 2003, Stefan Reuther wrote:

> Hello,
>
> I have been writing a program which takes an OpenC++ parse tree,
> and translates it into a more regular output, i.e., user-defined
> operators are turned into function calls, overload resolution
> being done, etc... I have used OpenC++ only as a parser library
> (I'm working with Michael Hohmuth).

That's a pity that you do not implement it in OpenC++ itself. You are
working on Fiasco project, right? Are your sources open?

> I found some C++ constructs which OpenC++ does not handle:
>
> - "if (declaration)" is not supported, neither is "while
>   (declaration)" nor "switch(declaration)". I have appended a
>   patch which adds that.
>
>   What is your general position about changing the parse tree
>   like this? Will that break people's programs or is that not a
>   problem?
>
> - "explicit" is not supported, but works, sort-of. "explicit" is
>   only allowed for constructors, and OpenC++ thinks that "explicit"
>   is the return type :-)
>
> - wide characters (L"klingon sentence here"). I've seen there is
>   a patch on SF which adds that.
>
> - "namespace A = B"
>
> - type-specifiers in non-canonical order are not accepted. For
>   example, "unsigned const long typedef int a" is legal C++,
>   but OpenC++ doesn't grok it. I'm unsure how that problem can
>   be solved minimally-invasive, and whether anyone cares about it.
>
> - function-try-blocks are not accepted.
>     a::a() try : mem_init() { } catch(...) { }
>
> In addition, some parse tree nodes lose information about which
> production was applied. For example, the types "unsigned int"
> and "::name" both turn into two-element lists [unsigned int] and
> [:: name], although the first one contains two type-specifiers
> while the second one contains one. I'm unsure whether that's a
> problem worth fixing, but it caused me some headaches when I
> wanted to analyze such trees.

I find the answer to this question important to the whole project, so I post
it in a separate e-mail.

> OpenC++ also does not recognize di- and trigraphs, nor does it
> support replacement keywords (i.e. "and_eq" instead of "&="). I
> think these are better in a preprocessor.

I do not quite understand where is the problem here. OpenC++ works on
preproc output, so it has no chance to see trigraps&co, right?

>
> Another problem which I found quite hard to solve: take an
> expression like this: "(name) + x * y". Depending upon whether
> the "name" is a type or a variable, this either means
>    ((name) +x) * y
> (cast +x, then multiply) or
>    (name) + (x * y)
> (multply, then add).
>
> OpenC++ usually parses this as the first form. Okay, I have no
> problem with OpenC++ mis-parsing things; I know it can't do
> better with that little knowledge it has. The problem here is
> that a parse problem affects its parent node, not just its
> child nodes (i.e. "(name)(1,2)" is either a function call or a
> cast of a comma expression. OpenC++ parses it as the latter but
> it is quite simple to fix that up.) Well, any helpful hints on
> that topic are appreciated.

I do not see any solution within parser itself. You have to know
the local environment to be able to do anything.

The honest solution would be to have node type that makes it
obvious, that parser does not know what it is. Further analysis
would change the node to one or another form, based on the
relevant identifiers bindings. I am not sure if this scheme
is currently implementable without seriously compromising backward
compatibility.

> The program which we finally want to run through the OpenC++
> parser is an operating system kernel. Kernel hackers tend to use
> gcc extensions a lot. What is your opinion on adding these to
> OpenC++ (i.e., if I made a patch for them, would it make it
> into OpenC++?). I'm talking about...
>
> - compound expressions ("({ if (x) .... })")
>
> - extended literals, gcc and C99 form
>   ("return (div_t) { 1, 0 };", "div_t x = { quot:3 };" resp.
>   "div_t x = { .quot = 3 }")
>
> - some keywords: restrict, asm, ...
>
> - typeof

I do not see any problems with letting those in, but perhaps under
a switch.

> - maybe some __attribute__ should be handled? OTOH, it can
>   simply be #defined out.

This one I would leave out at the moment, especially if you do not have
clear requirement for it. Again, if you need it, go ahead and put
it under the switch.

> Thank you for reading until here,

"I have made this letter longer than usual, because I lack time
to make it short." [Blaise Pascal]

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] Let's break OpenC++ up

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

Hi,

In his e-mail Stefan Reuther offered several patches to OpenC++ parser.
Those patches are welcome, however I think we again hit recurring problem:

Conceptually OpenC++ consists of three sybsystems:

    Frontend --- reads preprocessed sources, makes parse tree
        out of them; possibly OpenC++ static analyzer also belongs
        in this subsystem

    Translator --- traverses syntax tree and transforms it
        according to rules described by metaclasses

    Driver --- runs preprocessor, Frontend, Translator,
        native compiler and linker.

As I understand Michael and Stefan work with Frontend and are not interested
in the rest of the system. I believe, that this is the most frequently
reused part of OpenC++ and I know of at least three more projects that
reuse just this part.

Thus I suggest that we take it out and make it a separate library.
Otherwise I can see serious problems with testing.

As you now, out present methodology is regression testing, e.g. we run
'make test' each time we modify anything.

This is very important, as this allows somebody who is not a guru to come
and commit some fixes without fear that he/she breaks some distant parts
of the package. Our testsuite is pathetically small at the moment, but
it already helps and I believe that it can grow.

But now comes the problem: when we just extend Frontend itself, without
proper support in Translator (e.g. your patches will make 'if ({...}) '
parse, but Translator will choke on it), we do not have way to add tests
that make sure the new Frontend functionality works.

With separate Frontend library, we can test the library on its own, and
this is what we need at the moment, because we somehow have to add tests
for the new features implemented by patches from Fiasco project.

BTW: Over a year ago there was a resolution on this forum to factor out the
Driver subsystem and make it a shell script (for easier maintenance
and to make underlying compiler/preproc/linker settable with Autoconf).

Let me know what you think.

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] still having problems with comments

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

Stanislav,

Sorry for not reploying to your previous mail about handling comments,
I did not have enough time to look into it. I will try next week, please
remind me if you do not hear from me until Tuesday.


On Wed, 12 Mar 2003, Stanislav Kaushanskiy wrote:

> Does any one have comments working while including
> <iostream>, <string>, <strstream>, etc ?

I do not think they will work fine at the moment due to limited support
for templates.

> this involves using the -C option to occ.
>
> if so could you send me your version of gcc and your version of openC++

The combination that I know to be working is gcc-2.95 and OpenC++ 2.6.1

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] still having problems with comments

[Stanislav K. <st...@uc...>]

Does any one have comments working while including
<iostream>, <string>, <strstream>, etc ?

this involves using the -C option to occ.

if so could you send me your version of gcc and your version of openC++

thanks


-stan

[Opencxx-users] RE: [opencxx] some OpenC++ experience

[Dupont, M. <mic...@mc...>]

-----Original Message-----
From: Stefan Reuther [mailto:sr...@ma...]

I have been writing a program which takes an OpenC++ parse tree,
and translates it into a more regular output, i.e., user-defined
operators are turned into function calls, overload resolution
being done, etc... I have used OpenC++ only as a parser library
(I'm working with Michael Hohmuth).

Do you have a classmodel? are you going to publish it?

>>Thank you for reading until here,
hey mo, a wiseguy!

mike

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

[Michael H. <ho...@sa...>]

Grzegorz Jakacki <ja...@he...> writes:
> On Tue, 11 Mar 2003, Michael Hohmuth wrote:
>> Alexandre Tolmos <kt...@fr...> writes:
>>
>> > Btw, Grzegorz has got problems compiling with Gcc 3.2.1 (errors in
>> > "buffer.cc" pertaining to the "placement new" operator). On my Mac I
>> > only have Gcc 3.1. Did you encounter such problems with Gcc 3.2?
>>
>> No, I did not.  Then again, so far I've only tried using Gcc-3.2
>> together with a version 6.0 of the garbage collector.
>
> Have you run 'make test' ?
>
> Most likely I did not supply you with enough info on the check-in
> procedure (I posted the draft some like two (?) weeks ago, I assumed you
> got it). We try to work in branches, tagged sandbox_USERID or
> sandbox_USERID_SOMETHING, and test before we merge to the trunk. 'make
> test' does testing. Perhaps you were not aware of it, otherwise you would
> not be able to successfully run 'make test', as your GC differs from CVS
> GC.
>
> I am very sorry about this confusion, I am planning to put such info on
> the website, I am working on this now. It should be ready before the end
> of this month.

Dear Grzegorz,

I am at loss here: I lost track of what we are discussing about. 
Just to clear up some confusion: 

Are you commenting on (1) the issue at hand (problems with
placement-new operator) or (2) on the Gcc patch I committed?

If (1):

I have not checked in any patches related to the garbage collector.  I
just proposed a GC patch for the old garbage collector (which I did
not check in) to you in case you would like to experiment with it.

If (2):

I have checked in my patch to the main trunk of the CVS, as you
advised in another post.

Yes, I did run "make test".  Before I applied my patch, it worked for
Gcc 2.95, but OpenC++ did not even compile for Gcc 3.0 and Gcc
3.2 because of the garbage collector's operator-new issue.
After my patch, the situation remained the same.  I am quite positive
that my changes do not break anything that was not broken before I
committed them.

However, using my experimental GC patch mentioned above, OpenC++
compiles.  The testsuite had to be adopted to ANSI C++ because of
namespace issues and "void main()", and I have committed the
corresponding changes now.  It now seems to work with Gcc 3.0, but
fails with Gcc 3.2, apparently because `occ' cannot parse a number of
STL header files coming with that compiler version.

Please note that `occ' currently assumes that you C++ compiler is
called `g++' (or `CC' on IRIX), and there does not seem to be an
option to change this.  Therefore, if your compiler has a different
name (for example, Gcc 3.2 is called `gcc-3.2' on Debian Linux), you
need to edit the line containing "compilerName" in driver2.cc.


As an aside: I subscribed to <ope...@li...>,
but it looks like commit messages are not reflected to this list.  Is
this intended?

Kind regards,
Michael
-- 
ho...@sa..., ho...@in...
http://www.sax.de/~hohmuth/

[Opencxx-users] [opencxx] some OpenC++ experience

[Stefan R. <sr...@ma...>]

Hello,

I have been writing a program which takes an OpenC++ parse tree,
and translates it into a more regular output, i.e., user-defined
operators are turned into function calls, overload resolution
being done, etc... I have used OpenC++ only as a parser library
(I'm working with Michael Hohmuth).

I found some C++ constructs which OpenC++ does not handle:

- "if (declaration)" is not supported, neither is "while
  (declaration)" nor "switch(declaration)". I have appended a
  patch which adds that.

  What is your general position about changing the parse tree
  like this? Will that break people's programs or is that not a
  problem?

- "explicit" is not supported, but works, sort-of. "explicit" is
  only allowed for constructors, and OpenC++ thinks that "explicit"
  is the return type :-)

- wide characters (L"klingon sentence here"). I've seen there is
  a patch on SF which adds that.

- "namespace A = B"

- type-specifiers in non-canonical order are not accepted. For
  example, "unsigned const long typedef int a" is legal C++,
  but OpenC++ doesn't grok it. I'm unsure how that problem can
  be solved minimally-invasive, and whether anyone cares about it.

- function-try-blocks are not accepted.
    a::a() try : mem_init() { } catch(...) { }

In addition, some parse tree nodes lose information about which
production was applied. For example, the types "unsigned int"
and "::name" both turn into two-element lists [unsigned int] and
[:: name], although the first one contains two type-specifiers
while the second one contains one. I'm unsure whether that's a
problem worth fixing, but it caused me some headaches when I
wanted to analyze such trees.

OpenC++ also does not recognize di- and trigraphs, nor does it
support replacement keywords (i.e. "and_eq" instead of "&="). I
think these are better in a preprocessor.

Another problem which I found quite hard to solve: take an
expression like this: "(name) + x * y". Depending upon whether
the "name" is a type or a variable, this either means
   ((name) +x) * y
(cast +x, then multiply) or
   (name) + (x * y)
(multply, then add).

OpenC++ usually parses this as the first form. Okay, I have no
problem with OpenC++ mis-parsing things; I know it can't do
better with that little knowledge it has. The problem here is
that a parse problem affects its parent node, not just its
child nodes (i.e. "(name)(1,2)" is either a function call or a
cast of a comma expression. OpenC++ parses it as the latter but
it is quite simple to fix that up.) Well, any helpful hints on
that topic are appreciated.


The program which we finally want to run through the OpenC++
parser is an operating system kernel. Kernel hackers tend to use
gcc extensions a lot. What is your opinion on adding these to
OpenC++ (i.e., if I made a patch for them, would it make it
into OpenC++?). I'm talking about...

- compound expressions ("({ if (x) .... })")

- extended literals, gcc and C99 form
  ("return (div_t) { 1, 0 };", "div_t x = { quot:3 };" resp.
  "div_t x = { .quot = 3 }")

- some keywords: restrict, asm, ...

- typeof

- maybe some __attribute__ should be handled? OTOH, it can
  simply be #defined out.


Thank you for reading until here,
  Stefan

[Opencxx-users] Re: [opencxx] Re: ANSI C++/Gcc 3.2 compatibility patches

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

On Tue, 11 Mar 2003, Michael Hohmuth wrote:

> Alexandre Tolmos <kt...@fr...> writes:
>
> > Btw, Grzegorz has got problems compiling with Gcc 3.2.1 (errors in
> > "buffer.cc" pertaining to the "placement new" operator). On my Mac I
> > only have Gcc 3.1. Did you encounter such problems with Gcc 3.2?
>
> No, I did not.  Then again, so far I've only tried using Gcc-3.2
> together with a version 6.0 of the garbage collector.

Have you run 'make test' ?

Most likely I did not supply you with enough info on the check-in
procedure (I posted the draft some like two (?) weeks ago, I assumed you
got it). We try to work in branches, tagged sandbox_USERID or
sandbox_USERID_SOMETHING, and test before we merge to the trunk. 'make
test' does testing. Perhaps you were not aware of it, otherwise you would
not be able to successfully run 'make test', as your GC differs from CVS
GC.

I am very sorry about this confusion, I am planning to put such info on
the website, I am working on this now. It should be ready before the end
of this month.

[snip]
>
> BTW: Is there a reason for not "cvs rm -f"-ing the redundant copy of
> the garbage collector in src/gc?

Alexandre has just done it.

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: ANSI C++/Gcc 3.2 compatibility patches

[Michael H. <ho...@sa...>]

Alexandre Tolmos <kt...@fr...> writes:

> Btw, Grzegorz has got problems compiling with Gcc 3.2.1 (errors in
> "buffer.cc" pertaining to the "placement new" operator). On my Mac I
> only have Gcc 3.1. Did you encounter such problems with Gcc 3.2?

No, I did not.  Then again, so far I've only tried using Gcc-3.2
together with a version 6.0 of the garbage collector.

This might be a problem with the old garbage collector: I believe it
does not define an placement-new operator for arrays for Gcc 3.2
because an error in an #ifdef directive.  If Grzegorz is using the old
garbage collector, he can try the simple patch I've appended below.

BTW: Is there a reason for not "cvs rm -f"-ing the redundant copy of
the garbage collector in src/gc?

Michael
-- 
ho...@sa..., ho...@in...
http://www.sax.de/~hohmuth/

[Opencxx-users] Re: [opencxx] Green light for gcc-3.2 patch

[Michael H. <ho...@sa...>]

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

> Please go ahead with merging your gcc-3.2 patch into main trunk.

Done.

Michael
-- 
ho...@sa..., ho...@in...
http://home.pages.de/~hohmuth/

[Opencxx-users] [opencxx] Green light for gcc-3.2 patch

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

Michael,

Please go ahead with merging your gcc-3.2 patch into main trunk.

Contact me if any problems.

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] gcc-3.1 fix and wide-char support checked in

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

Hi,

Alexandre Tolmos has completed the checkin of Michael Buro's fix,
which makes OpenC++

  * compile on gcc-3.1
  * support wide character literals

Big thanks! This really moves us forward.

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: ANSI C++/Gcc 3.2 compatibility patches

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

On Mon, 10 Mar 2003, Alexandre Tolmos wrote:

[snip]
> Sorry, I'm responsible for that global namespace pollution :)

I think several 'using namespace std' at toplevel had been in CVS before
your checkin. They were introduced when we moved to 'Opencxx' namespace. =
I
had this issue on TODO list, but it was never critical. Now it would be
good to fix it once we are at it.

[snip]
> Actually I should have put the "using namespace std" declarations
> within the "Opencxx" namespace itself; then none of the symbols from
> the standard library would have been promoted in the global namespace...

Sounds good. I would suggest however, that you do not fix it now, let's
give Michael a chekin slot, while you are busy with GC anyway.

[snip]
> I think we should move to the new standard headers but I don't know if
> it would still compile on Win32.

Depends on compiler, I would presume.

Best regards
Grzegorz



> Btw, Grzegorz has got problems compiling with Gcc 3.2.1 (errors in
> "buffer.cc" pertaining to the "placement new" operator). On my Mac I
> only have Gcc 3.1. Did you encounter such problems with Gcc 3.2?
>
> Alexandre.
>
> -----------------------------------------------------------------------=
-
> -
> Alexandre Tolmos
> E-mail:=A0...@fr...
> ICQ: 92964905
> -----------------------------------------------------------------------=
-
> -
> "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
> -----------------------------------------------------------------------=
-
> -
>
>
>
>
>

##################################################################
# 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: ANSI C++/Gcc 3.2 compatibility patches

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

On Mon, 10 Mar 2003, Michael Hohmuth wrote:

> Grzegorz Jakacki <ja...@he...> writes:
>
> > You have been added to the project. Currently Alexandre Tolmos is
> > finishing his commits wrt. gcc-3.x, there will be an annoucement once he
> > is done. Before this happens you may want to contact me if you think you
> > need any help on branching/merging.
>
> Thanks.
>
> I don't think I need any help with merging, but I would like to have
> some feedback.
>
> I observed that in the current CVS version (which supposedly already
> contains some or all of the previous GCC3 work), there appear some
> "using namespace std" declarations in header files.  This, to my eyes,
> is bad style.  I am working on a project that uses OpenC++ as a
> library, and there it potentially ``hurts'' if a header file imports
> the whole std namespace into the global namespace.

Agreed.

> So, once Alexandre is finished, I would like to undo these changes and
> instead revert to the style used in my patch:  The "using namespace
> std" declarations are only allowed to appear in .cc files, and .h
> files reference std symbols using qualified names.

Agreed. This is well covered in Herb Sutter's "More Exceptional C++", part
of it is accessible at http://www.gotw.ca/gotw/053.htm .

> There also is the issue of naming header files coming from standard
> C.  In my original patch, they are included as, for example, <cstring>
> instead of <string.h>, whereas the current CVS version uses the
> latter, older style.  Here, I am planning to leave it at the CVS
> version's style, because I think that it might be more portable.

There is a trade-off here. It is more portable, but pollutes namespace ---
functions from string.h are declared in global namespace, whereas
functions from cstring are declared in 'std'. This is not very relevant
when OpenC++ is compiled as application, but it is, when OpenC++ is used
as a library.

I would suggest that we stick to <cstring> style when writting new code,
so that eventually old header style is eliminated.

> Do you (Grzegorz, Alexande, or anyone else) have any objections?

Only the above.

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] Old/new header style

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

Hi All,

Is anybody on the list using OpenC++ with compiler that does not accept

   #include <cstring>

?

If so, please send me the name and version of this compiler and how much
are you interested in having OpenC++ on this platform.

Best regards
GJ

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