Hacker News new | ask | show | jobs
by dpark 208 days ago
I feel this is a case of using the same word to mean something different. C++ “object” here seems to mean something more akin to “can be allocated and stuffed into an array” than a Smalltalk-type object.

i.e. C++ primitive types are defined to be objects but do not fit into a traditional object-oriented definition of “object”.

1 comments

Yes, many people believe that C++ isn't really "object-oriented", including famously Alan Kay, the inventor of the term. Nevertheless, that is the definition of "object" in C++, and Java is based on C++, Smalltalk, and Cedar, and makes an "object"/"primitive" distinction that C++, Smalltalk, and Cedar do not, so "Java [did something] by deciding everything must be an object" is exactly backwards.
I'm not sure who invented "object oriented", but objects were invented by Simula in 1967 (or before, but first released then?) and that is where C++ takes the term from. Smalltalk-80 did some interesting things on top of objects that allow for object oriented programming.

In any case, Alan Kay is constantly clear that object oriented programming is about messages, which you can do in C++ in a number of ways. (I'm not sure exactly what Alan Kay means here, but it appears to exclude function calls, but would allow QT signal/slots)

The specific thing you can do in Smalltalk (or Ruby, Python, Objective-C, Erights E, or JS) that you can't do in C++ (even Qt C++, and not Simula either) is define a proxy class you can call arbitrary methods on, so that it can, for example, forward the method call to another object across the network, or deserialize an object stored on disk, or simply log all the methods called on a given object.

This is because, conceptually, the object has total freedom to handle the message it was sent however it sees fit. Even if it's never heard of the method name before.

You can do that in C++ too - it is just a lot of manual work. Those other languages just hide (or make easy) all the work needed to do that. There are trade offs though - just because you can in C++ doesn't mean you should: C++ is best where the performance cost of that is unacceptable.
No, in C++ it's literally impossible. The language provides no way to define a proxy class you can call arbitrary methods on. You have to generate a fresh proxy class every time you have a new abstract base class you want to interpose, either by hand, with a macro processor, or with run-time code generation. There's no language mechanism to compile code that calls .fhqwhgads() successfully on a class that doesn't have a .fhqwhgads() method declared.
you don't call fhqwhgads() on your proxy class though. You call runFunction("fhqwhgads") and it all compiles - the proxy class then string matches on the arguments. Of course depending on what you want to do it can be a lot more complex. That is do manually what other languages do for you automatically under the hood.

Again, this is not something you should do, but you can.

C++ standard gets the definition of object from the C standard, i.e. a bunch of memory with a type.

Nothing to do with the objects of OOP.

To be clear, I’m not trying to pick at whether or not C++ is “really object oriented”.

What I’m saying is that the discrepancy between primitives in C++ and Java is entirely one of definition. Java didn’t actually change this. Java just admitted that “objects” that don’t behave like objects aren’t.

On the contrary, Java objects are very different from C++ objects, precisely because they lack a lot of the "primitive-like" features of C++ objects such as copying, embedding as fields, and embedding in arrays. (I'm tempted to mention operator overloading, but that's just syntactic sugar.)
Java differs from C++ in an endless number of ways.

What I’m saying is that in both C++ and Java, there are a set of primitive types that do not participate in the “object-orientedness”. C++ primitives do not have class definitions and cannot be the base of any class. This is very much like Java where primitives exist outside the object system.

If the C++ standard used the term “entities” instead of “objects” I don’t think this would even be a point of discussion.

It's not some minor point of terminology.

The entire design of C++ is built around eliminating all distinctions between primitive "entities" and user-defined "entities" in a way that Java just isn't. It's true that you can't inherit from integers, but that's one of very few differences. User-defined "entities" don't (necessarily) have vtables, don't have to be heap-allocated, can overload operators, can prevent subclassing, don't necessarily inherit from a common base class, etc.

C++'s strange definition of "object" is a natural result of this pervasive design objective, but changing the terminology to "entity" wouldn't change it.

> The entire design of C++ is built around eliminating all distinctions between primitive "entities" and user-defined "entities"

If the intent was to erase all distinction between built-in and user-defined entities then making the primitive types unable to participate in object hierarchies was a pretty big oversight.

But at this point I think we’re talking past each other. Yes, in Java objects are more distinct from primitives than in C++. But also yes, in C++ there is a special group of “objects” that are special and are notably distinct from the rest of the object system, very much like Java.