orbitcpp-list

[orbitcpp-list] Re: C++ mapping of OUT variable-length structures

[Diego S. R. <dse...@di...>]

Hi!

On Wed, Apr 24, 2002 at 09:31:55PM +0200, ERDI Gergo wrote:
| On Wed, 24 Apr 2002, Diego Sevilla Ruiz wrote:
|=20
| > | So this is useful when you pass in (on the caller side) a non-empty
| > | structure, right?
| >=20
| > Hmmm... I can't understand what you mean by a non-empty structure...
| > This has nothing to do with either if the structure is empty or
| > non-empty... (and I don't see the need for an empty structure either.=
..)
|=20
| OK so let's talk about actual code here.
|=20
| Suppose I have the following on the client side:
|=20
| 	Test::Test_st *strct;
| 	master_ptr->foo (strct);
| 	// Do stuff on strct
| 	delete strct;

OK.

|=20
| The signature of foo is, according to this _out convention:
|=20
| 	void foo (Test::Test_st_out struct_out);
|=20
| So in the above example, when master_ptr->foo returns, struct_out point=
s
| to a valid structure, right?
|=20
| So, what happens when instead, the following is done:
|=20
| 	Test::Test_st *strct =3D new Test::Test_st;
| 	// Fill strct
| 	// Use it as an IN parameter
| 	other_ptr->other_method (*strct);
| 	=09
| 	master_ptr->foo (strct);
|=20
| 	delete strct;
|=20

So you are leaking memory here. That of the previous "new" allocated
struct.=20

The correct code is to either=20

1. use Test::Test_st_var struct or
2. add a delete struct *after* other_method and *before* foo call.

| Will master_ptr->foo in this case delete the old strct first?

No, it wont. It will free it *only* if you are using a _var variable.

| Or is this
| simply something that shouldn't be done? If it shouldn't be done, then =
I,
| again, don't understand what the _out class is supposed to do: you coul=
d
| use vanilla Test::Test_st*&'s as the OUT argument type and do the same.
|=20

OK. Let's go deeper in detail ;-) It actually works OK if you only use
pointers, but let's assume that you're using _var classes, that is:

Test::Test_st_var st =3D new Test::Test_st();

OK. Then, if you've declared the method foo as:

foo( Test::Test_st*& t_out)

and you call foo ( st ) , then this is what happens:

_var class has a normal Test_st*& operator that returns the internal
pointer (actually, a reference to it, which is assigned to t_out).=20

Then, the server implementation code does something like:

t_out =3D new Test::Test_st();
...

That is, it is accessing (through a reference) to the *internal* pointer
of a _var variable (st), and it is modifying without telling the actual
_var variable. So the *previous* value of the internal _var variable
pointer now leaks.

It is now clear enough?

With _out type, you force a conversion from _var to _out, in which the
previous internal pointer of the _var variable is (correctly)
deallocated before the call enters in the actul implementation.

	Hope this helps.
	diego.

|=20
| --=20
|    .--=3D ULLA! =3D---------------------.   `We are not here to give us=
ers what
|    \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC =
2001
|     `---=3D ca...@ca... =3D---'
| find / -user `grep ^you: /etc/passwd|cut -d: -f3` -a -name base -exec c=
hown us.us {} \;
|=20

--=20
Diego Sevilla Ruiz  http://ditec.um.es/~dsevilla  dse...@um...  \    /\
Dpto. Ingenier=EDa y Tecnolog=EDa de Computadores http://ditec.um.es   ) =
 ( ')
Visiting Extreme! Computing Lab       http://extreme.indiana.edu  (  /  )
Indiana University, Bloomington               http://www.iub.edu   \(__)|

[orbitcpp-list] Re: C++ mapping of OUT variable-length structures

[Diego S. R. <dse...@di...>]

Hi!

Por 24/Apr/2002, 20:44:27, dec=EDa ERDI Gergo:

| On Wed, 24 Apr 2002, Diego Sevilla Ruiz wrote:
|=20
| > I hope I can explain it well... Please, take a look at H&V book, page=
s
| > 300-302. The question is that as the _out types are allocated by the
| > callee, (and are passed by reference), there must be a way to dealloc=
ate
| > the previous owned reference if you use a _var type.
|=20
| So this is useful when you pass in (on the caller side) a non-empty
| structure, right?

Hmmm... I can't understand what you mean by a non-empty structure...
This has nothing to do with either if the structure is empty or
non-empty... (and I don't see the need for an empty structure either...)

|=20
| > In the C++ mapping (contrary to the C mapping) out types are always
| > allocated by the callee and freed by the caller.
|=20
| Does this also hold for arrays of variable-length items?
|=20

yes. It is the same (array_slice*&, which is allocated within the object
implementation). C++ mapping is pretty homogeneous.

	Best regards.
	diego.

--=20
Diego Sevilla Ruiz  http://ditec.um.es/~dsevilla  dse...@um...  \    /\
Dpto. Ingenier=EDa y Tecnolog=EDa de Computadores http://ditec.um.es   ) =
 ( ')
Visiting Extreme! Computing Lab       http://extreme.indiana.edu  (  /  )
Indiana University, Bloomington               http://www.iub.edu   \(__)|

[orbitcpp-list] Re: C++ mapping of OUT variable-length structures

[Diego S. R. <dse...@di...>]

Hi!

On Wed, Apr 24, 2002 at 04:04:55PM +0200, ERDI Gergo wrote:
| According to a CORBA/C++ spec I've found on the web, the mapping of OUT
| arguments for variable-length structures is T*&. However, I see that th=
ere
| are auxillary _out classes in the main ORBit2/C++ branch.=20
| So my questions are:
| 	1, What's the point of these _out classes?

I hope I can explain it well... Please, take a look at H&V book, pages
300-302. The question is that as the _out types are allocated by the
callee, (and are passed by reference), there must be a way to deallocate
the previous owned reference if you use a _var type. That is, the
pointer contained in the call (the value of the T*&) must be 0 (NULL),
so the _out type constructor ensures this for just pointers (for
instance char*) and for _var classes. This is:=20

1) it frees any memory allocated with the internal _var variable before=20
calling the method if the actual _var variable is passed as an _out=20
parameter, and

2) it sets any pointer to null (if not using a _var variable).

| 	2, Where should the allocation happen? Should the server allocate
| the structure? Should it be allocated by the client before doing the ca=
ll?
| Both? Neither?

The structure must be allocated by the implementation code for this
object written by the object implementation programmer.

|=20
| Right now in my ORBit/C++ branch I'm allocating/deallocating on the cli=
ent
| side via the new/delete operators, but it would be very easy to modify
| this scheme to do the Right Thing.

In the C++ mapping (contrary to the C mapping) out types are always
allocated by the callee and freed by the caller.

> So what does the CORBA/C++ spec say
| about this?
|=20

Hope I explained it well...

	Best regards.
	diego.

--=20
Diego Sevilla Ruiz  http://ditec.um.es/~dsevilla  dse...@um...  \    /\
Dpto. Ingenier=EDa y Tecnolog=EDa de Computadores http://ditec.um.es   ) =
 ( ')
Visiting Extreme! Computing Lab       http://extreme.indiana.edu  (  /  )
Indiana University, Bloomington               http://www.iub.edu   \(__)|

Re: [orbitcpp-list] orbit-1.0/orb/env.h:51: warning: non-static const member in class without a constructor

[Sam C. <sc...@bi...>]

Richard Andrews <bb...@ya...> wrote:
> In this case I assume the value gets set elsewhere in a C routine which
> has a different concept of * const.

It's even better than that. I believe they are all static objects,
defined in the various stubs generated by the IDL compiler. One object
per IDL type, no more, no less, all static.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] orbit-1.0/orb/env.h:51: warning: non-static const member in class without a constructor

[<bb...@ya...>]

My take...

tc is a member pointer inside the object being constructed. However it
is * const. This means you can't change where the pointer points to
after it is initialized.
But because the containing object has no constructor, there's no
initialization which says what tc should point to.

In C++ there would be no way to make use of the tc member because when
the object is constructed tc points somewhere random, but there's no
legal way to change its value (in C++).

In this case I assume the value gets set elsewhere in a C routine which
has a different concept of * const.


 --- Sam Couter <sc...@bi...> wrote: 
> 
> The warnings come about because C++ is only mostly compatible with C,
> not fully compatible, and the ORBit header files are just C. I'm not
> sure what the full implications are of having non-static const
> members
> in a class without a constructor, but we have them. :)


http://messenger.yahoo.com.au - Yahoo! Messenger
- A great way to communicate long-distance for FREE!

Re: [orbitcpp-list] orbit-1.0/orb/env.h:51: warning: non-static const member in class without a constructor

[Sam C. <sc...@bi...>]

Dan Kegel <dk...@ix...> wrote:
> /usr/local/include/orbit-1.0/orb/env.h:56: warning: non-static const memb=
er
> `CORBA_TypeCode_struct
> *const {anonymous struct}::tc' in class without a constructor
>=20
> What's the story on those -- are they spurious warnings?

Yes and no. As far as I'm aware, the warnings are correct. However, it
doesn't seem to cause any problems. The code still compiles and seems to
work.

The warnings come about because C++ is only mostly compatible with C,
not fully compatible, and the ORBit header files are just C. I'm not
sure what the full implications are of having non-static const members
in a class without a constructor, but we have them. :)
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] problems compiling orbitcpp-examples-0.2 with orbitcpp-0.30.4 under redhat 7

[Sam C. <sc...@bi...>]

Marcus Rosell <mar...@de...> wrote:
> I changed the declaration of helloWorld in "helloworld-impl.hh", but:

You need to change it in helloworld-impl.cc as well. The declarations
must match.

> why can't the interface declaration of helloWorld in
> POA_hellomodule::Hello be overridden in derived class?

Because that's just how C++ is. The method has the same number and types
of arguments, which means you're talking about the exact same method.
That means return types and thrown exceptions must match exactly.

> v2.96, the one Redhat is shipping with.
> I know people says it's crappy, but somehow they have compiled the rest
> of the system with it :-)

I was just curious. It's a real bug, and other compilers should also
whinge about it but don't.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] CORBA::ORB::destroy() static?!

[Dan K. <dk...@ix...>]

While porting an app to Orbitcpp, I got the error

no matching function for call to`CORBA::ORB::destroy ()'

According to "Advanced Corba Programming with C++",
page 521, there's a normal method PortableServer::POA::destroy;
yet Orbitcpp seems to make it a static method:

/usr/local/include/orb/orbitcpp_poa.hh:  static void destroy( ...

I'm just a newbie to corba and orbitcpp, but it kinda
looks like orbit isn't following the standard here.
Am I right?

Thanks,
Dan

[orbitcpp-list] 2nd try [PATCHLET] Fix annoying warning when compiling generated files

[Dan K. <dk...@ix...>]

Sorry about the formatting of that last message.  2nd try:

Compiling files generated by orbit-idl --lang=c++ generates
tons and tons of warnings because of a missing 'const' in
_orbitcpp::error's prototype.  Here's a little patch to
add the missing const (which is still missing in cvs, I believe).

Now, I know y'all are focusing on orbit2, but still, it's
probably a good idea to maintain orbit0's stuff at least until
orbit2 is production-ready.   I'll gladly buy a beer for the
maintainer who commits this patchlet, or something like it...

Thanks,
Dan

- Dan

diff --exclude-from=x -au orbitcpp-0.30.4.orig/orb/orbitcpp_tools.cc
orbitcpp-0.30.4/orb/orbitcpp_tools.cc
--- orbitcpp-0.30.4.orig/orb/orbitcpp_tools.cc  Thu Apr 18 08:34:14 2002
+++ orbitcpp-0.30.4/orb/orbitcpp_tools.cc       Thu Apr 18 08:34:57 2002
@@ -58,7 +58,7 @@



-void _orbitcpp::error(char *text) {
+void _orbitcpp::error(const char *text) {
        printf("%s\n",text);
        abort();
 }
diff --exclude-from=x -au orbitcpp-0.30.4.orig/orb/orbitcpp_tools.hh
orbitcpp-0.30.4/orb/orbitcpp_tools.hh
--- orbitcpp-0.30.4.orig/orb/orbitcpp_tools.hh  Thu Apr 18 08:34:14 2002
+++ orbitcpp-0.30.4/orb/orbitcpp_tools.hh       Thu Apr 18 08:35:02 2002
@@ -69,7 +69,7 @@
        inline void release_guarded(CORBA_TypeCode tc)
{release_guarded((CORBA_Object)tc);}


-       void error(char *text);
+       void error(const char *text);

        // JKL: this is used by any to make temporary and bounded string
typecodes
        CORBA_TypeCode TypeCode_allocate();

[orbitcpp-list] [PATCHLET] Fix annoying warning when compiling generated files

[Dan K. <dk...@ix...>]

diff --exclude-from=x -au orbitcpp-0.30.4.orig/orb/orbitcpp_tools.cc
orbitcpp-0.30.4/orb/orbitcpp_tools.cc
--- orbitcpp-0.30.4.orig/orb/orbitcpp_tools.cc  Thu Apr 18 08:34:14 2002
Compiling files generated by orbit-idl --lang=c++ generates
tons and tons of warnings because of a missing 'const' in
_orbitcpp::error's prototype.  Here's a little patch to
add the missing const (which is still missing in cvs, I believe).

Now, I know y'all are focusing on orbit2, but still, it's
probably a good idea to maintain orbit0's stuff at least until
orbit2 is production-ready.   I'll gladly buy a beer for the
maintainer who commits this patchlet, or something like it...

Thanks,
Dan

+++ orbitcpp-0.30.4/orb/orbitcpp_tools.cc       Thu Apr 18 08:34:57 2002
@@ -58,7 +58,7 @@



-void _orbitcpp::error(char *text) {
+void _orbitcpp::error(const char *text) {
        printf("%s\n",text);
        abort();
 }
diff --exclude-from=x -au orbitcpp-0.30.4.orig/orb/orbitcpp_tools.hh
orbitcpp-0.30.4/orb/orbitcpp_tools.hh
--- orbitcpp-0.30.4.orig/orb/orbitcpp_tools.hh  Thu Apr 18 08:34:14 2002
+++ orbitcpp-0.30.4/orb/orbitcpp_tools.hh       Thu Apr 18 08:35:02 2002
@@ -69,7 +69,7 @@
        inline void release_guarded(CORBA_TypeCode tc)
{release_guarded((CORBA_Object)tc);}


-       void error(char *text);
+       void error(const char *text);

        // JKL: this is used by any to make temporary and bounded string
typecodes
        CORBA_TypeCode TypeCode_allocate();

[orbitcpp-list] orbit-1.0/orb/env.h:51: warning: non-static const member in class without a constructor

[Dan K. <dk...@ix...>]

I just tried out orbitcpp for the first time.
I'm using up to date sources, I think
(orbitcpp-0.30.4, ORBit-0.5.15). /usr/local/bin/orbit-idl --libIDL-version
reports libIDL 0.6.8 (CORBA 2.2).
I'm running Red Hat 7.2.

I get a number of warnings if I compile IDL output with my customary 
-Wall -W -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
-Wwrite-strings.
  
One warning seems to happen with g++2.96, but not with g++3:

/usr/local/include/orbit-1.0/orb/env.h:51: warning: non-static const member
`CORBA_TypeCode_struct
*const {anonymous struct}::tc' in class without a constructor
/usr/local/include/orbit-1.0/orb/env.h:56: warning: non-static const member
`CORBA_TypeCode_struct
*const {anonymous struct}::tc' in class without a constructor

What's the story on those -- are they spurious warnings?
- Dan

Re: [orbitcpp-list] problems compiling orbitcpp-examples-0.2 with orbitcpp-0.30.4 under redhat 7

[Marcus R. <mar...@de...>]

tor 2002-04-18 klockan 14.13 skrev Sam Couter:
> Marcus Rosell <mar...@de...> wrote:
> > I have tried to compile the orbitcpp examples, but failed.
> > 
> > I don't have any idea whats wrong, if it's a bug or if i'm doing
> > something stupid.
> 
> That's a bug. In helloworld-impl.cc and helloworld-impl.hh, the
> declarations for the hellowWorld() method are incorrect. Just add the
> appropriate throws clause yourself:
> 
> char* helloWorld(const char* greeting)
> 	throws (CORBA::SystemException);

I changed the declaration of helloWorld in "helloworld-impl.hh", but:

----------

helloworld-impl.cc:7: declaration of `char 
*hellomodule::Hello_impl::helloWorld (const char *)' throws different 
exceptions
helloworld-impl.hh:14: than previous declaration `char 
*hellomodule::Hello_impl::helloWorld (const char *) throw 
(CORBA::SystemException)'

----------

Know we have two implementations of
"hellomodule::Hello_impl::helloWorld",
one in the .hh file and one in the .cc file.

why can't the interface declaration of helloWorld in
POA_hellomodule::Hello be overridden in derived class?


> What compiler are you using? This bug hasn't been reported before.

v2.96, the one Redhat is shipping with.
I know people says it's crappy, but somehow they have compiled the rest
of the system with it :-)


> -- 
> Sam "Eddie" Couter  |  mailto:sc...@bi...
> Debian Developer    |  mailto:ed...@de...
>                     |  jabber:sa...@ja...
> OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] problems compiling orbitcpp-examples-0.2 with orbitcpp-0.30.4 under redhat 7

[Sam C. <sc...@bi...>]

Marcus Rosell <mar...@de...> wrote:
> I have tried to compile the orbitcpp examples, but failed.
>=20
> I don't have any idea whats wrong, if it's a bug or if i'm doing
> something stupid.

That's a bug. In helloworld-impl.cc and helloworld-impl.hh, the
declarations for the hellowWorld() method are incorrect. Just add the
appropriate throws clause yourself:

char* helloWorld(const char* greeting)
	throws (CORBA::SystemException);

What compiler are you using? This bug hasn't been reported before.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] problems compiling orbitcpp-examples-0.2 with orbitcpp-0.30.4 under redhat 7

[Marcus R. <mar...@de...>]

I have tried to compile the orbitcpp examples, but failed.

I don't have any idea whats wrong, if it's a bug or if i'm doing
something stupid.


I get the following error:


c++ -g -O0 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-I/usr/include/orbit-1.0 -o client client.o
generated/libhelloworldStubs.a -L/usr/lib /usr/lib/liborbitcpp.so
-lstdc++ -lORBit -lIIOP -lORBitutil /usr/lib/libglib.so -lnsl -lm
c++ -DHAVE_DLFCN_H=1  -I. -I.  -Igenerated -I.. -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/include/orbit-1.0     -g -O0
-I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0
-c server.cc
In file included from server.cc:3:
helloworld-impl.hh:13: looser throw specifier for `virtual char 
*hellomodule::Hello_impl::helloWorld (const char *)'
generated/helloworld-cpp-skels.hh:46:   overriding `virtual char 
*POA_hellomodule::Hello::helloWorld (const char *) throw 
(CORBA::SystemException)'
make[2]: *** [server.o] Error 1
make[2]: Leaving directory `/tmp/orbitcpp-examples-0.2/helloworld'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/orbitcpp-examples-0.2/helloworld'
make: *** [all-recursive] Error 1

......
Code from the generated file....

namespace POA_hellomodule {
        class Hello : public ::hellomodule::Hello, public virtual
PortableServer::ServantBase { 

....
....
....


                // C++ interface
        public:
                Hello();
                virtual ~Hello() {              }
                ::PortableServer_Servant *_orbitcpp_get_c_servant() {
                        return reinterpret_cast<
::PortableServer_Servant *>(&m_target);
                }

                ::hellomodule::Hello_ptr _this() {
                        PortableServer::POA_var rootPOA =
_default_POA();
                        PortableServer::ObjectId_var oid =
rootPOA->activate_object(this);
                        CORBA::Object_ptr object =
rootPOA->id_to_reference(oid);
                        return reinterpret_cast<
::_orbitcpp::stub::hellomodule::Hello *>(object);
                }

                virtual char *helloWorld(char const *greeting)
                        throw (CORBA::SystemException) = 0;
        };
}


Happy for any help.

/* Marcus Rosell

   mar...@de... */

RE: [orbitcpp-list] Re: Status of orbitcpp

[Dan K. <dk...@ix...>]

Sam Couter wrote:
>Marco Canini <m.c...@li...> wrote:
>> What's current status of orbit-cpp?
>Currently not being actively developed (as far as I know), but I'm
>willing to commit patches.

Glad to hear that.  I'm about to start using orbit-cpp at work,
and will submit patches to allow cross-compiling glib1/oribit0/orbit-cpp
soonish.  (The glib patches are from Montavista, bless their souls.)

Although some people think cross-compiling is an arcane thing that
isn't worth supporting in the main codeline, it's worth noting that the
rise of Linux PDAs means a lot of people are starting to use
cross-compilers.  Plus, the patches are often relatively small
and restricted to the autoconf support, so they aren't particularly risky.

>Most development effort seems to be going into the C++ bindings for
>ORBit2, which aren't quite ready yet.

I'm looking forward to the day I can switch to orbit2 and its c++ 
bindings.  We already submitted a clean patch for glib2 to allow 
cross-compiling it; it'll be interesting to see if it makes it into
the main codeline.

- Dan

[orbitcpp-list] Re: Status of orbitcpp

[Sam C. <sc...@bi...>]

Marco Canini <m.c...@li...> wrote:
> What's current status of orbit-cpp?

Currently not being actively developed (as far as I know), but I'm
willing to commit patches.

Most development effort seems to be going into the C++ bindings for
ORBit2, which aren't quite ready yet.

> I sent a bug report on seg fault for idl compiler, is someone handling
> it?

I haven't had time to look at it yet; If you send me a patch which fixes
the problem then I can commit it.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] (no subject)

[Anton I. <id...@cr...>]

[orbitcpp-list] BUG: Segmentation Fault

[Marco C. <m.c...@li...>]

Hi, I'm getting a Segmentation Fault
when I want to compile an idl like this one:

module Bar {

   union Foo switch(boolean) {
      case TRUE:
         long first;
      case FALSE:
         string second;
   };

   typedef sequence<Foo> ManyFoo;

};

I've yet filled a BUG report at SF:

http://sourceforge.net/tracker/index.php?func=detail&aid=537513&group_id=646&atid=100646

I've tried to debug, but I lost myself in getTopLevelInterface at
language.cc:364

I hope you can resolve this bug, because a relly need a sequence of
unions with a variable-length member.

MC

[orbitcpp-list] [ orbitcpp-Bugs-537513 ] IDL compiler Segmentation Fault

[<no...@so...>]

Bugs item #537513, was opened at 2002-04-01 00:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100646&aid=537513&group_id=646

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Canini (m_canini)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDL compiler Segmentation Fault

Initial Comment:
while compiling the following idl orbit-idl will crash.
If you change "string second;" into "long second;" it
won't fail.
If you remove the typedef it won't fail.

module Bar {

   union Foo switch(boolean) {
      case TRUE:
         long first;
      case FALSE:
         string second;
   };

   typedef sequence<Foo> ManyFoo;

};

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=100646&aid=537513&group_id=646

Re: [orbitcpp-list] ORBit-C++ overhead measurement

[Sam C. <sc...@bi...>]

Dan Kegel <da...@ix...> wrote:
> done.  Hopefully we'll have an autoconf macro soon for detecting
> orbit-c++...

What's wrong with the AM_PATH_ORBITCPP macro defined in orbitcpp.m4?

(If the one in the 0.30.4 release doesn't work, grab the one from CVS)
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Re: cpp: World duly helloed

[Alex H. <al...@an...>]

On Mon, 2002-03-11 at 10:05, Michael Meeks wrote:

> 	It seems strange to me that that should be the case, but perhaps I'm
> missing something. It would seem to me that having _this produce a
> client reference is somewhat strange, but I havn't read the C++ spec.
> 
> 	Regards,
> 
> 		Michael.
> 

Hi Michael,

That's how it is :) The _this() method activates the object on the root
POA (if not already activated) and returns a reference to it.

This is covered in Henning & Vinoski, which is IHMO essential reading if
working with CORBA & C++. 

In fact its probably also a good read for people working on the C
bindings as it gives good descriptions of the POA features needed for
the evictor pattern, which is the sanest way to do distributed object
lifetime management I've come across.

Cheers,
Alex.

[orbitcpp-list] Re: cpp: World duly helloed

[ERDI G. <ca...@ca...>]

On 9 Mar 2002, Michael Meeks wrote:

> =09Really great news ! I'm interested in quite why you needed to link the
> skels - though it is standard practice - especially in libraries to
> include the lot, it should not be necessary - what symbols were you
> missing ?

the skels contain the glue code between the c++ wrapper and the c corba
object, so of course this implementation is needed in client apps.

--=20
   .--=3D ULLA! =3D---------------------.   `We are not here to give users =
what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---=3D ca...@ca... =3D---'
Ha paranoi=E1sokkal akarsz megismerkedni, kezdd el k=F6vetni =F4ket.

Re: [orbitcpp-list] [patch] Wrap returned objects

[<mu...@t-...>]

Please commit. ORBit2 cpp branch patches should go to the orbit list.

On Sat, 2002-03-09 at 21:31, ERDI Gergo wrote:
> Index: cpp/types.cc
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvs/gnome/ORBit2/src/idl-compiler/cpp/Attic/types.cc,v
> retrieving revision 1.1.2.6
> diff -u -u -r1.1.2.6 types.cc
> --- cpp/types.cc	7 Mar 2002 17:33:41 -0000	1.1.2.6
> +++ cpp/types.cc	9 Mar 2002 20:27:18 -0000
> @@ -1192,7 +1192,9 @@
>  											  IDLTypedef const *activeTypedef =3D NULL) const {
>  	// must return stub ptr and not ptr in order to work when smart pointer=
s are used
>  	ostr
> -		<< indent << "return reinterpret_cast< " << getQualifiedCPPStub() << "=
 *>(_retval);" << endl;
> +		<< indent << getQualifiedCPPStub() << "* _cpp_retval =3D new " << getQ=
ualifiedCPPStub () << "(_retval);" << endl
> +		<< indent << "CORBA_Object_release (_retval, 0);" << endl
> +		<< indent << "return _cpp_retval;" << endl;
>  }
> =20
> =20
>=20
> --=20
>    .--=3D ULLA! =3D----------------------.   `We are not here to give use=
rs what
>    \    http://cactus.rulez.org       \   they want'  -- RMS, at GUADEC 2=
001
>     `-----=3D ca...@ca... =3D--'
> Kicsi, s=E1rga =E9s kapar: k=EDnai n=F5gy=F3gy=E1sz.
>=20
>=20
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> https://lists.sourceforge.net/lists/listinfo/orbitcpp-list
--=20
Murray Cumming
mu...@us...
www.murrayc.com

[orbitcpp-list] [patch] Wrap returned objects

[ERDI G. <ca...@ca...>]

Index: cpp/types.cc
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/gnome/ORBit2/src/idl-compiler/cpp/Attic/types.cc,v
retrieving revision 1.1.2.6
diff -u -u -r1.1.2.6 types.cc
--- cpp/types.cc=097 Mar 2002 17:33:41 -0000=091.1.2.6
+++ cpp/types.cc=099 Mar 2002 20:27:18 -0000
@@ -1192,7 +1192,9 @@
 =09=09=09=09=09=09=09=09=09=09=09  IDLTypedef const *activeTypedef =3D NUL=
L) const {
 =09// must return stub ptr and not ptr in order to work when smart pointer=
s are used
 =09ostr
-=09=09<< indent << "return reinterpret_cast< " << getQualifiedCPPStub() <<=
 " *>(_retval);" << endl;
+=09=09<< indent << getQualifiedCPPStub() << "* _cpp_retval =3D new " << ge=
tQualifiedCPPStub () << "(_retval);" << endl
+=09=09<< indent << "CORBA_Object_release (_retval, 0);" << endl
+=09=09<< indent << "return _cpp_retval;" << endl;
 }
=20
=20

--=20
   .--=3D ULLA! =3D----------------------.   `We are not here to give users=
 what
   \    http://cactus.rulez.org       \   they want'  -- RMS, at GUADEC 200=
1
    `-----=3D ca...@ca... =3D--'
Kicsi, s=E1rga =E9s kapar: k=EDnai n=F5gy=F3gy=E1sz.

[orbitcpp-list] Re: Implementation inheritance

[ERDI G. <ca...@ca...>]

On Sat, 9 Mar 2002, ERDI Gergo wrote:

> After playing around with every combination of virtual inheritance, I
> decided to look for 'canonical' answers on the Web. However, the pages
> I've found all boiled down to my initial solution.

Don't you hate it when you send an email and half a minute later you
find the answer by yourself?

So the solution is:

class Hello_impl: public virtual POA_hellomodule::Hello
{
public:
	virtual char* helloWorld (const char* greeting) throw (CORBA::SystemException);
};

class Hello2_impl: public virtual POA_hellomodule::Hello2,
		   public virtual Hello_impl
{
public:
	void foo () throw (CORBA::SystemException);
};


I forgot that if Hello_impl inherits POA_hellomodule::Hello only virtually
but you instancize(sp?) a Hello_impl, it will (of course) get a fully
working POA_hellomodule::Hello ancestor.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= ca...@ca... =---'
You are in a twisty maze of little install diskettes.