On 07/12/2010 09:54 AM, Johnny Willemsen wrote:
Hi all,
We are talking with various users of TAO to see if we can create a new modern IDL to C++ mapping. The idea is to drop all old compilers which lead to the current mapping and make a new IDL to C++ mapping that is using the latest draft C++0x standard.
We want to use full STL, shared_ptr, r-value, and everything else we could need.
What C++ language to use: I am thinking you should go as way out modern standard C++ as you can and clearly indicate your intent to do. We got the old mapping for those tied to old tools. I guess creating the best possible mapping within C++0x constraints is the first objective. Make sure we get a mapping that feels right at least 5-10 years from now.
The idea is to prototype this first in TAO and than see if on the long term we can propose a new IDL to C++ V2 mapping to the OMG
I did find some discussions on this list about 2 years ago, are people interested in this effort,
Yes
any input is welcome.
Backward compatibility will most likely be an issue, but should not stop anything like this from moving forward. Especially not as a prototyping effort. I guess IDL based products in an ideal world should support old and new C++ mapping if a V2 mapping eventually is approved by OMG. Alternatively and a lot more realistically; to assure early user adaptation of new mapping there need to be some re-engineering magic, adapter generator or adapter code generally available to avoid users concerns of vendor lock-in. Requiring an adapter may however put undesired design constraints on the new mapping, so I think it may be wisely ignored if needed. Nevertheless, if it is possible to create an adapter solution where the adapter have minimal overhead and provide V2 mapping for users tied to products only supporting V1, then adapter support seems to me as the way to go as far as user adaption. But there are surely other paths one can take. As long as we get a new mapping in place - and actual user adoption become a reality - most actively supported C++ CORBA IDL related products are likely going to make the new mapping native. Heck... the old one is stone age. The really interesting part from a C++/Boost perspective is how a general two-way mapping from C++ to IDL'ish typed data and interfaces should be crafted. If there is something in this, and people have ideas, this may be a time to step up and promote ideas as they may affect the new C++ mapping. If this is possible and done right, it may be a step on the the path to some nifty new possibilities. Maybe with a defined subset of C++ as data/interface definition language (probably looks a lot like IDL) and support from new tools based on good C++ front-ends like Clang, we could provide generation of mappings between C++, CORBA ORB/IDL, Microsoft IDL, WSDL, possibly DDL, and other interface definition solutions and middle-ware worlds. Hey what do we need modelling tools for ;-) I guess I dream of a better world where data protocol mappings is a lesser concern in my daily work. I am not sure this is even possible in a way that actually provide a real solution, but if it is to be done with focus on C++, it will likely be done around here. Nevertheless, getting a completely arcane major interface definition language binding to C++ fixed is certainly a step in the right direction - also for C++ as a programming language. Thanks Johnny and friends for working on this. -- Bjørn