Can different member functions of the same class be in differenttranslation units?

[gw7rib]

If a class has more than one member function, is it possible for the
code for one to be in one translation unit (ie file) and the code for
another to be in a different translation unit? I would have thought
so, yet I still have a nagging doubt about it. If it is allowed, is it
a good idea?

My problem is that I have a class which does far, far too much, but I
haven't managed to break its functions down into several self-
contained groups. I thought that perhaps separating up the source
code, even if it is still part of the same class, might help by
clarifying what links between the various functions are required. Or
is there a better way?

Thanks in advance.
Paul.

[Victor Bazarov]

gw****@aol.com wrote:

If a class has more than one member function, is it possible for the
code for one to be in one translation unit (ie file) and the code for
another to be in a different translation unit?

Yes, absolutely. From the language point of view there is nothing
that should prevent it.

I would have thought
so, yet I still have a nagging doubt about it. If it is allowed, is it
a good idea?

That is up to you and your team. The only reason to split code on
translation units is to work on those separately. If you want to
allow one member of your team to work on one part of the class while
another works on some other part and no conflict exists from your
source control system, splitting might be a good idea.

My problem is that I have a class which does far, far too much, but I
haven't managed to break its functions down into several self-
contained groups.

You may need to break the class into several and inherit them or
instantiate them separately. Consider redesigning.

I thought that perhaps separating up the source
code, even if it is still part of the same class, might help by
clarifying what links between the various functions are required. Or
is there a better way?

Different areas of functionality belong to different classes, at
least according to my understanding of OOD.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Dec 12, 10:47 pm, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

If a class has more than one member function, is it possible
for the code for one to be in one translation unit (ie file)
and the code for another to be in a different translation
unit?

Yes, absolutely. From the language point of view there is
nothing that should prevent it.

I would have thought so, yet I still have a nagging doubt
about it. If it is allowed, is it a good idea?

That is up to you and your team. The only reason to split
code on translation units is to work on those separately.

Most linkers still treat the object file as the unit of
granularity, which means that in a well written general purpose
class, which will be used in a variety of applications, every
non-virtual function will be in a separate source file, so that
the final executable only contains what it needs. (There are
exceptions, of course.)

Writing such libraries is a special case, however, and doesn't
concern most people.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Victor Bazarov]

James Kanze wrote:

[..]
Most linkers still treat the object file as the unit of
granularity, which means that in a well written general purpose
class, which will be used in a variety of applications, every
non-virtual function will be in a separate source file, so that
the final executable only contains what it needs. (There are
exceptions, of course.)
[..]

I know that some advanced linkers manage to remove unused static
functions from the final program as part of optimizing it. This
is to complement your response, not to contradict it, mind you.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Dec 13, 2:29 pm, "Victor Bazarov" <[e-mail]:

James Kanze wrote:

[..]
Most linkers still treat the object file as the unit of
granularity, which means that in a well written general purpose
class, which will be used in a variety of applications, every
non-virtual function will be in a separate source file, so that
the final executable only contains what it needs. (There are
exceptions, of course.)
[..]

I know that some advanced linkers manage to remove unused static
functions from the final program as part of optimizing it. This
is to complement your response, not to contradict it, mind you.

I've heard this as well. The linkers on my principal target
don't, however, and if you're maintaining separate sources for
each function on one platform, it's easier to do it everywhere
than to use two different strategies.

It is more work. For low level classes with lots of more or
less similarly sized functions, it's worth it. But it's not
worth doing everywhere---for example, well over 90% of the code
of my RegularExpression class in the parser, which is invoked by
the constructor. Given that, it's probably not worth breaking
the other functions out into separate files---any user will pick
up 90% of the code anyway. (On the other hand, the parser
itself is complicated enough that it needs to be spread over
several source files. And because I originally developped it on
a 16 bit machine where every byte counted, my current
implementation still does have every function in a separate
file.)

If the class is only going to be used in one application, of
course, there's no point in it. If the function isn't used,
don't even write it, and if it is, it has to be linked in
anyway, so you might as well put it in the same file as the
other functions.

Also, if virtual functions are involved, the compiler will want
to put their address in the vtbl, whether they're invoked or
not. Which means that they will be linked in, so you might as
well put them all in the same source file.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]