D
Dylan
thanks
J
Jacques Labuschagne
Dylan said:
An object is an instance of a type.
Jacques.
J
Jonathan Turkanis
It's like the difference between a boxer and a weight class, or an employee and
a job description.
Jonathan
a job description.
Jonathan
R
Rafal 'Raf256' Maj
(e-mail address removed)
The same as between "a humen" and "the Dylan".
The same as between "a humen" and "the Dylan".
R
Rafal 'Raf256' Maj
(e-mail address removed)
typo... *human*
typo... *human*
J
Jon Bell
object :: type == cookie :: cookie-cutter
D
Dave O'Hearn
What's the difference between "int" and "5"?
The question is rather vague. I don't know if it has an answer.
Philosophers have debated this stuff for thousands of years and show no
sign of stopping soon.
When inheritence comes in, it is important not to confuse the different
relationships. The type-instance relationship is not the same as the
base-derived relationship. Sometimes people will get sloppy and use the
phrase "is a" to describe all these relationships, like 'file' is an
fstream, fstream is an ifstream, etc. They are two different things.
The question is rather vague. I don't know if it has an answer.
Philosophers have debated this stuff for thousands of years and show no
sign of stopping soon.
When inheritence comes in, it is important not to confuse the different
relationships. The type-instance relationship is not the same as the
base-derived relationship. Sometimes people will get sloppy and use the
phrase "is a" to describe all these relationships, like 'file' is an
fstream, fstream is an ifstream, etc. They are two different things.
H
Howard
Dave O'Hearn said:
They have? I don't recall any such discussions. For example, "what's the
difference between 'human" and "Bob'?" One is a description/definition, the
other names a specific instance.
I see no confusion (or vagueness) here at all. An object is an instance of
a type. A type is a description (a declaration), which follows very cleary
defined rules in the C++ language. There are built-in types and
user-defined types. Since this question is asked in the C++ language
newsgoup, it seems pretty clear that these are the definitions asked for.
That's a rather confusing analogy. The "is a" relationship described public
inheritance, only. What this has to do with types and objects is, well,
nothing as far as I can see...?
No offense intended, Dave, but I think you're just going to confuse the
newbie here. Philosophy and C++ don't mix very well, in my opinion.
-Howard
J
jeffc
Howard said:
Agreed. "Is a" makes sense in both contexts, even though it means 2 different
things.
D
Dave O'Hearn
Howard said:
Exactly. I see no confusion either, but the OP is confused. How?
No offense intended, Dave, but I think you're just going to confuse
the newbie here. Philosophy and C++ don't mix very well, in my
opinion.
Almost. I was trying to show the OP that his question was confusing,
not to confuse the OP. The difference between a type and an object
should be obvious to everyone, no technical background required. If it
isn't obvious, there is probably some confusion in terms. But I can't
guess what that confusion is. It would help if he asked a more specific
question about objects and types. (Un)fortunately, if this is a
homework, he may not be able to.
D
Dave O'Hearn
jeffc said:
The FAQ has a whole section on confusions that arise from using "is a"
to describe the derived-base relationship.
http://www.parashift.com/c++-faq-lite/proper-inheritance.html
The FAQ recommends "is substituable for", and describes it in terms of
contracts.
P
Paavo Helde
An object takes up space in computer memory at runtime, a type does not.
hth
Paavo
hth
Paavo
H
Howard
Paavo Helde said:
I don't think that's a good description, or even accurate. Computer memory
is doled out by the operating system, and may be largely out of the control
of the code as to exactly when and where it is allocated.
But, regardless of the memory model used, what about member functions and
static member data? Both of those exist independent of instances of a class
(i.e., objects), since they are shared by all instances. So simply
declaring a class or struct type may result in memory allocation for those
members, separate from any instanciated objects of that type.
-Howard
J
Jonathan Mcdougall
Howard said:
Who said that?
Jonathan
J
jeffc
Dave O'Hearn said:
I really see no reason for that, when it's perfectly natural in our regular
speech to discuss it as is. A dog is an animal. Fido is a dog. What could be
simpler? We don't go around saying "a dog is substitutable for an animal."
J
jeffc
Jonathan Mcdougall said:
Who said what? What he just said? Or that static class data members take
space?
H
Howard
Jonathan Mcdougall said:
Are you suggesting I'm wrong? Don't you agree that static data takes up
space, and that that space is distinct from the space used by individual
instances? Same with the code for the functions, right? It exists in one
place, distinct from any individual instance. All instances of the class or
struct refer to that same location when calling a given member function.
Thus, the static data and the member functions take up space (or at least
MAY take up space), regardless of whether there are any objects (instances)
of that class or struct currently in memory. So... I'm saying that
distinguishing between types and objects by whether they consume memory is
(at the least) misleading.
-Howard
J
Jonathan Mcdougall
jeffc said:
Who said what he just said?
Obviously, yes.
That's one of the things he said, yes.
Jonathan
E
E. Robert Tisdale
Dylan said:
A type is:
1. the set of all values that an object of a given type can have
together with
2. the set of operations that can be performed on an object
of that type.
An object is an instance of some type --
something that does (or at least could) occupy computer memory.
D
Dave O'Hearn
Howard said:
It's not that far off. With "storage" instead of "computer memory at
runtime", it is correct. "Object" is defined as "a region of storage",
and the Standard never defines "storage".
Since I just checked the Standard, I might as well add that it doesn't
define "type". In 3.9/1 it says that "Types describe objects (1.8),
references (8.3.2), or functions (8.3.5)." Then if you chase down the
reference in 1.8/1, you get "An object has a 'type' (3.9). The term
'object type' refers to the type with which the object is created."
That seems to be all there is.