[omniORB] IDL Linked list

[William Bauder]

The linked list won't work - IDL does not allow forward declaration of
structures.  As other have mentioned, you can implement it as an array
or as an object that iterates through the list on the server side.  If
you're really concerned about performance, you can implement it as a mix
of the two - the method returns an array of the first n items in the
list, and a reference to an iterator to retrieve the next batch of
objects.  (CosNaming::NamingContext::list() is an example of this).
 
Pointers - most CORBA implementations do not allow you to use NULLs, so
if you need to check if somethiing is present, your need to do a
discriminator union, i.e.
 
  union bar_t switch(boolean)
  {
    case TRUE: string str;
  };
  
  struct data_t
  {
    long val;
    bar_t bar;
  };

Populating it would look something like this:
 
char* stringValue;
data_t data;
...
if(stringValue==NULL){
  data.bar._default();    //sets the discriminator to FALSE
}
else{
  data.bar.str(stringValue);    //sets the discriminator to TRUE, and
populates the 
}
 
To check the value:
 
const char* stringValue;
data_t data;
...
if(data.bar._d()==1){
  stringValue=data.bar.str();
}
else{
  stringValue=NULL;
}
 
One thing to watch for - there are a couple of CORBA implementations out
there that don't handle this properly, so if you're planning on using
this with multiple implementations, test them before moving forward with
everything.
 
 
 -----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of David
Sent: Friday, April 11, 2008 7:29 AM
To: Martin Trappel
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] IDL Linked list



Hi,

Great, thanks. Maybe I'm not going about solving my problem in the right
way though. I have a C++ scenario which looks something like this:

class A {
  int foo( data_t );
};

typedef struct data_s {
  int val;
  bar_t *bar;
  struct data_s *next;
} data_t;

typedef struct bar_s {
  char *str;
} bar_t;

I need to make A accessible via CORBA. That is, another machine, where
the data_t and bar_t structs reside, should be able to call a.foo(). The
data_t and bar_t arguments need to be sent over the network. I'm not
sure how the bar pointer in data_t will be handled though -- do I need
to get rid of it? I want to minimize the amount of object passing
needed.

Note that this is a modification of an existing codebase. I want to
integrate CORBA into this as little as possible, but if CORBA is going
to send the arguments, it needs to know what they look like, right?
Would an alternative be to "serialize" the data_t struct (not
necessarily into a stream/string, but just something that CORBA handles
well), send it over the network to an AProxy object, which would
"deserialize" the data_t struct and call a.foo()?

Am I rambling like a madman? I hope not. Let me know if any of this
makes any sense to you.

/David



On Fri, Apr 11, 2008 at 12:29 PM, Martin Trappel <0xCDCDCDCD at gmx.at>
wrote:


mov . wrote:


Hi,

I've googled a fair amount, and found nothing on the mailing list about
this. How would I model a linked list in IDL? Could someone maybe point
me to some good IDL documentation for omniORB, if there is any. I've
looked at the C++ Language Mapping, Version 1.2 from OMG, but I haven't
found anything there either. What I want is something that's equivalent
to, and preferably also maps to,

typedef struct list_item_s {
 int value;
 struct list_item_s *next;
} list_item_t;

Any ideas? Am I missing something obvious? Any help is appreciated.

/David




IDL only defines an Interface, so it may not make sense to define a
linked list in IDL. Of course, if you really like to model a linked list
on the interface level, you could write something like:

module Example {
 interface ListItem;

 interface ListItem {
   int GetValue();
   ListItem Next();
 };
};

br,
Martin



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080411/99aef19b/attachment-0001.htm