80 likes | 193 Views
CORBA IN THE BALANCE Middleware & the Human Spirit AL GORE. The CORBA C++ Mapping: Beyond Repair? MARS 2007 -03-14 Douglas C. Schmidt Vanderbilt University Institute for Software Integrated Systems. Disclaimer.
E N D
CORBA IN THE BALANCE Middleware & the Human Spirit AL GORE The CORBA C++ Mapping: Beyond Repair?MARS 2007-03-14Douglas C. SchmidtVanderbilt UniversityInstitute for Software Integrated Systems
Disclaimer This talk presents my quixotic perspective as a long-time CORBA advocate & does not (necessarily) represent any company’s perspective
What are the Problems? • 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? • 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 • 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++ Mapping • Fix valuetypes so they use consistent reference counting scheme • All types should offer exception-safe swap() operations • Use bool, wchar_t, wstring, std::string, std::vector, etc. • Do not introduce new types unless you must • Repeat number (1) until you reach (10) • All memory should be self-managed • This includes CORBA::Object, sequences, strings, structures of all types, etc • Structs & unions should have useful constructors • 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
Why All This Is Hard • Tyranny of the installed base • Not clear what the strategic directions are for CORBA
Ultimately, this isn’t a technical issue, per se, it’s a question of… Some Options • 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”?