> I care in this case because its a discussion of C++'s OOP abilities.

Which you have yet to justify as anything less than "I don't like typing the asterisk", without explaining what the real problem is.

I program in CL most days and I don't like typing the parenthesis. As soon as someone comes up with a way for me to get some of the flexibility I get out of CL without doing it I'll be a happy guy. Until then, I keep my bitching by-and-large to myself.

> Especially in the context I used it. I used the word evaluate because Sun's Java docs used it.

No they don't you liar. I challenge you to find a place on sun.com that says "A reference variable is one that evaluates to a pointer."

> Are you saying that if I passed in an object Baz in VB.Net to
> (snippets omitted)

No.

I said:

Sub Foo(ByRef X As String)
    X = "Bar"
End Sub
...
Dim Y
Foo(Y)
Print(Y)

and:

void Foo(string& X) {
    X = *new string("Bar");
}
...
    string Y;
    Foo(Y);
    cout << Y << endl;

are equivalent, and that this is what a C++ programmer calls a reference. The following:

Sub Foo(ByVal X As String)
    X = "Bar"
End Sub

and:

void Foo(string* X) {
    X = new string("Bar");
}

are also equivalent; they do nothing except waste memory and time because the above change to "X" doesn't affect the caller of Foo. These are what C++ programmers call pointers and what VB programmers call Objects. Some very misguided tutorials refer to these as reference types. Those tutorials are usually written by non-programmers.

> I do and you need to remember I am focusing on its OOP abilities. I understand it is limited in many respects by its compatibility with C and it other programming paradigms. This is what I am pointing out.

You have no idea what you're talking about. CLOS, Smalltalk and Simula pioneered OOP in three completely separate respects: method resolution, message passing and data hiding. Visual basic is about as object-oriented as a bucket of rocks; barely meeting some very loose definition of the term "Object".

C++ uses objects in the simula-sense. Java uses them in the smalltalk-sense. Saying one is more object-oriented than the other is retarded.

C++ has a lot of problems, but being "less object oriented than visual basic" is a crap load of shit.

> I would say there are problems with the way its implemented most of the time such as in C++.

And that's because you matter how?

Either justify a broad statement like "C++'s multiple inheritence is fucking evil." or shut the fuck up, and at this point I'd prefer the latter; you don't seem to have anything interesting to add.

> After working with OOP languages that don't support it, I find that it allows for better class creation.

You're wrong.

> I know there are times I wish I could use it but am much happier with the heirarchy after not doing so.

Double wrong. You've never used it before. You're a big fat liar.

> I was not claiming C++ is the only language with multiple inheirtence. But comparing it to Python is a little odd as Python's implementation is limited (but still troublesome as I feel all implementaiton of multiple inhieritence are).

Liar liar pants on fire.

> I have found the members of the heirarchy to be more extensible down the line instead of trying to cram it all in to the fewest number of classes.

Wronger than wrong.

Multiple inheritence creates more classes, not less. It gives you the ability to hook method implemention into your interface classes, and specifies a method resolution order for interacting with that data.

It's not evil, but it is surprising if your mixins interact with local data. This is why C++ programmers recommend you don't do that.