const Vs #define, what to use and when

const one of the features which was not present in C but was introduced in C++. Its interesting to know why would anyone use const to declare constant values and not #defines which are being used since ages and have done the work more or less without much trouble.

Well the problem with #define is that its a preprocessor directive. Which means it needs to be put in a .h file for sharing among different files. But if it just needs to be used in a single cpp file, it works like a charm. But imagine that you need to include it in several files. Then you are in a big mess. If you make a simple change in that .h file, the build process will compile all files that include the header file. Which in case of big projects can mean a lot of headache.

So welcome to const. This can help you get rid of this problem. Since these const variables are actually compiled and not used as in case of header files. There is no need to compile all files using const variables, provided you make use of forward declarations  in the cpp files.

Const does not mean that it does not have any downside. It does have a problem. If you have a large number of declarations they all take some memory and you now understand what it can lead to. But in most cases, const is actually better than #define. But you need to take that call.

Note: The above is based on my understanding. If you think otherwise, do let me know why.

Why you should use forward declarations

Well I am sure you have always heard people telling you to use forward class declaration. I am not sure if you too have thought that what’s the point of it.

Well one best use case is in case of circular dependency. When you have a class A depended on class B and class B also references class A, you will be in a mess including header files in each other. So forward declaration would be a good way out of the mess, provided it meets certain conditions.

Another reason for using forward class declaration is that you will actually speed up the compilation time. Say you include class A as a pointer in class B and for that you have included header file of A in B. Then for any change in A, if it affects B in any manner or not, would lead to compilation of class B as well. This can be a serious pain point in case of large projects. If A has a forward declaration, then A would be compiled(obviously) and then at link time, compiler would make class B aware of A. 

But now the big question is, when can u not use forward declaration. Well answer to that question is very simple. Think like a compiler, in what situations would you be missing an actual declaration.

One of the reason can be when you are using the class as a base class. In that case u cannot determine the base class function  and the compiler cannot check for rules until it finds the declaration.

Another case is when you declare it as a member. In this case compiler has no clue about the size of memory to be allocated for this member. So forward declaration does not work here as well.

At times you want to define functions in the header file itself. In that case, if your function uses a forward declared class, it would throw a compile time error, because it has no clue about its properties.

Also its pretty clear that if you try and create an dynamically allocated object of class, forward declaration would not work if you try and call some function on that object. Again simply because the compiler would have no clue about that.

So friends its important that we use, forward declarations wherever possible. It does make life a lot more simpler, but then one size does not fit all

virtual function -- the key to OOP

I actually never understood this concept until I had to code something in it. It was really awesome to realize what this virtual keyword can do. I actually believe that we should make all our class member functions virtual. Though this may generate some sort of an overhead but I feel that the compiler optimization should take care of it. The main use of this virtual keyword is in cases where we need to reuse certain classes. Often the framework in which we are working in identifies a single base class. so now when this framework wants to make use of the new class, it can do so without any problem. Though the framework calls the same function it would now be able to access the function modified for the new class. Often when we have written code for drawing certain objects on the screen, we would have anticipated line, circle, triangle and a polygon. But later we realize the need for having quadrilaterals and squares also as they are frequently used. So in this case had we made use of a base class shapes, which would have had a virtual function called draw. The framework would just call 'draw' for the entire list of shapes it had. Since the 'draw' is virtual, you can expect the object specific 'draw' to be called. So you can easily extend you library. This is also called factory pattern. But this is not the only pattern to use virtual, there are others also but this example give us a very good reason to why we need virtual function, though there are ways to live without it also. But why use a knife to cut a tree when u have an axe.

Multiparadigm Programming

I had never ever known if any term like that ever existed in this world. But recently I did. Now what it actually means is that instead one we use several programming paradigms to the best of effect while coding.

As Leda designer Tim Budd holds it: The idea of a multiparadigm language is to provide a framework in which programmers can work in a variety of styles, freely intermixing constructs from different paradigms. := (wikipedia)

From what I understood is that C++ provides us means to make use of objects and design patterns as well as give us the ability to make use of Templates. That is to say that we make use of OOPS as well as generic programming paradigms makes C++ really powerful.