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.
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 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.
For now I do not use header files at all. Classes are each in a single .cpp file completely. But to save compile time I want to make use of header files now. My hope is that Visual Studio won't compile classes which weren't modified for debug builds then.
Is there a way to mention only public methods and members in the header file. In theory that would be enough information for the compiler. If another file, say main.cpp includes the class header there is no need for private methods and members, is it?
How can I use header files without retyping the names of private methods and members? The reasons for me to want so is coding productivity. When I want do add a small helper function to the class used by another method, I don't want to have to also add it's signature to the header file.
If another file, say main.cpp includes the class header there is no need for private methods and members, is it?
No, public methods and members aren't necessarily enough. For example, if another .cpp file were to try and create an instance of your class:
SomeClass instance;
the compiler will need to know, among other things, how much memory to allocate for SomeClass. For that it requires full knowledge of SomeClass's private data members.
The way you are framing the question makes it sound as if you were intent on fighting the language. I don't think that's a good way to go about it. I think the best way is to do things the way things are usually done in the language of your choice, and depart from that only when there is a specific, clearly understood need.
The way things are usually done in C++ is that the entire class declaration goes in the header file, and the definition is in some way split between the header file and the corresponding .cpp file. The exact split is determined by various technical considerations. For example, templates and inline functions normally have to appear in the header file. On the other hand, placing code in header files increases dependencies and potentially build times.
There are ways to address these issues. However, since this involves extra complexity, I'd argue that this should only be done if there is a clearly identifiable need.
I don't know of a way to do what you're asking, but there is another way to give some isolation. You might want to take a look at the pimpl idiom as it offers isolation about private information. It's a little bit of extra work, but it can be extremely useful, especially in large projects.
All function declarations should go in header files and all function definitions should go in cpp files. It's not good coding practice to put declarations inside the cpp files.
You could put definitions inside headers though, when you write templates or inline functions.
Once you declare the class in the header file, you have to declare all its methods and members inside the class' declaration in the header, given that your class is no longer declared in the cpp file.
I have different classes all arranged in a hierarchy.
To reduce the amount of code, I started creating template functions. The base class will use the template functions and some of the derived classes will also use the same functions. Where am I suppose to put all of these templates so I don't get undefined reference issues like I have been? Should I put all the definitions in a header file and then just include that header files in the .cpp part of the class that call the functions. will that work? As of right now, all of my classes(class.cpp, class.h) compile fine, but everything blows up during the linking. I tried to put all the templates in a namespace and then include that namespace in the implementation of all my classes but that doesn't seem to work. My question is, how would you go about making a separate entity that just holds templated functions that any class can use on it's data members?
The definitions of template functions and template classes belong in header files, not .cpp files.
This is because the compiler essentially has to generate a brand new function for each set of template parameters that's used in the file that #includes the header. If the template function were defined in a .cpp file, then all of the appropriate versions of these functions would have to be generated without knowing what the calling code looks like, and that's basically impossible. (You do get duplicate definitions of template functions this way, but the linker removes those and makes sure there's only one copy if each template instantiation in the final binary.)
I see a lot of people confused by this thing... templates are not types.
They become types when instantiated.
For this reason members of templates must stay in the same data unit you are going to use them.
If you template is generic and you want to use it in all your code, just put everything in header files.
Now, if you don't like (and i would understand that) that you show declarations and definitions and implementation all in the same file, you can split templates in two different files.
For example, "list.h" with your declaration and "list.inc" with your implementation.
To make it work, you have to include both.
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 :-)