The CORBA C++ Mapping: Beyond Repair? MARS 2007 -03-14 Douglas C. Schmidt Vanderbilt University...
-
Upload
randolf-hicks -
Category
Documents
-
view
216 -
download
0
Transcript of The CORBA C++ Mapping: Beyond Repair? MARS 2007 -03-14 Douglas C. Schmidt Vanderbilt University...
The CORBA C++ Mapping: Beyond Repair?
MARS 2007-03-14
Douglas C. SchmidtVanderbilt University
Institute for Software Integrated Systems
CORBAIN THE
BALANCEMiddleware & the Human Spirit
AL GORE
Disclaimer
This talk presents my quixotic perspective as a
long-time CORBA advocate & does not (necessarily) represent any company’s
perspective
Motivation
What are the Problems?1. Memory management is too complicated & easy to get wrong
due to lots of rules to memorize, e.g.,
• Storing strings within sequences & structs
• Not handling the return reference from an operation, but passing it to another operation
• Not setting length() of sequence properly
• Not duplicating object references properly
• Not using ServantBase_var properly
Many of these problems stem from the lack of “self-managing” types in the C++ mapping
What are the Problems?2. Lack of standard C++ classes makes CORBA look “old & lame”
& causes extra work for programmers
• e.g., it’s a lot of work to move the data back & forth between the standard C++ types you want to manipulate & the types you need to pass as parameters
3. A tremendous amount of code gets generated for the C++ mapping, leading to bloat & slow compilation
• The size difference between the same essential set of functionality can be roughly on the order of 5:1
• e.g., for e*ORB C & C++ on Red Hat 9 Linux compiled with gcc 3.2 the C libec_poa.so is 29 kbytes C++ vs libe_mpoa.so is 105 kbytes
Top 10 Things to Fix in C++ Mapping1.All memory should be self-
managed• This includes
CORBA::Object, sequences, strings, structures of all types, etc
2.Structs & unions should have useful constructors
3.Arrays should be implemented using std::vector<>
Many more suggestions in CUJ columns by Vinoski & Schmidt• http://www.ddj.com/dept/cpp/184403757• http://www.ddj.com/dept/cpp/184403765• http://www.ddj.com/dept/cpp/184403778
4.Fix valuetypes so they use consistent reference counting scheme
5.All types should offer exception-safe swap() operations
6.Use bool, wchar_t, wstring, std::string, std::vector, etc.• Do not introduce new types
unless you must
7.Repeat number (1) until you reach (10)
• Tyranny of the installed base
• Not clear what the strategic directions are for CORBA
Why All This Is Hard
Some Options
Ultimately, this isn’t a technical issue,
per se, it’s a question of…
• Wait for CORBA vendors to devise general fixes• Pros: Establish critical mass of vendors necessary to
assure impact
• Cons: To paraphrase the eminent Jay-Z: “I've got ninety nine problems but the C++ mapping ain't one”
• Define an alternative mapping for a specific domain, e.g., embedded systems• Pros: Probably more realistic than trying to
standardize a totally new general mapping
• Cons: Doesn’t address the problem of trying to grow the overall general CORBA market
• Define an alternative general mapping & prototype it via open-source ORBs• Pros: Let the market decide, i.e., similar to Boost for
C++
• Cons: Establishing critical mass
• Adopt the ICE C++ mapping wholesale• Pros: Well thought out & based on “modern” C++
• Cons: Legal implications, i.e., is the ICE spec “open”?