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.
>> 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.
>>> 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.
Thomas Richter <t...@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:
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."
> Thomas Richter<t...@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:
> 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.
>>> 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:
>> 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.
In article <jkndjl$a9...@news.belwue.de>,
Thomas Richter <t...@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...
> In article<jkndjl$a9...@news.belwue.de>,
> Thomas Richter<t...@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.
>>> 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.
In article <4f79bb47$0$6854$e4fe5...@news2.news.xs4all.nl>,
Johnny Willemsen <jwillem...@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.
>>>> 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.
