Hello Boosters, Where I work we are implementing an open source, modern, CORBA implementation and IDL mapping. We want it to support C++ and C++11 IDL mapping, but we also want to create another IDL mapping. This new IDL mapping is being experimentated in the following url https://github.com/expertisesolutions/mORBid/tree/concepts It still has some very problematic issues (like compilation-time of generated code) and of course it is still far from completion. But, we would like to hear suggestions about this approach. What we did was that an IDL interface is mapped to a typedef for boost::type_erasure (I found the idea quite cool for the reasons that I'll mention below) with the requirements defined in the IDL, e.g. its operations. The IDL also emits a model for this type_erasure which is the actual stub class and is called remote_reference. It also emits a proxy_reference model for the same type_erasure typedef which receives a std::reference_wrapper and proxies the calls, this is needed because type_erasure can't switch between by-reference and by-value in runtime. Why I believe this approach is better than current IDL to C++11 mapping: Because the IDL to C++11 mapping is too intrusive. You can't really use normal classes you have written for use as servants in CORBA because you have to inherit from Skeletons classes *and* you have to use the *exact* same signature as defined in the mapping. This is *way too restricted*. This is also inerent to the OO paradigm that CORBA uses. But, we can mimic the same features using type-erasure instead of directly using dynamic polymorphism. This gives a much greater freedom to users. It might be that Boost.type_erasure is not the best tool here because of compile-time and compiler memory usage, but the idea surely is. We still haven't seriously profiled boost.type_erasure yet, but we will do so as soon as possible. I think it might be very interesting to experiment with lite concepts and Boost.concept_check as well. Also, we created a EDSL for GIOP and IIOP mapping based on the boost.spirit infrastructure. We use that to treat alignment and endianness automatically and to use the same grammar for generation and parsing of IIOP messages. The message header grammar is defined like this: start = "GIOP" & octet('\1') /* GIOP major version */ & octet('\0') /* GIOP minor version */ & endianness [ octet(MessageType) /* message_type */ & raw_size(ulong_)[body] ] ; Which is compiled to IIOP parser or generator through boost.spirit infrastructure of make_terminal, make_directive and etc. This works splendid well and is really easy to use, extend, is statically checked and has great performance. Whoever feel interested, please take a look and comments are highly appreciated. Regards, -- Felipe Magno de Almeida