The CORBA C++ Mapping: Beyond Repair? MARS Douglas C. Schmidt Vanderbilt University Institute for Software Integrated Systems CORBA IN THE BALANCE Middleware & 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++ Mapping 1.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 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”?