Lets say I have 2 classes. One is BaseClass and one is DerivedClass, being a derived class of BaseClass. I need to be able to create objects of both classes in another file. By using an #include statement to include the derived class in the new file, I have access to the derived class directly and the base class indirectly (as the derived class includes it in its file). Is it better to use this method of indirect "access" to the base class, or would it be better to directly include it alongside the derived class in the file?
The general advice is include what you use.
If you are coding to an API specification, and that specification does not explicitly detail the base-derived nature of the classes, then any changes to that relationship may break the includes that the files you depend on use.
See here as well.
If you are certain the BaseClass will always the base to the DerivedClass, then there may be little need include both, but for clarity, I would go ahead and do it anyway, it shows your intent.
Including all needed headers instead of relying on transitivity gives has two advantages:
If your header files will be refactored, you will not need to change your cpp file.
It clearly identifies your intent for other developers.
Related
If i include a base class in a different class, will that base's derived classes be included also. If i include lets say a shape class, and that class is a base class for the derived classes square and circle, will square and circle be included in that different class.
I want to do this, so if i decide to add another shape class later on(call it diamond), it will be easier writing...
#include <shapes.h>
rather than...
#include <square.h>
#include <circle.h>
#include <triangle.h>
No, it won't.
When you do #include<a.h>, the preprocessor recursively inline the content in a.h here.
So in your case you will only get the base class.
Besides, it is not a good idea to do this(include .h where base class is in and get all derived classes).
If you do that, maybe one day you only want to create a class derived from the base, you include all derived classes which are not used at all, increasing the code size.
No, the header files for the derived classes will not be included automatically. However, the good news is that in most cases you probably won't need to include the header files for the derived classes at all - the code responsible for creating the different shape objects needs to know about circles and triangles, but in most cases the code that (for example) draws the shapes can simply call a virtual draw function that will do the right thing for whichever kind of shape it happens to be given. Virtual functions are implemented in such a way that calling shape's draw function will correctly call the overridden versions for circle and triangle even if the header files for those classes aren't included in the file where the call is made.
If you find that your code regularly needs to know if something is a circle or a triangle (and hence needs to include the header files), that probably points to a problem with the shape class' interface. In that case, you should take another look at shape and see if you can change it in a way that you can call virtual functions and let the compiler sort out which is the correct implementation for each shape.
For the more general problem of having a whole bunch of header files that you often want to include together, you can make life easier by creating a single header file that includes all of the others. For example, you might create shape_library.h and put #includes for all of the different shape headers in there. That way, everything else can just include shape_library.h, and you only have one place to change if the headers get rearranged.
Suppose I have class like this (simplified):
class Foo_p;
class Foo
{
private:
Foo_p *p;
public:
Foo();
/* methods, etc... */
};
This class is a part of an API.
The Foo_p is all the private parts of the class, which are not
declared in the class Foo itself as usual, but rather in a separate forward-declared class that is only used by the underlying implementation not visible on the outside.
I've seen this pattern used in a couple of projects, is there a name for it?
Also, how do I use it properly (e.g. exception safety, etc.)? Where should the actual implementation go? In class Foo, as usual, only using Foo_p for storage of data, or in the Foo_p class with Foo being just a wrapper?
That is the pimpl idiom
See
Handle/Body Idiom - close cousin and the seminal idea for pimpl EDIT Found an online copy of this original James Coplien talk
GotW #100: Compilation Firewalls (Difficulty: 6/10)
GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10) for the most recent on this
This is known is PIMPL. private/pointer-to-private implementation. The class, Foo_p, your class would have been is implemented privately and accessed through a pointer to it so that rather than displaying the true class to clients, they only get to see the public interface you chose to expose. It essentially abstracts away from the header the vestiges of implementation detail present in the protected and private members.
I've found it unwieldy in VC++- it breaks code completion. It is useful if you are very sure of your implementation and don't want the private and protected members on display in the header.
I put the actual implementation of class Foo_p in the cpp file for class Foo, although this may have been the cause of the code-completion breaking, at least I don't have to run the risk of the class being reused by inclusion of its header.
It's a d-pointer which is a type of opaque-pointer. Similar to the PIMPL idiom.
One type of opaque pointer commonly used in C++ class declarations is
the d-pointer. The d-pointer is the only private data member of the
class and points to an instance of a struct. Named by Arnt Gulbrandsen
of Trolltech, this method allows class declarations to omit private
data members, except for the d-pointer itself.[6] The result is that
more of the class' implementation is hidden from view, that adding new
data members to the private struct does not affect binary
compatibility, and that the header file containing the class
declaration only has to #include those other files that are needed for
the class interface, rather than for its implementation. As a side
benefit, compiles are faster because the header file changes less
often. The d-pointer is heavily used in the Qt and KDE libraries.
https://en.wikipedia.org/wiki/Opaque_pointer#C.2B.2B
Why would you have an abstract base class defining an interface for a library where there is only one (always and forever) derived class?
You may want to swap out the implementation for something like Unit Testing
One reason why you would do this is for testability. It is much simpler to test dependent objects when their dependencies are defined as interfaces. This give the easy ability to mock or stub.
To violate the reused abstraction principle.
In short, don't do this.
Those who say "for testing" are overlooking that you can just replace
Base < - > Derived
Base < - > DerivedForMockingAndTesting
with
Derived < - > DerivedForMockingAndTesting
That is, let your existing implementation Derived serve as the "abstraction" to be mocked out and tested in unit testing.
If you can be 100% certain that there will always be only one and exactly one derived class? Not much reason. BUT: In reality you hardly will be 100% certain of anything and surely not the future of your code.
You may find the need for different versions of that class to be binary compatible. You may also find that for other reasons, you wish to encapsulate the definition of the class- for example, because the definition requires a header which has poor macros, and that kind of thing, or the header containing what's necessary to define the class has a very long compile time.
For example, I wrote a class to encapsulate the features offered by my operating system- for now, things like dynamic loading and creating a window. Even though there'll only ever be one implementation for one compile target (Windows, etc), I chose to use a run-time abstraction, because I wanted to guarantee that the rest of my code never saw a platform-specific header, and the Windows header is full of so many macros and stuff, that I didn't want them leaking out.
The most obvious reason would be to be able to put the class'
implementation in a source file, and not in a header. All that is
exposed in the header is the abstract base class (and a factory function
necessary to construct it, but this could be a static member). This
avoids having to include the header files for any member data; the pimpl
idiom is more idiomatic in C++ for this, but using abstract classes like
this is far from unknown, and works fairly well as well.
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 :-)
As I understand, the pimpl idiom is exists only because C++ forces you to place all the private class members in the header. If the header were to contain only the public interface, theoretically, any change in class implementation would not have necessitated a recompile for the rest of the program.
What I want to know is why C++ is not designed to allow such a convenience. Why does it demand at all for the private parts of a class to be openly displayed in the header (no pun intended)?
This has to do with the size of the object. The h file is used, among other things, to determine the size of the object. If the private members are not given in it, then you would not know how large an object to new.
You can simulate, however, your desired behavior by the following:
class MyClass
{
public:
// public stuff
private:
#include "MyClassPrivate.h"
};
This does not enforce the behavior, but it gets the private stuff out of the .h file.
On the down side, this adds another file to maintain.
Also, in visual studio, the intellisense does not work for the private members - this could be a plus or a minus.
I think there is a confusion here. The problem is not about headers. Headers don't do anything (they are just ways to include common bits of source text among several source-code files).
The problem, as much as there is one, is that class declarations in C++ have to define everything, public and private, that an instance needs to have in order to work. (The same is true of Java, but the way reference to externally-compiled classes works makes the use of anything like shared headers unnecessary.)
It is in the nature of common Object-Oriented Technologies (not just the C++ one) that someone needs to know the concrete class that is used and how to use its constructor to deliver an implementation, even if you are using only the public parts. The device in (3, below) hides it. The practice in (1, below) separates the concerns, whether you do (3) or not.
Use abstract classes that define only the public parts, mainly methods, and let the implementation class inherit from that abstract class. So, using the usual convention for headers, there is an abstract.hpp that is shared around. There is also an implementation.hpp that declares the inherited class and that is only passed around to the modules that implement methods of the implementation. The implementation.hpp file will #include "abstract.hpp" for use in the class declaration it makes, so that there is a single maintenance point for the declaration of the abstracted interface.
Now, if you want to enforce hiding of the implementation class declaration, you need to have some way of requesting construction of a concrete instance without possessing the specific, complete class declaration: you can't use new and you can't use local instances. (You can delete though.) Introduction of helper functions (including methods on other classes that deliver references to class instances) is the substitute.
Along with or as part of the header file that is used as the shared definition for the abstract class/interface, include function signatures for external helper functions. These function should be implemented in modules that are part of the specific class implementations (so they see the full class declaration and can exercise the constructor). The signature of the helper function is probably much like that of the constructor, but it returns an instance reference as a result (This constructor proxy can return a NULL pointer and it can even throw exceptions if you like that sort of thing). The helper function constructs a particular implementation instance and returns it cast as a reference to an instance of the abstract class.
Mission accomplished.
Oh, and recompilation and relinking should work the way you want, avoiding recompilation of calling modules when only the implementation changes (since the calling module no longer does any storage allocations for the implementations).
You're all ignoring the point of the question -
Why must the developer type out the PIMPL code?
For me, the best answer I can come up with is that we don't have a good way to express C++ code that allows you to operate on it. For instance, compile-time (or pre-processor, or whatever) reflection or a code DOM.
C++ badly needs one or both of these to be available to a developer to do meta-programming.
Then you could write something like this in your public MyClass.h:
#pragma pimpl(MyClass_private.hpp)
And then write your own, really quite trivial wrapper generator.
Someone will have a much more verbose answer than I, but the quick response is two-fold: the compiler needs to know all the members of a struct to determine the storage space requirements, and the compiler needs to know the ordering of those members to generate offsets in a deterministic way.
The language is already fairly complicated; I think a mechanism to split the definitions of structured data across the code would be a bit of a calamity.
Typically, I've always seen policy classes used to define implementation behavior in a Pimpl-manner. I think there are some added benefits of using a policy pattern -- easier to interchange implementations, can easily combine multiple partial implementations into a single unit which allow you to break up the implementation code into functional, reusable units, etc.
May be because the size of the class is required when passing its instance by values, aggregating it in other classes, etc ?
If C++ did not support value semantics, it would have been fine, but it does.
Yes, but...
You need to read Stroustrup's "Design and Evolution of C++" book. It would have inhibited the uptake of C++.