Velocity Reviews > Re: Compatibility question

# Re: Compatibility question

BartC
Guest
Posts: n/a

 10-24-2012
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:

> int foobar;

> int foobar;
> {
> double foobar;
> }

You're confusing things with these lexical matters. (The first two foobars
can't coexist as written, while the last shadows the second. Compilers are
paid to sort these things out for you.)

> Either I'm completely misunderstanding you, or you have a very
> odd definition of the word "variable", and one that's inconsistent
> both with the way the standard uses the word in a few footnotes,
> and with the idea of something that's "able to vary".

Let's take these examples:

int abc = 67;
enum {def = 777};
9200; /* The constant 9200 */

The type of the 67 in abc, the 777 of def, and the 9200 are, presumably, int
in all three cases. This implies that they have equal status, yet the abc
name allows you to do &abc, and it can be used as an lvalue; you can't do
this with def or 9200.

And examining any output code, def and 9200 will probably both be immediate
operands, while the 67 of abc likely has to be fetched from memory.

I'm just saying that imagining the name 'abc' actually has an int* type,
which the compiler dereferences for you to yield the int value, can help
explain the difference.

(This stuff is the same in a lot of languages. So it's not so useful to be
sidetracked by having to only use C standard terminology.)

>>> I suspect it's best to let ST explain what he means.

I expect the above not what he had in mind though.

--
Bartc

Greg Martin
Guest
Posts: n/a

 10-24-2012
On 12-10-24 01:20 PM, Steve Thompson wrote:
> On Tue, Oct 23, 2012 at 03:53:21PM -0700, Keith Thompson wrote:
>> Steve Thompson <(E-Mail Removed)> writes:
>>> On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
>>>> Steve Thompson <(E-Mail Removed)> writes:
>>>>> On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
>>>> [...]
>>>>>> Whatever goes on under the hood (and I'd dispute that 'a' is "really a
>>>>>> pointer") it's much easier to learn a language in its own terms, at
>>>>>> least as far as that's possible.
>>>>>
>>>>> Well, no. 'a' is never a pointer as such in the terms of the language
>>>>> syntax, but its treatment by the compiler internally is nominally
>>>>> equivalent to they way it handles a pointer, with the exception that
>>>>> the language grammar forbids its use in the program text as a pointer.
>>>>
>>>> I don't believe that's true. Do you have some evidence that it is?
>>>
>>> The distinction is largely moot. In a practical sense, all variables
>>> have a value which is stored somewhere. The compiler is making an
>>> explicit use of a pointer when it does something with the value. The
>>> problem is that "use" in this context may as well be referring to ether
>>> or memory and there's no easy way of knowing which it is.

>>
>> When you say "explicit use of a pointer", do you mean that there's
>> a pointer *object* somewhere, or are you talking about a pointer
>> *value*, also known as an "address"?

>
> I suppose address is the better term, but that does not work for
> registers.
>

I know I should stay out of this. It seems a bit of a train wreck but
.... I strikes me that it does work for registers and points (bad choice
of word I know) to a fundamental use of the word pointer. A register can
hold either an address that points to a value or it can hold the value
itself, should the value be the sort that fits. The same can be said of
memory locations. They can hold a pointer to some location where a value
is stored or can hold the value itself. A name in assembly can refer to
an area of memory that holds value. You can refer to that value using
the name or you can refer to the address where the memory is.

To me this is the pretty much in keeping with the idea, in C, that <int
a> will hold a value and <int *a> will hold the address of a value. C
semantics or otherwise this seems a fairly widely used idiom of speech.
Is there really a reason to come up with a new way to view it?

Keith Thompson
Guest
Posts: n/a

 10-24-2012
James Kuyper <(E-Mail Removed)> writes:
> On 10/24/2012 05:38 PM, Keith Thompson wrote:
> ...
>> ... This is comp.lang.c, where we
>> discuss the C programming language, which is defined by the ISO C
>> standard, which has an unambiguous meaning for the word "pointer".

>
> Well - sort of. In different contexts it uses the term "pointer" to mean
> either a pointer object or a pointer value. I've found it useful,
> particularly in this newsgroup, to be more careful about that
> distinction than the standard itself is.

That's a good point. But the standard's use of the term doesn't
extend beyond objects, values, and perhaps expressions and types,
of C pointer types.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson
Guest
Posts: n/a

 10-24-2012
Steve Thompson <(E-Mail Removed)> writes:
[...]

Steve, it's been brought to my attention that you're posting under the
same e-mail address used by "Uncle Steve". I presume you're the same
person. I killfiled you some time ago for being rude and vulgar
in the unlikely event that anyone cares).

I've replied to recent articles only because you're now posting under a
different name, and my newsreader didn't notice.

This recent discussion hasn't been constructive anyway, and I won't
continue it unless I see a very good reason to do so. (Others will do
as they choose.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson
Guest
Posts: n/a

 10-24-2012
"BartC" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:

>
>> int foobar;

>
>> int foobar;
>> {
>> double foobar;
>> }

>
> You're confusing things with these lexical matters. (The first two foobars
> can't coexist as written, while the last shadows the second. Compilers are
> paid to sort these things out for you.)

The two code snippets were intended to be independent, and were meant to
clarify what you mean by the word "variable". I still don't know what
you mean by the word. Can you provide a definition?

>> Either I'm completely misunderstanding you, or you have a very
>> odd definition of the word "variable", and one that's inconsistent
>> both with the way the standard uses the word in a few footnotes,
>> and with the idea of something that's "able to vary".

>
> Let's take these examples:
>
> int abc = 67;
> enum {def = 777};
> 9200; /* The constant 9200 */
>
> The type of the 67 in abc, the 777 of def, and the 9200 are, presumably, int
> in all three cases.

They aren't just "presumably" of type int, they *are* of type int. I
can cite the standard if you like.

> This implies that they have equal status,

No, it merely implies that they have the same type.

> yet the abc
> name allows you to do &abc, and it can be used as an lvalue; you can't do
> this with def or 9200.

Yes, because abc is (the name of) an object, and def and 9200 are not.

> And examining any output code, def and 9200 will probably both be immediate
> operands, while the 67 of abc likely has to be fetched from memory.

Quite possibly. It's also possible that the object abc could be stored
in a CPU register, or that a reference to abc can be replaced by the
equivalent of a literal 67 if the compiler can prove that its value
hasn't changed since it was initialized. So what?

> I'm just saying that imagining the name 'abc' actually has an int* type,
> which the compiler dereferences for you to yield the int value, can help
> explain the difference.

I strongly disagree. That's simply not the way it's defined. abc is an
object, and the compiler can generate code that refers to its value (a
reference, not a dereference).

> (This stuff is the same in a lot of languages. So it's not so useful to be
> sidetracked by having to only use C standard terminology.)

It's not so useful to use words that are defined by the C standard with
inconsistent meanings, especially here in comp.lang.c. If you're going
to use other terminology here, I suggest it's your responsibility to
define it (if you want to be understood).

>>>> I suspect it's best to let ST explain what he means.

>
> I expect the above not what he had in mind though.

I no longer care what ST had in mind.

But I'm still interested in what you mean by the word "variable".

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

BartC
Guest
Posts: n/a

 10-25-2012
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:

> But I'm still interested in what you mean by the word "variable".

This will be difficult using only definitions in the C standard, to say
nothing of the various exceptions in the language (variables that you can't
apply & to; or names you *can* apply & to, but can't be lvalues; etc.).

I'll instead take an example from a recent compiler project of mine: out of
15 or so classifications of a name (ie. identifier), 3 of those I class as
variables (static variable, frame (auto) variable, and parameter variable).

There are all names of locations that contain a value of type T. In common
with pretty much every HLL, I dereference such a name when used in an
expression, to yield the value of type T the name refers to. When the name
(ie. location) itself is of interest, then the & operator it used to
suppress that dereference, to yield a pointer of type T*. Pretty much
exactly like C so far, if you forget the exceptions.

The frame and parameter variables, of course, can have multiple instances.

(I also have named constants, where the name directly yields the type T
value. A T* pointer is not possible here. I don't support register variables
or named bitfields, but they would anyway have a different classification
from the 3 main types above)

Or the short version: a named object..

--
Bartc

Keith Thompson
Guest
Posts: n/a

 10-25-2012
"BartC" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:

>
>> But I'm still interested in what you mean by the word "variable".

[snip]

> Or the short version: a named object..

Ok, a variable is a named object; that's really all I was looking
for. That's about the same way I think of it. Interestingly,
a const-qualified named object is a "variable", even though it's
not "able to vary". I'm not sure whether a struct or union member
is a "variable" (is "foo.bar" a name?), but I'm not sure how much
that matters.

Your earlier article seemed to imply that a variable is a name, not the
object that name refers to, but I guess that's not what you actually
meant.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse
Guest
Posts: n/a

 10-26-2012
Steve Thompson <(E-Mail Removed)> writes:
<snip>
> My meta-point was basically about the fact that (a) English terminology
> is overloaded, and not merely in relation to programming, and (b) that
> it is useful to think about software, compilers, and programming in
> general terms. There is probably something worthwhile to be had in
> examining the philosophy or metaphysics of computer software and
> programming. I think those who reflexively stomp on discussions that
> move beyond the confines of a single standard or methodology are in
> some way threatened by different ways of thinking about these
> subjects.

Yes, that's possible, but sometimes Brave New Ideas are just wrong.

Sometimes evidence that they are wrong comes directly from their
proponents, such as when you wrote that:

"... conceptually 'a' is still a pointer to the data in the specific
structure identified by 'a'. I found it very confusing when I was
learning C."

(This was in the context of a declaration like "struct point {
int x, y, z; } a;".)

It's no wonder that you found it confusing: it's wrong. It's going to
be a hindrance to learning C to think of 'a' as a pointer when it
isn't one, even "conceptually".

--
Ben.

Phil Carmody
Guest
Posts: n/a

 10-27-2012
Steve Thompson <(E-Mail Removed)> writes:
> No, a char ** object is a pointer to a char ** object.

And I thought Bill was the most woo-woo person on the froup...

If you want to use C in the future, run into a wall at high speed. Forget
everything you know. Relearn from scratch. Correctly this time.

Phil
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

Ben Bacarisse
Guest
Posts: n/a

 10-27-2012
Steve Thompson <(E-Mail Removed)> writes:

> On Fri, Oct 26, 2012 at 01:02:14PM +0100, Ben Bacarisse wrote:
>> Steve Thompson <(E-Mail Removed)> writes:
>> <snip>
>> > My meta-point was basically about the fact that (a) English terminology
>> > is overloaded, and not merely in relation to programming, and (b) that
>> > it is useful to think about software, compilers, and programming in
>> > general terms. There is probably something worthwhile to be had in
>> > examining the philosophy or metaphysics of computer software and
>> > programming. I think those who reflexively stomp on discussions that
>> > move beyond the confines of a single standard or methodology are in
>> > some way threatened by different ways of thinking about these
>> > subjects.

>>
>> Yes, that's possible, but sometimes Brave New Ideas are just wrong.
>>
>> Sometimes evidence that they are wrong comes directly from their
>> proponents, such as when you wrote that:
>>
>> "... conceptually 'a' is still a pointer to the data in the specific
>> structure identified by 'a'. I found it very confusing when I was
>> learning C."
>>
>> (This was in the context of a declaration like "struct point {
>> int x, y, z; } a;".)
>>
>> It's no wonder that you found it confusing: it's wrong. It's going to
>> be a hindrance to learning C to think of 'a' as a pointer when it
>> isn't one, even "conceptually".

>
> I agree that it isn't a pointer in C, but it is an identifier that is
> associated with the structure. With a less restrictive definition of
> 'pointer', it is and the implementation of its actual use in a program
> mimics the semantics of a C pointer, to a certain degree. Since I am
> not using a restrictive definition of 'pointer' in every instance
> where I use the term, I think my statements are logically coherent.

Can you explain what you found "very confusing" when you were learning
C? That might explain what your "'a' is conceptually a pointer" model
helps with. My own view is that, being wrong, it can only obfuscate
matters, but knowing what it helped you with might move things on.

<snip>
--
Ben.