[ANN] IDL to C++11 recommended for adoption by the OMG

Post by Johnny Willemsen
The OMG has recommended our IDL to C++11 language mapping for adoption.

Thank you for your work! This is really needed.

Yours,
VB.

--
"If /dev/null is fast in web scale I will use it."

http://www.mongodb-is-web-scale.com/

Johnny Willemsen

2012-03-25 14:20:26 UTC

Hi,

Post by Johnny Willemsen
The OMG has recommended our IDL to C++11 language mapping for adoption.

Thank you for your work! This is really needed.

Thanks for your comment. We are in the final steps of finishing our
TAOX11 product which implements this new language mapping for the TAO
CORBA implementation. We are also going to work on a CIAOX11 which will
be a CCM product matching the CIAO open source product and OpenDDSX11
which will be OpenDDS with this new language mapping.

Feel free to contact me if you are interested in any of these products.

Best regards,

Johnny Willemsen
Remedy IT

Thomas Richter

2012-03-25 15:28:52 UTC

Post by Johnny Willemsen
The OMG has recommended our IDL to C++11 language mapping for adoption.

Thank you for your work! This is really needed.

Indeed, I agree. The current C++ language mapping is "rotten". I browsed
a little bit in the new mapping and it seems rather canonical.

I wonder a little bit why length-limited sequences do not map to
length-limited types instead of vector, though, e.g. std:array or plain
arrays.

BTW, does anyone have an idea whether or when omniorb will support the
new mapping?

Greetings,
Thomas

Johnny Willemsen

2012-03-27 12:13:04 UTC

Hi,

Post by Thomas Richter

Post by Johnny Willemsen
The OMG has recommended our IDL to C++11 language mapping for adoption.

Thank you for your work! This is really needed.

Indeed, I agree. The current C++ language mapping is "rotten". I browsed
a little bit in the new mapping and it seems rather canonical.
I wonder a little bit why length-limited sequences do not map to
length-limited types instead of vector, though, e.g. std:array or plain
arrays.

The IDL length limited is just a max, the array would always fully
allocate it, which could be something you don't want. Hopefully at some
point we can standardize some IDL annotations that you can use to
control the mapping as user, override the default

Post by Thomas Richter
BTW, does anyone have an idea whether or when omniorb will support the
new mapping?

Not sure, that is up to each product/vendor to decide. We are working on
an implementation as addition to TAO. As users you are in control, you
can push vendors/products to supply the new mapping and if they are not
willing to switch to a vendor that does provide it.

Johnny

Volker Birk

2012-03-27 13:36:56 UTC

Post by Thomas Richter
I wonder a little bit why length-limited sequences do not map to
length-limited types instead of vector, though, e.g. std:array or plain
arrays.

For a better understanding I can reccommend this article:

<http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1>

Maybe different implementations of std::array do here a better job. But
after measuring with GCC, that after optimization usually there is no
difference in performance, I'm not interested any more ;-)

Yours,
VB.

--
"If /dev/null is fast in web scale I will use it."

http://www.mongodb-is-web-scale.com/

Thomas Richter

2012-03-27 19:45:39 UTC

Post by Thomas Richter
I wonder a little bit why length-limited sequences do not map to
length-limited types instead of vector, though, e.g. std:array or plain
arrays.

<http://www.parashift.com/c++-faq-lite/containers.html#faq-34.1>
Maybe different implementations of std::array do here a better job. But
after measuring with GCC, that after optimization usually there is no
difference in performance, I'm not interested any more ;-)

Actually, I'm not so much worried about the speed. I'm more interested
in the additional compile time check it would allow.

Greetings,
Thomas

Johnny Willemsen

2012-03-29 18:15:28 UTC

Hi,

Post by Thomas Richter

Post by Thomas Richter
I wonder a little bit why length-limited sequences do not map to
length-limited types instead of vector, though, e.g. std:array or plain
arrays.

Actually, I'm not so much worried about the speed. I'm more interested
in the additional compile time check it would allow.

During marshaling the CORBA layer could do a check, we are working on
some additional traits that allow you easily to do any check in your code.

Johnny

Duncan Grisby

2012-04-02 10:10:48 UTC

Post by Thomas Richter
BTW, does anyone have an idea whether or when omniorb will support the
new mapping?

The answer is possibly. It depends on the demand. The old C++ mapping
is awful, and this new one is clearly much better, but on the other
hand, there is a lot of code out there using the old mapping. My
initial reading of the new mapping suggests that there won't be any
clean migration path for code using the old mapping to the new
mapping, due to clashing namespaces, so I wonder how much real demand
there will be. How many people are writing new brand new C++ CORBA
code?

If anyone was interested in sponsoring omniORB support for the new
mapping, that would make it more likely...

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

Martin B.

2012-04-02 10:30:22 UTC

Post by Duncan Grisby

Post by Thomas Richter
BTW, does anyone have an idea whether or when omniorb will support the
new mapping?

Now that is horrible news indeed. It absolutely should be possible to
mix - obviously only to a certain extent - the two models in the same
application.

Post by Duncan Grisby
there will be. How many people are writing new brand new C++ CORBA
code?

Well. We still are, but also have old code around, and that stuff should
be able to be compiled into the same app at the very least.

cheers,
Martin

Johnny Willemsen

2012-04-02 14:44:23 UTC

Hi,

Post by Duncan Grisby

Post by Thomas Richter
BTW, does anyone have an idea whether or when omniorb will support the
new mapping?

Now that is horrible news indeed. It absolutely should be possible to
mix - obviously only to a certain extent - the two models in the same
application.

Yes, it can be done, we do something similar in our TAOX11 product. You
can use the old and new mapping withing the same application.

Post by Duncan Grisby
there will be. How many people are writing new brand new C++ CORBA
code?

Well. We still are, but also have old code around, and that stuff should
be able to be compiled into the same app at the very least.

It is possible but it is some work for the vendor to support it. We are
also looking at some tooling that could convert old code to the new
structure. That itself is a challenge, but when the conversion tool has
also IDL as input it should be able to do probably 99% of the code
conversion.

Johnny

Duncan Grisby

2012-04-02 16:22:01 UTC

Post by Johnny Willemsen

Post by Duncan Grisby
The answer is possibly. It depends on the demand. The old C++ mapping
is awful, and this new one is clearly much better, but on the other
hand, there is a lot of code out there using the old mapping. My
initial reading of the new mapping suggests that there won't be any
clean migration path for code using the old mapping to the new
mapping, due to clashing namespaces,

Now that is horrible news indeed. It absolutely should be possible to
mix - obviously only to a certain extent - the two models in the same
application.

Yes, it can be done, we do something similar in our TAOX11 product. You
can use the old and new mapping withing the same application.

How do you deal with the clashing identifiers in the CORBA,
PortableServer, etc. namespaces? Are you using some macro magic to
remap the namespace names?

It's not clear to me that it's compliant with either the old or new
C++ mappings to have the "CORBA" namespace actually be some other name
substituted in by a macro, but maybe it's okay as long as it looks
right to the application code.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

Johnny Willemsen

2012-04-04 11:23:06 UTC

Hi,

Post by Duncan Grisby

Post by Johnny Willemsen