=?gb2312?B?tPC4tDogW29tbmlPUkJdIG9iamVjdCByZWZlcmVuY2Ugd2lkZW5pbg==?= =?gb2312?B?ZyB0byBhIG1lbWJlciA=?=

[=?gb2312?B?zfXj/MHr?=]

HI~~:
	hello every one. it's  very diffault  to MASTER omniOrb from =
sourcecode,because  omniOrb is so HUGE, though omniOrb is a free =
project, where can I get  UML class diagram or detailed  design Doc  , =
not the pdf files  with the release version omniOrb.

      from CHINA PAIC=09

-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com]=B4=FA=B1=ED Duncan =
Grisby
=B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA3=D4=C226=C8=D5 22:44
=CA=D5=BC=FE=C8=CB: Zsolt Rizsanyi
=B3=AD=CB=CD: omniORB
=D6=F7=CC=E2: Re: [omniORB] object reference widening to a member=20


On Friday 26 March, Zsolt Rizsanyi wrote:

> I had a nasty bug because I was implicitly widening an _var object=20
> reference to an Object_member of the of a CORBA struct.
>=20
> After reading up in the C++ language mapping specification, I have =
found=20
> that a compile time error should be generated on an attempt to =
implicitly=20
> widen an _var reference to Object_var.

[...]
> In my understanding the ors.obj =3D echoVar assignment should generate =
a=20
> compile time error.
> Am I mistaken? Or is this issue already known?

It should cause a compile time error but it doesn't. Unfortunately, it
can't be done in 4.0.x because it requires an incompatible change to
the _var classes. It's already fixed in the 4.1 development branch.

Cheers,

Duncan.

--=20
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list