Any interest in creating new CORBA IDL to C++ mapping?
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. 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, any input is welcome. Johnny Willemsen Remedy IT www.theaceorb.nl
On 7/12/2010 3: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. 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, any input is welcome.
Johnny Willemsen Remedy IT www.theaceorb.nl _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
In a world of language specific Java's J2EE and .NET's WCF, I would welcome an overhaul to CORBA's C++ mapping. I think documentation will be key here. Not just the mapping but also CCM and TAO.
Hi,
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. 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, any input is welcome.
In a world of language specific Java's J2EE and .NET's WCF, I would welcome an overhaul to CORBA's C++ mapping. I think documentation will be key here. Not just the mapping but also CCM and TAO.
We agree, documentation is important, but it would save us a lot of problems when we don't have to explain people the strange CORBA C++ mapping with its memory management rules. We do include CCM with the same update, we are currently making large improvements to CIAO as CCM implementation, but also 2 commercial modeling tool vendors will add soon support for CCM and D&C modeling. I am searching for people who can give us some guidance and feedback on what we could do with all the new C++ features. Personally I have been working with the current IDL to C++ mapping for almost 10 years now, I just have been brainwashed this period, but are very interested in creating a new IDL to C++ mapping and move my brain forward again ;-) Johnny
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
On Jul 12, 2010, at 3:54 AM, Johnny Willemsen wrote:
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. 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 am not all that familiar with C++0x, but I think you should consider an updated mapping to C++03+TR1. If that doesn't require too many compromises (compared to a C++0x mapping), then it might be the best way to drive early adoption. On the other hand, I wouldn't want the new mapping to be outdated before it's ratified as a standard, either. A tricky balancing act for you.
I did find some discussions on this list about 2 years ago, are people interested in this effort, any input is welcome.
+1
Hi,
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. 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 am not all that familiar with C++0x, but I think you should consider an updated mapping to C++03+TR1. If that doesn't require too many compromises (compared to a C++0x mapping), then it might be the best way to drive early adoption. On the other hand, I wouldn't want the new mapping to be outdated before it's ratified as a standard, either. A tricky balancing act for you.
Yes, it is a tricky balance, but also the reason why we maybe just go for C++0x is that it will be much easier to determine whether a compiler will than be able to compile the new mapping or not. By stating that we need C++0x, it will be clear what a compiler should support or not, else we get slowly all kinds of questions which means that we restrict ourselves in what we can use If you have ideas for C++03+TR1, just send them to me, we are gathering ideas now. Johnny
I did find some discussions on this list about 2 years ago, are people interested in this effort, any input is welcome.
+1 _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 14 Jul 2010, at 14:05, Ian Emmons wrote:
On Jul 12, 2010, at 3:54 AM, Johnny Willemsen wrote:
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. 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 am not all that familiar with C++0x, but I think you should consider an updated mapping to C++03+TR1. If that doesn't require too many compromises (compared to a C++0x mapping), then it might be the best way to drive early adoption. On the other hand, I wouldn't want the new mapping to be outdated before it's ratified as a standard, either. A tricky balancing act for you.
Basing on TR1 is very dangerous. It was never an official standard and gcc at least (I believe) considers it deprecated, and doesn't promise it will continue to work, when the compiler is put into C++0x mode, or have bugs fixed in future. Chris
"Johnny Willemsen" <jwillemsen@remedy.nl>: 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. 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
This would be very welcome and something I've hoped would happen for a long time (I keep checking the OMG web site for efforts in this area, but keep being disappointed). I'll be happy to help in whatever way I can (and as time allows). I've used ACE for many years and TAO for a couple of years on a couple of work projects, but my Corba knowledge is fairly limited (and I don't know any of the internals and protocol details, yet). I would guess that a nice IDL to C++ mapping could be done with C++03 and TR1 , sprinkled in with some Boost libraries (that hopefully could / should be standardized, e.g. boost::any), and maybe a few C++0x features that really simplify things. Are there C++0x features that are "must haves"? (Lambdas, auto, decltype? I would think move semantics / r-value operations are mostly optimizations, but maybe I'm missing something major.) Cliff
Hi,
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. 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
This would be very welcome and something I've hoped would happen for a long time (I keep checking the OMG web site for efforts in this area, but keep being disappointed).
It is a huge undertaking to make a new mapping, but if there is enough interest we do see some options to start the work. It needs funding by some users but more importantly we need good ideas and feedback from the C++ community, let us not get another bad mapping
I'll be happy to help in whatever way I can (and as time allows). I've used ACE for many years and TAO for a couple of years on a couple of work projects, but my Corba knowledge is fairly limited (and I don't know any of the internals and protocol details, yet).
I would guess that a nice IDL to C++ mapping could be done with C++03 and TR1 , sprinkled in with some Boost libraries (that hopefully could / should be standardized, e.g. boost::any), and maybe a few C++0x features that really simplify things. Are there C++0x features that are "must haves"? (Lambdas, auto, decltype? I would think move semantics / r-value operations are mostly optimizations, but maybe I'm missing something major.)
Please share ideas of how things could look like, for example, what do we do for the _var/_ptr/_narrow, how would this look like with a new mapping. We can easily use std::string, std::vector, but especially _var/_ptr replacement is very important. Johnny
On 7/14/2010 2:22 PM, Johnny Willemsen wrote:
Please share ideas of how things could look like, for example, what do we do for the _var/_ptr/_narrow, how would this look like with a new mapping. We can easily use std::string, std::vector, but especially _var/_ptr replacement is very important.
Ideas: - Use shared_ptr for both _var and _ptr. std::shared_ptr<FooFactory> factory = // get a Foo factory std::shared_ptr<Foo> foo = factory->make_a_foo("my foo"); foo->do_something(); Or even the now evil: factory->make_a_foo("my foo")->do_something(); // currently leaks _narrow will still be needed since you need the server's help. - IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&); C++0x allows std::vector to be returned via std::move without cost. - No exception specs - Forget backward compatibility. Consider it a new language. It doesn't replace the current C++ mapping it is a new language mapping for Modern_C++. So vendors can support either one or both. Just like vendors can now support C++ and Java and Python or just Java, etc. KevinH -- Kevin Heifner
Hi, Thanks for the ideas, I am storing all ideas safely and will try to move forward with the ideas during the summer. I do agree with backward compatibility, I see this as a full new mapping which requires real modern C++ compilers. Johnny
Please share ideas of how things could look like, for example, what do we do for the _var/_ptr/_narrow, how would this look like with a new mapping. We can easily use std::string, std::vector, but especially _var/_ptr replacement is very important.
Ideas:
- Use shared_ptr for both _var and _ptr.
std::shared_ptr<FooFactory> factory = // get a Foo factory std::shared_ptr<Foo> foo = factory->make_a_foo("my foo"); foo->do_something();
Or even the now evil:
factory->make_a_foo("my foo")->do_something(); // currently leaks
_narrow will still be needed since you need the server's help.
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
C++0x allows std::vector to be returned via std::move without cost.
- No exception specs
- Forget backward compatibility. Consider it a new language. It doesn't replace the current C++ mapping it is a new language mapping for Modern_C++. So vendors can support either one or both. Just like vendors can now support C++ and Java and Python or just Java, etc.
KevinH
-- Kevin Heifner
On Wed, Jul 14, 2010 at 3:58 PM, Kevin Heifner <heifnerk@ociweb.com> wrote:
- Forget backward compatibility. Consider it a new language. It doesn't replace the current C++ mapping it is a new language mapping for Modern_C++. So vendors can support either one or both. Just like vendors can now support C++ and Java and Python or just Java, etc.
Totally. This should be considered a new target language. Jon
On 14/07/10 22:58, Kevin Heifner wrote:
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
Can you use templates? When you take strings/sequences, why not take ranges instead of specific types the user would have to convert to?
On 7/22/10 7:57 AM, Mathias Gaunard wrote:
On 14/07/10 22:58, Kevin Heifner wrote:
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
Can you use templates? When you take strings/sequences, why not take ranges instead of specific types the user would have to convert to?
YES! YES! YES! Although it's tricker than you think, because IDL allows you to declare composite types with embedded sequences. I'd like to see IDL sequences mapped into templates that use trait classes that allow the programmer to use any of the appropriate STL ordered container abstractions (vector, list, deque, or user defined ones) as the underlying storage. IDL sequence classes should also be a sequence container so that <algorithm> works with them. So something like this: // IDL struct Foo { long l; string s; }; typedef sequence<Foo> FooSeq; interface Bar { FooSeq manipulate(in FooSeq arg); }; would map to something like this: // C++ struct Foo { CORBA::Long l; std::string s; }; template < class Storage = CORBA::ConcreteSequenceStorage<std::vector,Foo>
class FooSeq : public CORBA::AbstractSequence<Foo> { ... };
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; }; // Example client code Bar mybar = ...; // get from a factory somewhere FooSeq<> simpleresult, simplearg; simpleresult = bar->manipulate<>(simplearg); // or for the more adventurous typedef FooSeq<CORBA::ConcreteStorage<std::list,Foo> MyFoo; MyFoo myresult MyFoo myarg; myresult = mybar->manipulate<MyFoo>(arg); // and perhaps even typedef CORBA::SequenceResultContainerAdaptor<std::deque,Foo> MyFooResult; std::deque<Foo> myresult2; std::set<Foo> myarg2; myresult2 = mybar->manipulate<MyFooResult>(myarg2); Let's think big. -- Jon Biggar jon@floorboard.com jon@biggar.org jonbiggar@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Interesting proposals, I agree, lets think big and see what the best mapping could be. Not worry about the old mapping, just make something completely new. Johnny On 08/02/2010 03:59 PM, Jon Biggar wrote:
On 7/22/10 7:57 AM, Mathias Gaunard wrote:
On 14/07/10 22:58, Kevin Heifner wrote:
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
Can you use templates? When you take strings/sequences, why not take ranges instead of specific types the user would have to convert to?
YES! YES! YES!
Although it's tricker than you think, because IDL allows you to declare composite types with embedded sequences.
I'd like to see IDL sequences mapped into templates that use trait classes that allow the programmer to use any of the appropriate STL ordered container abstractions (vector, list, deque, or user defined ones) as the underlying storage. IDL sequence classes should also be a sequence container so that <algorithm> works with them.
So something like this:
// IDL struct Foo { long l; string s; };
typedef sequence<Foo> FooSeq;
interface Bar { FooSeq manipulate(in FooSeq arg); };
would map to something like this:
// C++ struct Foo { CORBA::Long l; std::string s; };
template < class Storage = CORBA::ConcreteSequenceStorage<std::vector,Foo>
class FooSeq : public CORBA::AbstractSequence<Foo> { ... };
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; };
// Example client code
Bar mybar = ...; // get from a factory somewhere
FooSeq<> simpleresult, simplearg;
simpleresult = bar->manipulate<>(simplearg);
// or for the more adventurous
typedef FooSeq<CORBA::ConcreteStorage<std::list,Foo> MyFoo; MyFoo myresult MyFoo myarg;
myresult = mybar->manipulate<MyFoo>(arg);
// and perhaps even
typedef CORBA::SequenceResultContainerAdaptor<std::deque,Foo> MyFooResult; std::deque<Foo> myresult2; std::set<Foo> myarg2;
myresult2 = mybar->manipulate<MyFooResult>(myarg2);
Let's think big.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMVtFmAAoJEF6eObUNSFTQL0MH/2TWKdUPgOHw4Nu7HjVkG6uM 4rNYAl+Dx515rBpqHPfFBGmoq9tCnN1621ZzYVVfN6w1jAWRDZyhb3bGKGCqk08b TNckNbq6w0HgF6aRQxcIc+5wk4KbBgCaictIh8XESdc6tbvt7L3u+Pv31ebl8b2Z PGFWQIWMINzfgmu/06tKQwi9BbjPhPktSJAuWtu+Sdl8E2wre/WkQC1h9G2hfQfz 4j2Kp9brJiaj0WO8+KxMdardykC8Uw3vuTPWOHxDnWZLQX3unyttur6kq8TFu1Qu J2kL9eK+sYdpi7Egz35Hm8hQDN81Zmd9bg72N8XtRr+6fvPJQG6WnvDLLXUqBt8= =t+xG -----END PGP SIGNATURE-----
The OMG is defining a new ISO C++ mapping for DDS. Note that DDS uses the CORBA mapping to define its interfaces. Even though this is DDS; it is closely related to the CORBA spec. The new mapping spec is currently a "work in progress" and only available to OMG members but I believe that there will be a public version in September. However, there is a LGPL project run by PrismTech (a DDS vendor) called SIMD (SIMple Dds, see http://code.google.com/p/simd-cxx/). SIMD appears to be an incubator for DDS in the same way that boost is an incubator for the std c++ libraries and has a prototype implementation of the new interfaces. SIMD appears to be doing the obvious things like using std::vector for sequences etc. This looks like a good place to look to get an early look at what they're thinking of. I also wonder if some of this could make its way back into the CORBA C++ mapping. If nobody has a similar incubator for CORBA then perhaps this boost library could take on that role. --glenn
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johnny Willemsen Sent: Monday, August 02, 2010 10:09 AM To: boost@lists.boost.org Cc: Jon Biggar Subject: Re: [boost] Any interest in creating new CORBA IDL to C++ mapping?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Interesting proposals, I agree, lets think big and see what the best mapping could be. Not worry about the old mapping, just make something completely new.
Johnny
On 08/02/2010 03:59 PM, Jon Biggar wrote:
On 7/22/10 7:57 AM, Mathias Gaunard wrote:
On 14/07/10 22:58, Kevin Heifner wrote:
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
Can you use templates? When you take strings/sequences, why not take ranges instead of specific types the user would have to convert to?
YES! YES! YES!
Although it's tricker than you think, because IDL allows you to declare composite types with embedded sequences.
I'd like to see IDL sequences mapped into templates that use trait classes that allow the programmer to use any of the appropriate STL ordered container abstractions (vector, list, deque, or user defined ones) as the underlying storage. IDL sequence classes should also be a sequence container so that <algorithm> works with them.
So something like this:
// IDL struct Foo { long l; string s; };
typedef sequence<Foo> FooSeq;
interface Bar { FooSeq manipulate(in FooSeq arg); };
would map to something like this:
// C++ struct Foo { CORBA::Long l; std::string s; };
template < class Storage = CORBA::ConcreteSequenceStorage<std::vector,Foo>
class FooSeq : public CORBA::AbstractSequence<Foo> { ... };
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; };
// Example client code
Bar mybar = ...; // get from a factory somewhere
FooSeq<> simpleresult, simplearg;
simpleresult = bar->manipulate<>(simplearg);
// or for the more adventurous
typedef FooSeq<CORBA::ConcreteStorage<std::list,Foo> MyFoo; MyFoo myresult MyFoo myarg;
myresult = mybar->manipulate<MyFoo>(arg);
// and perhaps even
typedef CORBA::SequenceResultContainerAdaptor<std::deque,Foo> MyFooResult; std::deque<Foo> myresult2; std::set<Foo> myarg2;
myresult2 = mybar->manipulate<MyFooResult>(myarg2);
Let's think big.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMVtFmAAoJEF6eObUNSFTQL0MH/2TWKdUPgOHw4Nu7HjVkG6uM 4rNYAl+Dx515rBpqHPfFBGmoq9tCnN1621ZzYVVfN6w1jAWRDZyhb3bGKGCqk08b TNckNbq6w0HgF6aRQxcIc+5wk4KbBgCaictIh8XESdc6tbvt7L3u+Pv31ebl8b2Z PGFWQIWMINzfgmu/06tKQwi9BbjPhPktSJAuWtu+Sdl8E2wre/WkQC1h9G2hfQfz 4j2Kp9brJiaj0WO8+KxMdardykC8Uw3vuTPWOHxDnWZLQX3unyttur6kq8TFu1Qu J2kL9eK+sYdpi7Egz35Hm8hQDN81Zmd9bg72N8XtRr+6fvPJQG6WnvDLLXUqBt8= =t+xG -----END PGP SIGNATURE----- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am aware of this mapping for DDS, it is a first step in a direction, but very focused on just DDS. I have asked the DDS vendors if they want to go a step further and make a full new IDL to C++ mapping, but they don't want to do that effort. In TAO we have recently added some prototype support to use a std::vector for a CORBA sequence. We want to really make a new mapping, I think boost together with TAO are a good incubator for a new IDL to C++0x mapping. Johnny On 08/02/2010 06:11 PM, Schrader, Glenn - 1002 - MITLL wrote:
The OMG is defining a new ISO C++ mapping for DDS. Note that DDS uses the CORBA mapping to define its interfaces. Even though this is DDS; it is closely related to the CORBA spec. The new mapping spec is currently a "work in progress" and only available to OMG members but I believe that there will be a public version in September.
However, there is a LGPL project run by PrismTech (a DDS vendor) called SIMD (SIMple Dds, see http://code.google.com/p/simd-cxx/). SIMD appears to be an incubator for DDS in the same way that boost is an incubator for the std c++ libraries and has a prototype implementation of the new interfaces. SIMD appears to be doing the obvious things like using std::vector for sequences etc. This looks like a good place to look to get an early look at what they're thinking of. I also wonder if some of this could make its way back into the CORBA C++ mapping. If nobody has a similar incubator for CORBA then perhaps this boost library could take on that role.
--glenn
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johnny Willemsen Sent: Monday, August 02, 2010 10:09 AM To: boost@lists.boost.org Cc: Jon Biggar Subject: Re: [boost] Any interest in creating new CORBA IDL to C++ mapping?
Hi,
Interesting proposals, I agree, lets think big and see what the best mapping could be. Not worry about the old mapping, just make something completely new.
Johnny
On 08/02/2010 03:59 PM, Jon Biggar wrote:
On 7/22/10 7:57 AM, Mathias Gaunard wrote:
On 14/07/10 22:58, Kevin Heifner wrote:
- IDL string is std::string - IDL sequence and array are std::vector - Java maps them to the same thing
std::vector<octet> object_id(); std::shared_ptr<Object> id_to_reference(const std::vector<octet>&);
Can you use templates? When you take strings/sequences, why not take ranges instead of specific types the user would have to convert to?
YES! YES! YES!
Although it's tricker than you think, because IDL allows you to declare composite types with embedded sequences.
I'd like to see IDL sequences mapped into templates that use trait classes that allow the programmer to use any of the appropriate STL ordered container abstractions (vector, list, deque, or user defined ones) as the underlying storage. IDL sequence classes should also be a sequence container so that <algorithm> works with them.
So something like this:
// IDL struct Foo { long l; string s; };
typedef sequence<Foo> FooSeq;
interface Bar { FooSeq manipulate(in FooSeq arg); };
would map to something like this:
// C++ struct Foo { CORBA::Long l; std::string s; };
template < class Storage = CORBA::ConcreteSequenceStorage<std::vector,Foo>
class FooSeq : public CORBA::AbstractSequence<Foo> { ... };
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; };
// Example client code
Bar mybar = ...; // get from a factory somewhere
FooSeq<> simpleresult, simplearg;
simpleresult = bar->manipulate<>(simplearg);
// or for the more adventurous
typedef FooSeq<CORBA::ConcreteStorage<std::list,Foo> MyFoo; MyFoo myresult MyFoo myarg;
myresult = mybar->manipulate<MyFoo>(arg);
// and perhaps even
typedef CORBA::SequenceResultContainerAdaptor<std::deque,Foo> MyFooResult; std::deque<Foo> myresult2; std::set<Foo> myarg2;
myresult2 = mybar->manipulate<MyFooResult>(myarg2);
Let's think big.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMVwdPAAoJEF6eObUNSFTQ68cIAKYsLW4AIBvPMBD9GVPZnr7Z Ljt9z4VBaDcLbWGDrFfZyU5AnQliIS5vkzCbYlwO82yUymyS4YLiieWPUmZ6UgHr uNaVzQNAQTjZjbeKLx13J+3SP/JpFHe/L7ocEAeOgAIFzZWcurOWi/HoFexUQ2Og Irwsvc5zMpfraOCjWS9Efh1PEPgnPxR33jck2fiEO0XcsBfoXfTXjBGKRXFzEMrg gC9ovT2P1FYnMOHtyfJuOtIVgV3SEqBfJx2dCZoV2ev3J/2fU424w9mv1KyTmkJ7 oyH9tEpRmjqQ4ti0tdedbpj66ALidy+YtUTeNu+SxpDrNCC0Kx5kgyeTf+UXRPE= =7QaR -----END PGP SIGNATURE-----
On 08/02/2010 07:58 PM, Johnny Willemsen wrote:
I am aware of this mapping for DDS, it is a first step in a direction, but very focused on just DDS. I have asked the DDS vendors if they want to go a step further and make a full new IDL to C++ mapping, but they don't want to do that effort.
I would hope all would somehow agree that commonality over the shared part of the IDL is worth aiming for. The problem I guess is that the DDS vendors does not have time to wait.
In TAO we have recently added some prototype support to use a std::vector for a CORBA sequence. We want to really make a new mapping,
It is unclear to me if you indicate that you tried the proposed DDS solutions and found them too be less than you desire, or that you tried them and realized that it is the way too go for CORBA as well? If part of your rationale is that CORBA need, or may need, a different mapping than the new DDS mapping for the shared parts. Could you please share this rationale. -- Bjørn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 08/03/2010 05:05 AM, Bjørn Roald wrote:
On 08/02/2010 07:58 PM, Johnny Willemsen wrote:
I am aware of this mapping for DDS, it is a first step in a direction, but very focused on just DDS. I have asked the DDS vendors if they want to go a step further and make a full new IDL to C++ mapping, but they don't want to do that effort.
I would hope all would somehow agree that commonality over the shared part of the IDL is worth aiming for. The problem I guess is that the DDS vendors does not have time to wait.
In TAO we have recently added some prototype support to use a std::vector for a CORBA sequence. We want to really make a new mapping,
It is unclear to me if you indicate that you tried the proposed DDS solutions and found them too be less than you desire, or that you tried them and realized that it is the way too go for CORBA as well?
The DDS mapping goes directly from the DDS PIM to the C++ PSM without IDL in between. It is really not an IDL to C++ mapping in terms of what we need for CORBA.
If part of your rationale is that CORBA need, or may need, a different mapping than the new DDS mapping for the shared parts. Could you please share this rationale.
DDS doesn't really have an IDL to C++ mapping, but directly a mapping from the DDS PIM to the C++ PSM. They are only focusing on the few interfaces DDS has, and these are all local calls, no remote calls like CORBA. The idea to use std::string and std::vector are things to reuse, but I think we need a different mapping, from IDL to C++0x Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMYQ/FAAoJEF6eObUNSFTQpBkH/30im19lBOq0Iqx1FN1BHcqZ EBZ/o3zz7fTS7UR5Vpm+x68rhI7lyIkQtnoX4y4XL9yqnYaNp4UsvdsPAiKycEj4 dy74OHfyHg2t34B9JqFswvVKOuYVRl+euKOFNl++LJtqSL4WmOD+Ay3fK0EUfgvd Ll8xOhNTzwAhRWXCVSUtSHNQPX1/SsF1iw7PIj7g7YumXCSfZNgWqv2LGokPWbjN 09RByd425YyBYzo/PMKu8W8crQJx4Ax03AOJDbsWz3WeGbCfxIVamcvFIglUwW72 BTS7/yOA5U36Xq/hH3+w+UgOU4dQdi0QYeq1aA7dJPHJUO7r8y9G0Bh23I+9YE4= =4ihJ -----END PGP SIGNATURE-----
On 02/08/10 14:59, Jon Biggar wrote:
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; };
C++ unfortunately does not have template virtual functions, so this code isn't well-formed.
On 8/2/10 7:31 AM, Mathias Gaunard wrote:
On 02/08/10 14:59, Jon Biggar wrote:
class Bar : public CORBA::Object { template<class _ResultType = FooSeq<>, class _argType = FooSeq<> > virtual _ResultType manipulate( const CORBA::SequenceInAdapter<_argType> &arg ) = 0; };
C++ unfortunately does not have template virtual functions, so this code isn't well-formed.
Quite true. I was piecing together this in the middle of the night due to lack of sleep. :( Fortunately, virtualness is unnecessary in this case. -- Jon Biggar jon@floorboard.com jon@biggar.org jonbiggar@gmail.com
On 07/12/2010 01: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. 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, any input is welcome.
Have you talked to Duncan Grisby, the omniORB maintainer, and the MICO folks yet? What is their take on it? Rob
Hi,
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. 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, any input is welcome.
Have you talked to Duncan Grisby, the omniORB maintainer, and the MICO folks yet? What is their take on it?
Not yet, it is on my todo list, just as hundreds of other points ;-) Johnny
participants (12)
-
Bjørn Roald -
Christopher Jefferson -
Cliff Green -
Ian Emmons -
Jarrad Waterloo -
Johnny Willemsen -
Jon Biggar -
Jonathan Franklin -
Kevin Heifner -
Mathias Gaunard -
Rob Riggs -
Schrader, Glenn - 1002 - MITLL