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

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

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

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

Hi,

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

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

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

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

Yes, that would be great!

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

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

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

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

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

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

Yes, it indeed looks like this was the reason.

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

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

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

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

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