Boost logo

Boost :

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-04-01 18:37:46

Stefan Seefeld skrev:
> vicente.botet wrote:
>> I think that a C++ CORBA implementation is a big deal. In addition a corba
>> implemenation is not very useful without a minimal set of CORBA services.
> I can imagine an experimental new C++ binding to be a worthy summer
> project. I have been using omniORB (
> heavily in the past, and I believe it to be easy enough to apply
> changes, in particular to its IDL compiler backend (which is written in
> Python), to generate code for such an alternative language binding.
> In addition, some of the obvious changes are small and could be applied
> incrementally.
> So, technically I don't see any reason not to try it, if someone's up to
> that task.

I agree that this aproach may be feasable to experiment with a new CORBA
C++ language binding front end. Other CORBA implementations may also be
used as back end in such an approach. TAO comes to my mind. I would
probe interrest to support such a project from the developers of the
candidate ORBs to see if they are willing to help.

Note also that there has been work done on proposals for new CORBA
language bindings for C++. I do not know the status or if anything has
been made public or standardized in any way. The latest CORBA C++
language mapping at is dated January 2008 but still contain the
old binding stuff. No use of std::string or std::vector<T>, etc. that
would make life so much simpler. I could not find a link, but I know I
have seen postings on this in the past. Probably on the CORBA
newsgroup. That is a good place to ask anyway.

   I would not mind at all if the C++ code I write for CORBA client or
servers, i.e. the C++
   in C++ to IDL mapping, was identical whether I used CORBA/IIOP or
anything else of a number
   of other supported communication back-ends. I do not see the logic
in why client or
   server source code should be concerned with details in the
implementation of how data is
   transfered between them. Maybe differences need to be mapped to
concepts much like
   std::iterator concepts so applications are hard-wired to requirements
to the communication, not
   to the implementation as is more common today.


Boost list run by bdawes at, gregod at, cpdaniel at, john at