Programming Puzzle

[Kai-Uwe Bux]

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."

This definition has a funny consequence: the variable *is* the object. The
reason is that if some expression is the "name of X", then this expression
"denotes X". Since the "name of the variable" is supposed to "denote the
object", the object better be the variable. Below, you seem to adopt this
point of view.

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."

Somewhere else, I proposed:

"A variable is an identifier denoting an lvalue."

The difference is that I consider the variable to be the identifier not the
object it designates.However, the standard seems to side with you.

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.

Correct.

What about non-const reference parameters? Are those variables? I have the
strong inclination to think of parameters as local variables initialized by
the caller.


Best

Kai-Uwe Bux

 

[Howard]

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

It's obviously impossible, since your own definition/opinion of what a
variable is precludes the possibility.

You're still arguing a point of terminology that's wholly irrelevant to the
stated problem. All of this nonsense started as a debate about swapping two
integer values (not swapping two variables). The issue was simply
ill-phrased (at some point earlier) in an attempt to point out a problem
where those two values reside at the same memory location. Someone slipped
up and referred to this as two "variables" sharing the same location, and
now the newsserver is filling up with this silliness.

What possible sense is there in this conversation continuing down this
path???

-Howard

 

[Kai-Uwe Bux]

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?

Sure thing,

I will go by the more restrictive definition from now on:

A variable is an identifier denoting an lvalue.


1) References:

int i = 5;
int& j = i;

In this case, "i" and "j" are two different identifiers, hence different
variables. This example illustrates that I think of the variable as the
*name* and not the object itself. Since the names are different, I consider
these different variables.


2) Call by reference parameters:

void some_function ( int & a, int & b ) {
...
}

Here "a" and "b" are identifiers that might or might not refer to the same
memory location, depending on how the function is called. If this is called
like

some_function( i, i );

then "a" and "b" will refer to the same memory location.

I should add that I have the strong inclination to think of parameters as
local variables that initialized by the caller.


Best

Kai-Uwe

 

[Gordon Burditt]

Please describe (in code) a situation where two variables share

the same memory

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

Could you please provide your definition of "variable"?

I'll provide mine: modifiable lvalue.

By this definition, these are variables:

foo.a (where foo is a struct or union)
foo[1] (where foo is an array of dimension at least 2)
foo[j] (where foo is an array, and j is in range)
foo[k] (where foo is an array, and k is in range)

AND, I'll claim that foo[j] and foo[k] are variables, and they
are usually different variables (occupy different memory), but
they could refer to the same memory if j == k.

Gordon L. Burditt

 

[Ioannis Vranos]

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?

To help all people involved in this really boring discussion, here are
some definitions of the standard:


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


"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.

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.

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.

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 sub-object; an
object of a most derived class type is called a most derived object.

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.

[Note: C++ provides a variety of built-in types and several ways of
composing new types from existing types (3.9). ]"






Regards,

Ioannis Vranos

 

[Scott Jacobsen]

int main (void)
{
if (printf("Hello World")) {}

/* Only needed for C90 compliance */
if (exit(EXIT_SUCCESS),1){}
}

Here was my less elegant solution. But I didn't even use anything that
looks like a ';'. (commas look a lot like semicolons...)

#include <stdio.h>
#include <stdlib.h>

int main() {
while(printf("hello\n") && 0) {
}
while(((int (*)(int))(exit))(0) || 1) {}
}

 

[Scott Jacobsen]

Those BS interviews asking about how to twiddle bits are a
waste of time. If I can't recall an exact algorithm, I just
look it up in one of my many reference books, including the
3 volumes of Knuth. The overall approach to solving a problem
and how I think about designing a solution is what's really
important. Don't sweat the small things, that's what junior
programmers are for.

When an interviewer uses these types of questions correctly they are
trying to see how you think. They aren't looking for the exact (or
even a correct) answer or exact syntax, but that you understand the
fundamentals the question is based on and that you can reason through
problems. Getting the right answer isn't the point.

Unfortunately these types of questions are often abused by people who
don't know how to interview. And if they don't ask anything but
bit-twiddler questions that's also a problem.

 

[Julie]

It's obviously impossible, since your own definition/opinion of what a
variable is precludes the possibility.

You're still arguing a point of terminology that's wholly irrelevant to the
stated problem. All of this nonsense started as a debate about swapping two
integer values (not swapping two variables). The issue was simply
ill-phrased (at some point earlier) in an attempt to point out a problem
where those two values reside at the same memory location. Someone slipped
up and referred to this as two "variables" sharing the same location, and
now the newsserver is filling up with this silliness.

What possible sense is there in this conversation continuing down this
path???

Virtually none.

I've learned what I needed to regarding the topic, including some new stuff on
unions (I'll freely admit that I've only consequentially used them when using
sockets, other than that, I've never had the need).

I've had my fill...

 

[Dik T. Winter]

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

Technically the case hinges on the definition of "variable", which C does
not give. Let Julie show the implementation of a swap function of two
"variables" in C, and after that we can look further.

 

[Julie]

Technically the case hinges on the definition of "variable", which C does
not give. Let Julie show the implementation of a swap function of two
"variables" in C, and after that we can look further.

Actually, the original says "two numbers" -- it disintegrated into 'show me two
variables that have the same memory location' soon afterward.

It has been shown that two variables can have have the same memory location
using unions. Therefore, in order to successfully use the XOR swap trick, the
precondition needs to be: uses two variables that do not share the same
address.

-end

 

[Foobarius Frobinium]

(e-mail address removed) (Dan Pop) wrote in message

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.

It is one thing to point out what the standard says, what messages
should be there, etc. It is another thing to get into a harsh argument
about it with someone else.

 

[Mabden]

In <[email protected]>

Sez who?


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.

Actually, it is the OP's question that I answered.

Let me help you out be repeating the question and answer for you, Dan.
Q. "What will happen if I compile and run this program??"
A. "You'll get a warning saying main() has no return value."

Do you see a question about standards or committees? No, just "what will
happen". So I showed a specific case of what would happen. Others have
reported their results of what happened.

Theory was not requested, not a specific implementation. On my box, that is
what will happen.

YMMV! ;-) Lighten up, Dan.

 

[Dan Pop]

Actually, it is the OP's question that I answered.

Let me help you out be repeating the question and answer for you, Dan.
Q. "What will happen if I compile and run this program??"
A. "You'll get a warning saying main() has no return value."

Do you see a question about standards or committees? No, just "what will
happen". So I showed a specific case of what would happen. Others have
reported their results of what happened.

The OP question was generic! He didn't ask "what will happen if *you*
compile and run this program?", did he? You can't provide an equally
generic answer based on the behaviour of your compiler. Such an answer
must be based on the C language definition.

Furthermore, the specific behaviour of one compiler or another is usually
considered off topic in this newsgroup, you need a *good* reason for
invoking your compiler's behaviour.

Theory was not requested, not a specific implementation. On my box, that is
what will happen. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Did the OP ask what will happen on *your* box? If not, what *exactly* is
your point, especially since you're admitting yourself that the question
was not about a specific implementation?

YMMV! ;-) Lighten up, Dan.

Stop behaving like an idiot and I'll lighten up ;-)

Dan

 

[Dan Pop]

Here was my less elegant solution. But I didn't even use anything that
looks like a ';'. (commas look a lot like semicolons...)

#include <stdio.h>
#include <stdlib.h>

int main() {
while(printf("hello\n") && 0) {
}
while(((int (*)(int))(exit))(0) || 1) {}

^^^^^^^^^^^^^^^^^^^^^^^^^
Undefined behaviour. You can convert the address of exit to an
incompatiple function pointer type, but you cannot dereference the
result without invoking undefined behaviour. Your code is akin to
calling exit() without including <stdlib.h> in C89: you can't call
a void function as if it were an int function.

It is not possible to call a void function in such a program without
using the comma operator. Fortunately, no C or C++ standard requires
the function main to terminate through an exit call or a return statement.

}

Dan

 

[Dan Pop]

<my two cents>

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

Nope, the discussion was about "variables".

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.

As long as c.l.c is still an imperfect ivory tower (i.e. it still has
connections with the real world) it is highly unrealistic to ignore
popular CS jargon terms like "variable" and "global", simply because the
C standard itself doesn't use them.

By the time c.l.c is officially decreed a select club of initiated
regulars, there would be no need to ban these terms, because no one would
use them, anyway.

I guess similar considerations apply to c.l.c++...

Dan

 

[Karl Heinz Buchegger]

That said, I would not place the equality/inequality check for the
possibility of the same variable passed in mind, but for efficiency.

If you have efficiency in mind, you better leave out the comparison
until tests show that the 'problem' it solves really happens that
often, that it makes a difference.

In any ordinary program one would not expect that special case to
happen very often. I would estimate around 1 out of 100 where this
'optimization' shortcut really is taken. That means: you slow down
99 cases just to speed up 1 case.

Same with the comparison for equality in an operator= (Sorry for
being off topic in comp.lang.c). If it is written exception safe,
there is no need for the test with 'this'. Especially not for
optimizaztion, since the case you are optimizing doesn't happen
that often in any typical program. But all other cases suffer
from a needless comparison.

 

[RoSsIaCrIiLoIA]

std::next_permutation and std:rev_permutation. An example:
#include <algorithm>
#include <string>
#include <iostream>


int main()
{
using namespace std;

string s="abcd";


do
cout<<s<<endl;
while(next_permutation(s.begin(), s.end()));
}

and if
unsigned s={12222, 839939, 9393999, 9099999, 98394763, 89383883};
Next_permutation is ok?
if not for me next_permutation==fuochino, deve essere modificata
esiste una soluzione non ricorsiva

 

[Dan Pop]

Yeah. I know. But it works on my system And exit never returns, so there
is no reason to worry about the return value (or lack there of).

Wrong (even if it works on your system). The invocation procedure of a
void function need not be the same as the invocation procedure of an
int function. Invoke the function the wrong way and chaos may occur.

All you
have to worry about is that the next instruction is that start of the exit
function.

And you have no guarantee about that, once you have invoked undefined
behaviour.

After that nothing matters.

After invoking undefined behavior you can't rely on the function you
intended to call being actually called. It's as simple as that.

Dan

 

[RoSsIaCrIiLoIA]

and if
unsigned s={12222, 839939, 9393999, 9099999, 98394763, 89383883};
Next_permutation is ok?

unsigned *s = {12222, 839939, 9393999, 9099999, 98394763, 89383883};

if not for me next_permutation==fuochino, deve essere modificata
esiste una soluzione non ricorsiva

it is wrong excuse me

 

[Irrwahn Grausewitz]

Nope, the discussion was about "variables".

Then, pray tell, how is the term "variable" defined, WRT to the C
language? Those who were using it were actually talking about named
objects, *technically*. However, except for C++, the term variable
isn't officially defined to mean "named object".

As long as c.l.c is still an imperfect ivory tower (i.e. it still has
connections with the real world) it is highly unrealistic to ignore
popular CS jargon terms like "variable" and "global", simply because the
C standard itself doesn't use them.

It's indeed highly unrealistic to expect everyone to avoid those
terms. However, a quick look in the archives shows that the use of
correct, well-defined terms, instead of sloppy jargon, serves well to
reduce the risk of confusion. What's wrong with object, external
linkage, file scope, etc.pp., after all?

Regards