Which of these statements about objects is true?

Question

Considering this:

struct { int x; } ix; struct A { A() {}; int x; }; A ia; 

Which one is correct?

 a. ix is an object b. ia is an object c. both are objects d. both are not objects. 

Answer 1

Many of these answers ignored the C ++ tag. In C ++, "an object is a storage area. [Note: a function is not an object, regardless of whether or not it occupies storage in the same way that objects do it.]" (C ++ Standard, 1.8 / 1).

If the homework question is related to C ++, then no other definition of the object is applicable, even “nothing is visible or tangible and relatively stable in form” (dictionary.reference.com). He does not ask for your opinion on the principles of OOP, he does ask if ix and ia are variables.

Since this is homework, I won’t tell you the answer, but note that struct { int x; } ix; struct { int x; } ix; - this is not the same as struct ix { int x; }; struct ix { int x; }; .

On the other hand, if your homework is OOP, then beat yourself out with any definition that your lecturer gave you an “object”. Since I don’t know what it is, I can’t tell you which answer it will consider correct ...

Answer 2

Given the C++ tag, the answer is pretty much "take your pick."

The C standard defines an object as a value (essentially) of everything that has an address, including all instances of native / primitive types (for example, int). Since C ++ is heavily dependent on C, this definition still has some weight in C ++. By this definition, essentially, each variable is an object, as well as several other things (for example, character string literals, dynamically allocated memory blocks).

In Smalltalk (at the opposite extreme), the answer would be none of them - this is an object - an object never has public data. Its behavior is defined entirely in terms of responses to messages.

Answer 3

The word “object” is a rather ambiguous specification without any other context, but in general, objects have identity, behavior, and state.

Neither ix nor ia have all three; ix fails because he lacks identity or behavior, and ia fails because he does not have behavior. Both are essentially just a drop of data.

Answer 4

These questions cannot be answered without further clarification. The question is marked with C ++, which means that the language is supposedly C ++.

In this case, if the declarations are made in the namespace area, the ix declaration is invalid. It is not allowed to use an unnamed class type (which does not have a binding) to declare an object with external connection. ix ad will work in local area

 void foo() { struct { int x; } ix; // OK, no linkage } 

It may also work if ix was declared internally in the namespace

 static struct { int x; } ix; // OK? Internal linkage? 

although I personally think that this should also have been poorly formed (Como somehow allows this).

But the external namespace declaration is poorly formed

 // In namespace scope struct { int x; } ix; // ERROR 

So, if the scope of the namespace is assumed, and if the above declarations should be considered as a single code, then there are no meaningful answers to these questions. All code is simply invalid. It's pointless. This is not C ++.

Otherwise, if ix declared without binding (local) or internally, then ix is an object.

As for ia , it is an object, regardless of where it is declared, since the class type is named.

Note that the concept of an object in C ++ has nothing to do with classes. An object in C ++ is a region of memory (memory). For example, a variable of type int is an object in C ++.

Added later: A little about the legitimacy of the ix declaration - an interesting problem. Apparently, C ++ 98 allowed such declarations that were outlawed in DR # 132 . However, later the offer was rejected (for a rather strange reason), and everything remained as it is. However, Comeau Online refuses to accept an object declaration with an external connection with an unnamed type (internal communication is OK). Perhaps this could be a formal mistake in the Como compiler (not that I complained about it).

Added even later: Oh, I see that there is still a later DR # 389 , which finally prohibits such ads, but the status of this DR is still CD1.

Answer 5

In C ++, there are two commonly used definitions of "object."

One of them is official in accordance with the C ++ standard and says that everything that has a dedicated storage for it is an object. A structure is an object, int is an object, bool is an object, a pointer is an object, a string literal is an object, etc. By this definition, ix , ia and x are all objects. But this is probably not what your teacher had in mind. You need to be a little language lawyer to use this definition, and it is not so widely known among "average" C ++ users. It is also not a very relevant definition for someone just learning a language.

The definition that is likely to be used refers to an object in an object-oriented sense. Here (at least in the C ++ language family) an object is usually an instance of a class.

Which leaves the following obvious question: Is the instance of the structure also an object? It depends. In C ++, the class and structure are essentially the same, so semantically, yes, but technically you are not using the class keyword, so it’s probably syntactically not.

In short: this is a stupid and poorly formulated question, and only you know what your teacher means or wants to hear, because you are the one who attended classes, not us. All we can do is guess that it defines a class.

Answer 6

By my definition, I would say that an object has properties and methods. Both nouns and verbs.

You can kick the ball, you can invade the country, and you can eat, milk or punch a cow. Therefore, these are objects.

You may have a data structure that represents the properties of a ball (radius), country (population), or cow (daily milk output in liters), but this data structure does not represent an object in my mind until you tell me how to handle the relevant behaviors .

I understand that this definition may not work 100% of the time, but it is close enough for my needs.

Answer 7

Technically, an object is an instance of a class, but the true usefulness of objects lies in their ability to encapsulate information and help in the design of systems. This is an analysis tool.

Answer 8

An object is an instnace type (whether it be a POD or a class).

This way you can extract the address of the object. All objects occupy at least one byte. The reason for this is that you do not need to add special code to process objects with zero size, because each object in memory has a given address (by creating at least one byte in total, the compiler will automatically have a unique address for each object )

 int main() { struct { int x; } ix; struct A { A() {}; int x; }; A ia; ix.x = 5; // Assigned a value. // Thus it has state and thus is an object. ia.x = 6; // Assigned a value. } 

So they are both objects.

Answer 9

The real answer is: "e. Anyone who writes such code should exercise to improve their readability." Okay, that was a joke.

This question is not so complicated. But elsewhere, I have seen programming tests written especially difficult to see if you can solve the puzzles. This is completely pointless because the code that is such a complex should not and usually does not exist. If it is hard to read, this is poorly written code.

Remember that the code is not written for computers. The code is written for the next developer after you read and understand.

And do not write the code so that it works. This is not a high enough standard. The worst trash in the world will work, but it's a nightmare to fix or update.