Please report new issues athttps://github.com/DOCGroup
The class TAO_ORB_Core us getting bigger and bigger by the day. It has become a kitchen stuff for lot of things that have been going on in the ORB. The class declaration is more than a 1000 lines and the implementations are more than 5 times the size. If the class is allowed to grow it is going to be a maintenance nightmare at some point. Here are some thoughts on how to attack this problem. (1) The class TAO_ORB_Core can be made a namespace. This gives us a chance to split the declaration and definition across multiple translation units. The namespace TAO_ORB_Core can be defined in multiple units (with each unit representing some logical collection) by opening namespaces again & again. One idea could be put all allocator related information in one translation unit, TSS relared stuff in another unit and so on. The catch for this is that we can take up this work only after TAO 1.2 goes out (ie. once we drop busted compiler support). We should at that point of time have compilers that have decent namespace support. I am not sure whether MSVC can handle this even after 1.2. (2) The other idea would be subset the ORB_Core in to different classes and make ORB_Core reference all these classes ie. using the age old composition technique.
I like choice #2. It better isolates related methods and attributes.
Accepted on behalf of TAO-support.
I don't see how (2) is going to give us any benefit - if the ORB_Core reference pulls in all the separate classes. Let me go on record as saying I like (1) better.
The issue in this bug report is related to maintenance not footprint. Using composition would certainly make the ORB core more maintainable.