By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,958 Members | 1,156 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,958 IT Pros & Developers. It's quick & easy.

[Q]Object:formal definition and description?

P: n/a
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What, if
any, associated semantics are shared by all objects? That part seems to go
beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #1
Share this Question
Share on Google+
44 Replies


P: n/a
Steven T. Hatton wrote:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What, if
any, associated semantics are shared by all objects? That part seems to go
beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?

No, I know of no resource, but the statement "a region of storage with
associated semantics" is sorta kinda equivalent to "data with operations
related to that data".

Does that help?

mark

Jul 22 '05 #2

P: n/a
Steven T. Hatton wrote:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What, if
any, associated semantics are shared by all objects? That part seems to go
beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?

No, I know of no resource, but the statement "a region of storage with
associated semantics" is sorta kinda equivalent to "data with operations
related to that data".

Does that help?

mark

Jul 22 '05 #3

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed to
ask it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"?
Associated semantics define behaviour (probably a bad word) in some
context.

For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.
I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".

Does anybody know of a resource that discusses (focuses on) this
topic?


A technical dictionary?
comp.object newsgroup?

Regards.
Jul 22 '05 #4

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed to
ask it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"?
Associated semantics define behaviour (probably a bad word) in some
context.

For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.
I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".

Does anybody know of a resource that discusses (focuses on) this
topic?


A technical dictionary?
comp.object newsgroup?

Regards.
Jul 22 '05 #5

P: n/a
bartek wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed to
ask it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"?
Associated semantics define behaviour (probably a bad word) in some
context.


I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics? Not without a lot
more thinking than I've already done. I suspect scope, name resolution,
declaration, initialization, definition (yes I know), conversion, duration,
possible operations, referencing, etc. Would all be part of the semantics
of an object of type int. But to provide a comprehensive, orthogonal and
clearly specifying list of semantics would be quite a challenge.
For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.


I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".


I actually was faced with the interesting situation of meeting a reasonably
intelligent person who did *not* understand the concept that the earth is
spherical. He was from Eritrea, and had very little formal education. I
explained it to him in terms of Newtonian gravitation (without explicit
reference to the inverse-square force law.) But the Earth isn't exactly
spherical, and that takes a bit of explaining, as well. Nonetheless, I can
begin with simple concepts of classical physics and come up with a very
good approximation to what the shape of the Earth should be, and find that
it matches the observed reality. IOW, the question about the Earth is not
quite as simple as it seems at first, but it is answerable on the basis of
reasonably sound first principles.

Part of what I'm trying to get at is how much of the definition of the
concept of object is defined explicitly by the Standard, and how much is
defined by consequence of definitions which associate semantics with
specific categories of objects as 'side effects'? What /are/ the first
principles?
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #6

P: n/a
bartek wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed to
ask it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"?
Associated semantics define behaviour (probably a bad word) in some
context.


I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics? Not without a lot
more thinking than I've already done. I suspect scope, name resolution,
declaration, initialization, definition (yes I know), conversion, duration,
possible operations, referencing, etc. Would all be part of the semantics
of an object of type int. But to provide a comprehensive, orthogonal and
clearly specifying list of semantics would be quite a challenge.
For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.


I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".


I actually was faced with the interesting situation of meeting a reasonably
intelligent person who did *not* understand the concept that the earth is
spherical. He was from Eritrea, and had very little formal education. I
explained it to him in terms of Newtonian gravitation (without explicit
reference to the inverse-square force law.) But the Earth isn't exactly
spherical, and that takes a bit of explaining, as well. Nonetheless, I can
begin with simple concepts of classical physics and come up with a very
good approximation to what the shape of the Earth should be, and find that
it matches the observed reality. IOW, the question about the Earth is not
quite as simple as it seems at first, but it is answerable on the basis of
reasonably sound first principles.

Part of what I'm trying to get at is how much of the definition of the
concept of object is defined explicitly by the Standard, and how much is
defined by consequence of definitions which associate semantics with
specific categories of objects as 'side effects'? What /are/ the first
principles?
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #7

P: n/a
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

What /are/ the first principles?


Think about this: in mathematics, which is thought of as fairly strict and
well-defined, perhaps the most well-defined of all possible fields, nobody can
agree on even what _kind_ of answers that question has. Yet mathematicians
can collaborate and can (to good approximation) understand each other's good
work, although not the bad. It's the same way in programming, only more so.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #8

P: n/a
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

What /are/ the first principles?


Think about this: in mathematics, which is thought of as fairly strict and
well-defined, perhaps the most well-defined of all possible fields, nobody can
agree on even what _kind_ of answers that question has. Yet mathematicians
can collaborate and can (to good approximation) understand each other's good
work, although not the bad. It's the same way in programming, only more so.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #9

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:4I********************@speakeasy.net:
bartek wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed
to ask it. The FAQ says an object is "A region of storage with
associated semantics." OK, what exactly is meant by "associated
semantics"?


Associated semantics define behaviour (probably a bad word) in some
context.


I'd accept something like how it is influenced by or influences the
outcome of programmatic operations. Maybe. Now, could I take an
example such as int, and provide an itemized list of related
semantics? Not without a lot more thinking than I've already done. I
suspect scope, name resolution, declaration, initialization,
definition (yes I know), conversion, duration, possible operations,
referencing, etc. Would all be part of the semantics of an object of
type int. But to provide a comprehensive, orthogonal and clearly
specifying list of semantics would be quite a challenge.
For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.


I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".


I actually was faced with the interesting situation of meeting a
reasonably intelligent person who did *not* understand the concept
that the earth is spherical. He was from Eritrea, and had very little
formal education. I explained it to him in terms of Newtonian
gravitation (without explicit reference to the inverse-square force
law.) But the Earth isn't exactly spherical, and that takes a bit of
explaining, as well. Nonetheless, I can begin with simple concepts of
classical physics and come up with a very good approximation to what
the shape of the Earth should be, and find that it matches the
observed reality. IOW, the question about the Earth is not quite as
simple as it seems at first, but it is answerable on the basis of
reasonably sound first principles.

Part of what I'm trying to get at is how much of the definition of the
concept of object is defined explicitly by the Standard, and how much
is defined by consequence of definitions which associate semantics
with specific categories of objects as 'side effects'? What /are/ the
first principles?


Because we see the world as somewhat "object oriented" ?

Sorry, perhaps because I look at C++ from a rather practical standpoint,
I can't imagine myself going into so much formal analysis and intricate
details, which actually bring no significant conclusions. I tend to take
it as it is.

I admire your quest for knowledge, and I'm jealous for the amounts of
spare time. :)

Jul 22 '05 #10

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:4I********************@speakeasy.net:
bartek wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in
news:oM********************@speakeasy.net:
This may seem like such a simple question, I should be embarrassed
to ask it. The FAQ says an object is "A region of storage with
associated semantics." OK, what exactly is meant by "associated
semantics"?


Associated semantics define behaviour (probably a bad word) in some
context.


I'd accept something like how it is influenced by or influences the
outcome of programmatic operations. Maybe. Now, could I take an
example such as int, and provide an itemized list of related
semantics? Not without a lot more thinking than I've already done. I
suspect scope, name resolution, declaration, initialization,
definition (yes I know), conversion, duration, possible operations,
referencing, etc. Would all be part of the semantics of an object of
type int. But to provide a comprehensive, orthogonal and clearly
specifying list of semantics would be quite a challenge.
For example, an object in the context of C++ *can be* for example "A
region of storage with a set of methods defined". Of course this much
more specific than what you've quoted.
What, if any, associated semantics are shared by all objects? That
part seems to go beyond the FAQ.


I don't mean to sound harsh, but this question reminds me of "Why the
earth is spherical".


I actually was faced with the interesting situation of meeting a
reasonably intelligent person who did *not* understand the concept
that the earth is spherical. He was from Eritrea, and had very little
formal education. I explained it to him in terms of Newtonian
gravitation (without explicit reference to the inverse-square force
law.) But the Earth isn't exactly spherical, and that takes a bit of
explaining, as well. Nonetheless, I can begin with simple concepts of
classical physics and come up with a very good approximation to what
the shape of the Earth should be, and find that it matches the
observed reality. IOW, the question about the Earth is not quite as
simple as it seems at first, but it is answerable on the basis of
reasonably sound first principles.

Part of what I'm trying to get at is how much of the definition of the
concept of object is defined explicitly by the Standard, and how much
is defined by consequence of definitions which associate semantics
with specific categories of objects as 'side effects'? What /are/ the
first principles?


Because we see the world as somewhat "object oriented" ?

Sorry, perhaps because I look at C++ from a rather practical standpoint,
I can't imagine myself going into so much formal analysis and intricate
details, which actually bring no significant conclusions. I tend to take
it as it is.

I admire your quest for knowledge, and I'm jealous for the amounts of
spare time. :)

Jul 22 '05 #11

P: n/a
bartek wrote:
Because we see the world as somewhat "object oriented" ?
The Teachings of the Buddha from the Dhammapada, page 1, verse 1:

1 All the phenomena of existence have mind as their precursor, mind as their
supreme leader, and of mind are they made. If with an impure mind one
speaks or acts, suffering follows him in the same way as the wheel follows
the foot of the drawer (of the chariot).

2. All the phenomena of existence have mind as their precursor, mind as
their supreme leader, and of mind are they made. If with a pure mind one
speaks or acts, happiness follows him like his shadow that never leaves
him.
Sorry, perhaps because I look at C++ from a rather practical standpoint,
I can't imagine myself going into so much formal analysis and intricate
details, which actually bring no significant conclusions. I tend to take
it as it is.

I think I have a reasonably good answer. See the excerpt from the Standard
quoted below.
I admire your quest for knowledge, and I'm jealous for the amounts of spare time. :)

If you knew the whole story, you might not be quite so jealous.
<title>[intro.object] 1.8</title>

<subtitle>The C++ object model</subtitle>

<para>
1 The constructs in a C + + program create, destroy, refer to, access,
and manipulate objects. An object is a region of storage. [Note: A
function is not an object, regardless of whether or not it occupies
storage in the way that objects do. ] An object is created by a
definition (3.1), by a new-expression (5.3.4) or by the implementation
(12.2) when needed. The properties of an object are determined when
the object is created. An object can have a name (clause 3). An object
has a storage duration (3.7) which influences its lifetime (3.8). An
object has a type (3.9). The term object type refers to the type with
which the object is created. Some objects are polymorphic (10.3); the
implementation generates information associated with each such object
that makes it possible to determine that object s type during program
execution. For other objects, the interpretation of the values found
therein is determined by the type of the expressions (clause 5) used
to access them.
</para>
<para>
2 Objects can contain other objects, called sub-objects. A sub-object
can be a member sub-object (9.2), a base class sub-object (clause 10),
or an array element. An object that is not a sub-object of any other
object is called a complete object.
</para>
<para>
3 For every object x, there is
some object called the complete object of x, determined as follows: If
x is a complete object, then x is the complete object of x.
Otherwise, the complete object of x is the complete object of the
(unique) object that contains x.
</para>
<para>
4 If a complete object, a data member
(9.2), or an array element is of class type, its type is considered
the most derived class, to distinguish it from the class type of any
base class subobject; an object of a most derived class type is called
a most derived object.
</para>
<para>
5 Unless it is a bit-field (9.6), a most derived object shall have a
non-zero size and shall occupy one or more bytes of storage. Base
class sub-objects may have zero size. An object of POD4) type (3.9)
shall occupy contiguous bytes of storage.
</para>
<para>
6 [Note:C++ provides a variety of built-in types and several ways of
composing new types from existing types (3.9). ]
</para>
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #12

P: n/a
bartek wrote:
Because we see the world as somewhat "object oriented" ?
The Teachings of the Buddha from the Dhammapada, page 1, verse 1:

1 All the phenomena of existence have mind as their precursor, mind as their
supreme leader, and of mind are they made. If with an impure mind one
speaks or acts, suffering follows him in the same way as the wheel follows
the foot of the drawer (of the chariot).

2. All the phenomena of existence have mind as their precursor, mind as
their supreme leader, and of mind are they made. If with a pure mind one
speaks or acts, happiness follows him like his shadow that never leaves
him.
Sorry, perhaps because I look at C++ from a rather practical standpoint,
I can't imagine myself going into so much formal analysis and intricate
details, which actually bring no significant conclusions. I tend to take
it as it is.

I think I have a reasonably good answer. See the excerpt from the Standard
quoted below.
I admire your quest for knowledge, and I'm jealous for the amounts of spare time. :)

If you knew the whole story, you might not be quite so jealous.
<title>[intro.object] 1.8</title>

<subtitle>The C++ object model</subtitle>

<para>
1 The constructs in a C + + program create, destroy, refer to, access,
and manipulate objects. An object is a region of storage. [Note: A
function is not an object, regardless of whether or not it occupies
storage in the way that objects do. ] An object is created by a
definition (3.1), by a new-expression (5.3.4) or by the implementation
(12.2) when needed. The properties of an object are determined when
the object is created. An object can have a name (clause 3). An object
has a storage duration (3.7) which influences its lifetime (3.8). An
object has a type (3.9). The term object type refers to the type with
which the object is created. Some objects are polymorphic (10.3); the
implementation generates information associated with each such object
that makes it possible to determine that object s type during program
execution. For other objects, the interpretation of the values found
therein is determined by the type of the expressions (clause 5) used
to access them.
</para>
<para>
2 Objects can contain other objects, called sub-objects. A sub-object
can be a member sub-object (9.2), a base class sub-object (clause 10),
or an array element. An object that is not a sub-object of any other
object is called a complete object.
</para>
<para>
3 For every object x, there is
some object called the complete object of x, determined as follows: If
x is a complete object, then x is the complete object of x.
Otherwise, the complete object of x is the complete object of the
(unique) object that contains x.
</para>
<para>
4 If a complete object, a data member
(9.2), or an array element is of class type, its type is considered
the most derived class, to distinguish it from the class type of any
base class subobject; an object of a most derived class type is called
a most derived object.
</para>
<para>
5 Unless it is a bit-field (9.6), a most derived object shall have a
non-zero size and shall occupy one or more bytes of storage. Base
class sub-objects may have zero size. An object of POD4) type (3.9)
shall occupy contiguous bytes of storage.
</para>
<para>
6 [Note:C++ provides a variety of built-in types and several ways of
composing new types from existing types (3.9). ]
</para>
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #13

P: n/a
On Sun, 04 Apr 2004 16:35:02 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote in comp.lang.c++:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What, if
any, associated semantics are shared by all objects? That part seems to go
beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?


Splurge, spend $18.00, buy a copy of the standard.

The definition of an object in C++ is basically inherited from ISO C
and has nothing at all to do with classes or OO terminology.

An object is indeed a region of storage. Objects have specific
properties. The two irreducible minimum properties, determined at the
time of the object's creation, are storage duration and type.

Given the trivial but complete program below:

int x;
int main(void)
{
int y;
return 0;
}

x is an object of type int with static storage duration. y is an
object of type int with automatic storage duration.

x happens to have external linkage and y happens to have no linkage,
but these are properties of the identifiers, not of the objects
themselves.

For more information, see 1.8 of ISO 14882:1998.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 22 '05 #14

P: n/a
On Sun, 04 Apr 2004 16:35:02 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote in comp.lang.c++:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What, if
any, associated semantics are shared by all objects? That part seems to go
beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?


Splurge, spend $18.00, buy a copy of the standard.

The definition of an object in C++ is basically inherited from ISO C
and has nothing at all to do with classes or OO terminology.

An object is indeed a region of storage. Objects have specific
properties. The two irreducible minimum properties, determined at the
time of the object's creation, are storage duration and type.

Given the trivial but complete program below:

int x;
int main(void)
{
int y;
return 0;
}

x is an object of type int with static storage duration. y is an
object of type int with automatic storage duration.

x happens to have external linkage and y happens to have no linkage,
but these are properties of the identifiers, not of the objects
themselves.

For more information, see 1.8 of ISO 14882:1998.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 22 '05 #15

P: n/a
Jack Klein wrote:
On Sun, 04 Apr 2004 16:35:02 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote in comp.lang.c++:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What,
if any, associated semantics are shared by all objects? That part seems
to go beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?
Splurge, spend $18.00, buy a copy of the standard.


The Standard isn't completely clear on some of the points I'm asking about.
The definition of an object in C++ is basically inherited from ISO C
and has nothing at all to do with classes or OO terminology.
The standard certainly doesn't say /that/, and I'm not convinced your
assertion is completely accurate. I'm aware of common OO terminology. I'm
also aware there are differences between their meanings when used by
different authors or to described different languages. It seems the term
"object" in the C++ Standard identifies the set of all fundamental and
aggregate type instances, and descriptions of the behavior of objects are
intended, unless otherwise specified, to apply to all objects. So either
we allow that the term object is being used in an OO sense, or we assert
that the general use of the term 'object' in the C++ standard is not used
to describe object oriented features of the language.
An object is indeed a region of storage. Objects have specific
properties. The two irreducible minimum properties, determined at the
time of the object's creation, are storage duration and type.
Is that stated in the standard? If so, where? Does it apply to all
objects, or only complete objects? What are the semantic implications of
having a type?
Given the trivial but complete program below:

int x;
int main(void)
{
int y;
return 0;
}

x is an object of type int with static storage duration. y is an
object of type int with automatic storage duration.
x happens to have external linkage and y happens to have no linkage,
but these are properties of the identifiers, not of the objects
themselves.
And this relates to my question in what way?
For more information, see 1.8 of ISO 14882:1998.


Does ISO 14882:2003 suffice? I already posted 1.8 from the current C++
Standard. Was there something missing? I don't have the older version you
referenced.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #16

P: n/a
Jack Klein wrote:
On Sun, 04 Apr 2004 16:35:02 -0400, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote in comp.lang.c++:
This may seem like such a simple question, I should be embarrassed to ask
it. The FAQ says an object is "A region of storage with associated
semantics." OK, what exactly is meant by "associated semantics"? What,
if any, associated semantics are shared by all objects? That part seems
to go beyond the FAQ.

Does anybody know of a resource that discusses (focuses on) this topic?
Splurge, spend $18.00, buy a copy of the standard.


The Standard isn't completely clear on some of the points I'm asking about.
The definition of an object in C++ is basically inherited from ISO C
and has nothing at all to do with classes or OO terminology.
The standard certainly doesn't say /that/, and I'm not convinced your
assertion is completely accurate. I'm aware of common OO terminology. I'm
also aware there are differences between their meanings when used by
different authors or to described different languages. It seems the term
"object" in the C++ Standard identifies the set of all fundamental and
aggregate type instances, and descriptions of the behavior of objects are
intended, unless otherwise specified, to apply to all objects. So either
we allow that the term object is being used in an OO sense, or we assert
that the general use of the term 'object' in the C++ standard is not used
to describe object oriented features of the language.
An object is indeed a region of storage. Objects have specific
properties. The two irreducible minimum properties, determined at the
time of the object's creation, are storage duration and type.
Is that stated in the standard? If so, where? Does it apply to all
objects, or only complete objects? What are the semantic implications of
having a type?
Given the trivial but complete program below:

int x;
int main(void)
{
int y;
return 0;
}

x is an object of type int with static storage duration. y is an
object of type int with automatic storage duration.
x happens to have external linkage and y happens to have no linkage,
but these are properties of the identifiers, not of the objects
themselves.
And this relates to my question in what way?
For more information, see 1.8 of ISO 14882:1998.


Does ISO 14882:2003 suffice? I already posted 1.8 from the current C++
Standard. Was there something missing? I don't have the older version you
referenced.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #17

P: n/a
Steven T. Hatton wrote:
The FAQ says [that]
an object is "A region of storage with associated semantics."
OK, what exactly is meant by "associated semantics"?
What, if any, associated semantics are shared by all objects?
That part seems to go beyond the FAQ.
Actually, objects are things that *could* occupy a region of storage.
Good optimizing compilers can and do "optimize away" the storage
for some objects that contain intermediate results for example.
The "associated semantics" have to do with the object's type.
An int and a float may be represented by the same number of bits
but the type determines how those bits are interpreted
and what operations may be applied to them.

In the context of a computer programming language,
an object is a *data* object. The type of an object can be
a User Defined Type (UDT) as well as a built-in type.
C++ programmers implement UDTs as class definitions.
At best, a UDT is the implementation of an Abstract Data Type (ADT).

In the context of Object Oriented Programming (OOP),
the program does not generally know exactly which method
(operation, function, etc.) applies to an object
without first inspecting the object at runtime
to determine the actual type of the object.
This is called "run-time polymorphism" or "dynamic binding"
and is, for some object oriented programmers, the essential feature
of objects and object oriented programming.
Does anybody know of a resource that discusses (focuses on) thistopic?


The comp.object newsgroup.
Jul 22 '05 #18

P: n/a
Steven T. Hatton wrote:
The FAQ says [that]
an object is "A region of storage with associated semantics."
OK, what exactly is meant by "associated semantics"?
What, if any, associated semantics are shared by all objects?
That part seems to go beyond the FAQ.
Actually, objects are things that *could* occupy a region of storage.
Good optimizing compilers can and do "optimize away" the storage
for some objects that contain intermediate results for example.
The "associated semantics" have to do with the object's type.
An int and a float may be represented by the same number of bits
but the type determines how those bits are interpreted
and what operations may be applied to them.

In the context of a computer programming language,
an object is a *data* object. The type of an object can be
a User Defined Type (UDT) as well as a built-in type.
C++ programmers implement UDTs as class definitions.
At best, a UDT is the implementation of an Abstract Data Type (ADT).

In the context of Object Oriented Programming (OOP),
the program does not generally know exactly which method
(operation, function, etc.) applies to an object
without first inspecting the object at runtime
to determine the actual type of the object.
This is called "run-time polymorphism" or "dynamic binding"
and is, for some object oriented programmers, the essential feature
of objects and object oriented programming.
Does anybody know of a resource that discusses (focuses on) thistopic?


The comp.object newsgroup.
Jul 22 '05 #19

P: n/a

I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics?


int is not an object in C++.

I think you should not worry about the syntax. You are not a lawyer.

Write code, observe behavior, find references to and question things
which you don't understand.

Too many lawyers in newsgroups these days...

Regards,

JLR
Jul 22 '05 #20

P: n/a

I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics?


int is not an object in C++.

I think you should not worry about the syntax. You are not a lawyer.

Write code, observe behavior, find references to and question things
which you don't understand.

Too many lawyers in newsgroups these days...

Regards,

JLR
Jul 22 '05 #21

P: n/a
Jorge Rivera wrote:
int is not an object in C++.
It is a type.

int j = 0;

j is an object of type int with an initial value of zero.
I think you should not worry about the syntax.
You are not a lawyer.
Write code, observe behavior and
find references to and question things which you don't understand.

Too many lawyers in newsgroups these days...


Too many programmers practicing language law without a license.

Jul 22 '05 #22

P: n/a
Jorge Rivera wrote:
int is not an object in C++.
It is a type.

int j = 0;

j is an object of type int with an initial value of zero.
I think you should not worry about the syntax.
You are not a lawyer.
Write code, observe behavior and
find references to and question things which you don't understand.

Too many lawyers in newsgroups these days...


Too many programmers practicing language law without a license.

Jul 22 '05 #23

P: n/a

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message news:95*****************@twister.nyroc.rr.com...

I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics?


int is not an object in C++.


int is an object in C++. It's just not a class.
Jul 22 '05 #24

P: n/a

"Jorge Rivera" <jo*****@rochester.rr.com> wrote in message news:95*****************@twister.nyroc.rr.com...

I'd accept something like how it is influenced by or influences the outcome
of programmatic operations. Maybe. Now, could I take an example such as
int, and provide an itemized list of related semantics?


int is not an object in C++.


int is an object in C++. It's just not a class.
Jul 22 '05 #25

P: n/a
Ron Natalie wrote:
int is an object in C++. It's just not a class.


No!

int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.

Jul 22 '05 #26

P: n/a
Ron Natalie wrote:
int is an object in C++. It's just not a class.


No!

int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.

Jul 22 '05 #27

P: n/a
Jorge Rivera wrote:
I'd accept something like how it is influenced by or influences the
outcome of programmatic operations. Maybe. Now, could I take an example
such as int, and provide an itemized list of related semantics?
int is not an object in C++.


An int is a type of object in C++. Most people probably do not think of an
instance of int as being an object. This is an issue that keeps coming
back to me as I learn more about the language.
I think you should not worry about the syntax.
I believe this is a question of semantics, not syntax.
You are not a lawyer.
:-)
Write code, observe behavior, find references to and question things
which you don't understand.
That's why I started asking. I'm reading the Standard, and its use of the
term 'object' is not consistent with my preconceived notions. IIRC, a guy
named Jerry Feldman once told me where in TC++PL(SE) Stroustrup explains
certain characteristics of fundamental types as resulting from the fact
they are actually objects, and therefore obey the rules applicable to all
objects.
Too many lawyers in newsgroups these days...


My reason for asking is actually more pragmatic than it may seem. I /do/
enjoy the study of languages, both natural and designed. That really isn't
my primary motive, however. I am trying to understand the language
definition better.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #28

P: n/a
Jorge Rivera wrote:
I'd accept something like how it is influenced by or influences the
outcome of programmatic operations. Maybe. Now, could I take an example
such as int, and provide an itemized list of related semantics?
int is not an object in C++.


An int is a type of object in C++. Most people probably do not think of an
instance of int as being an object. This is an issue that keeps coming
back to me as I learn more about the language.
I think you should not worry about the syntax.
I believe this is a question of semantics, not syntax.
You are not a lawyer.
:-)
Write code, observe behavior, find references to and question things
which you don't understand.
That's why I started asking. I'm reading the Standard, and its use of the
term 'object' is not consistent with my preconceived notions. IIRC, a guy
named Jerry Feldman once told me where in TC++PL(SE) Stroustrup explains
certain characteristics of fundamental types as resulting from the fact
they are actually objects, and therefore obey the rules applicable to all
objects.
Too many lawyers in newsgroups these days...


My reason for asking is actually more pragmatic than it may seem. I /do/
enjoy the study of languages, both natural and designed. That really isn't
my primary motive, however. I am trying to understand the language
definition better.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #29

P: n/a
E. Robert Tisdale wrote:
int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.


I'm starting to wonder whether a pointer is an object in C++ parlance. I
have found no statement clearly excluding pointers from the set of all C++
objects. In the case of functions, they are explicitly excluded. The same
question might be asked of a reference.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #30

P: n/a
E. Robert Tisdale wrote:
int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.


I'm starting to wonder whether a pointer is an object in C++ parlance. I
have found no statement clearly excluding pointers from the set of all C++
objects. In the case of functions, they are explicitly excluded. The same
question might be asked of a reference.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #31

P: n/a
Alf P. Steinbach wrote:
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

What /are/ the first principles?


Think about this: in mathematics, which is thought of as fairly strict and
well-defined, perhaps the most well-defined of all possible fields, nobody
can
agree on even what _kind_ of answers that question has. Yet
mathematicians can collaborate and can (to good approximation) understand
each other's good
work, although not the bad. It's the same way in programming, only more
so.

"Pure mathematics consists entirely of such asseverations as that, if such
and such a proposition is true of anything, then such and such another
proposition is true of that thing... It's essential not to discuss whether
the proposition is really true, and not to mention what the anything is of
which it is supposed to be true... If our hypothesis is about anything and
not about some one or more particular things, then our deductions
constitute mathematics. Thus mathematics may be defined as the subject in
which we never know what we are talking about, nor whether what we are
saying is true."- Bertrand Russell

However, mathematics relies on definitions which are commonly accepted, and
understood at least in so much as to lead other mathematicians to
manipulate symbols in such a way as to produce results their peers will
understand as equivalent to their own. IOW, mathematics can be viewed as
an exercise in deterministic symbol manipulation.

There is a field called metamathematics which studies the mechanisms of
mathematics. I don't know if there is formally a field called axiomatics,
but I certainly believe there has been much study along the lines suggested
by the term. One view is that of Euclid which holds certain principles are
fundamental and selfevident. Another view holds that axioms can be posited
at will, and the only test of their validity is whether they can be shown
not to be mutually derivable, and not to lead to inconsistencies. Which of
course begs a few questions....

But for the sake of programming, I tend to believe some concepts can, and
should be clearly defined, at least for pragmatic purposes.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #32

P: n/a
Alf P. Steinbach wrote:
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

What /are/ the first principles?


Think about this: in mathematics, which is thought of as fairly strict and
well-defined, perhaps the most well-defined of all possible fields, nobody
can
agree on even what _kind_ of answers that question has. Yet
mathematicians can collaborate and can (to good approximation) understand
each other's good
work, although not the bad. It's the same way in programming, only more
so.

"Pure mathematics consists entirely of such asseverations as that, if such
and such a proposition is true of anything, then such and such another
proposition is true of that thing... It's essential not to discuss whether
the proposition is really true, and not to mention what the anything is of
which it is supposed to be true... If our hypothesis is about anything and
not about some one or more particular things, then our deductions
constitute mathematics. Thus mathematics may be defined as the subject in
which we never know what we are talking about, nor whether what we are
saying is true."- Bertrand Russell

However, mathematics relies on definitions which are commonly accepted, and
understood at least in so much as to lead other mathematicians to
manipulate symbols in such a way as to produce results their peers will
understand as equivalent to their own. IOW, mathematics can be viewed as
an exercise in deterministic symbol manipulation.

There is a field called metamathematics which studies the mechanisms of
mathematics. I don't know if there is formally a field called axiomatics,
but I certainly believe there has been much study along the lines suggested
by the term. One view is that of Euclid which holds certain principles are
fundamental and selfevident. Another view holds that axioms can be posited
at will, and the only test of their validity is whether they can be shown
not to be mutually derivable, and not to lead to inconsistencies. Which of
course begs a few questions....

But for the sake of programming, I tend to believe some concepts can, and
should be clearly defined, at least for pragmatic purposes.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #33

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
E. Robert Tisdale wrote:
int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.
I'm starting to wonder whether a pointer is an object in
C++ parlance. I have found no statement clearly excluding
pointers from the set of all C++ objects.


Pointers are objects. They take on a value, may have an address, and have
associated operations.
In the case of functions, they are explicitly excluded.
A function may have an address and has associated operations, but it cannot
have a value.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has no
address (the address is that of the aliased object), no value (the value is
that of the aliased object), and no associated operations other than its
initial binding (all other operations are on the aliased object).

Claudio Puviani
Jul 22 '05 #34

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
E. Robert Tisdale wrote:
int is a *type* -- a built-in type.
An object is an *instance* of some type:

int j = 0;

j is an *object* of type int.
I'm starting to wonder whether a pointer is an object in
C++ parlance. I have found no statement clearly excluding
pointers from the set of all C++ objects.


Pointers are objects. They take on a value, may have an address, and have
associated operations.
In the case of functions, they are explicitly excluded.
A function may have an address and has associated operations, but it cannot
have a value.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has no
address (the address is that of the aliased object), no value (the value is
that of the aliased object), and no associated operations other than its
initial binding (all other operations are on the aliased object).

Claudio Puviani
Jul 22 '05 #35

P: n/a
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote Pointers are objects. They take on a value, may have an address, and have
associated operations.

That's kind of what I expected.
In the case of functions, they are explicitly excluded.


A function may have an address and has associated operations, but it
cannot have a value.


I have an easier was to determine that a function isn't an object. It is
explicitly stated in 1.8 of the Standard.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has
no address (the address is that of the aliased object), no value (the
value is that of the aliased object), and no associated operations other
than its initial binding (all other operations are on the aliased object).


I have yet to really examine references, but that was more or less what I
expected. Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.

I know my level of understanding of references is below that which I can
gain from carefully reading the FAQ, so I'll do my homework before pursuing
it further.

This is a somewhat telling passage from 3.5:

"A name is said to have linkage when it might denote the same object,
*reference*, function, type, template, namespace or value as a name
introduced by a declaration in another scope:..." (*emphasis* mine)

So we can probably assume the namable 'things' in the list other than object
are not objects. Note that this includes references.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #36

P: n/a
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote Pointers are objects. They take on a value, may have an address, and have
associated operations.

That's kind of what I expected.
In the case of functions, they are explicitly excluded.


A function may have an address and has associated operations, but it
cannot have a value.


I have an easier was to determine that a function isn't an object. It is
explicitly stated in 1.8 of the Standard.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has
no address (the address is that of the aliased object), no value (the
value is that of the aliased object), and no associated operations other
than its initial binding (all other operations are on the aliased object).


I have yet to really examine references, but that was more or less what I
expected. Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.

I know my level of understanding of references is below that which I can
gain from carefully reading the FAQ, so I'll do my homework before pursuing
it further.

This is a somewhat telling passage from 3.5:

"A name is said to have linkage when it might denote the same object,
*reference*, function, type, template, namespace or value as a name
introduced by a declaration in another scope:..." (*emphasis* mine)

So we can probably assume the namable 'things' in the list other than object
are not objects. Note that this includes references.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #37

P: n/a
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.


Wrong question. The key point is that a C++ reference cannot be re-seated;
if a reference R refers now to object X, then R refers to object X until R
ceases to exist. There are no operations on the reference itself, and in
many cases (but not all) it need not occupy any storage.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #38

P: n/a
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.


Wrong question. The key point is that a C++ reference cannot be re-seated;
if a reference R refers now to object X, then R refers to object X until R
ceases to exist. There are no operations on the reference itself, and in
many cases (but not all) it need not occupy any storage.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #39

P: n/a
Steven T. Hatton wrote:
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote

Pointers are objects. They take on a value, may have an address, and have
associated operations.

That's kind of what I expected.
In the case of functions, they are explicitly excluded.


A function may have an address and has associated operations, but it
cannot have a value.


I have an easier was to determine that a function isn't an object. It is
explicitly stated in 1.8 of the Standard.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has
no address (the address is that of the aliased object), no value (the
value is that of the aliased object), and no associated operations other
than its initial binding (all other operations are on the aliased
object).


I have yet to really examine references, but that was more or less what I
expected. Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.

I know my level of understanding of references is below that which I can
gain from carefully reading the FAQ, so I'll do my homework before
pursuing it further.

This is a somewhat telling passage from 3.5:

"A name is said to have linkage when it might denote the same object,
*reference*, function, type, template, namespace or value as a name
introduced by a declaration in another scope:..." (*emphasis* mine)

So we can probably assume the namable 'things' in the list other than
object
are not objects. Note that this includes references.


OTOH: "The storage duration categories apply to references as well. The
lifetime of a reference is its storage duration." - 3.7 of PL-C++03 (The
Standard)

And also TC++PL(SE) pg 98:
"[A] reference isn't an *object* that can be manipulated the way a pointer
is:

PP: [&ii]\
\
\
rr:---> ii: [i]

In some cases, the compiler can optimize away a reference so that there is
no *object* representing that reference at run-time." (emphasis mine)

This is starting to sound more and more like wave particle duality. :-/
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #40

P: n/a
Steven T. Hatton wrote:
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote

Pointers are objects. They take on a value, may have an address, and have
associated operations.

That's kind of what I expected.
In the case of functions, they are explicitly excluded.


A function may have an address and has associated operations, but it
cannot have a value.


I have an easier was to determine that a function isn't an object. It is
explicitly stated in 1.8 of the Standard.
The same question might be asked of a reference.


A reference isn't an object, but an alias for an object. A reference has
no address (the address is that of the aliased object), no value (the
value is that of the aliased object), and no associated operations other
than its initial binding (all other operations are on the aliased
object).


I have yet to really examine references, but that was more or less what I
expected. Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.

I know my level of understanding of references is below that which I can
gain from carefully reading the FAQ, so I'll do my homework before
pursuing it further.

This is a somewhat telling passage from 3.5:

"A name is said to have linkage when it might denote the same object,
*reference*, function, type, template, namespace or value as a name
introduced by a declaration in another scope:..." (*emphasis* mine)

So we can probably assume the namable 'things' in the list other than
object
are not objects. Note that this includes references.


OTOH: "The storage duration categories apply to references as well. The
lifetime of a reference is its storage duration." - 3.7 of PL-C++03 (The
Standard)

And also TC++PL(SE) pg 98:
"[A] reference isn't an *object* that can be manipulated the way a pointer
is:

PP: [&ii]\
\
\
rr:---> ii: [i]

In some cases, the compiler can optimize away a reference so that there is
no *object* representing that reference at run-time." (emphasis mine)

This is starting to sound more and more like wave particle duality. :-/
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #41

P: n/a
Steven T. Hatton wrote:

[snip]

int i = 999;
int j = 0;
int* p = &j;

p is a *pointer* to j.
*p is a *reference* to j.

*p = 666; // means
j == 666; // is true

*p is another name for j.

p = &i; // a pointer can be *reseated*

Now, *p is a *reference* to i and

*p == 999; // is true

Pass by reference

void f(int&);

is typically implemented as

void f(int*);

meaning that
the compiler passes the [virtual] machine address of the object
to represent a reference or a pointer to an object.

Jul 22 '05 #42

P: n/a
Steven T. Hatton wrote:

[snip]

int i = 999;
int j = 0;
int* p = &j;

p is a *pointer* to j.
*p is a *reference* to j.

*p = 666; // means
j == 666; // is true

*p is another name for j.

p = &i; // a pointer can be *reseated*

Now, *p is a *reference* to i and

*p == 999; // is true

Pass by reference

void f(int&);

is typically implemented as

void f(int*);

meaning that
the compiler passes the [virtual] machine address of the object
to represent a reference or a pointer to an object.

Jul 22 '05 #43

P: n/a
Alf P. Steinbach wrote:
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.


Wrong question. The key point is that a C++ reference cannot be
re-seated; if a reference R refers now to object X, then R refers to
object X until R
ceases to exist. There are no operations on the reference itself, and in
many cases (but not all) it need not occupy any storage.


I have some things I want to add to this discussion, but first I want to
finish clause 3. I just found this in 3.9/9 "An /object type/ is a
(possibly cv-qualified) type that is not a function type, *not* a
*reference* type, and not a void type."

Now, if I can remain conscious for the next 4 pages, I'll be back with a few
observations regarding references. Probably in a followup to Robert's most
recent post in this thread.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #44

P: n/a
Alf P. Steinbach wrote:
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:

Does this mean references aren't really runtime 'things'? IOW,
are they bound to something else at compile time? I believe what I'm
asking is whether references are always static.


Wrong question. The key point is that a C++ reference cannot be
re-seated; if a reference R refers now to object X, then R refers to
object X until R
ceases to exist. There are no operations on the reference itself, and in
many cases (but not all) it need not occupy any storage.


I have some things I want to add to this discussion, but first I want to
finish clause 3. I just found this in 3.9/9 "An /object type/ is a
(possibly cv-qualified) type that is not a function type, *not* a
*reference* type, and not a void type."

Now, if I can remain conscious for the next 4 pages, I'll be back with a few
observations regarding references. Probably in a followup to Robert's most
recent post in this thread.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #45

This discussion thread is closed

Replies have been disabled for this discussion.