8 ms·
Technically C has objects. That's any chunk of memory with a type, size, alignment and duration. Incidentally C++ has exactly the same definition. Just being p
by gpderetta 4y ago
Technically C has objects. That's any chunk of memory with a type, size, alignment and duration. Incidentally C++ has exactly the same definition.
Just being pedantic, nothing to see here.
- Karellen 4y ago> That's any chunk of memory with a type, size, alignment and duration. Isn't that just "a variable"?
- gpderetta 4y agoint * int_ptr = malloc(sizeof(int)); int_ptr is a variable (and also an object), the pointed to memory is an object but not a variable.
- smcl 4y agoI think the point is that the C standard (or K&R, or both? I forget) repeatedly refers to "objects", and uses the word differently than we're used to in OOP
- oriolid 4y agoC++ has syntax for adding functions to objects and type system support for deriving object types from other object types and overriding those member functions. There are some who consider these a rather important thing.
- gpderetta 4y agoI'm just saying that, pedantically, "object" is a term of art in C and C++ which has little to do with the typical OOP definition of object.
- tialaramex 4y agoIndeed. For example the language needs a notion of these objects having some particular type, and they need to be able to have lifetimes, so that we can talk about ideas like type punning (legal in C in some ways, not legal in C++), about aliasing rules, and about provenance. If you don't want to do any of this, you can't achieve the performance from high level software (where "high level" here means C rather than machine code) that people have come to expect and demand.
- zozbot234 4y agoThese are pretty much the same thing, though. The C-specific definition of "object" was devised to make C usable with hardware architectures like segmented memory, which was being marketed as "OOP down to the hardware" back in the 1980s. The fact that the term "object" is used here is not a coincidence.
- oriolid 4y agoJust out of curiosity, what is the typical OOP definition of object?
- gpderetta 4y agoAh, that's a trick question. There is no typical OOP definition of object. I used to think that only aspect everybody agrees on is late binding, but some people consider traits-like static binding a form of OOP.
- oriolid 4y agoWell, you brought up the subject :) I think it's a bit intellectually dishonest to appeal to typical OOP definition when there isn't one (except that your language isn't true OOP but my language, I won't tell which one, is). And there are quite a few different definitions of late binding too.
- deleted 4y ago[deleted]
- gpderetta 4y agoThere are multiple contradicting definitions of OOP, but I don't know any that would include C POD types and primitives.
- oriolid 4y agoThe original claim was that C++ "objects" and C PODs and primitives are the same. It's a rather odd claim, and the questions whether C++ "objects" are true objects, there is even a definition of true object, or was object oriented programming a good idea to begin with, don't seem to be closely related.
- gpderetta 4y agoThe standard definition definition of Object in C++ is the same as the definition of Object in C because the standard says so: https://en.cppreference.com/w/cpp/language/object https://en.cppreference.com/w/cpp/language/object . Is not a problem of interpretation. It is just that the C standard uses the term object for just a bunch of memory (with a type) and the C++ standard does so too. Nothing to do with objects in the OOP sense.