C++Talk.NET

Bill Pierce · Guest

I recently inherited maintenance of a library that contains, among other
things, a class with nearly 1500 member functions. As a first step, I'd
like to split it in two obvious new classes. The problem is that there is
several programs in production that use this library that I can't break.
Conceptually, here's what I have:

class HugeMama : public LoLevelClass
{
public:
void Type1Function001( ... );
o
o
o
void Type1Function800( ... );
char data_array[10];

void Type2Function001( ... );
o
o
o
void Type2Function700( ... );
}

Class LoLevelClass has no data members. "data_array" is used only by Type1
functions. This is what I'm thinking of doing:

class Type1Class : public LoLevelClass
{
public:
void Type1Function001( ... );
o
o
o
void Type1Function800( ... );
char data_array[10];
}

class Type2Class : public LoLevelClass
{
public:
void Type2Function001( ... );
o
o
o
void Type2Function700( ... );
}

class HugeMama : public Type1Class, public Type2Class
{
}

New programs can use the new classes and existing programs will still
compile using class HugeMama until we can switch them over to the 2 new
classes. Obviously, a class with 800 member functions is still too big. This
is just a first step. I concerned over using multiple inheritance, even if
it's only temporary, hopefully. Is there a better way? Or, other things
that I need to consider?

Bill Pierce

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ulrich Eckhardt · Guest

Bill Pierce wrote:

Dave Harris · Guest

[email]whpierce (AT) NOSPAM (DOT) comcast.net[/email] (Bill Pierce) wrote (abridged):

Pavel Vozenilek · Guest

"Bill Pierce" wrote:

Bill Pierce · Guest

Thanks to all for the replies. I'm sorry for the slow response. We had a
hurricane blow through here and it sort put everything else on hold for a
while.

I found out a little more history of this class. It started out as 1400 "C"
software generated functions that somebody then wrapped into a class when
the projects switched from Sun/Solaris platforms to PC/Windows platforms.
The last 100 or so functions have been added by hand by various people over
the last 3 - 4 years.

Pavel, you may be particularly interested to hear that because the original
1400 functions were software generated, they have never been unit tested. In
fact, as best as I can tell, only a few of the hand coded functions have
ever been explicitly tested at all. In all other cases they either took it
on faith that the software generate code was right or did some quick sanity
checks of the production programs. This is one of the reasons that I want to
restructure it all. There is no chance that I'll get a big enough block of
time to sit down and write 1500 unit tests. But, if I can break it into
logical chunks first, maybe I can "eat the elephant one bite at a time."

Dave, the LoLevelClass has no data members, but I didn't think about the
function member ambiguity that would occur in HugeMama. I'll have to decide
whether I want to explicitly resolve those or try your other approach. The
problem with a piecemeal division is that it takes years for change requests
in the production code to work their way through our process. I'm the
impatient sort that doesn't want to have to live with this monster any
longer than I have to. So, any changes that I can make that remain invisible
to the client programs are much preferred.

Uli, the reason for your confusion is I didn't show the actual code. It's
nearly 56K lines, 2.5Mb in size. Most of the newer hand-coded 100 functions
use implied "this" to access the data_array and the other functions. Of
course the older software-generated, wrapped C code doesn't realize that it
does too. I hadn't considered using separate namespaces. I have to give it
some thought and research to see what advantages they would bring.

Thanks again to all.
Bill Pierce

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Balog Pal · Guest

"Bill Pierce" <whpierce (AT) NOSPAM (DOT) comcast.net> wrote

Francis Glassborow · Guest

In article <8cudnZ64tfxAwtHcRVn-jg (AT) comcast (DOT) com>, Bill Pierce
<whpierce (AT) NOSPAM (DOT) comcast.net> writes