Michael
2008-03-30 20:21:35 UTC
Hello,
I stumbled over an issue regarding recursive structures in IDLs. Basically it is the same
issue posted by Renzo Tomaselli backin 2005 (see below), but I couldn't find any
indication that this has ever been fixed.
In contrast to Renzo I'm not building a DynAny but I'm just sending the recursive struct
inside of an any (the process dies on signal 6 somewhere inside of omniorb).
pseudoIDL:
struct Message
{
long id;
any payload;
};
struct Entry;
typedef sequence<Entry> EntrySeq;
struct Entry
{
string name;
EntrySeq entries;
};
pseudocode:
Entry e;
e.name="test";
e.entries.length(1);
e.entries[0].name="test2";
Message m;
m.id = 1;
m.payload <<= e;
factory->doremotecall(m);
==>
pure virtual method called
terminate called without an active exception
Abort trap: 6 (core dumped)
The anonymous construct works ok:
struct Entry
{
string name;
sequence<Entry> entries;
};
but omniidl gives a warning:
"Warning: Anonymous sequences for recursive structures are deprecated. Use a forward
declaration instead".
regards
michael
-- Post of Renzo Thu Apr 7 21:00:20 BST 2005
Hi,
it's me again. Indeed, the alternative construction:
struct JobNode {
sequence<JobNode, 2>next;
};
typedef sequence<JobNode, 2> JobNodeList;
works fine, since the failing alias is moved outside. Btw, this is the
common form of all OMG recursion examples.
However, omniidl complains saying "Warning: Anonymous sequences for
recursive structures are deprecated. Use a forward declaration instead".
Just a warning, but exactly what is not actually working in dynamic
procedures.
Renzo
I stumbled over an issue regarding recursive structures in IDLs. Basically it is the same
issue posted by Renzo Tomaselli backin 2005 (see below), but I couldn't find any
indication that this has ever been fixed.
In contrast to Renzo I'm not building a DynAny but I'm just sending the recursive struct
inside of an any (the process dies on signal 6 somewhere inside of omniorb).
pseudoIDL:
struct Message
{
long id;
any payload;
};
struct Entry;
typedef sequence<Entry> EntrySeq;
struct Entry
{
string name;
EntrySeq entries;
};
pseudocode:
Entry e;
e.name="test";
e.entries.length(1);
e.entries[0].name="test2";
Message m;
m.id = 1;
m.payload <<= e;
factory->doremotecall(m);
==>
pure virtual method called
terminate called without an active exception
Abort trap: 6 (core dumped)
The anonymous construct works ok:
struct Entry
{
string name;
sequence<Entry> entries;
};
but omniidl gives a warning:
"Warning: Anonymous sequences for recursive structures are deprecated. Use a forward
declaration instead".
regards
michael
-- Post of Renzo Thu Apr 7 21:00:20 BST 2005
Hi,
it's me again. Indeed, the alternative construction:
struct JobNode {
sequence<JobNode, 2>next;
};
typedef sequence<JobNode, 2> JobNodeList;
works fine, since the failing alias is moved outside. Btw, this is the
common form of all OMG recursion examples.
However, omniidl complains saying "Warning: Anonymous sequences for
recursive structures are deprecated. Use a forward declaration instead".
Just a warning, but exactly what is not actually working in dynamic
procedures.
Renzo
Hi all,
I have some problems while building a recursive typecode
dynamically, while everythings works file from standard idl (e.g.
static) usage.
typedef sequence<JobNode, 2> JobNodeList;
struct JobNode {
JobNodeList next;
};
CORBA::TypeCode_var tcNode =
orb->create_recursive_tc("IDL:/JobNode:1.0");
CORBA::TypeCode_var tcSeq = orb->create_sequence_tc(2, tcNode);
CORBA::TypeCode_var tcAlias =
orb->create_alias_tc("IDL:/JobNodeList:1.0", "JobNodeList", tcSeq);
...
the last statement throws an exception from method NP_resolved(),
since it tries to match JobNodeList vs. Node, failing of course.
Indeed JobNode would be resolved one step out. I guess a nested
definition would work as a workaround (I'll try it later), however I
feel this behavior fighting against the correct behavior while derived
from static idl.
Any suggestion ? Thanks,
Renzo Tomaselli
I have some problems while building a recursive typecode
dynamically, while everythings works file from standard idl (e.g.
static) usage.
typedef sequence<JobNode, 2> JobNodeList;
struct JobNode {
JobNodeList next;
};
CORBA::TypeCode_var tcNode =
orb->create_recursive_tc("IDL:/JobNode:1.0");
CORBA::TypeCode_var tcSeq = orb->create_sequence_tc(2, tcNode);
CORBA::TypeCode_var tcAlias =
orb->create_alias_tc("IDL:/JobNodeList:1.0", "JobNodeList", tcSeq);
...
the last statement throws an exception from method NP_resolved(),
since it tries to match JobNodeList vs. Node, failing of course.
Indeed JobNode would be resolved one step out. I guess a nested
definition would work as a workaround (I'll try it later), however I
feel this behavior fighting against the correct behavior while derived
from static idl.
Any suggestion ? Thanks,
Renzo Tomaselli