we can use normal class as base class , instead abstract

Because you can't create an instance of an abstract class, but it forces you to provide implementations of various methods.

It's sort of a cross between and class and an interface - it defines a contract that the derived class must adhere to, but can also provide a default implementation of basic functions (that an interface can't).

For example, in my I have a FlexPanel, with an abstract FlexControl. The FlexControl derived objects are autosized to fit within the FlexPanel as the user shrinks and enlarges them. The FlexPanel holds a number of controls that are based on FlexControl which provides a common look and feel by providing the title, toolbar, and main display element, allowing the derived class to fill the display with it's information. There is no point in allowing a basic FlexControl because it does not know what kind of information to display. If I was writing a video management app then one FlexControl might hold Videos, another Actors and the third Genres for example.

Because an abstract class allows me to provide the basic implementation of the tool bar and display I can handle (for example) drag and drop in the abstract class, calling the derived class overrided method to actually decide what to do with the dropped files - without re-inventing the wheel and implementing the same basic drag and drop code in each.

Please see the answer by OriginalGriff and an interesting comment by Ed Nutting, who posed a valid interpretation of the problem you have: why making a class abstract when functionally it can be non-abstract?

I can illuminate this matter a bit.

First of all, let's note that you cannot create a non-abstract class if it has abstract methods. This is clear, because it guards a developer from calling a method which does not have implementations. It was possible in early object-oriented systems; typically, an exception was thrown.

You can work-around this by actually implementing all such methods with the keyword virtual instead of abstract. If the body of such method is doing something useful, so there are cases where it should not be overridden, this is quite acceptable and often useful practice. Otherwise, such method is called pseudo-abstract and still can be used, but not so often.

So the question, is, why not making all abstract methods virtual, giving them some implementations, sometimes empty (that is, using pseudo-abstract methods), making all such classes non-abstract and using them where an abstract class could be useful? Here is the answer: functionally, this is quite possible, and, provided you make no mistakes in you code, is fully equivalent to the approach with using abstract classes whenever possible. Why not doing so? Because the approach with using abstract classes whenever possible is always better. Why? "No mistakes" I mentioned above is the key — you cannot guarantee you do not make mistakes like using some base class where the derived class is needed or calling a pseudo-abstract method explicitly where the overridden method is needed — the compiler would not help you to detect your mistake. In other words, the approach based on using those abstract classes is fool-proof. This is the main reason why the abstract classes were introduced.

—SA