Pointers In C++

[Alisha]

A pointer is a variable which stores the address of another
variable. There are two important operators when working with pointers
in C++: the address of (&) operator and the value of (*) operator.
They have been overloaded in C++ so they may have different uses in
different contexts.

How much storage space does a pointer consume?
Use sizeof(ptr) without the '*' operator to determine the memory
utilised on your system. Irrespective of datatype or whether the
pointer points to a single variable or array, as a general rule,
pointers must use the same amount of memory space.

The & operator gives us the address of a variable and * gives us the
value of a variable at a specified address.

Please tell me something more about Pointer in C++.
www.onlinevideogallery.com

 

[Stefan Ram]

A pointer is a variable which stores the address of another
variable.

IIRC, both »pointer« and »variable« are not defined explicitly
by ISO/IEC 14882:2003(E).

What you call »variable« seems to be what is called »variable«
in Java, but is called »object« in ISO/IEC 14882:2003(E).
There are also pointers to functions, and null pointers, which
both do not point to any object at all.

Since »( char * )0« is a pointer, but not an object, pointers
do not have to be objects.

I'd like to suggest this explicit definitions for the two
terms, which are not explicitely defined in ISO/IEC
14882:2003(E):

A pointer is a value of a pointer type.

A variable is a name (including its attributes, such as
its type) that is declared in the source text as a name to
be bound to an object (during execution). (see also
ISO/IEC 14882:2003(E), 3p4)

Sometimes ISO/IEC 14882:2003(E) seems to use »pointer« to
refer to a pointer /type/. For example:

»For each argument type T in the function call, [...]
o If T is a pointer to U or an array of U, [...]«

 

[James Kanze]

* Stefan Ram:

[...]

The definition of "variable" in §3/4 is succinct and complete,
and I don't understand how you can refer to it above, "3p4",
and still maintain that there's no definition of the term.

Ditto, the term "pointer" is defined by §3.9.2/1 with
reference §8.3.1.

Independantly of the clarity (I have no problem with it, but
clarity is subjective), the terms are in italics in the cited
text. And (§1.3) "Terms that are used only in a small portion
of this International Standard are defined where they are used
and italicized where they are defined." Of course, I'm not
sure that either variable or pointer would qualify as "used only
in a small portion" of the standard. But the intent is clear:
the cited text is a definition, in the sense of the standard.

 

[Stefan Ram]

of this International Standard are defined where they are used
and italicized where they are defined." Of course, I'm not

Thanks for the hint regarding italis! It helps to know when
ISO/IEC 14882:2003(E) deems a term to be »defined«.

Both of you, James and Alf, refer to »definition«, while I
was using »explicit definition«.

To me, an »explicit definition« is a definition of the
following form:

»An <new term> is a <known superordinate concept>,
so that <complete list of requirements> are fulfilled.«

For example, for »object«,

»An object is a region of storage that has a type.«

Or (in mathematics), for »x«,

»x e N, 0 = x + 2.«
(x is a natural number, so that x plus 2 is zero.)

On the other hand, just stating one property, but not all
properties required, and not giving a known superordinate
concept is not an explicit definition to me. For example,
the following is not an explicit definition of »car«:

A car can be obtained by a visit to a car shop.

 

[Stefan Ram]

Not in C++.

»An object is a region of storage. [...] An object has a type«

ISO/IEC 14882:2003(E), 1.8

Hm, no such.

Yes, I should have chosen »x - 2«.

you have an implicit definition, not an explicit one

The /whole/ sentence is an explicit definition that
/contains/ implicit parts. For example, let »'« be the
successor mapping (for example, 0' = 1), then I define:

2 :=( ix.( x e N ^ 0 = x - 0'' ))
(in words: »2 is that x that is in N and fulfills 0 = x - 0''«.)

because the definition can't be substituted for an occurrence of x; the
definition is not of the form "x is ...".

In

2 + 3 = 5,

I can substitute the above definition for »2«, yielding:

( ix.( x e N ^ 0 = x - 2 ))+ 3 = 5.

So it is explicit as a whole, while it contains implicit parts.

(This is like »0;« not being an expression in C++, even though
»0« is an expression contained in it.)

It seems that the argument is that some definitions do not
impose enough constraints to your taste,

What does not fit my taste was the lack of a
superordinate concept.

here that you have a much more constraining

A superordinate concept would satisfy me, even if the number
of additional constraints were zero, e.g.:

»A car is an automobile.«

Here »automobile« is the superordinate concept, and since I do
not require additional constraints, I allow to define synonyms
(aliases), and I allow a concept to be deemed superordinate to
itself (like any set is a subset of itself).

For example, the object definition quoted above pleases me,
because it starts by giving the superordinate concept »region
of storage«, and then it lists additional properties of
objects, like that fact that an object has a type.

 

[Kai-Uwe Bux]

* Stefan Ram:

»An object is a region of storage that has a type.«
Not in C++.

»An object is a region of storage. [...] An object has a type«

ISO/IEC 14882:2003(E), 1.8

Sorry, a region of storage does not have a type.

The proposed definition of "object" does not entail the claim that any
region of storage has a type. It says that an object is a region of storage
that has a type. If a region of storage does not have a type, it would not
qualify as an object according to the proposed definition.

The standard, on the other hand, is very clear that some regions of storage
have types (namely those regions of storage that happen to be objects).

A region of storage may be part of many objects, with different types.

Yes, and nothing in the proposed definition of "object" would contradict
that.



Best

Kai-Uwe Bux

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

* Stefan Ram:
»An object is a region of storage that has a type.«
Not in C++.
»An object is a region of storage. [...] An object has a type«

ISO/IEC 14882:2003(E), 1.8
Sorry, a region of storage does not have a type.

The proposed definition of "object" does not entail the claim that any
region of storage has a type. It says that an object is a region of
storage that has a type.

You're contradicting yourself.

If a region of storage does not have a type, it would not
qualify as an object according to the proposed definition.

I think that's true.

So it's not compatible with C++.

That sentence only talks about those regions of storage that are not object.
But if x is an object and objects are regions of storage, then some region
of storage _is_ the object x. In that case, that region of storage has a
type since the object x has a type.

Chapter & verse please.

You have already been given the necessary quotes:

[1.8/1]: An object is a region of storage. ["object" in italics]

Note that this is a conceptual stipulation that identifies objects with
regions of storage. Consequently, all attributes of an object become
attributes of the region of storage that this object happens to be (there
is no conceptual distinction between the object and the region of storage
that it _is_).

Therefore, when the standard goes [in the same clause] to say that objects
have storage duration, lifetime, and type it _follows_ that certain regions
of storage (namely those that happen to be objects) have storage duration,
lifetime, and type.

Should be corrected if anything so bad has managed to sneak into the
standard!

Maybe. The standard could say "An object occupies a region of storage" or
"An object has a region of storage". But the standard chose to use "is" and
thereby chose to identify objects and their regions of storage on a
conceptual level. Whether that decision is _wise_ is a different matter.

BTW: This is very much like the differences of materialist and
non-materialist accounts of what a human is. Materialist would say a human
_is_ a body and non-materialists would say a human _has_ a body. The former
would then go on to say that if humans had immortal souls, it would follow
that certain bodies had immortal souls. (This is one of the reasons that
materialists tend to be critical of religion and that religious
philosophers tend to be critical of materialism. Both agree that the
inference is valid

It does.

How so? Let's say you have an object x of type T which has a member x.a of
type S. Also, suppose that x_ptr is a char* so that

[x_ptr, x_ptr+sizeof(T) )

_is_ the object X and a_ptr is a char* so that

[a_ptr, a_ptr + sizeof(S) )

_is_ the object x.a. Then the region [a_ptr, a_ptr+sizeof(S) ) has type S
and the region [x_ptr, x_ptr + sizeof(T) ) has the type T. Of course, that
even goes when the two regions of storage coincide. BTW: in that case, x
and x.a _are_ the same(!) object according to the standard (which makes
more sense that one might think at first: after all any change to x will
affect a).

Although there exists a silly convoluted interpretation (reading
"has" as "is associated with" and "a" as "at least one") where it doesn't.

There is nothing silly about it. It just follows straight from the
identification made by the standard.

However, it doesn't matter, for it goes only to the practical reason why
regions of storage are not regarded as having types.

Understanding the difference between storage (untyped) and object (typed)
is
fundamental. For example, a void* doesn't point to storage of type void.
But it's no big deal to take that untyped storage and make an object out
of it via e.g. placement new.

I think it's wrong of you to try to sow confusion about this distinction.

You may not like the conceptual identification of objects with regions of
storage, but the italics in the standard [1.8/1] make it very clear that
the statement "An object is a region of storage" is meant as a definition
of the term object. Since it is supposed to be a definition, it makes an
identification on the conceptual level (for better or worse).

Maybe, what one would want is something like "an object is a typed region of
storage". So, two objects would be the same if and only if they occupy the
same region in memory _and_ have the same type. Creation of an object could
then be regarded as the act of typing a certain region of memory.


BTW: I don't think the identification is actually all that harmful. The
standard is not a book to teach C++ but just a specification that should
allow one to deduce the observable behavior of C++ programs. I do not (yet)
see how that [1.8/1] or my interpretation of it negatively impacts on that.



Best

Kai-Uwe Bux

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

* Kai-Uwe Bux:
Alf P. Steinbach wrote:

* Stefan Ram:
»An object is a region of storage that has a type.«
Not in C++.
»An object is a region of storage. [...] An object has a type«

ISO/IEC 14882:2003(E), 1.8
Sorry, a region of storage does not have a type.
The proposed definition of "object" does not entail the claim that any
region of storage has a type. It says that an object is a region of
storage that has a type.
You're contradicting yourself.


If a region of storage does not have a type, it would not
qualify as an object according to the proposed definition.
I think that's true.

So it's not compatible with C++.

That sentence only talks about those regions of storage that are not
object. But if x is an object and objects are regions of storage, then
some region of storage _is_ the object x. In that case, that region of
storage has a type since the object x has a type.

That's a category error. The atoms you're constituted of don't smell good
even if you've put on cologne.

(a) Your analogy is slightly misleading. I never claimed that the units of
memory comprising the region of storage have a type. The region as a whole
can still have a type (that is, the chunk of matter that is me can
definitely smell good if it puts on cologne even though the atoms don't).

(b) Nonetheless, it still would be a category error if "object" and "region
of storage" were on conceptually different levels. However, [1.8/1]
precludes that (not because it makes an identification statement, but
because it does so in the context of a definition).

The standard, on the other hand, is very clear that some regions of
storage have types (namely those regions of storage that happen to be
objects).
Chapter & verse please.

You have already been given the necessary quotes:

[1.8/1]: An object is a region of storage. ["object" in italics]

Note that this is a conceptual stipulation that identifies objects with
regions of storage.

Note that it's not.

Of course it is. That is what "a is b" definitions do: they identify
concepts. In this case, the concept of "object" is identified with "region
of storage". I really don't see any wiggleroom in the wording; and it is
meant as a definition of the term "object".

Consequently, all attributes of an object become
attributes of the region of storage that this object happens to be (there
is no conceptual distinction between the object and the region of storage
that it _is_).

C.E.

Therefore, when the standard goes [in the same clause] to say that
objects have storage duration, lifetime, and type it _follows_ that
certain regions of storage (namely those that happen to be objects) have
storage duration, lifetime, and type.

C.E.

Your C.E. marks here are misplaced. As pointed out above, "object"
and "region of storage" are not on conceptually different levels. However,
that is (as I will agree below) a rather unfortunate state of affairs.

In short: the C.E. marks are whishfull thinking (and I share the wish.

Shall we discuss angels & their sizes?

Unfortunately, I have not much to contribute to that discussion since I
have no experience with angels whatsoever. But please feel free to share
any insight you might have.

I hope I'll never encounter a materialist or a non-materialist for real,
if it's true they are folks who agree that such an inference would be
valid.

I'm somewhat frightened by insane people.

It's not at all insane. It's just the way identity statements generally
work. If X=Y, you can infer p(Y) from p(X). If you want to avoid the
conclusion, the correct way is not charging people making the inference
with insanity; the correct way is to rephrase the hypotheses so that
unwelcome conclusions are avoided. This goes even more if the hypotheses
are just definitions.

BTW: there are some cases where X=Y and p(X) does not imply p(Y). For
instance, at some point I believed that the number of planets orbiting the
sun is 9. Now, science tells us that it is 10 (or whatever the current
number is). Of course, I did not believe that 9 is 10. This phenomenon is
known: certain words such as "believe" span special contexts.

A region of storage may be part of many objects, with different types.
Yes, and nothing in the proposed definition of "object" would
contradict that.
It does.

How so? Let's say you have an object x of type T which has a member x.a
of type S. Also, suppose that x_ptr is a char* so that

[x_ptr, x_ptr+sizeof(T) )

_is_ the object X and a_ptr is a char* so that

[a_ptr, a_ptr + sizeof(S) )

_is_ the object x.a. Then the region [a_ptr, a_ptr+sizeof(S) ) has type S
and the region [x_ptr, x_ptr + sizeof(T) ) has the type T. Of course,
that even goes when the two regions of storage coincide. BTW: in that
case, x and x.a _are_ the same(!) object according to the standard (which
makes more sense that one might think at first: after all any change to x
will affect a).

Think about what you have ended up with: two different objects of
different types, created at different times, that are or are not
identically the same object depending on whether their sizes are the same.

You might also wish to think about what that means for construction and
automatic destructor calls.

It really makes a mess of that.

Thinking about it more, I had come to similar conclusions. I started
worrying mostly about life-time issues because although one could live with
object (as regions of storage) having multiple types, it would be much
harder to deal with the same object having different life-times.

No, a statement that has a reasonable general interpretation does not
necessarily mean an unreasonable special case interpretation.

Then, what is your interpretation of the _definition_ "an object is a region
of storage". I can see many nice interpretations of such a statement that
would avoid the above consequences, however, none of those interpretations
qualifies as a _definition_; and that is what makes it tricky. Definitions
fix the meanings of terms, that is, they are conceptual stipulations. If
you put "is" into a definition, you should mean it

Even if some
politicians think that's possible. "I did not have sex with that woman",
hey, must be generally true, because it's true according to my own very
special case interpretations of "sex" and "that" and "woman".

However, it doesn't matter, for it goes only to the practical reason why
regions of storage are not regarded as having types.

Understanding the difference between storage (untyped) and object
(typed) is
fundamental. For example, a void* doesn't point to storage of type void.
But it's no big deal to take that untyped storage and make an object out
of it via e.g. placement new.

I think it's wrong of you to try to sow confusion about this
distinction.

You may not like the conceptual identification of objects with regions of
storage, but the italics in the standard [1.8/1] make it very clear that
the statement "An object is a region of storage" is meant as a definition
of the term object.

Yes. Although that does not hold for all uses of italics, nor of all the
places where they forgot them.

Since it is supposed to be a definition, it makes an
identification on the conceptual level (for better or worse).

C.E.

Huh?

I can see the kind of understanding that motivated the C.E. marks above.
However, the statement

if "a is b" is put forth as a definition it makes an identification
on the conceptual level

is not a category error. (It still might be too bold or general and
therefore false, but that is a different matter.)

Now you're talking, except that the proposed wording is nearly just as bad
as the one we're discussing, which is due to a faulty conceptual
foundation. The static type is not associated with the region (a runtime
concept). The static type is associated with a name in the source code
(compile time). Concentrate on that before starting to veer off into
dynamic type. Essentially, "storage" is wholly and only a runtime concept,
while the "object" concept is a bridge over to the compile time view, how
we choose to think of the storage in one particular context, including
(the type) restrictions on possible operations.

Well, the notion of "object" that you are proposing is certainly attractive.
It is not the one put forth in [1.8/1], but I think it would make perfect
sense to rework [1.8/1] in that direction.

BTW: I don't think the identification is actually all that harmful. The
standard is not a book to teach C++ but just a specification that should
allow one to deduce the observable behavior of C++ programs. I do not
(yet) see how that [1.8/1] or my interpretation of it negatively impacts
on that.

Having a conceptual foundation that leads to incorrect conclusions (such
as your identification of two different objects as the same object),

It's not an incorrect conclusion, it's an unwelcome consequence. Don't shoot
the messanger

and
that precludes forming some correct conclusions, and that stands in the
way of insights and general understanding, as well as understanding what
the heck other people are talking about, and learning new stuff, is
ungood.

Well, it's even more ungood if it stands in the way of making sense of the
rest of the standard. And at least with regard to life-time, it seems to do
exactly that.



Best

Kai-Uwe Bux

 

[Matthias Buelow]

Maybe. The standard could say "An object occupies a region of storage" or
"An object has a region of storage". But the standard chose to use "is" and
thereby chose to identify objects and their regions of storage on a
conceptual level. Whether that decision is _wise_ is a different matter.

Well, the question would be: does the object still exist if it had been
written to tape when the computer has been melted and turned into cola
cans? The above wording avoids such (purely philosophical, of course)
questions, because they're meaningless in the discussion of a running
C++ program.