I’ve used the ACE CDR stream classes before, but only to talk to each other (i.e. I always had an ACE CDR class on the other end). I’m writing an app that needs to interface with a legacy app via sockets. The interface is a fairly straight-forward “network byte order” type of data marshalling and only deals with primitive types. I dread writing a bunch of data marshalling code when CDR ops are right there. But aren’t the ACE CDR classes very specific to the CDR standard? Or can they be used to talk non-CDR protocol? Does CDR do any byte stuffing or alignment that would cause problems?
Thanks,
Keith.
Hi Keith,
Yes, the ACE CDR classes conform to the CORBA alignment specs. One of our former grad students added capability to disable it however. I’m not sure if it’s part of the distribution or not. Anybody know this off the top of their head?
Jeff
> I’ve used the ACE CDR stream classes before, but only to talk to
> each other (i.e. I always had an ACE CDR class on the other end).
> I’m writing an app that needs to interface with a legacy app via
> sockets. The interface is a fairly straight-forward “network byte
> order” type of data marshalling and only deals with primitive
> types. I dread writing a bunch of data marshalling code when CDR
> ops are right there. But aren’t the ACE CDR classes very specific
> to the CDR standard? Or can they be used to talk non-CDR protocol?
> Does CDR do any byte stuffing or alignment that would cause problems?
I'm not sure about the CDR types off the top of my head, but "network
byte order" is just big-endian, so you could try it.
Failing that, there's always XDR, which is part of the SunRPC suite.
Old-school, but it works, and will generate the host-to-network-and-
back code for you much like the IDL compiler does.
---
Chris Cleeland, Principal Software Engineer
http://www.theaceorb.com AND http://www.ociweb.com