R
ronic
I am creating a big class.
and I want to define in different files for this class.
How to do it?
Thanks.
and I want to define in different files for this class.
How to do it?
Thanks.
R
Rolf Magnus
ronic said:
Are you sure you can't split it up into several smaller classes?
Define what? The class itself or its member functions? The latter is
easy. You can simply make several implementation files that contain the
functions. The former would be possible, but I'd advice against it,
since it makes the code less readable. It could go something like:
//foo.h
class Foo
{
public:
# include "foo_functions1.h"
# include "foo_functions2.h"
# include "foo_functions3.h"
};
//foo_functions1.h
void someFunc(int param);
void anotherFunc() const;
//...
and so on.
A
Alberto Barbati
ronic said:
Big classes are usually a sign of poor design. Are you sure you really
need such a big class? Think twice before answering.
I am of the school "one component, one file" where "component" is one or
more strongly related classes. Therefore it sound blasphemous to me to
even think of spliting one single class in more than one file.
*Very reluctantly*, the _only_ way is to write this:
class BigBlasphemousClass
{
#include "BigBlasphemousClass1.h"
#include "BigBlasphemousClass2.h"
};
but merely looking at such thing gives me shivers.
Regards,
Alberto Barbati
N
Nick Hounsome
ronic said:
A big class is probably bad design.
Not knowing how to put it in different files means you are an inexperienced
programmer who
hasn't read much which again implies that the class is probably a bad
design.
I know it's not directly helpful but I promise that in the long term
you'll be better off just stuffing it all one file and spending the time
saved reading C++ design books so you do it right next time.
Assuming that you ignore my advice:
If the problem is that the declarations (.h) file is too big then:
1. Don't use inline methods.
2. If you do use inline methods - define them in a sparate file included
from the main .h
If the problem is just the size of the .cpp/.cxx etc file then just split it
in two - there
is no (practical) reason not to.
C
Claudio Puviani
Alberto Barbati said:
You've renewed my faith in humanity.
Claudio Puviani
L
lilburne
Nick said:
The practical problem is that you then have more than one
place to look for the source. I like to have corresponding
file names:
include/somecomponent/myClass.h
source/somecomponent/myClass.cpp
having to ferret about looking in
source/somecomponent/myClass_part1.cpp
source/somecomponent/myClass_part2.cpp
source/somecomponent/myClass_part3.cpp
is a tad annoying.
N
Nick Hounsome
lilburne said:
By practical I only meant easy to create not easy to maintain
S
Sims
I read what you and others say but what about cases where the splitting of
files is more for ease of use rather than design.
For example imaging a data handling class.
You could split the class to make it easier to handle.
class SomeDataHandelingClass
{
#include "SomeDataHandelingClass_READ.h";
#include "SomeDataHandelingClass_WRITE.h";
#include "SomeDataHandelingClass_MISC.h";
};
Would that not be a case where splitting the class would make it somewhat
easier to read eventhouh the class might not be that big?
Simon
A
Alberto Barbati
Sims said:
No. Your SomeDataHandelingClass.h file may be easier to read, but the
three sub-include files are definitely not. Those files won't be
self-contained and their interpretation will be dependent on something
external to them. How could they be easier to read?
The only case in which I consider splitting a class definition into two
(not more) include files is if I define a lot of inline functions. In
that case I may write:
class ClassWithInlineFunctions
{
// declaration of all members
};
// definition of all inline member functions
#include "ClassWithInlineFunctions.inl"
Notice that the file "ClassWithInlineFunctions.inl" would still be
self-contained (at least at the syntactic level) as the #include occurs
at global scope. Except for some namespace-wrapping techniques used to
solve compatibility issues with legacy code, putting an #include
anywhere except at global scope is pure evil.
Alberto
R
ronic
Nick Hounsome said:
Thank for all your good help.
I am creating a class to simulate a micro controller. The micro
controller has
several hundreds instructions. So there are serveral hundreds private
instruction handlers. So I do like this
private:
#include "act.h"
#include "act_ABS.h"
#include "act_ADC_1.h"
#include "act_ADC_2.h"
#include "act_ADCF.h"
#include "act_ADD_1.h"
#include "act_ADD_2.h"
#include "act_ADD_3.h"
......
A
anon luker
Nick Hounsome said:
It is not only "not directly helpful", but it is insulting. I feel as
if I should apologize to the op on your behalf. A person need not be
familiar with every possible technique to design or produce quality
software. A series of assumptions and vacuous conclusions on your
part does not render the op ignorant.
J
Julie
It is not only "not directly helpful", but it is insulting. I feel as
Amen.
Amen.
J
Jorge Rivera
ronic said:
It appears to me that you are going to do this anyway, then why post here?
You heard all sorts of reasons why not to do it, but you insist on doing
it...
Anyway, you could divide your microcontroller instructions by type
(math, comparison, etc) into different smaller classes. That you way
you have manageable classes, while splitting the functions into smaller
modules.
Just a thought,
Jorge L.
A
Alberto Barbati
ronic said:
If all those are private, why would you want to put them in the class
declaration? You are creating a dependency hell! If you change or add
one single instruction handler, you have to recompile the whole
program... All that is, technically, unnecessary. The client of you
class does not need to know all that stuff.
If that's the case, I may suggest using free-functions defined into an
implementation namespace and move all your #includes inside the .cpp
file of your class.
Alberto Barbati