Well, if I get too far into this topic, I'll probably end
up demonstrating just how much I DON'T know about C#...
LOL But here goes my best "layman's" explanation:
Computer programming languages, at their lowest levels,
all operate on the same basic principles, and even teh
most complex and intriguing constructs are still
represented by some faily basic data types, coupled with
some pretty slick techniques for maknig it all work. Such
is the case with OOP.
A lot goes on under the covers to make things like
inheritance and virtual fxns to work. For example, when
you have base class a, with virtual fxn f1(), and then
class's b & c each inherit from a, and then override f1()
with their own versions, how does C++ know, when you
create p (a pointer to an "a"), but point it at a "b" or
a "c" (a derrived type of an "a"), how does C++ know that
it's suposed to call b::f1() and not a::f1() if the only
thing that a pointer to an "a" contains is information
about an "a", not about "b"'s "c"'s or any other types?
The answer is that under the covers, it creates something
called a vtable, which I won't get into explaining
(because I'd probably get it wrong anyway). It uses the
vtable, completely invisibly to you, to keep track of the
most-derrived versions of virtual fxns.
Enough about C++....
While may say that C# "doesn't use pointer", in fact it
DOES, but it simply wraps them up in Java-like
references. This, among other features of the language,
affords C# the ability to safely make certain kinds of
assumptions about objects and data types that were
programming landmines in C++.
C++, through multiple inheritance, allows one to
conceptually do some pretty bizarre things which, in C#
would have undefined results. For example, consider a C++
base class a, with derrived classes b and c (that is, b
and c each inherit from a.) Now, consider a fourth class,
d, with multiple parent classes b and c or, to look at it
in a different perspective, d has a b which has an a, but
d also has a c which also has an a.... Hmmm.... One "a",
but two instances of it? Or do they share them? Such are
the problems of mutiple inheritance. The structure and
syntax of C++ is such that the behavior of this type of
class is actually defined within the language. C# trades
off some of that (dare I say useless... or at least
dangerous?) flexibility of C++ for a more practical and
streamlined approach. Yes, you do lose multiple
inheritance but, in reality, there are generally more
concise, and certainly safer ways to accomplish the same
tasks. A muliple-inheritance type of object model does
not particularly fit the more contemporary n-tier data and
process model of modern applications, for which C# was
created and, hence, it was determined to be dispensible.
The concept of an inerface in C# does nto syntactically
nor structurally contribute to the language. Instead,
think of interfaces as more of a "contract" that
says, "Any classes that look like this WILL IMPLEMENT
these functions and properties". In that sense,
interfaces are something akin to the MFC pure virtual base
classes, whose sole existence was simply to provide a
foundation upon which to build other classes. Interfaces
allow you to do pertty much the same thing. By creating
an interface, and then including that interface in
subsequent clases, you contractually commit yuorself to
includign all of the prototyped functions in the
interface, eliminating the possibility of forgetting a
crucial behavior or property.
I apologize if some of my answer is convoluded or nto 100%
technically accurate, but hopefully that at least gives
you a fwe things to think about. When I was first exposed
to C#, as a C++ programmer, I was not impressed. I felt
like someone was really sore that Java was finally proven
to be an inferior language, and this was their attempt to
get even with us (LOL). I have recognized since then,
however that while C++ still remains far and above a
superior language for programming, particularly at the
system level, C# marries the best concepts of OOP,
Windows, and the web, with the structure of C++ to provide
a superior design platform for .NET style tiered
applications.
Jim