I remember years ago, when C++ first became popular, the compilers had restrictions so that certain object oriented features weren’t supported. Are there still common restrictions imposed on object oriented languages? If there are, then what object oriented language / compiler has the most complete coverage of object oriented concepts?
The restrictions in C++ are mostly to do with the incredible difficulty of implementing a compiler which implements all the features required by the C++ standard. I’m not aware of any compiler that is 100% compliant with the standard, although I heard Comeau C++ is getting pretty close.
What, specifically, do you mean? There are lots of philosophies about object oriented languages. E.g., you can’t compare even C++ with Objective-C. Object Pascal goes another way. Visual Basic is in some vague way object oriented.
Do you have an example of what you’re asking?
Seeing as nobody can really agree on what “object-oriented” means, it’s a rather difficult question to answer. Certainly there are lists of features that various environments tend to pick and choose from. Perl has multiple inherritence, polymorphism and dynamic dispatch, but no protected or private data members.[sup]1[/sup]. Java has only single inherritence and does support protected data. And ten thousand other comparisons of this type can be made. This isn’t due to any particular problem with compilers, just language design.
[sup]1. There are neat tricks you can do with closures and lexical scoping to simulate private data in Perl classes, though. [/sup]
The most common definition I’ve seen is that an object-oriented language is one that supports polymorphic variables. However, most people would balk at the suggestion that VB isn’t object oriented, so maybe it’s a fuzzy property.
In addition to the question of what features a language has, there’s also the question of how to handle issues that every language will have to deal with. Say you have classes C -> B -> A, and someone invokes a method on an object of type C that isn’t found in C’s set of methods. Should the compiler start looking in B and move up to A, or should it start looking in A and move down to B? C++ does the former, and (IIRC) Java does the latter.
That doesn’t even touch on object-oriented languages that don’t have classes…
All I know is that I started out in '82 by first learning ‘C’/Unix, and then Pascal, then on to COBOL, BASIC, and PC’s. (Sort of retarted, yes, but you have to learn what is in use when the Military ships you somewhere).
Anyway, to this day I’m still not an OO programmer, even though I’ve been trying since about '87 when Borland released Object Pascal.
I understand the high level concepts about OO. I just seem unable to make the great conceptual leap and it pisses me off to no end.
Sorry for the highjack.
C++ will do the latter if the method is declared virtual and the former if it isn’t.
If the answer was any simpler then that, it just wouldn’t be C++. 
Actually, my brain misfired and I didn’t parse the issue correctly.
I should have said: C++ will do the latter if the method is a pure virtual function. If the method was a regular virtual function, then it would exist in C’s set of methods; if it wasn’t defined at all in C then there would be a compile-time error.
Actually, this is identical to Java’s semantics–just substitute “abstract method” for “pure virtual function.”
ultralifter, were you thinking of the whole “methods aren’t dynamically dispatched by default in C++ but they are in Java” thing?
There’s existing in C’s methods, and there’s being declared there. I meant the latter.
But are you sure about that? When I run the code below in MS VC.net '03, I get the output of B::foo. I’d hate to think something like that was compiler specific.
class Z
{
public:
virtual void foo() = 0;
};
class A : public Z
{
public:
virtual void foo() { printf( "Me = A.
" ); }
};
class B : public A
{
public:
virtual void foo() { printf( "Me = B.
" ); }
};
class C : public B
{
};
int main()
{
C c;
c.foo();
return 0;
}
I’m not incredibly familiar with Java, so the default dynamic dispatch is new to me. Does that mean that no method ever gets deadstripped by the linker?
Your example makes it MUCH clearer–when you first wrote “C → B → A” I parsed that as “C, it’s subclass B, and B’s subclass A”. I’m too used to diagrams of trees with the root node at the top.
Here’s a Java equivalent to your C++ example. When I run it, it B’s foo is what gets called:
abstract class Z {
abstract public void foo();
}
class A extends Z {
public void foo() {
System.out.println("Me = A.");
}
}
class B extends A {
public void foo() {
System.out.println("Me = B.");
}
}
class C extends B {
}
public class Test {
public static void main(String[] args) {
C c = new C();
c.foo();
}
}
Linker? What’s that? 
A .class file (the bytecode equivalent of an object file) includes all the methods of a class. You run a Java program by starting up a VM and telling it the name of the class whose “main” method you wish to invoke. It then loads the definitions of the classes that the code in “main” requires on an as-needed basis from .class files (or some package containing them).
And, come to think of it, every implementation of Java (even ones that compile straight-to-native code), would have to keep all (public) methods accesible in perpetuity in all programs: Java’s “reflection” facilities allow you to instantiate objects and call methods that aren’t actually mentioned in the source code. E.g.:
...
void callArbitraryMethod(String nameOfClass, String nameOfMethod) throws Exception {
Class theClass = Class.forName(nameOfClass);
Object theObject = theClass.getConstructor(null).newInstance(null);
Method theMethod = theClass.getMethod(nameOfMethod);
theMethod.invoke(theMethod, theObject);
}
...
This is getting a bit far off topic…
The point is, aside from the issue of whether a language has a particular feature, there are also often choices about how to make it behave, so that muddies the question a little bit.
So there are definitely still restrictions out there, or at least implementation nuances. I don’t know, I find a lot of C++ and Java to be very clumsy and esoteric, but I suppose I will always feel that way being an assembly language programmer at heart.
It took me several attempts, it finally clicked after a week or so of immersing myself in C# I found OO to be one of those things that only makes sense once you already understand it.
In C you are used to doing things directly say:
bash_nail_into_plank(nail_ptr, plank_ptr);
The OO version will look more like:
h = new Hammer;
n = new Nail;
p = new Plank;
h.bashIn( n, p );
Which initially looks like a lot of palaver. What it really means is that -with luck- someone has already defined the Hammer, Nail and Plank classes and you just pull them off the shelf and use them rather than having to detail what to do in your bash_nail_into_plank() function.
Fiddlesticks. Should be:
Hammer h = new Hammer**();
Nail n = new Nail();
Plank p = new Plank()**;
Guess I’m rusty, they keep me busy with C and PL/SQL, haven’t done OO in months 
In C++, both Hammer h = new Hammer; and Hammer h = new Hammer(); would compile. Hammer h(); is not legal because the compiler thinks it’s a function definition.
If you’re having trouble “Getting” OOP, I recommend complete immersion.
Download Squeak, get a good book on squeak, and become a Smalltalk hacker. You’ll instantly be way cooler then people who use Java or C++ for OOP.
Nitpick:
I don’t think either of those would compile, 'cause h isn’t declared to be a pointer?
Also, wouldn’t Hammer h() compile just fine? It would stack-allocate an instance of h and invoke its zero-arg constructor.
mattmorgan you getting all this
Maybe some of these variations will compile. This is (part of) the problem of trying to learn OO though C++, it is very hard to see the wood for the ~::<<ing trees.
Seconded. I would put a beginning programmer or someone new to OOP on C++. Unless I really, really hated them.
If you’re new to OOP (or even new to programming), I’d seriously look at Squeak.
If its too esoteric for you, I’d say even Python would be a better language to cut your teeth on.
Doh! I would NEVER put a begginner on C++.
I left out an important word, there.