opencxx-users

[Opencxx-users] RE: [opencxx] problems with compiling for gctest.exe

[Youssef H. <yha...@dc...>]

Hi mike,
OKAY, the gc-code can be compiled with <make -fMakefile.dj> under =
cygwin-bash-shell. gctest.exe can be generated under and it works.
How to compile the src-code to get occ.exe ? Which Makefile shold one =
use. I tried the Makefile.Linux (unser src/Unix) and got the following =
error message:
$ make -fMakefile.Linux
g++ -O -g -c -o buffer.o ../buffer.cc
In file included from ../types.h:131,
                 from ../buffer.h:41,
                 from ../buffer.cc:38:
../gc/gc_cpp.h:132:1: warning: "_cdecl" redefined
../buffer.cc:1:1: warning: this is the location of the previous =
definition
In file included from ../buffer.cc:38:
../buffer.h:80: `ostream' was not declared in this scope
../buffer.h:80: parse error before `,' token
../buffer.h:106: parse error before `&' token
............
=20
=20
#include <iostraeam> in bufer.h doesn't help.
Any idea ?
youssef

-----Original Message-----
From: Dupont, Michael [mailto:mic...@mc...]
Sent: 06 December 2002 18:22
To: 'op...@cs...'
Subject: RE: [opencxx] problems with compiling for gctest.exe



I dont know if people use open c++ under cygwin,=20
right now I am busy with the gcc port.=20

this is the general instructions for porting software=20
1. make a list of the libs needed=20
2. get the sources=20
3. read the readmes=20
4. read the installation instructions=20
 mostly under cygwin=20
        ./configure=20
        make=20
        make test /     make check=20
        make install=20
mike=20

-----Original Message-----=20
From: Youssef HASSOUN [ mailto:yha...@dc...]=20
Sent: Friday, December 06, 2002 6:31 PM=20
To: op...@cs...=20
Subject: RE: [opencxx] problems with compiling for gctest.exe=20


Hi mike,=20
> Check that you might have to compile all the libs yourself.=20
Could you please tell me how to do that.=20
yousef=20



-----Original Message-----=20
From: James Michael DuPont [ mailto:mdu...@ya...]=20
Sent: 05 December 2002 12:44=20
To: op...@cs...=20
Subject: Re: [opencxx] problems with compiling for gctest.exe=20


did you compile libgc yourself?=20

I have libgc as part of gcc installed here,=20

# if defined(I_HIDE_POINTERS) || defined(GC_I_HIDE_POINTERS)=20
    typedef GC_word GC_hidden_pointer;=20
#   define HIDE_POINTER(p) (~(GC_hidden_pointer)(p))=20
#   define REVEAL_POINTER(p) ((GC_PTR)(HIDE_POINTER(p)))=20

Check that you might have to compile all the libs yourself.=20

Mike.=20

--- Youssef HASSOUN <yha...@dc...> wrote:=20
> Hi,=20
> I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get=20
> the linker problem shown below.=20
> Any idea why is that ?=20
>=20
> TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation=20
>  +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj=20
> +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj=20
> _map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj=20
> +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob=20
> j +ptr_chck.obj +gc_cpp.obj +mallocx.obj=20
>         c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@=20
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland=20
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland=20
> Error: Unresolved external '_HIDE_POINTER' referenced from=20
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize=20
> Error: Unresolved external '_REVEAL_POINTER' referenced from=20
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize=20
>=20
> ** error 1 ** deleting gctest.exe=20
>=20
> Regards.=20


=3D=3D=3D=3D=3D=20
James Michael DuPont=20
http://introspector.sourceforge.net/=20

__________________________________________________=20
Do you Yahoo!?=20
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.=20
http://mailplus.yahoo.com=20

[Opencxx-users] RE: [opencxx] problems with compiling for gctest.exe

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

I dont know if people use open c++ under cygwin, 
right now I am busy with the gcc port.

this is the general instructions for porting software
1. make a list of the libs needed
2. get the sources
3. read the readmes
4. read the installation instructions
 mostly under cygwin 
	./configure
	make 
	make test /	make check
	make install
mike

-----Original Message-----
From: Youssef HASSOUN [mailto:yha...@dc...]
Sent: Friday, December 06, 2002 6:31 PM
To: op...@cs...
Subject: RE: [opencxx] problems with compiling for gctest.exe


Hi mike,
> Check that you might have to compile all the libs yourself.
Could you please tell me how to do that.
yousef



-----Original Message-----
From: James Michael DuPont [mailto:mdu...@ya...]
Sent: 05 December 2002 12:44
To: op...@cs...
Subject: Re: [opencxx] problems with compiling for gctest.exe


did you compile libgc yourself?

I have libgc as part of gcc installed here,

# if defined(I_HIDE_POINTERS) || defined(GC_I_HIDE_POINTERS)
    typedef GC_word GC_hidden_pointer;
#   define HIDE_POINTER(p) (~(GC_hidden_pointer)(p))
#   define REVEAL_POINTER(p) ((GC_PTR)(HIDE_POINTER(p)))

Check that you might have to compile all the libs yourself.

Mike.

--- Youssef HASSOUN <yha...@dc...> wrote:
> Hi,
> I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get
> the linker problem shown below.
> Any idea why is that ?
> 
> TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
>  +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj
> +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj
> _map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj
> +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob
> j +ptr_chck.obj +gc_cpp.obj +mallocx.obj
>         c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> Error: Unresolved external '_HIDE_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> Error: Unresolved external '_REVEAL_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> 
> ** error 1 ** deleting gctest.exe
> 
> Regards.


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Opencxx-users] RE: [opencxx] problems with compiling for gctest.exe

[Youssef H. <yha...@dc...>]

Hi mike,
> Check that you might have to compile all the libs yourself.
Could you please tell me how to do that.
yousef



-----Original Message-----
From: James Michael DuPont [mailto:mdu...@ya...]
Sent: 05 December 2002 12:44
To: op...@cs...
Subject: Re: [opencxx] problems with compiling for gctest.exe


did you compile libgc yourself?

I have libgc as part of gcc installed here,

# if defined(I_HIDE_POINTERS) || defined(GC_I_HIDE_POINTERS)
    typedef GC_word GC_hidden_pointer;
#   define HIDE_POINTER(p) (~(GC_hidden_pointer)(p))
#   define REVEAL_POINTER(p) ((GC_PTR)(HIDE_POINTER(p)))

Check that you might have to compile all the libs yourself.

Mike.

--- Youssef HASSOUN <yha...@dc...> wrote:
> Hi,
> I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get
> the linker problem shown below.
> Any idea why is that ?
> 
> TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
>  +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj
> +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj
> _map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj
> +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob
> j +ptr_chck.obj +gc_cpp.obj +mallocx.obj
>         c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> Error: Unresolved external '_HIDE_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> Error: Unresolved external '_REVEAL_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> 
> ** error 1 ** deleting gctest.exe
> 
> Regards.


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Opencxx-users] [opencxx] Re: Introspector Project and OpenC++ (was "problems with compiling for gctest.exe")

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

--- Francois Taiani <fra...@la...> wrote:
> Hi James,
> 
> I went on the introspector project page (which you have a link on in
> your signature). It seems very interesting, in particular for people
> interested in open compilation.
> 
Dear Francois,
Thanks for writing.

I have on my open task list for OpenC++ to help create a better API
between the walker and the Tree. 
(That with stefan as well)
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45429&group_id=40789&group_project_id=16305

To do this, we need to have a better explicit model of what the parser
returns, a detail model of the asts.

I have been working on that as part of the gcc introspector project.

We have a simple model now of the core C from the gcc
1. I have extracted the code of the c compiler into XML using a patched
tree dumper
2. I modeled the attributes and node types by statistical analysis (of
the example data)
3. I have fed this model into a meta-architecture for generation of
SQL, Perl, Java and other classes
4. I have written feeds from the gcc to read the XML and instanciate
these new classes.
5. I have boostrapped the gcc itself, and translated the entire
sourcecode into a huge postgres database.

I have reviewed the C# .net ECMA reflection standard and the Asp.net
codedoms. Also The java reflection model and the TreeCC model from the
pnet project.

Now I am working with a small team to create a new interface into the
gcc,
using the librdf /redland application framework. This will present the
internal meta data of the gcc to a C,Perl, Python, Java, tcl and Ruby. 

The data storage will be available as a internal memory storage, as an
BerkleyDB and as XML/RDf  or notation3.

Right now you can join the testing effort, we need people to help test
the various language interfaces.

When this is ready, we can also replace the openc++ parser with the GCC
as an option.
and before you say, no because of licensing, wait and see 
1.  GCC can use openC++, the openC++ cannot use gcc.
2.  You can use the GCC in openc++ if you use it under the gpl.

I hope the introspector will provide the next generation of data
transfer layer between the compiler and the people who need it. The
clients of openc++ are on my target list of potential customers.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Opencxx-users] [opencxx] Introspector Project and OpenC++ (was "problems with compiling for gctest.exe")

[Francois T. <fra...@la...>]

Hi James,

I went on the introspector project page (which you have a link on in
your signature). It seems very interesting, in particular for people
interested in open compilation.

On the source forge page I read
(http://sourceforge.net/projects/introspector/)
--
The GCC Node Introspector is a perl XML interface to GNU Compiler
Collection (GCC) to support meta programming in c/c++ and perl. This
project is underway
--

I was wondering if introspector in its current state primarily targets
documentation and reverse-engineering purposes, or is bound in the
mid-term to do things similar to those OpenC++ does right now (and maybe
more).

Best regards

Francois

On Thu, 2002-12-05 at 13:44, James Michael DuPont wrote:
> did you compile libgc yourself?
> 
> I have libgc as part of gcc installed here,
> 
> # if defined(I_HIDE_POINTERS) || defined(GC_I_HIDE_POINTERS)
>     typedef GC_word GC_hidden_pointer;
> #   define HIDE_POINTER(p) (~(GC_hidden_pointer)(p))
> #   define REVEAL_POINTER(p) ((GC_PTR)(HIDE_POINTER(p)))
> 
> Check that you might have to compile all the libs yourself.
> 
> Mike.
> 
> --- Youssef HASSOUN <yha...@dc...> wrote:
> > Hi,
> > I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get
> > the linker problem shown below.
> > Any idea why is that ?
> > 
> > TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
> >  +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj
> > +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj
> > _map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj
> > +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob
> > j +ptr_chck.obj +gc_cpp.obj +mallocx.obj
> >         c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@
> > Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> > Error: Unresolved external '_HIDE_POINTER' referenced from
> > C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> > Error: Unresolved external '_REVEAL_POINTER' referenced from
> > C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> > 
> > ** error 1 ** deleting gctest.exe
> > 
> > Regards.
> 
> 
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
-- 
Francois Taiani                 +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr)  Dependable Computing 
http://www.laas.fr/~ftaiani     and Fault Tolerance

[Opencxx-users] Re: [opencxx] problems with compiling for gctest.exe

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

did you compile libgc yourself?

I have libgc as part of gcc installed here,

# if defined(I_HIDE_POINTERS) || defined(GC_I_HIDE_POINTERS)
    typedef GC_word GC_hidden_pointer;
#   define HIDE_POINTER(p) (~(GC_hidden_pointer)(p))
#   define REVEAL_POINTER(p) ((GC_PTR)(HIDE_POINTER(p)))

Check that you might have to compile all the libs yourself.

Mike.

--- Youssef HASSOUN <yha...@dc...> wrote:
> Hi,
> I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get
> the linker problem shown below.
> Any idea why is that ?
> 
> TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
>  +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj
> +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj
> _map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj
> +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob
> j +ptr_chck.obj +gc_cpp.obj +mallocx.obj
>         c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@
> Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
> Error: Unresolved external '_HIDE_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> Error: Unresolved external '_REVEAL_POINTER' referenced from
> C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
> 
> ** error 1 ** deleting gctest.exe
> 
> Regards.


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Opencxx-users] RE: [opencxx] resources compiling for occ.exe on win2000

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

start with
www.cygwin.com

and download the gcc.

Or do you have to use this stupid mscv compiler?
mike

-----Original Message-----
From: Youssef HASSOUN [mailto:yha...@dc...]
Sent: Thursday, December 05, 2002 12:09 PM
To: op...@cs...
Subject: [opencxx] resources compiling for occ.exe on win2000 


Hi,
Could somebody help me in getting the resources to compile for occ.exe on
windows 2000 (compiler (c1.exe), linker (link.exe) and the libs needed to
compile the openc++ sources). I imagine one needs, in addition, the right
make-tool.

CPP=cl.exe

CPP_PROJ=/nologo /MLd /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D
"_CONSOLE"\
 /D "_MBCS" /FR"$(INTDIR)\\" /Fp"$(INTDIR)\occ.pch" /YX /Fo"$(INTDIR)\\"\
 /Fd"$(INTDIR)\\" /FD /c  /TP

LINK32=link.exe

LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
 advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib\
 odbccp32.lib /nologo /subsystem:console /incremental:yes\
 /pdb:"$(OUTDIR)\occ.pdb" /debug /machine:I386 /out:"$(OUTDIR)\occ.exe"\
 /pdbtype:sept   

thanks.

[Opencxx-users] [opencxx] problems with compiling for gctest.exe

[Youssef H. <yha...@dc...>]

Hi,
I use Borland's compiler bcc32.exe and  linker ilinke.exe and I get the linker problem shown below.
Any idea why is that ?

TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
 +alloc.obj +reclaim.obj +allchblk.obj +misc.obj   +mach_dep.obj +os_dep.obj +mark_rts.obj +headers.obj +mark.obj   +obj
_map.obj +blacklst.obj +finalize.obj +new_hblk.obj   +dbg_mlc.obj +malloc.obj +stubborn.obj +dyn_load.obj   +typd_mlc.ob
j +ptr_chck.obj +gc_cpp.obj +mallocx.obj
        c:\borland\bcc55\bin\bcc32 @MAKE0003.@@@
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_HIDE_POINTER' referenced from C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize
Error: Unresolved external '_REVEAL_POINTER' referenced from C:\PHD\TOOLS\OPENC++2.5.12\SRC\GC\GC.LIB|finalize

** error 1 ** deleting gctest.exe

Regards.

[Opencxx-users] [opencxx] resources compiling for occ.exe on win2000

[Youssef H. <yha...@dc...>]

Hi,
Could somebody help me in getting the resources to compile for occ.exe on windows 2000 (compiler (c1.exe), linker (link.exe) and the libs needed to compile the openc++ sources). I imagine one needs, in addition, the right make-tool.

CPP=cl.exe

CPP_PROJ=/nologo /MLd /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE"\
 /D "_MBCS" /FR"$(INTDIR)\\" /Fp"$(INTDIR)\occ.pch" /YX /Fo"$(INTDIR)\\"\
 /Fd"$(INTDIR)\\" /FD /c  /TP

LINK32=link.exe

LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib\
 advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib\
 odbccp32.lib /nologo /subsystem:console /incremental:yes\
 /pdb:"$(OUTDIR)\occ.pdb" /debug /machine:I386 /out:"$(OUTDIR)\occ.exe"\
 /pdbtype:sept   

thanks.

[Opencxx-users] compiling openc++ sources on win2000

[Youssef H. <yha...@dc...>]

Hi,
Could somebody help me in getting the compiler (c1.exe), the linker =
(link.exe) and the libs needed to compile the openc++ sources.
I imagine one needs, in addition, the right make-tool.

CPP=3Dcl.exe

CPP_PROJ=3D/nologo /MLd /W3 /Gm /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D =
"_CONSOLE"\
 /D "_MBCS" /FR"$(INTDIR)\\" /Fp"$(INTDIR)\occ.pch" /YX =
/Fo"$(INTDIR)\\"\
 /Fd"$(INTDIR)\\" /FD /c  /TP

LINK32=3Dlink.exe

LINK32_FLAGS=3Dkernel32.lib user32.lib gdi32.lib winspool.lib =
comdlg32.lib\
 advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib\
 odbccp32.lib /nologo /subsystem:console /incremental:yes\
 /pdb:"$(OUTDIR)\occ.pdb" /debug /machine:I386 /out:"$(OUTDIR)\occ.exe"\
 /pdbtype:sept  =20

thanks.

[Opencxx-users] Re: [opencxx] How to change the function return type

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

> I want to change the function return type from double to string. Can
> anybody tell me how to accomplish it?

This is a good question. I am not sure if OpenC++ lets you do it
out-of-the-box. If you figure out that you want to implement this
functionality by yourself, have a look at Member::SetArgumentList()
and search for 'new_args' in member.{h,cc} .

Best regards
GJ

>
> //sample code
> Class A {
> Public:
>
>   	A(){}
> 	~A(){}
> 	double func();
>
> };
> double A::func() {
> 	double d;
> 	cout<<"func is called"<<endl;
> 	return d;
> }
>
> In this code, I want to change the function return type to char in all
> the places i.e. in function declaration and definition. Inside the
> function definition, I am able to change it but not the return type.
>
> Any help is welcome.
>              - Thanx SureshLalwani.
>
>
>
>
>
> -----Original Message-----
> From: own...@cs...
> [mailto:own...@cs...] On Behalf Of Grzegorz Jakacki
> Sent: Tuesday, November 26, 2002 2:10 AM
> To: OpenC++
> Subject: RE: [opencxx] Looking for help
>
> On Mon, 25 Nov 2002, suresh wrote:
>
> > Hi,
> > I have solved the first and third problem mentioned in my previous
> > email. Thanx for you guys help. For the second problem, which is
> finding
> > the instantiation of all the objects of a class (classA), I just need
> to
> > know the instantiation statements. I don't want any runtime
> information.
> > Based on the objects (object names), I have to add MACROs in the
> header
> > file of ClassA. The macro will take object name as an argument.
> >
> > Explaination:
> >
> > /* classA in file classA.h and classA.cpp */
> > Class classA {
> > 	.....
> > 	.....
> > 	......
> > }
> >
> > /* classB in file classB.h and classB.cpp */
> > class classB {
> > 	.....
> > 	classA objA1;
> > 	classA objA2 = new classA;
>         ^^^^^^^^^^^^
>         classA* objA2 ?
>
> > 	.....
> > }
> >
> > Now I need to add MACRONAME(objA1) and MACRONAME(objA2) in the header
> > file of classA.
>
> Do you want to translate individual header files? It is going to be
> difficult, since OpenC++ sits behind preprocessor, so it does not really
> see separate header files. If it is enough to just add the macros in
> *translation unit*, that should be easy (see AppendAfterTopLevel()).
> Remember to instruct OpenC++ to perform second preprocessor pass.
> If this advice is not what you are looking for then I am afraid you have
> to shed some more light on why do you need those macros.
>
> > Any help is welcome. I am facing one more problem, I
> > tried translateNew But translateNew's arguments don't have the object
> > name.
>
> Because object created with "new" does not have a name. What do you mean
> by "object name" in:
>
>     some_function(2, new classA);
>
> ?
>
> Do you really want to find all instantiations or just instantiations of
> some specific form (e.g. "classA* ID = new classA") and nothing else?
>
> 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. #
> ##################################################################
>
>
>
>
>
>
>

##################################################################
# 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] How to change the function return type

[suresh <su...@em...>]

Hi,
I want to change the function return type from double to string. Can
anybody tell me how to accomplish it?

//sample code
Class A {
Public:

  	A(){}
	~A(){}
	double func();

};
double A::func() {
	double d;
	cout<<"func is called"<<endl;
	return d;
}

In this code, I want to change the function return type to char in all
the places i.e. in function declaration and definition. Inside the
function definition, I am able to change it but not the return type.

Any help is welcome.
             - Thanx SureshLalwani.





-----Original Message-----
From: own...@cs...
[mailto:own...@cs...] On Behalf Of Grzegorz Jakacki
Sent: Tuesday, November 26, 2002 2:10 AM
To: OpenC++
Subject: RE: [opencxx] Looking for help

On Mon, 25 Nov 2002, suresh wrote:

> Hi,
> I have solved the first and third problem mentioned in my previous
> email. Thanx for you guys help. For the second problem, which is
finding
> the instantiation of all the objects of a class (classA), I just need
to
> know the instantiation statements. I don't want any runtime
information.
> Based on the objects (object names), I have to add MACROs in the
header
> file of ClassA. The macro will take object name as an argument.
>
> Explaination:
>
> /* classA in file classA.h and classA.cpp */
> Class classA {
> 	.....
> 	.....
> 	......
> }
>
> /* classB in file classB.h and classB.cpp */
> class classB {
> 	.....
> 	classA objA1;
> 	classA objA2 = new classA;
        ^^^^^^^^^^^^
        classA* objA2 ?

> 	.....
> }
>
> Now I need to add MACRONAME(objA1) and MACRONAME(objA2) in the header
> file of classA.

Do you want to translate individual header files? It is going to be
difficult, since OpenC++ sits behind preprocessor, so it does not really
see separate header files. If it is enough to just add the macros in
*translation unit*, that should be easy (see AppendAfterTopLevel()).
Remember to instruct OpenC++ to perform second preprocessor pass.
If this advice is not what you are looking for then I am afraid you have
to shed some more light on why do you need those macros.

> Any help is welcome. I am facing one more problem, I
> tried translateNew But translateNew's arguments don't have the object
> name.

Because object created with "new" does not have a name. What do you mean
by "object name" in:

    some_function(2, new classA);

?

Do you really want to find all instantiations or just instantiations of
some specific form (e.g. "classA* ID = new classA") and nothing else?

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] move this ML to sourceforge

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

Dear all the subscribers of the OpenC++ mailing list:

I eventually contacted the sourceforge admin to move this mailing list
to sourceforge.  Their response is very quick and kind, so now we can
move only if I send them the list of the subscribers.

See this for details:

https://sourceforge.net/tracker/?func=detail&atid=200001&aid=643933&group_id=1

I'll send the list tomorrow night (evening in Europe, morning in US).
If any one has objection, please email me before that time.  (You should
be able to unsubscribe this mailing list after the move, though.)

Regards,

Chiba

[Opencxx-users] RE: [opencxx] Looking for help

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

On Mon, 25 Nov 2002, suresh wrote:

> Hi,
> I have solved the first and third problem mentioned in my previous
> email. Thanx for you guys help. For the second problem, which is finding
> the instantiation of all the objects of a class (classA), I just need to
> know the instantiation statements. I don't want any runtime information.
> Based on the objects (object names), I have to add MACROs in the header
> file of ClassA. The macro will take object name as an argument.
>
> Explaination:
>
> /* classA in file classA.h and classA.cpp */
> Class classA {
> 	.....
> 	.....
> 	......
> }
>
> /* classB in file classB.h and classB.cpp */
> class classB {
> 	.....
> 	classA objA1;
> 	classA objA2 = new classA;
        ^^^^^^^^^^^^
        classA* objA2 ?

> 	.....
> }
>
> Now I need to add MACRONAME(objA1) and MACRONAME(objA2) in the header
> file of classA.

Do you want to translate individual header files? It is going to be
difficult, since OpenC++ sits behind preprocessor, so it does not really
see separate header files. If it is enough to just add the macros in
*translation unit*, that should be easy (see AppendAfterTopLevel()).
Remember to instruct OpenC++ to perform second preprocessor pass.
If this advice is not what you are looking for then I am afraid you have
to shed some more light on why do you need those macros.

> Any help is welcome. I am facing one more problem, I
> tried translateNew But translateNew's arguments don't have the object
> name.

Because object created with "new" does not have a name. What do you mean
by "object name" in:

    some_function(2, new classA);

?

Do you really want to find all instantiations or just instantiations of
some specific form (e.g. "classA* ID = new classA") and nothing else?

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] Looking for help

[suresh <su...@em...>]

Hi,
I have solved the first and third problem mentioned in my previous
email. Thanx for you guys help. For the second problem, which is finding
the instantiation of all the objects of a class (classA), I just need to
know the instantiation statements. I don't want any runtime information.
Based on the objects (object names), I have to add MACROs in the header
file of ClassA. The macro will take object name as an argument.

Explaination:

/* classA in file classA.h and classA.cpp */
Class classA {
	.....
	.....
	......
}

/* classB in file classB.h and classB.cpp */
class classB {
	.....
	classA objA1;
	classA objA2 = new classA;
	.....
}

Now I need to add MACRONAME(objA1) and MACRONAME(objA2) in the header
file of classA. Any help is welcome. I am facing one more problem, I
tried translateNew But translateNew's arguments don't have the object
name. Is there anyway, I can get the name of object? Thanx in advance
		-Suresh Lalwani

Note: I am using opencxx-2.5.12 version on windows XP for development
purpose. Later on I will use this program on a Sun machine.



-----Original Message-----
From: own...@cs...
[mailto:own...@cs...] On Behalf Of Francois Taiani
Sent: Monday, November 25, 2002 1:57 AM
To: OpenC++
Subject: Re: [opencxx] Looking for help

Hi Suresh,

I'm not a big expert on opencxx, but here are the few hints I can give
you regarding your questions:

On Fri, 2002-11-22 at 22:46, suresh wrote:
> 
> 1.	When I am trying to load the metaclass for c functions. It is
> giving warning that: 'Mop is not able to load the "CFunctionClass" '.
> CFunctionClass is a metaclass which I defined for translation of C
> functions. Here is the code
> 

Metaclasses are compiled into shared libraries. The error may come from
occ not finding CFunctionClass.so in its library search path. Here's
what the command reference says on the topic (man occ): "

"First, MyClass.mc should be compiled into shared libraries MyClass.so
and MyClass-init.so. The produced shared libraries must be under the
directory specified by LD_LIBRARY_PATH."

> 
> 2.	I have several classes. I am using the same metaclass for all
> classes' code translation. The problem is I need to see how many
objects
> of a class (say classA) are instantiated in the whole application. 

If you want to know the number of instantiation *statements* (i.e. the
number of places in your code where you have "new classA"), I think occ
can do that. If you need to know the number of instances of a given
class that may be constructed on a given program run, I'm afraid no open
compiler can do that. (I'm afraid that's what is called an undecidable
property.)

For the first question, I think you can use the Class::TranslateNew
method.

---
Ptree* TranslateNew(Environment* env, Ptree* header,
            Ptree* new_op, Ptree* placement,
            Ptree* type_name, Ptree* arglist)

This translates a new expression. header is a user-defined keyword (type
modifier), :: (if the expression is ::new), or nil. new_op is the new
operator. type_name may include an array size surrounded by []. arglist
is arguments to the constructor. It includes parentheses () . placement,
type_name, and arglist have not been translated yet.
--

>  
> 
> 3.	As I have one metaclass, I want to statically overload this
> metaclass so that I don't need to insert the metaclass declaration
> before every class definition. I tried using
> "ChangeDefaultMetaClass("mainMetaClass)" by calling it from the
> Initialize() method and using -S option at the time of compilation but
> this is not working. 
> 
>                   %occ -S mainMetaClass.mc
> 
> this command is giving me problems at the time of linking.
> 
What kind of linking problems? I have a small example that exactly do
that and compiles fine. Here's what it looks like:

--
class MyMetaClass : public Class {
public:
  static bool Initialize();
[...]
}

// ----------------------------------------------------------
bool MyMetaClass::Initialize() {
  Class::ChangeDefaultMetaclass  ("MyMetaClass");
  Class::SetMetaclassForFunctions("MyMetaClass");
  return true ;
} // EndMethod MyMetaClass::Initialize
--  

Cheers

Francois

[Opencxx-users] Re: [opencxx] Looking for help

[Francois T. <fra...@la...>]

Hi Suresh,

I'm not a big expert on opencxx, but here are the few hints I can give
you regarding your questions:

On Fri, 2002-11-22 at 22:46, suresh wrote:
> 
> 1.	When I am trying to load the metaclass for c functions. It is
> giving warning that: 'Mop is not able to load the "CFunctionClass" '.
> CFunctionClass is a metaclass which I defined for translation of C
> functions. Here is the code
> 

Metaclasses are compiled into shared libraries. The error may come from
occ not finding CFunctionClass.so in its library search path. Here's
what the command reference says on the topic (man occ): "

"First, MyClass.mc should be compiled into shared libraries MyClass.so
and MyClass-init.so. The produced shared libraries must be under the
directory specified by LD_LIBRARY_PATH."

> 
> 2.	I have several classes. I am using the same metaclass for all
> classes' code translation. The problem is I need to see how many objects
> of a class (say classA) are instantiated in the whole application. 

If you want to know the number of instantiation *statements* (i.e. the
number of places in your code where you have "new classA"), I think occ
can do that. If you need to know the number of instances of a given
class that may be constructed on a given program run, I'm afraid no open
compiler can do that. (I'm afraid that's what is called an undecidable
property.)

For the first question, I think you can use the Class::TranslateNew
method.

---
Ptree* TranslateNew(Environment* env, Ptree* header,
            Ptree* new_op, Ptree* placement,
            Ptree* type_name, Ptree* arglist)

This translates a new expression. header is a user-defined keyword (type
modifier), :: (if the expression is ::new), or nil. new_op is the new
operator. type_name may include an array size surrounded by []. arglist
is arguments to the constructor. It includes parentheses () . placement,
type_name, and arglist have not been translated yet.
--

>  
> 
> 3.	As I have one metaclass, I want to statically overload this
> metaclass so that I don't need to insert the metaclass declaration
> before every class definition. I tried using
> "ChangeDefaultMetaClass("mainMetaClass)" by calling it from the
> Initialize() method and using -S option at the time of compilation but
> this is not working. 
> 
>                   %occ -S mainMetaClass.mc
> 
> this command is giving me problems at the time of linking.
> 
What kind of linking problems? I have a small example that exactly do
that and compiles fine. Here's what it looks like:

--
class MyMetaClass : public Class {
public:
  static bool Initialize();
[...]
}

// ----------------------------------------------------------
bool MyMetaClass::Initialize() {
  Class::ChangeDefaultMetaclass  ("MyMetaClass");
  Class::SetMetaclassForFunctions("MyMetaClass");
  return true ;
} // EndMethod MyMetaClass::Initialize
--  

Cheers

Francois

[Opencxx-users] Re: [opencxx] Looking for help

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

On Fri, 22 Nov 2002, suresh wrote:

[...]
> 1.	When I am trying to load the metaclass for c functions. It is
> giving warning that: 'Mop is not able to load the "CFunctionClass" '.

Which version of OpenC++ is it? What OS is this? Are you compiling your
metaclass to dlopenable module (usually something like CFunctionClass.so)?
Are you sure the library function (dlopen() or lt_dlopen(), depending on
the version of OpenC++) is able to find your dlopenable module (depending
on OS you may be required to set up LD_LIBRARY_PATH or something similar)?

[...]
> 2.	I have several classes. I am using the same metaclass for all
> classes' code translation. The problem is I need to see how many objects
> of a class (say classA) are instantiated in the whole application. I.e.
> there may be a class classB where the object of classA is instantiated.
> I want to know all such objects and put the MACRO definition for them in
> the class header file.

I do not quite understand. Object instantiation takes place during the
execution. OpenC++ deals with classes defined in the input file, not
objects that are instantiated during the execution of (possibly compiled)
input file.

Perhaps you are trying to find all classes in which instantiation of
objects of 'classA' can possibly take place. In general this is difficult,
but possible. Observe, that object of type 'classA' can be instantiated in
many ways, for instance:

  * definition of variable of type 'classA',
  * instantiation of object that has (possibly indirect) subobject of
    type 'classA' or member of type 'classA'
  * 'new classA'
  * 'classA()' within expression
  * user-defined conversion (this one is difficult to find!!!)

Think also about distasters like:

    template <class T> class Foo { ... };
    template <class T> class Foo<T*> { ... new classA ... };

There is a possible instantiation of object of type 'classA' within
some (!) specializations of class template Foo.

Hopefully you do not need to handle all the above cases.

It is also not clear to me where you want to put your macro, why you want
to do it and what would it expand to --- declaration, expression?

> 3.	As I have one metaclass, I want to statically overload this
> metaclass so that I don't need to insert the metaclass declaration
> before every class definition.

I do not quite understand what you mean by "overloading a metaclass".
In C++ you can overload functions, not classes (nor metaclasses in
OpenC++).

> I tried using
> "ChangeDefaultMetaClass("mainMetaClass)" by calling it from the
> Initialize() method and using -S option at the time of compilation but
> this is not working.
>
>                   %occ -S mainMetaClass.mc
>
> this command is giving me problems at the time of linking.

Error message would help a lot to see what is really going wrong. If you
can post short exemplary source on which occ fails, that would help even
more.

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] Looking for help

[suresh <su...@em...>]

Hi,

My name is Suresh. I am new to OpenC++ group. I am working on a project
which basically does the source code translation. I am facing few
problems. These problems are:-

 

1.	When I am trying to load the metaclass for c functions. It is
giving warning that: 'Mop is not able to load the "CFunctionClass" '.
CFunctionClass is a metaclass which I defined for translation of C
functions. Here is the code

//In my main metaclass  inside Initialize(), I have 

setMetaclassForFunctions("CFunctionClass");

 

//and in CFunctionClass.mc, I have overloaded a class member function 

TranslateFunctionCall(...) {

            ..

            ..

}

            The idea is I want to change the function call in main()
method and this function is not part of any class which have metaclass
declaration.

            This function is like C library function defined by some
other vendor.

 

2.	I have several classes. I am using the same metaclass for all
classes' code translation. The problem is I need to see how many objects
of 

a class (say classA) are instantiated in the whole application. I.e.
there may be a class classB where the object of classA is instantiated.
I want to know all such objects and put the MACRO definition for them in
the class header file. 

 

3.	As I have one metaclass, I want to statically overload this
metaclass so that I don't need to insert the metaclass declaration
before every class definition. I tried using
"ChangeDefaultMetaClass("mainMetaClass)" by calling it from the
Initialize() method and using -S option at the time of compilation but
this is not working. 

                  %occ -S mainMetaClass.mc

this command is giving me problems at the time of linking.

 

If anybody know about any of the problem. Plzz email me. Thanks in
advance

                                                - Suresh Lalwani.

 

 

 

 

[Opencxx-users] Re: [opencxx] Another question regarding double inheritance

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

On 6 Nov 2002, Francois Taiani wrote:

> Hi Grzegorz,
>
> thanks for having check the testcase against current CVS.
>
> > I am sorry, but at the moment I do not have time to check if this is a real
> > fix. If somebody can pick it up (add testcase, try this fix, run tests,
> > commit if ok), please do. Francois, can you track this bug and make sure
> > that eventually the fix is checked in?
>
> I'll try to do it, though given my high personal "context switch rate",
> I don't promise to be very performant. As soon as I've tested your fix,
> I'll let you know what the results are.

OK, thanks.

Grzegorz

>
> Cheers
>
> Francois
>
> On Wed, 2002-11-06 at 09:47, Grzegorz Jakacki wrote:
> > On 4 Nov 2002, Francois Taiani wrote:
> >
> > > Hi Grzegorz
> > >
> > > I'm using OpenC++ version 2.5.12, along with gcc 2.95.4, libc6 2.2.5,
> > > and libstdc++ 2.10. My machine runs Linux kernel 2.4.18 on a pentium
> > > III.
> >
> > I tried on HEAD version from CVS, the bug is still there.
> >
> > What I have found (line numbers according to HEAD):
> >
> > (1) I found simpler testcase:
> >
> >     class A{};
> >     namespace N
> >     {
> >         class B { };
> >         class A : public ::A, public B
> >         {};
> >     }
> >
> >
> > (2) There is a bug in lookup of base classes. OpenC++ merely ignores the
> >     scope. Thus in the testcase above it links class 'A' (not '::A'!) as
> >     base of 'A', so when it comes to finding 'B' the lookup starts
> >     from the current scope (this is also a little bit strange), which is
> >     class 'A', and proceeds first to base classes, and here it is looping
> >     forever.
> >
> > (3) IMHO it is enough to fix lookup for base classes, namely:
> >
> > env.cc:100     else{
> > env.cc:101         int len;
> > env.cc:102         Environment* e = this;
> > env.cc:103         char* base = Encoding::GetBaseName(name->GetEncodedName(), len, e);
> >
> >     gets name proper into 'base' and environment corresponding
> >     to scope into 'e', but does not use 'e' any more!!!
> >
> > env.cc:104         if(base != nil && e != nil)
> > env.cc:105             if(LookupType(base, len, bind))
> >                                      ^^^^
> >            perhaps just this should be 'e'
> >
> > env.cc:106                 if(bind != nil){
> > env.cc:107                     bind->GetType(tinfo, this);
> > env.cc:108                     return tinfo.ClassMetaobject();
> > env.cc:109                 }
> >
> >
> > I am sorry, but at the moment I do not have time to check if this is a real
> > fix. If somebody can pick it up (add testcase, try this fix, run tests,
> > commit if ok), please do. Francois, can you track this bug and make sure
> > that eventually the fix is checked in?
> >
> > Let me know if any issues.
> >
> > Regards
> > Grzegorz
> >
> > >
> > > Cheers
> > >
> > > Francois
> > >
> > > On Mon, 2002-11-04 at 10:05, Grzegorz Jakacki wrote:
> > > >
> > > > Hi,
> > > >
> > > > Which version of OpenC++ does it?
> > > >
> > > > Regards
> > > > Grzegorz
> > > >
> > > > On 1 Nov 2002, Francois Taiani wrote:
> > > >
> > > > > Hi again,
> > > > >
> > > > > I'm applying OpenC++ on a program with namespaces and double
> > > > > inheritance, and occ seems to have troubles when it encounters the
> > > > > following pattern: (which compile correctly with "g++ -c".)
> > > > > --
> > > > > class A{};
> > > > > namespace N
> > > > > {
> > > > >   class B { };
> > > > >   class A : virtual public ::A, virtual public B
> > > > >   {};
> > > > > }
> > > > > --
> > > > > If I launch occ on this bit of code (here for instance with the default
> > > > > metaclass Class), I get a segmentation fault:
> > > > > --
> > > > > $ /usr/bin/occ -E -SClass test2.cc
> > > > > zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> > > > > --
> > > > > I've used gdb to investigate what was going on and it seems occ is
> > > > > trapped in an infinite recursion. Below is what the bottom of the stack
> > > > > looks like just after the segfault. Environment::SearchBaseOrUsing ()
> > > > > and Environment::LookupType() recursively call each other until the
> > > > > memory space available to the stack gets exhausted.
> > > > > ---
> > > > > <--snip-- Infinite recursion leading to segmentation fault-->
> > > > > ..
> > > > > #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > > #32641 0x080693c9 in Environment::LookupType ()
> > > > > #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > > #32643 0x080693c9 in Environment::LookupType ()
> > > > > #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > > #32645 0x080693c9 in Environment::LookupType ()
> > > > > #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > > #32647 0x080693c9 in Environment::LookupType ()
> > > > > #32648 0x080692bb in Environment::LookupClassMetaobject ()
> > > > > #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> > > > > #32650 0x08085764 in ClassWalker::RecordMembers ()
> > > > > #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> > > > > #32652 0x0806c799 in Walker::TranslateClassSpec ()
> > > > > #32653 0x08062904 in PtreeClassSpec::Translate ()
> > > > > #32654 0x0806b014 in Walker::Translate ()
> > > > > #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> > > > > #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> > > > > #32657 0x08062440 in PtreeDeclaration::Translate ()
> > > > > #32658 0x0806b014 in Walker::Translate ()
> > > > > #32659 0x0806c3a8 in Walker::TranslateBrace ()
> > > > > #32660 0x08062244 in PtreeBrace::Translate ()
> > > > > #32661 0x0806b014 in Walker::Translate ()
> > > > > #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> > > > > #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> > > > > #32664 0x0806b014 in Walker::Translate ()
> > > > > #32665 0x0805de0a in Compile ()
> > > > > #32666 0x0805db2a in Compile ()
> > > > > #32667 0x0805d941 in Compile ()
> > > > > #32668 0x0805d834 in Compile ()
> > > > > #32669 0x0805d7b4 in main ()
> > > > > #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> > > > > ---
> > > > > Interstingly, the segfault disappears if I remove any of the base
> > > > > classes of N::A. For instance occ works fine on
> > > > > --
> > > > > class A{};
> > > > >
> > > > > namespace N
> > > > > {
> > > > >   class B { };
> > > > >   class A : virtual public ::A // , virtual public B
> > > > >   {};
> > > > > }
> > > > > --
> > > > > The problem also disappears if I use another name for N::A (one that
> > > > > does not mask ::A). I think this is a bug, but I'm not sure. Would
> > > > > someone have any comment on it ?
> > > > >
> > > > > Thanks in advance
> > > > >
> > > > > Francois
> > > > >
> > > > > --
> > > > > Francois Taiani                 +33 (0) 5 6133 6406
> > > > > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > > > > http://www.laas.fr/~ftaiani     and Fault Tolerance
> > > > >
> > > > >
> > > > >
> > > >
> > > > ##################################################################
> > > > # 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. #
> > > > ##################################################################
> > > --
> > > Francois Taiani                 +33 (0) 5 6133 6406
> > > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > > http://www.laas.fr/~ftaiani     and Fault Tolerance
> > >
> > >
> > >
> >
> > ##################################################################
> > # 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. #
> > ##################################################################
> --
> Francois Taiani                 +33 (0) 5 6133 6406
> LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> http://www.laas.fr/~ftaiani     and Fault Tolerance
>
>
>

##################################################################
# 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] Another question regarding double inheritance

[Francois T. <fra...@la...>]

Hi Grzegorz,

thanks for having check the testcase against current CVS.

> I am sorry, but at the moment I do not have time to check if this is a real
> fix. If somebody can pick it up (add testcase, try this fix, run tests,
> commit if ok), please do. Francois, can you track this bug and make sure
> that eventually the fix is checked in?

I'll try to do it, though given my high personal "context switch rate",
I don't promise to be very performant. As soon as I've tested your fix,
I'll let you know what the results are. 

Cheers

Francois

On Wed, 2002-11-06 at 09:47, Grzegorz Jakacki wrote:
> On 4 Nov 2002, Francois Taiani wrote:
> 
> > Hi Grzegorz
> >
> > I'm using OpenC++ version 2.5.12, along with gcc 2.95.4, libc6 2.2.5,
> > and libstdc++ 2.10. My machine runs Linux kernel 2.4.18 on a pentium
> > III.
> 
> I tried on HEAD version from CVS, the bug is still there.
> 
> What I have found (line numbers according to HEAD):
> 
> (1) I found simpler testcase:
> 
>     class A{};
>     namespace N
>     {
>         class B { };
>         class A : public ::A, public B
>         {};
>     }
> 
> 
> (2) There is a bug in lookup of base classes. OpenC++ merely ignores the
>     scope. Thus in the testcase above it links class 'A' (not '::A'!) as
>     base of 'A', so when it comes to finding 'B' the lookup starts
>     from the current scope (this is also a little bit strange), which is
>     class 'A', and proceeds first to base classes, and here it is looping
>     forever.
> 
> (3) IMHO it is enough to fix lookup for base classes, namely:
> 
> env.cc:100     else{
> env.cc:101         int len;
> env.cc:102         Environment* e = this;
> env.cc:103         char* base = Encoding::GetBaseName(name->GetEncodedName(), len, e);
> 
>     gets name proper into 'base' and environment corresponding
>     to scope into 'e', but does not use 'e' any more!!!
> 
> env.cc:104         if(base != nil && e != nil)
> env.cc:105             if(LookupType(base, len, bind))
>                                      ^^^^
>            perhaps just this should be 'e'
> 
> env.cc:106                 if(bind != nil){
> env.cc:107                     bind->GetType(tinfo, this);
> env.cc:108                     return tinfo.ClassMetaobject();
> env.cc:109                 }
> 
> 
> I am sorry, but at the moment I do not have time to check if this is a real
> fix. If somebody can pick it up (add testcase, try this fix, run tests,
> commit if ok), please do. Francois, can you track this bug and make sure
> that eventually the fix is checked in?
> 
> Let me know if any issues.
> 
> Regards
> Grzegorz
> 
> >
> > Cheers
> >
> > Francois
> >
> > On Mon, 2002-11-04 at 10:05, Grzegorz Jakacki wrote:
> > >
> > > Hi,
> > >
> > > Which version of OpenC++ does it?
> > >
> > > Regards
> > > Grzegorz
> > >
> > > On 1 Nov 2002, Francois Taiani wrote:
> > >
> > > > Hi again,
> > > >
> > > > I'm applying OpenC++ on a program with namespaces and double
> > > > inheritance, and occ seems to have troubles when it encounters the
> > > > following pattern: (which compile correctly with "g++ -c".)
> > > > --
> > > > class A{};
> > > > namespace N
> > > > {
> > > >   class B { };
> > > >   class A : virtual public ::A, virtual public B
> > > >   {};
> > > > }
> > > > --
> > > > If I launch occ on this bit of code (here for instance with the default
> > > > metaclass Class), I get a segmentation fault:
> > > > --
> > > > $ /usr/bin/occ -E -SClass test2.cc
> > > > zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> > > > --
> > > > I've used gdb to investigate what was going on and it seems occ is
> > > > trapped in an infinite recursion. Below is what the bottom of the stack
> > > > looks like just after the segfault. Environment::SearchBaseOrUsing ()
> > > > and Environment::LookupType() recursively call each other until the
> > > > memory space available to the stack gets exhausted.
> > > > ---
> > > > <--snip-- Infinite recursion leading to segmentation fault-->
> > > > ..
> > > > #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > #32641 0x080693c9 in Environment::LookupType ()
> > > > #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > #32643 0x080693c9 in Environment::LookupType ()
> > > > #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > #32645 0x080693c9 in Environment::LookupType ()
> > > > #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> > > > #32647 0x080693c9 in Environment::LookupType ()
> > > > #32648 0x080692bb in Environment::LookupClassMetaobject ()
> > > > #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> > > > #32650 0x08085764 in ClassWalker::RecordMembers ()
> > > > #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> > > > #32652 0x0806c799 in Walker::TranslateClassSpec ()
> > > > #32653 0x08062904 in PtreeClassSpec::Translate ()
> > > > #32654 0x0806b014 in Walker::Translate ()
> > > > #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> > > > #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> > > > #32657 0x08062440 in PtreeDeclaration::Translate ()
> > > > #32658 0x0806b014 in Walker::Translate ()
> > > > #32659 0x0806c3a8 in Walker::TranslateBrace ()
> > > > #32660 0x08062244 in PtreeBrace::Translate ()
> > > > #32661 0x0806b014 in Walker::Translate ()
> > > > #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> > > > #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> > > > #32664 0x0806b014 in Walker::Translate ()
> > > > #32665 0x0805de0a in Compile ()
> > > > #32666 0x0805db2a in Compile ()
> > > > #32667 0x0805d941 in Compile ()
> > > > #32668 0x0805d834 in Compile ()
> > > > #32669 0x0805d7b4 in main ()
> > > > #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> > > > ---
> > > > Interstingly, the segfault disappears if I remove any of the base
> > > > classes of N::A. For instance occ works fine on
> > > > --
> > > > class A{};
> > > >
> > > > namespace N
> > > > {
> > > >   class B { };
> > > >   class A : virtual public ::A // , virtual public B
> > > >   {};
> > > > }
> > > > --
> > > > The problem also disappears if I use another name for N::A (one that
> > > > does not mask ::A). I think this is a bug, but I'm not sure. Would
> > > > someone have any comment on it ?
> > > >
> > > > Thanks in advance
> > > >
> > > > Francois
> > > >
> > > > --
> > > > Francois Taiani                 +33 (0) 5 6133 6406
> > > > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > > > http://www.laas.fr/~ftaiani     and Fault Tolerance
> > > >
> > > >
> > > >
> > >
> > > ##################################################################
> > > # 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. #
> > > ##################################################################
> > --
> > Francois Taiani                 +33 (0) 5 6133 6406
> > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > http://www.laas.fr/~ftaiani     and Fault Tolerance
> >
> >
> >
> 
> ##################################################################
> # 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. #
> ##################################################################
-- 
Francois Taiani                 +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr)  Dependable Computing 
http://www.laas.fr/~ftaiani     and Fault Tolerance

[Opencxx-users] Re: [opencxx] Another question regarding double inheritance

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

On 4 Nov 2002, Francois Taiani wrote:

> Hi Grzegorz
>
> I'm using OpenC++ version 2.5.12, along with gcc 2.95.4, libc6 2.2.5,
> and libstdc++ 2.10. My machine runs Linux kernel 2.4.18 on a pentium
> III.

I tried on HEAD version from CVS, the bug is still there.

What I have found (line numbers according to HEAD):

(1) I found simpler testcase:

    class A{};
    namespace N
    {
        class B { };
        class A : public ::A, public B
        {};
    }


(2) There is a bug in lookup of base classes. OpenC++ merely ignores the
    scope. Thus in the testcase above it links class 'A' (not '::A'!) as
    base of 'A', so when it comes to finding 'B' the lookup starts
    from the current scope (this is also a little bit strange), which is
    class 'A', and proceeds first to base classes, and here it is looping
    forever.

(3) IMHO it is enough to fix lookup for base classes, namely:

env.cc:100     else{
env.cc:101         int len;
env.cc:102         Environment* e = this;
env.cc:103         char* base = Encoding::GetBaseName(name->GetEncodedName(), len, e);

    gets name proper into 'base' and environment corresponding
    to scope into 'e', but does not use 'e' any more!!!

env.cc:104         if(base != nil && e != nil)
env.cc:105             if(LookupType(base, len, bind))
                                     ^^^^
           perhaps just this should be 'e'

env.cc:106                 if(bind != nil){
env.cc:107                     bind->GetType(tinfo, this);
env.cc:108                     return tinfo.ClassMetaobject();
env.cc:109                 }


I am sorry, but at the moment I do not have time to check if this is a real
fix. If somebody can pick it up (add testcase, try this fix, run tests,
commit if ok), please do. Francois, can you track this bug and make sure
that eventually the fix is checked in?

Let me know if any issues.

Regards
Grzegorz

>
> Cheers
>
> Francois
>
> On Mon, 2002-11-04 at 10:05, Grzegorz Jakacki wrote:
> >
> > Hi,
> >
> > Which version of OpenC++ does it?
> >
> > Regards
> > Grzegorz
> >
> > On 1 Nov 2002, Francois Taiani wrote:
> >
> > > Hi again,
> > >
> > > I'm applying OpenC++ on a program with namespaces and double
> > > inheritance, and occ seems to have troubles when it encounters the
> > > following pattern: (which compile correctly with "g++ -c".)
> > > --
> > > class A{};
> > > namespace N
> > > {
> > >   class B { };
> > >   class A : virtual public ::A, virtual public B
> > >   {};
> > > }
> > > --
> > > If I launch occ on this bit of code (here for instance with the default
> > > metaclass Class), I get a segmentation fault:
> > > --
> > > $ /usr/bin/occ -E -SClass test2.cc
> > > zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> > > --
> > > I've used gdb to investigate what was going on and it seems occ is
> > > trapped in an infinite recursion. Below is what the bottom of the stack
> > > looks like just after the segfault. Environment::SearchBaseOrUsing ()
> > > and Environment::LookupType() recursively call each other until the
> > > memory space available to the stack gets exhausted.
> > > ---
> > > <--snip-- Infinite recursion leading to segmentation fault-->
> > > ..
> > > #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32641 0x080693c9 in Environment::LookupType ()
> > > #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32643 0x080693c9 in Environment::LookupType ()
> > > #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32645 0x080693c9 in Environment::LookupType ()
> > > #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> > > #32647 0x080693c9 in Environment::LookupType ()
> > > #32648 0x080692bb in Environment::LookupClassMetaobject ()
> > > #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> > > #32650 0x08085764 in ClassWalker::RecordMembers ()
> > > #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> > > #32652 0x0806c799 in Walker::TranslateClassSpec ()
> > > #32653 0x08062904 in PtreeClassSpec::Translate ()
> > > #32654 0x0806b014 in Walker::Translate ()
> > > #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> > > #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> > > #32657 0x08062440 in PtreeDeclaration::Translate ()
> > > #32658 0x0806b014 in Walker::Translate ()
> > > #32659 0x0806c3a8 in Walker::TranslateBrace ()
> > > #32660 0x08062244 in PtreeBrace::Translate ()
> > > #32661 0x0806b014 in Walker::Translate ()
> > > #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> > > #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> > > #32664 0x0806b014 in Walker::Translate ()
> > > #32665 0x0805de0a in Compile ()
> > > #32666 0x0805db2a in Compile ()
> > > #32667 0x0805d941 in Compile ()
> > > #32668 0x0805d834 in Compile ()
> > > #32669 0x0805d7b4 in main ()
> > > #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> > > ---
> > > Interstingly, the segfault disappears if I remove any of the base
> > > classes of N::A. For instance occ works fine on
> > > --
> > > class A{};
> > >
> > > namespace N
> > > {
> > >   class B { };
> > >   class A : virtual public ::A // , virtual public B
> > >   {};
> > > }
> > > --
> > > The problem also disappears if I use another name for N::A (one that
> > > does not mask ::A). I think this is a bug, but I'm not sure. Would
> > > someone have any comment on it ?
> > >
> > > Thanks in advance
> > >
> > > Francois
> > >
> > > --
> > > Francois Taiani                 +33 (0) 5 6133 6406
> > > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > > http://www.laas.fr/~ftaiani     and Fault Tolerance
> > >
> > >
> > >
> >
> > ##################################################################
> > # 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. #
> > ##################################################################
> --
> Francois Taiani                 +33 (0) 5 6133 6406
> LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> http://www.laas.fr/~ftaiani     and Fault Tolerance
>
>
>

##################################################################
# 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] Another question regarding double inheritance

[Francois T. <fra...@la...>]

Hi Grzegorz

I'm using OpenC++ version 2.5.12, along with gcc 2.95.4, libc6 2.2.5,
and libstdc++ 2.10. My machine runs Linux kernel 2.4.18 on a pentium
III.

Cheers

Francois

On Mon, 2002-11-04 at 10:05, Grzegorz Jakacki wrote:
> 
> Hi,
> 
> Which version of OpenC++ does it?
> 
> Regards
> Grzegorz
> 
> On 1 Nov 2002, Francois Taiani wrote:
> 
> > Hi again,
> >
> > I'm applying OpenC++ on a program with namespaces and double
> > inheritance, and occ seems to have troubles when it encounters the
> > following pattern: (which compile correctly with "g++ -c".)
> > --
> > class A{};
> > namespace N
> > {
> >   class B { };
> >   class A : virtual public ::A, virtual public B
> >   {};
> > }
> > --
> > If I launch occ on this bit of code (here for instance with the default
> > metaclass Class), I get a segmentation fault:
> > --
> > $ /usr/bin/occ -E -SClass test2.cc
> > zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> > --
> > I've used gdb to investigate what was going on and it seems occ is
> > trapped in an infinite recursion. Below is what the bottom of the stack
> > looks like just after the segfault. Environment::SearchBaseOrUsing ()
> > and Environment::LookupType() recursively call each other until the
> > memory space available to the stack gets exhausted.
> > ---
> > <--snip-- Infinite recursion leading to segmentation fault-->
> > ..
> > #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> > #32641 0x080693c9 in Environment::LookupType ()
> > #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> > #32643 0x080693c9 in Environment::LookupType ()
> > #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> > #32645 0x080693c9 in Environment::LookupType ()
> > #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> > #32647 0x080693c9 in Environment::LookupType ()
> > #32648 0x080692bb in Environment::LookupClassMetaobject ()
> > #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> > #32650 0x08085764 in ClassWalker::RecordMembers ()
> > #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> > #32652 0x0806c799 in Walker::TranslateClassSpec ()
> > #32653 0x08062904 in PtreeClassSpec::Translate ()
> > #32654 0x0806b014 in Walker::Translate ()
> > #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> > #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> > #32657 0x08062440 in PtreeDeclaration::Translate ()
> > #32658 0x0806b014 in Walker::Translate ()
> > #32659 0x0806c3a8 in Walker::TranslateBrace ()
> > #32660 0x08062244 in PtreeBrace::Translate ()
> > #32661 0x0806b014 in Walker::Translate ()
> > #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> > #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> > #32664 0x0806b014 in Walker::Translate ()
> > #32665 0x0805de0a in Compile ()
> > #32666 0x0805db2a in Compile ()
> > #32667 0x0805d941 in Compile ()
> > #32668 0x0805d834 in Compile ()
> > #32669 0x0805d7b4 in main ()
> > #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> > ---
> > Interstingly, the segfault disappears if I remove any of the base
> > classes of N::A. For instance occ works fine on
> > --
> > class A{};
> >
> > namespace N
> > {
> >   class B { };
> >   class A : virtual public ::A // , virtual public B
> >   {};
> > }
> > --
> > The problem also disappears if I use another name for N::A (one that
> > does not mask ::A). I think this is a bug, but I'm not sure. Would
> > someone have any comment on it ?
> >
> > Thanks in advance
> >
> > Francois
> >
> > --
> > Francois Taiani                 +33 (0) 5 6133 6406
> > LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> > http://www.laas.fr/~ftaiani     and Fault Tolerance
> >
> >
> >
> 
> ##################################################################
> # 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. #
> ##################################################################
-- 
Francois Taiani                 +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr)  Dependable Computing 
http://www.laas.fr/~ftaiani     and Fault Tolerance

[Opencxx-users] Re: [opencxx] Another question regarding double inheritance

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

Hi,

Which version of OpenC++ does it?

Regards
Grzegorz

On 1 Nov 2002, Francois Taiani wrote:

> Hi again,
>
> I'm applying OpenC++ on a program with namespaces and double
> inheritance, and occ seems to have troubles when it encounters the
> following pattern: (which compile correctly with "g++ -c".)
> --
> class A{};
> namespace N
> {
>   class B { };
>   class A : virtual public ::A, virtual public B
>   {};
> }
> --
> If I launch occ on this bit of code (here for instance with the default
> metaclass Class), I get a segmentation fault:
> --
> $ /usr/bin/occ -E -SClass test2.cc
> zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
> --
> I've used gdb to investigate what was going on and it seems occ is
> trapped in an infinite recursion. Below is what the bottom of the stack
> looks like just after the segfault. Environment::SearchBaseOrUsing ()
> and Environment::LookupType() recursively call each other until the
> memory space available to the stack gets exhausted.
> ---
> <--snip-- Infinite recursion leading to segmentation fault-->
> ..
> #32640 0x08069434 in Environment::SearchBaseOrUsing ()
> #32641 0x080693c9 in Environment::LookupType ()
> #32642 0x08069434 in Environment::SearchBaseOrUsing ()
> #32643 0x080693c9 in Environment::LookupType ()
> #32644 0x08069434 in Environment::SearchBaseOrUsing ()
> #32645 0x080693c9 in Environment::LookupType ()
> #32646 0x08069434 in Environment::SearchBaseOrUsing ()
> #32647 0x080693c9 in Environment::LookupType ()
> #32648 0x080692bb in Environment::LookupClassMetaobject ()
> #32649 0x0806af6f in Walker::RecordBaseclassEnv ()
> #32650 0x08085764 in ClassWalker::RecordMembers ()
> #32651 0x08085245 in ClassWalker::TranslateClassSpec ()
> #32652 0x0806c799 in Walker::TranslateClassSpec ()
> #32653 0x08062904 in PtreeClassSpec::Translate ()
> #32654 0x0806b014 in Walker::Translate ()
> #32655 0x0806d72d in Walker::TranslateTypespecifier ()
> #32656 0x0806b8d3 in Walker::TranslateDeclaration ()
> #32657 0x08062440 in PtreeDeclaration::Translate ()
> #32658 0x0806b014 in Walker::Translate ()
> #32659 0x0806c3a8 in Walker::TranslateBrace ()
> #32660 0x08062244 in PtreeBrace::Translate ()
> #32661 0x0806b014 in Walker::Translate ()
> #32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
> #32663 0x08062394 in PtreeNamespaceSpec::Translate ()
> #32664 0x0806b014 in Walker::Translate ()
> #32665 0x0805de0a in Compile ()
> #32666 0x0805db2a in Compile ()
> #32667 0x0805d941 in Compile ()
> #32668 0x0805d834 in Compile ()
> #32669 0x0805d7b4 in main ()
> #32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
> ---
> Interstingly, the segfault disappears if I remove any of the base
> classes of N::A. For instance occ works fine on
> --
> class A{};
>
> namespace N
> {
>   class B { };
>   class A : virtual public ::A // , virtual public B
>   {};
> }
> --
> The problem also disappears if I use another name for N::A (one that
> does not mask ::A). I think this is a bug, but I'm not sure. Would
> someone have any comment on it ?
>
> Thanks in advance
>
> Francois
>
> --
> Francois Taiani                 +33 (0) 5 6133 6406
> LAAS-CNRS (http://www.laas.fr)  Dependable Computing
> http://www.laas.fr/~ftaiani     and Fault Tolerance
>
>
>

##################################################################
# 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] Another question regarding double inheritance

[Francois T. <fra...@la...>]

Hi again,

I'm applying OpenC++ on a program with namespaces and double
inheritance, and occ seems to have troubles when it encounters the
following pattern: (which compile correctly with "g++ -c".)
--
class A{};
namespace N
{
  class B { };
  class A : virtual public ::A, virtual public B
  {};
}
--
If I launch occ on this bit of code (here for instance with the default
metaclass Class), I get a segmentation fault:
--
$ /usr/bin/occ -E -SClass test2.cc      
zsh: segmentation fault  /usr/bin/occ -SClass test2.cc
--
I've used gdb to investigate what was going on and it seems occ is
trapped in an infinite recursion. Below is what the bottom of the stack
looks like just after the segfault. Environment::SearchBaseOrUsing ()
and Environment::LookupType() recursively call each other until the
memory space available to the stack gets exhausted.
---  
<--snip-- Infinite recursion leading to segmentation fault-->
..
#32640 0x08069434 in Environment::SearchBaseOrUsing ()
#32641 0x080693c9 in Environment::LookupType ()
#32642 0x08069434 in Environment::SearchBaseOrUsing ()
#32643 0x080693c9 in Environment::LookupType ()
#32644 0x08069434 in Environment::SearchBaseOrUsing ()
#32645 0x080693c9 in Environment::LookupType ()
#32646 0x08069434 in Environment::SearchBaseOrUsing ()
#32647 0x080693c9 in Environment::LookupType ()
#32648 0x080692bb in Environment::LookupClassMetaobject ()
#32649 0x0806af6f in Walker::RecordBaseclassEnv ()
#32650 0x08085764 in ClassWalker::RecordMembers ()
#32651 0x08085245 in ClassWalker::TranslateClassSpec ()
#32652 0x0806c799 in Walker::TranslateClassSpec ()
#32653 0x08062904 in PtreeClassSpec::Translate ()
#32654 0x0806b014 in Walker::Translate ()
#32655 0x0806d72d in Walker::TranslateTypespecifier ()
#32656 0x0806b8d3 in Walker::TranslateDeclaration ()
#32657 0x08062440 in PtreeDeclaration::Translate ()
#32658 0x0806b014 in Walker::Translate ()
#32659 0x0806c3a8 in Walker::TranslateBrace ()
#32660 0x08062244 in PtreeBrace::Translate ()
#32661 0x0806b014 in Walker::Translate ()
#32662 0x0806b765 in Walker::TranslateNamespaceSpec ()
#32663 0x08062394 in PtreeNamespaceSpec::Translate ()
#32664 0x0806b014 in Walker::Translate ()
#32665 0x0805de0a in Compile ()
#32666 0x0805db2a in Compile ()
#32667 0x0805d941 in Compile ()
#32668 0x0805d834 in Compile ()
#32669 0x0805d7b4 in main ()
#32670 0x400ca0bf in __libc_start_main () from /lib/libc.so.6
---
Interstingly, the segfault disappears if I remove any of the base
classes of N::A. For instance occ works fine on
--
class A{};

namespace N
{
  class B { };
  class A : virtual public ::A // , virtual public B
  {};
}
--
The problem also disappears if I use another name for N::A (one that
does not mask ::A). I think this is a bug, but I'm not sure. Would
someone have any comment on it ?

Thanks in advance

Francois

-- 
Francois Taiani                 +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr)  Dependable Computing 
http://www.laas.fr/~ftaiani     and Fault Tolerance

[Opencxx-users] [opencxx] Question about Environment::isNamespace()

[Francois T. <fra...@la...>]

Hi everyone,

I'm trying to understand how to use Environment::isNamespace() (which is
documented in
http://www.csg.is.titech.ac.jp/~chiba/opencxx/ref-appendix.html)

The documentation reads: "If this environment represents a name space,
then this member function returns the name of that name space.
Otherwise, it returns nil."

I've written the following small metaprogram that aims at illustrating
that:

--
[..Some declaration stuff..]

void MetaNamespace::TranslateClass(Environment *e) {

  cerr << "Analysed Class is:" << this->Name() << endl ;
  cerr << "e->Dump(0): " ; e->Dump(0) ;
  cerr << "e->Dump(1): " ; e->Dump(1) ; 
  cerr << "e->Dump(2): " ; e->Dump(2) ; 
  cerr << "e->IsNamespace(): \"" 
       <<  e->IsNamespace()->ToString() 
       << "\"" << endl ; 
}
--

However, when I use it on the following source:
--
metaclass MetaNamespace ;
class A { };
namespace MyNamespace {
  class B { };
};
--

I obtain the following result:

--
$ occ -E testNamespace.cc
Analysed Class is:A
e->Dump(0): {A(65), }
e->Dump(1): Environment::Dump(): the bottom is reached.
e->Dump(2): Environment::Dump(): the bottom is reached.
e->IsNamespace(): "(null)"
Analysed Class is:B
e->Dump(0): {B(66), }
e->Dump(1): {A(65), }
e->Dump(2): Environment::Dump(): the bottom is reached.
e->IsNamespace(): "(null)"
--

As expected, B is correctly analysed as not being in the same scope as
A: The environment in which B is present is enclosed in the one A is in.
But e->IsNamespace() always returns 'null', although I would expect it
to return "MyNamespace" at some point (intuitively when analysing B).

I'm wondering if the problem comes from my not using
Environment::isNamespace() properly, or if there could be some bug at
work.

I'll be grateful for any hint.

Thanks a lot

Francois

-- 
Francois Taiani                 +33 (0) 5 6133 6406
LAAS-CNRS (http://www.laas.fr)  Dependable Computing 
http://www.laas.fr/~ftaiani     and Fault Tolerance