I am writing a c++ program which consists of 8 classes.
1.Vehicle
derived class 1. Seat
2.Door
2.Passenger
3.Settings
derived class 1. SeatSettings
2. InfotainmentSettings
4.PassengerLocation
I don't have any previous experience in c++. While writing the program should I write all the classes in a single .cpp file or in different .cpp file. If as different .cpp file then parent and derived class should be in same file ?.
Really you can write classes in any place of your programs. Inside h files, cpp files, inside other classes, inside methods and so on. C++ give complete control under source code of the application.
In general way you describe interface of a class in a h files, and implement methods in a cpp file. But you can implement inline or template methods in the h file.
I think that you should start from Classes guide, and when you will have knowledges about capability you can select right way to implement your classes.
You should make a separate .h and .cpp file pair for each class you implement in c++ unless it is a template class or struct
Separate the classes but keep the parent and derived classes in the same file.
Put your class declarations in .h files and the implementations in .cpp files and then include the .h file in its corresponding .cpp file.
Related
I am a beginner in C++. I have a question regarding C++ design.
My file contains A,B,C,D,E class definitions. Class A contains the API which is used by other applications. I have defined this in a .h file. Classes B,C,D & E define concrete classes by inheriting an abstract class which is provided by some library. These definitions are not used by any external application, but only used by class A.
I have seen online that all the class definitions are provided in an .h file and the function implementations in a .cpp file. My question here is, even though class B,C,D & E definitions are not used externally by anyone, should I define them in the .h file? If I do define them there anyway, I cannot expose them to other applications, right?
If a class is only used locally in one module, you can declare it in the .cpp file. This is actually good practice; don't expose more than necessary.
In a case where you need to define a class (or function, etc.) in a header (for example, to share it between several related .cpp file) but you do not want to expose it publicly, you can have a separate, private header file which is only included in the relevant places, but is not made public. This can be hinted at by appending "private" to the header file name.
I'm new to cpp, say I want to use an object Dog, is it ok to use only header file for the class Dog? the methods would be implemented in an inline manner.
Or is it that I should partition the class to an header and a cpp file implementing the methods defined in the header file?
The class Dog is used in some other cpp file (as a concrete object and not a pointer - Dog dog = new Dog()...).
is it ok to use only header file for the class Dog?
Yes, it is ok.
But when programs are getting larger, it's more practical to separate declaration from implementation and organize the program into semi-independent code fragments, which can be used to minimize compilation times and chance of errors.
ATL project "Class>Add>Implement Interface" procedure has generated a lot of class functions from IDL to header file. As I understood it would be more clever to have function realization in cpp file. Is it possible to move realization to cpp file somehow automatically?
I believe that many ATL classes are template classes, and the source code for templates needs to be available at each point where those classes are used (with the usual exceptions where a declaation might suffice...)
So moving the code into a separate .cpp file wouldn't work.
I am completely confused as to the proper way to layout a C++ project.
I had all my classes in separate .cpp files, with their definitions in .h files. I then had one "header.h" which contained all the class headers, external dependencies and a few other things. But I wasn't able to use class names in the header files, where I needed to declare a pointer to one.
Can someone please explain the proper object-orientated layout for a C++ project.
You can fix the problem "wasn't able to use class names in the header files, where I needed to declare a pointer to one" by using forward class declarations, like:
class myClass;
However, having every class include a header.h that then includes every class is overkill. Instead, you should have each class specifically include only the classes and external dependencies that it actually needs.
Background
I have an abstract class, something like
class IConverter{
public:
virtual void DoConvertion() = 0;
};
There will be many concrete classes which just implements DoConvertion method.
class TextConverter : public IConverter{
public:
virtual void DoConvertion(){
// my code goes here
}
};
class ImageConverter : public IConverter{
public:
virtual void DoConvertion(){
// my code goes here
}
};
There will be many concrete implementation like this. I have created a header file say, CharacterConverter.h which has the abstract class IConverter.
Question
Since my concrete classes just implement the DoConvertion method, is it required to create separate header files for each concrete class? I mean is it required to create ImageConverter.h, TextConverter.h and so on for all concrete classes? All these header files is going to contain the same code like IConverter abstract class.
Any thoughts?
It is not required. It's basically a judgment call.
If the implementation is simple for each class you can put them all in one .h and one .cpp
If the implementations are a bit longer, then it's probably cleaner to use a separate .h and .cpp file for each.
Some advantages of using a different .h/.cpp for each class:
It will keep the code organized and clean
Reduced compiling work: A change in one of the implementations won't need to recompile all others
Faster compiling time: Several compilers can compile multiple files at once such as Visual Studio's /MP switch. With several files you'll have a faster compile time.
Other files can include only what they need instead of everything
Faster link time: Linking time will be reduced due to incremental linking
Using version control you can look back on only the changes to a particular derived class, instead of having to go through all changes made to the massive 1 .h/.cpp file to find that one change in a particular derived class.
One of the main points of creating an interface class is so that clients can be depend on the abstract interface rather than the concrete implementation, and you are then free to change the implementation without impacting clients.
Putting the concrete declarations in the same header files as the interface declarations defeats this, so now if you change an implementation detail of a concrete class, your clients would need to re-compile.
Something you might consider, depending on the rest of your design, is a factory, where your abstract class has a static method (or multiple static methods, depending on how you implement it) that constructs the appropriate subclass and returns it as an IConverter*. With this, you can expose only the abstract definition in the header file, and have all the concrete class definitions and implementations in a single .cpp file along with the super class implementation. This gets a bit unwieldy if your subclass are large, but with smaller classes it reduces the number of files you have to manage.
But, as others have pointed out, it's ultimately a judgment call. The only performance issues would be related to compiling; more cpp files might take (slightly) longer to compile and more header files might increase dependency analysis. But there's no requirement that every header file have a matching cpp and vice verse.
Based on the comments, I'd recommend a structure like this:
IConverter.h ==> definition of IConverter
Converters.h ==> definitions of all subclasses
IConverter.cpp ==> include IConverter.h and Converters.h, contain implementation of IConverter abstract functionality (static factory method and any inheritable functionality)
TextConvter.cpp, ImagerConverter.cpp, etc. ==> seperate cpp files for each subclass, each containing IConverter.h and Converters.h
This allows you to only include the IConverter.h in any clients that use the factory and generic functionality. Putting all the other definitions in a single header allows you to consolidate if they're all basically the same. Separate cpp files allow you to take advantage of the compiler benefits mentioned by Brian. You could inline the subclass definitions in header files as mentioned, but that doesn't really buy you anything. Your compiler is usually smarter than you are when it comes to optimizations like inline.
You'll probably get answers both ways.
I'd say, for any trivial converters, having all of them in a single .h/.cpp pair is sufficient and that it's overkill to split every one into a single pair. I think the tradeoff of maintenance of lots of files vs. maintenance of a bunch of methods within a single file is worth it in this case.
Complex conversions probably deserve their own file pairs.
You will need definitions of the concrete classes to create objects, so you'll need to put those definitions into a .h file somewhere. Which file you put them in is up to you.
The best answer to this is what's easier to read. One long source file is going to be difficult for you and other programmers to follow. On the other hand, many tiny (half screen-full) source files is just as bad.
You'd probably be better off using factories or function pointers.
However, one particularly nasty way that springs to mind is using a macro to declare your concrete classes. For example:
At the bottom of IConverter.h include the following macro
#define DECLARE_CONVERTER_CLASS(CLASS_NAME) \
class CLASS_NAME : public IConverter\
{ \
public: \
CLASS_NAME() {} \
virtual void DoConversion(); \
}; \
Then in MyConverter1.cpp
DECLARE_CONVERTER_CLASS(MyConverter1)
virtual void MyConverter1::DoConversion()
{
...
}
Yuck :-)