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

[Johnny Willemsen]

Hi,

The OMG has recommended our IDL to C++11 language mapping for adoption.
Within a few weeks the OMG will publish a beta 1 specification and we
will the next months on the V1.0 of this new language mapping. See
http://osportal.remedy.nl for more details and examples.

Best regards,

Johnny Willemsen
Remedy IT
http://www.theaceorb.nl

[Volker Birk]

Johnny Willemsen <jwill...@remedy.nl> wrote:
> 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]

Hi,

>> 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.

[Thomas Richter]

On 25.03.2012 13:19, Volker Birk wrote:
> Johnny Willemsen<jwill...@remedy.nl> wrote:
>> 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]

Hi,

>>> 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

> 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]

Thomas Richter <th...@math.tu-berlin.de> wrote:
> 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 ;-)

[Thomas Richter]

On 27.03.2012 15:36, Volker Birk wrote:
> Thomas Richter<th...@math.tu-berlin.de> wrote:
>> 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 ;-)

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]

Hi,

>>> 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 ;-)
>
> 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]

In article <jkndjl$a9k$1...@news.belwue.de>,

Thomas Richter <th...@math.tu-berlin.de> wrote:

>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 --
-- dun...@grisby.org --
-- http://www.grisby.org --

[Martin B.]

On 02.04.2012 12:10, Duncan Grisby wrote:
> In article<jkndjl$a9k$1...@news.belwue.de>,
> Thomas Richter<th...@math.tu-berlin.de> wrote:
>
>> 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,

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.

> 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]

Hi,

>>> 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,
>
> 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.

>> 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]

In article <4f79bb47$0$6854$e4fe...@news2.news.xs4all.nl>,

Johnny Willemsen <jwill...@remedy.nl> wrote:

>>> 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.

[Johnny Willemsen]

Hi,

>>>> 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?

Just using multiple namespace with some macros and using.

> 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.

At the end the user gets the types he needs, the specs don't describe
how things have to be implemented to our idea.

Johnny