Re: which is faster : C or C++?

Primarily what I love about C++ is the STL. It has never given me more pleasure to see a library in action. Granted that the organisation of the STL reflects the fact that there were multiple design heads involved but yet it's the most beautiful piece of code I have ever seen.

I dunno if I can say it's the most beautiful piece of code (I haven't actually read the source), but I fully agree with you that it's a fantastic library. The way they have designed it, with such a wonderful separation of containers, iterators, algorithms and functions is quite brilliant.

Whats even better about C++ is it doesn't force a programming paradigm on you, it lets you design your solution in any way you wish, so if you want to have a C style program, well just go right ahead!!

Agree again. The best thing about C++ is that it gives the programmer a lot of freedom. It supports procedural, object oriented and generic programming. I don't think there's any other language that does that. Microsoft is also fully integrating it into .NET in the next version of their compiler, so it will support garbage collection and will have access to the Base Class Library. Just another way C++ can be used.

.NET and Java are supporting generics in their newest versions. Naturally they are looking at C++ for ideas. But I feel the won't be able to come up with as elegant a solution as the STL because they only support OOP. Some proposed functionality I've read about for the next version of .NET collections is quite ugly. Like including same algorithm functionality in each collection. There is no iterator abstraction, so each collection in a way is different. It's a dilema for them. How to support all the functionality in an OOP way. It'll be interesting to see what they finally come up with. Haven't seen how Java handles it.

Always remember that C++ was meant to be a better and "safer" C.

The general trend it seems is that all the guru's (i.e. Bjarne and friends) are encouraging to make use of more abstractions and use the STL in the name of convenience, maintenance and safety. For ex. Go for vectors instead of straight arrays, Use as little manual memory management as possible or if you need to play with pointers go for some of the safe versions available through STL and boost. I took a course on generic programming where we used the STL. We hardly new'd and delete'd. It's a testament to C++'s flexibility. It's able to adapt to the evolving paradigms.

virtual functions are implemented using a lookup table that gives you a function pointer for each derived class type. Thus, these kind of functions can simply not be inlined

If a compiler is smart enough, it should be able to inline some calls to virtual functions. There's a way to explicity (statically) call virtual functions...

class Base
{
     public:
          virtual void Function1()
          {
               cout >> "Base::Function1";
          }
};

class Derived : public Base
{
     public:
          virtual void Function1()
          {
               cout >> "Derived::Function1";
          }

          void Function2()
          {
               Base::Function1(); // can be inlined
          }
};

Correct me if I'm wrong about this fact. Or if this particular example is wrong.

I think the guys designing and implementing C++ were as concerned about performance as anyone. They did everything possible for limited performance hits. I don't think anyone can fault them. Dinesh had recommended a book long back called "The C++ Object Model". It gives you a good idea about how they implemented a lot of the features. Virtual functions and polymorphism in general is discussed at length. And they give a lot of examples in CFront. So you can see what C code is generated.