[omniORB] Returning complex types from server

Wernke zur Borg Wernke.zur.Borg at vega.de
Tue Apr 26 18:11:28 BST 2005


> >
> >  I have a general doubt about CORBA. I want return a
> > struct composed from another struct from my corba
> > server. But it looks that my returned struct is empty
> > when the client trys print its fields.
> > How can I do the right memory allocation in the server
> > to return correctly the struct ?
> > 
> > Example: ( it doesnt work )
> > 
> >   struct MyTime {
> > short   day;
> > short   month;
> > short   year;
> > short   second;
> > short   minute;
> > short   hour;
> > };
> > 
> >   struct MyEvent {
> >    short eventType;   
> >    MyTime eventTime;
> > }
> > interface  I1 
> > {
> >   MyEvent   getEvent()
> > }
> > ---------------------------------------------
> > // generated serevr implementation code
> > 
> >  MyEvent getEvent()
> > {
> >   MyEvent  event;
> >  // some code
> >   
> >  return  event;
> > }
> 
> I can't see anything wrong. You have a fixed length struct (one of its
> members happens to be another fixed length struct). Fixed 
> length struct is
> returned from a method by value, so the signature of your 
> getEvent method is
> correct, and it shouldn't matter that 'event' is a local variable in
> getEvent(), since a copy of it is being returned.
> 
> Unless I'm missing something (or indeed there's a bug - 
> possibly I never
> used a fixed length struct myself), then I can only suggest 
> you trying more
> experiments. Try something just returning an integer. Then 
> try a struct that
> _doesn't_ have another struct as a member. etc...
> 


In addition to that you should enable ORB tracing to see if your data goes
across the line. If it does, your client code is not accessing the returned
struct correctly. If it does not, then your server is not filling the struct
correctly. As Clarke pointed out, it is possible to allocate fixed-length
structs on the stack, so there should not be a particular problem. 

Perhaps you want to post some details of your "// some code" ;-)

Wernke 




More information about the omniORB-list mailing list