[omniORB] recursive typecodes

[Renzo Tomaselli]

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

Renzo Tomaselli wrote:

> Hi all,
>    I have some problems while building a recursive typecode 
> dynamically, while everythings works file from standard idl (e.g. 
> static) usage.
> Let's consider the canonical binary tree example (pasting from my idl):
>
> typedef sequence<JobNode, 2> JobNodeList;
> struct JobNode {
>    JobNodeList next;
> };
>
> In a dynamic building procedure, we would have:
>
> 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
>
>
>
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>