Programming Puzzle

D

Dan Pop

In said:
Well, you should, depending on compiler flags.

Sez who?
gcc -Wall gives you:

foo.c: In function `main':
foo.c:10: warning: control reaches end of non-void function

Add a -std=c99 to your gcc invocation and the warning goes away.

My point was that it is sheer nonsense to say "you'll get a warning about
that" if the standard doesn't *require* a diagnostic.

I entirely agree that the code deserves a diagnostic, even when compiled
in C99 mode, but this is something completely different.

Dan
 
D

Dan Pop

In said:
I'll retract my statement -- I'll agree that a union does allow for two
variables to share the same memory address.

And, if you think even harder, you'll realise that it's the same thing
with pointers: *p and *q are two different variables, but they may share
the same memory address, depending on how the p and q variables have been
initialised (e.g. one may be pointing to one member of the union, the
other may be pointing to the other member of the union mentioned in the
union example :)

Dan
 
D

Dan Pop

In said:
C++'s std::vector for example is of variable length, however usage in
the style:

vector<int> somearray(5);

is too common.

Which has nothing to do with *your* usage of the term VLA, which has a
very well defined meaning in C99.
I do not know/have understood what "trap representations" actually are,
however in C++98 it is guaranteed to be safe to read POD types as
sequences of chars and unsigned chars:

It doesn't matter: in the common subset of the two languages, it is
*always* the most restrictive language that "wins".

However, if C++ allows one's complement and sign-magnitude, the guarantees
about plain char are a lie: because -0 and +0 are different
representations of the *same* value and you're effectively losing
information when reading a byte through a plain char: bytes with all
bits zero and bytes with all bits one will be read as having the *same*
value. And if you copy this value to another place, you have no guarantee
that the same representation will be used.

That is, assuming that plain char has the same semantics in both
languages: a type *different* from both signed char and unsigned char, but
sharing the semantics of one of them.

Dan
 
R

Rob Williscroft

Dan Pop wrote in in comp.lang.c++:
However, if C++ allows one's complement and sign-magnitude, the
guarantees about plain char are a lie: because -0 and +0 are different
representations of the *same* value and you're effectively losing
information when reading a byte through a plain char: bytes with all
bits zero and bytes with all bits one will be read as having the
*same* value. And if you copy this value to another place, you have
no guarantee that the same representation will be used.

In C++ plain char is allowed to have the same representation and
symantics as unsigned char.

Its required that char and unsigned char be usable as "raw-memory".

Conclusion: on a one's compliment/signed magnitude machine char has
the same representation and symantics as unsigned char.
That is, assuming that plain char has the same semantics in both
languages: a type *different* from both signed char and unsigned char,
but sharing the semantics of one of them.

Yes.

Rob.
 
J

Julie

Dan said:
And, if you think even harder, you'll realise that it's the same thing
with pointers: *p and *q are two different variables, but they may share
the same memory address, depending on how the p and q variables have been
initialised (e.g. one may be pointing to one member of the union, the
other may be pointing to the other member of the union mentioned in the
union example :)

Negative. I do not consider pointers or references that point to the same
variable to *be* the same variable. In your example, yes _p_ and _q_ are
variables, _*p_ and _*q_ are not, they merely (may) point to 0 or more
variables.
 
J

Julie

pete said:
In post
http://groups.google.com/[email protected]
in the function n_sort, the variable (*node),
has the same address as either (tail) or (head) after this line:

node = GT(head, tail) ? &tail : &head;

Try again.

No *variable* is sharing the same address. Node, head, and tail all have
different addresses, unless you can say that any of the following is true:

&node == &head == &tail

It doesn't matter what node _points_ to, it matters where node _is_.

Under your logic, the following two variables:

int a = 1;
int b = 2;

become the _same_ same variable with the following:

b = 1;

Surely you don't now consider a and b the same _variable_, do you?

Remember, we are talking about _addresses_ of variables, not the _value_ of
variables.
 
J

Julie

Howard said:
Haven't we beaten this dead horse long enough???

-Howard

No, just getting started.

Those that are not interested in the outcome or further discussion of this
topic/thread, are welcome to ignore the thread in their newsreader. In
Netscape (4.x), press 'K' and you will not be bothered any more w/ our
senseless blather on swapping and the (dis)similarity of variable addresses.
 
J

JKop

Julie posted:
No, just getting started.

Those that are not interested in the outcome or further discussion of
this topic/thread, are welcome to ignore the thread in their
newsreader. In Netscape (4.x), press 'K' and you will not be bothered
any more w/ our senseless blather on swapping and the (dis)similarity
of variable addresses.

I'm a variable.


-JKop
 
D

Dan Pop

In said:
Negative.

I see: I was pushing your thinking capabilities too hard ;-)
I do not consider pointers or references that point to the same
variable to *be* the same variable. In your example, yes _p_ and _q_ are
variables, _*p_ and _*q_ are not, they merely (may) point to 0 or more
variables.

Wrongo! *p and *q don't point to anything (unless p and q are pointers to
pointers), they are as "variables" as you can get. It is p and q that
point to variables.

Dan
 
K

Kai-Uwe Bux

Julie said:
No, just getting started.

Those that are not interested in the outcome or further discussion of this
topic/thread, are welcome to ignore the thread in their newsreader. In
Netscape (4.x), press 'K' and you will not be bothered any more w/ our
senseless blather on swapping and the (dis)similarity of variable
addresses.

Hi,


may I offer a tentative definition for the term "variable" that hopefully
describes the way I use the term: To me a variable is a textual
representation of an lvalue within a piece of source code. The lvalue
condition distinguishes variables from arbitrary expressions. A variable
can change its value, and the basic means of accomplishing that is the
assignment. For instance, I consider "*p" a variable whenever "p" deontes a
pointer to something non-const.

It is clear from the definition I gave that there can be literally
thousands of variables that refer to the same memory location.

What is your prefered definition of variable?


Best

Kai-Uwe Bux
 
I

Irrwahn Grausewitz

Julie said:
Try again.

No *variable* is sharing the same address. Node, head, and tail all have
different addresses, unless you can say that any of the following is true:

&node == &head == &tail

It doesn't matter what node _points_ to, it matters where node _is_.

Under your logic, the following two variables:

int a = 1;
int b = 2;

become the _same_ same variable with the following:

b = 1;

Surely you don't now consider a and b the same _variable_, do you?

Remember, we are talking about _addresses_ of variables, not the _value_ of
variables.

<my two cents>

1. Technically, the discussion is about objects, identifiers that
designate/denote objects (aka variable names in C++), and values.

2. Julie is right, insofar as no two distinct identifiers can
designate the same object - with the obvious exception of union
members, but consider: union { int a, b; } u, *up = &u;
Now u.a, u.b, up->a and up->b denote the same object, but they are
*not* identifiers that denote objects, but expressions consisting
of two operands and one operator each. The member designators a
and b cannot be used in their own right to denote an object, they
can only appear as second operand of the . or -> operator.

3. The others are right, in that two pointer objects can reference the
same memory location (= have the same value, just like two ints
can hold equal values). This however has no bearing on the "swap a
variable with itself" issue: swapping the pointer values won't work
portably with XOR anyway, and using indirection to access the
pointed-to object involves an expression that is *not* a variable.

4. The infamous "swap with XOR" method has not only limitations WRT
the type of the operands [*], it's also broken by design, because
it fails to correctly swap the value of an object (sic!) with
itself.

5. I suggest to drop the term "variable" all together, *especially* in
cross-posts between c.l.c and c.l.c++, since it's not defined at
all in the C standard and IMHO somewhat vaguely defined in the C++
standard.


[*] Modulo accessing the representation of each operand byte-per-byte
through a pointers to unsigned char.

</my two (actually five ;-) cents>

Regards
 
J

Julie

Dan said:
I see: I was pushing your thinking capabilities too hard ;-)


Wrongo! *p and *q don't point to anything (unless p and q are pointers to
pointers), they are as "variables" as you can get. It is p and q that
point to variables.

We disagree.
 
J

Julie

Kai-Uwe Bux said:
Hi,

may I offer a tentative definition for the term "variable" that hopefully
describes the way I use the term: To me a variable is a textual
representation of an lvalue within a piece of source code. The lvalue
condition distinguishes variables from arbitrary expressions. A variable
can change its value, and the basic means of accomplishing that is the
assignment. For instance, I consider "*p" a variable whenever "p" deontes a
pointer to something non-const.

It is clear from the definition I gave that there can be literally
thousands of variables that refer to the same memory location.

What is your prefered definition of variable?

I don't consider "*p" a variable under any circumstances. p is the variable,
*p is merely a derefrence that may point to something.

Forget the pointers for a moment. Do you consider the following the same
variable?

int a = 1;
int b = 1;

or how about:

int * p = (int *)0x12345;
int * q = (int *)0x12345;

or finally:

int c = 1;
int * r = &c;
int * s = &c;
 
K

Kai-Uwe Bux

Julie said:
I don't consider "*p" a variable under any circumstances. p is the
variable, *p is merely a derefrence that may point to something.

Now, I know one thing that you do not consider a variable. What I am
longing for is a definition. Then I could try to construct examples more to
your liking.
Forget the pointers for a moment. Do you consider the following the same
variable?

I have not offered a definition for the phrase "the same variable".
However, if you want I can explore the consequences of the definition I
proposed. In fact, that might help to illustrate the definition.
int a = 1;
int b = 1;

"a" and "b" are different variables.
or how about:

int * p = (int *)0x12345;
int * q = (int *)0x12345;

"*p", "*q", "p", and "q" are four pairwise different variables.
or finally:

int c = 1;
int * r = &c;
int * s = &c;

"c", "*r", "*s", "r", and "s" are five pairwise different variables.

So here is the explanation:

I defined variables to be "textual representations of lvalues". Thus, "a"
and "b" will always never be the same variable since they just differ as
"textual representations". Only two occurences of the same chunk of text
can qualify as "the same variable".


Again, I would like to know about your definition. From what you said about
pointers, I might guess one:

A variable is an identifier denoting an lvalue.

This is clearly more restrictive than what I proposed. According to this
definition, "*p" would not be a variable. Is that the definition you want?


Best

Kai-Uwe Bux
 
I

Irrwahn Grausewitz

Kai-Uwe Bux said:
Julie wrote:

[Discussion about what constitutes a variable]
may I offer a tentative definition for the term "variable" that hopefully
describes the way I use the term: To me a variable is a textual
representation of an lvalue within a piece of source code. The lvalue
condition distinguishes variables from arbitrary expressions. A variable
can change its value, and the basic means of accomplishing that is the
assignment. For instance, I consider "*p" a variable whenever "p" deontes a
pointer to something non-const.

It is clear from the definition I gave that there can be literally
thousands of variables that refer to the same memory location.

What is your prefered definition of variable?

For c.l.c++: I think the definition from the standard should apply:

"A variable is introduced by the declaration of an object.
The variable's name denotes the object."

For c.lc: there's no definition of the term variable.

Personally, I'm not happy with both versions. I'd rather go with
something like:

"A variable is a modifiable object which is designated
by its declared name."

However, with neither definition *p is a variable, though it's an
expression that evaluates to an lvalue designating an actual object,
provided the variable p (sic!) holds a valid pointer value.

Regards
 
J

Julie

Kai-Uwe Bux said:
Now, I know one thing that you do not consider a variable. What I am
longing for is a definition. Then I could try to construct examples more to
your liking.

I've deliberately not defined what I think a variable is, as I don't have a
ready-made definition that has been completely evaluated. Regardless, I know
what a variable *isn't*, and that is what I've been focusing on.

Can you give me an example (other than unions and placement new) of _two_
variables that have the same memory location?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,820
Latest member
GilbertoA5

Latest Threads

Top