orbitcpp-list

[orbitcpp-list] Compiler Any support and sequence bug

[John L. <jk...@lu...>]

I managed to get the IDL compiler to eek out code for Any. Marshalling and
Demarshalling work
and I spent some to get operator functions made for user defined types. The
compiler patch can be
found at ftp://www.luebsphoto.com/pub/
There is also the beginnings of the CORBA::Any I mentioned earlier.
In hammering out the Any insertion extraction operator generation, I found
a bit a bug. The sequence
creation in the compiler uses that IDLWriteSeqSpec job. Well consider:
typedef sequence<long, 5> test_seq;
typedef sequence<long, 5> test_seq2;
The IDLWriteSeqSpec job should only run once, yet right now it runs for
both writeTypedefs for the
sequences. There are two possible solutions, the pretty/fast one, and the
kludgy one. The code
generated by IDLWriteSeqSpec job can be guarded by #ifndef, #define, #endif
so even though
the code appears more than once, there are no compilation problems. The
"better" solution is to
 have a map of CPPTypeNames of the sequences and the map is checked before
the a sequence
Write spec job is submitted.
I made a few changes to make this effect and ended up with
ftp://www.luebsphoto.com/pub/compiler2.idl.

John Luebs

Re: [orbitcpp-list] Compiler Any support and sequence bug

[Phil D. <ph...@us...>]

Hi John,

Many thanks for submitting this; I'm afraid I won't be able to look at
it until tomorrow evening (spare time is a bit scarce at present :-(

Sam - have you had a chance to look at this? Is there any crossover
with what you've done?

Thanks again John,

Phil

John Luebs writes:
 > I managed to get the IDL compiler to eek out code for Any. Marshalling and
 > Demarshalling work
 > and I spent some to get operator functions made for user defined types. The
 > compiler patch can be
 > found at ftp://www.luebsphoto.com/pub/
 > There is also the beginnings of the CORBA::Any I mentioned earlier.
 > In hammering out the Any insertion extraction operator generation, I found
 > a bit a bug. The sequence
 > creation in the compiler uses that IDLWriteSeqSpec job. Well consider:
 > typedef sequence<long, 5> test_seq;
 > typedef sequence<long, 5> test_seq2;
 > The IDLWriteSeqSpec job should only run once, yet right now it runs for
 > both writeTypedefs for the
 > sequences. There are two possible solutions, the pretty/fast one, and the
 > kludgy one. The code
 > generated by IDLWriteSeqSpec job can be guarded by #ifndef, #define, #endif
 > so even though
 > the code appears more than once, there are no compilation problems. The
 > "better" solution is to
 >  have a map of CPPTypeNames of the sequences and the map is checked before
 > the a sequence
 > Write spec job is submitted.
 > I made a few changes to make this effect and ended up with
 > ftp://www.luebsphoto.com/pub/compiler2.idl.
 > 
 > John Luebs
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 

Re: [orbitcpp-list] Compiler Any support and sequence bug

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
>=20
> Sam - have you had a chance to look at this? Is there any crossover
> with what you've done?

I haven't had a chance to look yet. I'll check it out today, with any luck.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Compiler Any support and sequence bug

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
> 
> Sam - have you had a chance to look at this? Is there any crossover
> with what you've done?

More than that - All I can add to this is a C++ wrapper of the ORBit
TypeCode to create a C++ TypeCode implementation. John's implementation of
Any is way beyond what I've got done so far.

I'm attaching my TypeCode implementation as a patch to orbitcpp_orb.{cc,hh}
and two new files: orbitcpp_typecode.{cc,hh}.
John, you might like to use this C++ wrapper implementation of TypeCode in
your Any implementation. I don't know if it's necessary or even useful.

The compiler still won't generate the appropriate C++ TypeCode constants
for each generated type though.
-- 
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Compiler Any support and sequence bug

[Phil D. <ph...@us...>]

Hi Sam, John,

Looks like we're going to have to do a merge-fest fairly soon. I've
almost finished union support (which was a bugger btw) and hope to do
a cvs commit tonight with this stuff. There are quite a few changes to
the compiler so I'd like to commit this before merging commences.

Then we have 2 options:

1) I merge the typecode/any patches manually and commit to cvs
2) We do the cvs 'thing' and each commit our stuff, merging as we go.

As a future plan, it makes sense to commit early and often - as long
as the thing compiles I'm not that fussed. (I'm guilty of not
committing early - mainly because I've had the archive to myself for
the last 3 months or so :-(

Cheers,

Phil


Sam Couter writes:
 > Phil Dawes <ph...@us...> wrote:
 > > 
 > > Sam - have you had a chance to look at this? Is there any crossover
 > > with what you've done?
 > 
 > More than that - All I can add to this is a C++ wrapper of the ORBit
 > TypeCode to create a C++ TypeCode implementation. John's implementation of
 > Any is way beyond what I've got done so far.
 > 
 > I'm attaching my TypeCode implementation as a patch to orbitcpp_orb.{cc,hh}
 > and two new files: orbitcpp_typecode.{cc,hh}.
 > John, you might like to use this C++ wrapper implementation of TypeCode in
 > your Any implementation. I don't know if it's necessary or even useful.
 > 
 > The compiler still won't generate the appropriate C++ TypeCode constants
 > for each generated type though.
 > -- 
 > Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
 > sa...@to...    |   tSA Consulting      |
 > PGP key available on key servers
 > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C