IDL to C++11 technical proposals
I am searching for technical proposals for the new IDL to C++0x mapping. If you have any ideas, just pust them here!
community site for CORBA, CCM and related technologies
Recent news
We have published our revised submission for IDL to C++11 on OSportal...
2 days 3 hours ago
ACE 6.0.8 and TAO 2.0.8 RPMs are now available at OpenSuSE Build...
3 weeks 5 days ago
Once again, thanks to the efforts of many developers, testers, and...
3 weeks 5 days ago
Once again, thanks to the efforts of many developers, testers, and...
8 weeks 1 day ago
- 1 of 9
- ››
Recent blog entries
After several months of hard work we are almost ready with our...
5 days 5 hours ago
Some time ago I was invited by the NATO TTCP working...
17 weeks 11 hours ago
- 1 of 4
- ››
Popular blog entries
After several months of hard work we are almost ready with our...
5 days 5 hours ago
5
Some time ago I was invited by the NATO TTCP working...
17 weeks 11 hours ago
0
Last week I attended the...
20 weeks 5 days ago
5
- 1 of 4
- ››
Author Information
Upcoming events
-
Mon, 2012-03-19
-
Tue, 2012-04-17
-
Wed, 2012-05-09
Recent users tweets
- #nowplaying VIVALDI / Huggett on 1.... — 1 day 15 hours ago
- My latest SlideShare upload : IDL to C++11 Revised Submission... — 2 days 3 hours ago
- Added new post on #ORBZone: IDL to C++... — 2 days 3 hours ago
- Added new post on #ORBZone: IDL to C++... — 5 days 5 hours ago
- Just finished another pass through our IDL to C++11 mapping, almost finished! — 5 days 5 hours ago
- 1 of 2
- ››
Latest comp.object.corba feeds
Sponsored by 
Copyright © 2010 - 2012 ORBZone.org
Standardized header files
If at all possible, it would be very nice to have standardized header file names for those files which are needed at the application level.
For example, in TAO the C++ header containing the IDL -> C++ mapping for Foo.idl is, by default, FooC.h. Other vendors use different naming conventions causing source code incompatibility.
The standardized header names in the new DDS C++ PSM is, I believe, one of its strongest and most useful features.
Trent Nadeau
Northrop Grumman Corp.
Some technical proposals
Some proposals I received in the past:
- Use shared_ptr for both _var and _ptr.
std::shared_ptr factory = // get a Foo factory
std::shared_ptr 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
std::vector object_id();
std::shared_ptr id_to_reference(const std::vector&);
C++0x allows std::vector to be returned via std::move without cost.
- No exception specs
- Use IDL annotations to control to which std container a sequence maps
shared_ptr is NOT a good match for _ptr
I'm all for replacing
_vartypes withshared_ptr(or a similar type with a compatible interface) butshared_ptris not a good match for the_ptrtypes.For example: The functions currently returning a
_ptrtype would be better off returning aunique_ptr, as they yield ownership of the value they return.For example: Functions currently taking a
const _ptrparameter can continue to do so - no need forshared_ptr.cheers,
Martin
shared_ptr
I don't think shared_ptr should be used. A specialized smart pointer would be a lot more appropriate and would allow more specialization for the ORB implementer. Giving more room for quality differentiation. I would like though that a generic smart pointer would be defined. Like corba_ptr instead of the T_ptr that is used today.
Explicit and partial specialization allow for the same behavior when differences arise for different smart pointer types.
But would be more easier to match for overload resolution.
Regards,
--
Felipe Magno de Almeida
shared_ptr
We came to the conclusion that we don't want to expose shared_ptr to the end user.
IDL annotations to control to which std container a sequence map
I would be okay with this only as an optional extension with std::vector as the default. I think requiring all implementations to support this is overkill. (Of course, one could ask if it is optional, does it belong in the standard?) The std::vector type has attributes that make it well suited for this.
std::vector
We agree that std::vector needs to be the default, the annotations can than be used to overrule the default. I think we should also standardize these to make it easy for people to use multiple ORB implementations
dynamic_cast
_narrow could possibly be replaced by a specialization of dynamic_cast<> that uses server information instead of RTTI.
Trent Nadeau
Northrop Grumman Corp.
dynamic_cast
_narrow could possibly be replaced by a specialization of dynamic_cast<> that uses server information instead of RTTI.
Trent, do you have an example of specialize dynamic_cast<>, as far as we know this isn't possible. It would be interesting to see if we can use dynamic_pointer_cast() instead of narrow()
I've done some more research,
I've done some more research, and it looks like you're correct. I thought that dynamic_cast was a free function created by the compiler; however, it seems that it truly is a built-in operator. The dynamic_pointer_cast function looks to be what I wished dynamic_cast to be.
Trent Nadeau
Northrop Grumman Corp.
C++0x goes FDIS!
As of March 2011, the JTC1/SC22/WG21 C++ Standards Committee has voted the C++0x specification to FDIS status. This means that it is ready for review and approval by the ISO; the final specification is expected to be published sometime in mid-2011. This means that there is no procedural reason to postpone an IDL to C++0x mapping.