[orbitcpp-list] Re: TypeCode for ORBit-C++

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

Hi Sam,

Sam Couter writes:
 > After a late night hacking, I've done some work towards getting TypeCode
 > added into ORBit-C++. I'd like it if you could have a look at what I've done
 > so far, and tell me if I'm doing it the right way, the wrong way, or the
 > most difficult way. I started with your instructions (they were very clear,
 > thanks), chased down OMG documents (bit of a pain), tried to decipher OMG
 > documents (a lot of a pain for someone with my level of understanding), and
 > tried to use existing ORBit-C++ code as an example to work from.
 > 
 > 
 > I have attached:
 > Output from the "cvs diff" command.
 > orbitcpp_typecode.hh
 > orbitcpp_typecode.cc
 > 
 > Please note that while I have a fair bit of experience with C and Java, I'm
 > a relative newcomer to C++. It probably shows. :)
 > 

Not really - this is cool! (It compiled out of the box which made me
smile :-)

BTW, Do you have a sourceforge account? Ideally I'd like you to be on
the orbitcpp dev list so that you have CVS write access and can check
this stuff in. (Makes my life easier if you can commit your own stuff)

 > 
 > I have some questions:
 > 
 > What's the best way to implement the StructMemberSeq, UnionMemberSeq and
 > EnumMemberSeq sequences? I have pasted some code that was generated using
 > orbit-idl on a partial IDL file, but I'm not so sure that's the right way to
 > go. That code is commented out, and so is the chunk of create_*_tc methods I
 > added in orbitcpp_orb.hh.
 > 

Using the generated code is probably the simplist way to proceed for
now. Andreas used a macro to generate his sequences (check out
ORBITCPP_DECLARE_SIMPLE_SEQUENCE in orbitcpp_poa.h - you may want to
do something similar.)

I don't think the stuff in orbitcpp_orb.hh is quite right:
e.g.
		TypeCode create_struct_tc(const char * id, const char * name,
			StructMemberSeq members);

needs to be:

        TypeCode_ptr create_struct_tc(const char * id, const char * name,
            const StructMemberSeq & members); 

since the PIDL is 

	     TypeCode create_struct_tc (
                     in RepositoryId id,
                     in Identifier name,
                     in StructMemberSeq members
         );


(Check out the table on page 104 of the CORBA C++ language mapping for
details of arguments and parameter passing rules).


Quick Tip: One way to verify C++ interfaces is to check another 2.3
compliant C++ ORB. I usually use MICO for this - http://www.mico.org/


 > I've used casts all over the place. Is that the correct way to go about
 > things?
 > 

I'm afraid so. This is the price we pay for binary compatibility
between the C and C++ mapping. (The benefits are in reduced code
memory footprint and performance.)

 > Some of the methods in the TypeCode interface aren't implemented by ORBit. I
 > don't know why that is, but I haven't yet implemented anything that's not in
 > ORBit already.
 > 
 > I assume putting my name in the "Copyright" and "Author" sections of the
 > files I've created is the way things are normally done. If not, feel free to
 > modify them appropriately.
 > 

Yep - that's fine. We've been sortof using an informal rule that
whoever creates the file takes the Copyright, and anybody adding to a
pre-existing file adds their name to the authors list.  In the future
this may have to change (e.g. if it becomes legally necessary to sign
copyright over to a third party or something) but I don't want to
think about that right now.

 > 
 > Last thing (sorry about the size of this message): I intend to get ORBit-C++
 > packaged for the Debian distribution of Linux, and have applied to be a
 > Debian maintainer for that reason. Are there any objections to this from the
 > ORBit-C++ project maintainers?
 > 

None from me.  - Andreas?

Once again, many thanks for doing this,

Cheers,

Phil