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.
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.
In my class in C++ I want to write a helper function (Which external users can't see or use) and found 2 ways to do that:
1) To declare it as private in the .h file and write the implementation in .cpp file.
2) To write the implementation directly in .cpp file without declaring it in the .h file.
What's the correct way, the difference or the advantage one have on the other?
Since you are not exposing this function through your interface, you should not declare it in the public header file. If you use it in a single cpp file, declare it in an anonymous namespace in that cpp file. If you use this function in multiple cpp files but you would still like to not make it a part of your interface, you can create internal header files that you #include in your source files, but aren't a part of your library's public interface.
The way is to create a class A that would be visible to the public, then create a descendant class B of this class and implement it privately. Then, when you are asked to create an A*, create a B* which is also an A* and return it. Your code sees a B* but the user of the class sees A* and may only access methods and variables declared in A. You also need to create/destroy your pointers with some function rather than with new/delete.
Pretty much like how COM implements IUnknown and stuff.
I've been programming in Java and C# for a while and I guess I always thought of objects and classes as being one and the same but the C++ course I'm following has the classes in .h files and the objects .cpp files. Is this typically how a C++ program is structured? Is the class/object relationship different than other OOP's?
You might as well see classes declarations in a .cpp file, e.g., if the one who wrote this file decided to use some help-classes that weren't supposed to be part of the API presented in the .h file.
Also, you might see in a .h file an object that is being held within a class as its private member.
Indeed, Java "pushes" you towards a pretty strict source and class files organization, that in many cases will match your folders & files organization. C++ allows you much more freedom in this regard, but however has the notion of includeing header files.
The relationship between the class and the object is not different to other languages. The object is an instance of the class.
So for example:
Car myCar("licence-plate123");
Car is the class. myCar is an instance of the Class Car and therefore the object.
To seperate the Class declaration is more like a convention and has nothing to do with objects and classes.
The .h-File contains the class description. There you can see, which methods the class provides, and what parameters they need. The .cpp-Files describe how each method works. So the actual source-code.
But as I have already said: This is more like a convention. You can also write all of it in the .h-File. It's not pretty but it works
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.
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 :-)