Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #27400 > unrolled thread

Compatibility question

Back to article view | Back to comp.lang.c

Contents

  Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 03:08 +0000
    Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-20 16:20 +1300
      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 11:50 +0100
        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-20 11:41 -0700
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:04 +0000
            Re: Compatibility question Barry Schwarz <schwarzb@dqel.com> - 2012-10-21 20:27 -0700
      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-20 04:01 +0000
        Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:26 +1300
          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 22:54 +0000
            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-22 12:29 +1300
              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-21 23:50 +0000
                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 02:27 +0100
                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 02:28 +0000
                    Re: Compatibility question Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 11:18 -0400
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 16:19 +0000
                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:37 +0100
                        Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:40 +0100
                    Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 17:30 +0100
                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 17:23 +0000
                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 10:52 -0700
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 18:42 +0000
                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 21:06 +0100
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 22:52 +0000
                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 03:33 +0100
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:28 +0000
                                    Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 16:45 +0100
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 17:53 +0000
                                      Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:41 -0700
                                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 21:28 +0100
                                      Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 20:57 +0100
                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 12:26 -0700
                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 20:39 +0000
                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 15:53 -0700
                                      Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 00:57 +0100
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-23 20:06 -0700
                                          Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 11:18 +0100
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 12:04 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-24 23:10 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:58 -0700
                                                  Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-25 01:46 +0100
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 19:40 -0700
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-24 20:20 +0000
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 14:38 -0700
                                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-24 17:55 -0400
                                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:29 -0700
                                        Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-24 15:21 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-26 03:30 +0000
                                            Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 13:02 +0100
                                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-27 00:04 +0000
                                                Re: Compatibility question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 20:15 +0100
                                                Re: Compatibility question Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-10-27 16:36 -0600
                                                  Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:36 +0000
                                          Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 22:42 +0300
                                            Re: Compatibility question Greg Martin <greg@softsprocket.com> - 2012-10-27 14:30 -0700
                                              Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-27 22:57 +0100
                                                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:04 -0700
                                                  Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 17:14 -0700
                                                    Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-27 18:04 -0700
                                        Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-24 16:46 -0700
                                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-25 01:18 +0000
                                    Re: Compatibility question Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-27 21:08 +0300
                                      Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-28 17:38 +0000
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:38 +0100
                            Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 16:50 -0700
                              Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:33 +0000
                        Re: Compatibility question Öö Tiib <ootiib@hot.ee> - 2012-10-22 14:23 -0700
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 17:26 -0400
                          Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 10:55 +1300
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:27 +0000
                        Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-22 22:44 +0100
                          Re: Compatibility question Les Cargill <lcargill99@comcast.com> - 2012-10-22 17:15 -0500
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:13 +0100
                          Re: Compatibility question James Kuyper <jameskuyper@verizon.net> - 2012-10-22 18:35 -0400
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 00:14 +0100
                          Re: Compatibility question Steve Thompson <stevet810@gmail.com> - 2012-10-22 23:42 +0000
                            Re: Compatibility question Ian Collins <ian-news@hotmail.com> - 2012-10-23 13:35 +1300
                          Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-22 17:01 -0700
                            Re: Compatibility question "BartC" <bc@freeuk.com> - 2012-10-23 01:47 +0100
                Re: Compatibility question Keith Thompson <kst-u@mib.org> - 2012-10-21 19:27 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#27530

On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> [...]
> > No annoyance taken, although now that I think of it it does show an
> > instance of overloaded semantics, which can be confusing.  When I was
> > less experienced with C, I was confused by the fact that variables
> > defined as structures were not pointers:
> >
> > struct point {
> > 	int x, y, z;
> > };
> >
> > struct point a;
> >
> >
> > One cannot reference 'a' (as such) in an expression even though it is
> > a pointer in the implementation because C allows one to use structures
> > as arguments to a function.  I'd never do that in my own code, but
> > some people may like the fact that they can pass complex data
> > structures around as if they were simple variables.  I think it wastes
> > resources, but of course that is less of an issue today than it was
> > when C was first developed.
> 
> I'm not sure what you mean when you say `a` "is a pointer in
> the implementation", especially after you mention "the fact that
> variables defined as structures were not pointers".

Meaning that under the hood in the C compiler, 'a' is really a
pointer.  The logic of the compiler causes it to use the structure
data as specified in the standard, but 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.

> Whatever you meant, the fact it that `a` *isn't* a pointer; it's
> the name of an object of type `struct point`, and the name `a`
> certainly can be used in an expression: as the LHS or RHS of an
> assignment, as a function argument, as an argument to `sizeof` or
> `&`, as the left operand of `.`, and probably in other ways that
> I haven't thought of.  Of course `&a` is a pointer (not a pointer
> object, but an expression of pointer type).

True enough, but the difference is that a structure cannot be used for
arithmetic operations of any kind in C.  That makes it fundamentally
different from simple type variables.  It may be meaningful to say that
structures passed to functions as values is a hack in the C language.
It fills a use-case scenario that will be found (or should be found)
only in trivial programs, IMHO.
 
> > These days I'm thinking more and more about cache-line usage, so I am
> > concerned with preserving the 'hotness' of my data.  Copying
> > structures around a whole lot is hostile to this paradigm, so that is
> > one language feature I am happy to avoid.
> 
> If a structure is smaller than a pointer, or not much bigger, it makes
> perfect sense to pass it around by value.

Most structures are considerably larger than a pointer in practice.
My personal opinion is that it is a waste to pass them around by
value in most cases.  Small structures are likely to be associated
with arrays of same, and all that copying will add up in non-trivial
applications.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27534

Steve Thompson <stevet810@gmail.com> writes:

> On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> [...]
>> > No annoyance taken, although now that I think of it it does show an
>> > instance of overloaded semantics, which can be confusing.  When I was
>> > less experienced with C, I was confused by the fact that variables
>> > defined as structures were not pointers:
>> >
>> > struct point {
>> > 	int x, y, z;
>> > };
>> >
>> > struct point a;
>> >
>> >
>> > One cannot reference 'a' (as such) in an expression even though it is
>> > a pointer in the implementation because C allows one to use structures
>> > as arguments to a function.  I'd never do that in my own code, but
>> > some people may like the fact that they can pass complex data
>> > structures around as if they were simple variables.  I think it wastes
>> > resources, but of course that is less of an issue today than it was
>> > when C was first developed.
>> 
>> I'm not sure what you mean when you say `a` "is a pointer in
>> the implementation", especially after you mention "the fact that
>> variables defined as structures were not pointers".
>
> Meaning that under the hood in the C compiler, 'a' is really a
> pointer.  The logic of the compiler causes it to use the structure
> data as specified in the standard, but 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.

I am not surprised.  I would have found it totally baffling when I was
learning C.  I find it baffling even now, having learnt C!

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.

In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
expression, just as if it had been declared to be an int.  trying to
reconcile this with some model that says it's a pointer (when it isn't
one) is bound to be confusing.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27549

On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> 
> > On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> [...]
> >> > No annoyance taken, although now that I think of it it does show an
> >> > instance of overloaded semantics, which can be confusing.  When I was
> >> > less experienced with C, I was confused by the fact that variables
> >> > defined as structures were not pointers:
> >> >
> >> > struct point {
> >> > 	int x, y, z;
> >> > };
> >> >
> >> > struct point a;
> >> >
> >> >
> >> > One cannot reference 'a' (as such) in an expression even though it is
> >> > a pointer in the implementation because C allows one to use structures
> >> > as arguments to a function.  I'd never do that in my own code, but
> >> > some people may like the fact that they can pass complex data
> >> > structures around as if they were simple variables.  I think it wastes
> >> > resources, but of course that is less of an issue today than it was
> >> > when C was first developed.
> >> 
> >> I'm not sure what you mean when you say `a` "is a pointer in
> >> the implementation", especially after you mention "the fact that
> >> variables defined as structures were not pointers".
> >
> > Meaning that under the hood in the C compiler, 'a' is really a
> > pointer.  The logic of the compiler causes it to use the structure
> > data as specified in the standard, but 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.
> 
> I am not surprised.  I would have found it totally baffling when I was
> learning C.  I find it baffling even now, having learnt C!
> 
> 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.
In a simplistic sense, all variables are pointers to a segment of
program data, modifiable or otherwise.  In the real world, variable
values may move around in and from RAM to CPU registers and back while
being identified as a single consistent entity.  This helps to
illustrate the difference between a language and its implementation.

> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
> expression, just as if it had been declared to be an int.  trying to
> reconcile this with some model that says it's a pointer (when it isn't
> one) is bound to be confusing.

I was never happy with the term lvalue or rvalue.  My brain wants to
think in terms of pointers, variables, and values.  Structures defined
as automatic variables don't fit all that neatly in that classification.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27557

Steve Thompson <stevet810@gmail.com> writes:

> On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>> 
>> > On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
>> >> Steve Thompson <stevet810@gmail.com> writes:
>> >> [...]
>> >> > No annoyance taken, although now that I think of it it does show an
>> >> > instance of overloaded semantics, which can be confusing.  When I was
>> >> > less experienced with C, I was confused by the fact that variables
>> >> > defined as structures were not pointers:
>> >> >
>> >> > struct point {
>> >> > 	int x, y, z;
>> >> > };
>> >> >
>> >> > struct point a;
>> >> >
>> >> >
>> >> > One cannot reference 'a' (as such) in an expression even though it is
>> >> > a pointer in the implementation because C allows one to use structures
>> >> > as arguments to a function.  I'd never do that in my own code, but
>> >> > some people may like the fact that they can pass complex data
>> >> > structures around as if they were simple variables.  I think it wastes
>> >> > resources, but of course that is less of an issue today than it was
>> >> > when C was first developed.
>> >> 
>> >> I'm not sure what you mean when you say `a` "is a pointer in
>> >> the implementation", especially after you mention "the fact that
>> >> variables defined as structures were not pointers".
>> >
>> > Meaning that under the hood in the C compiler, 'a' is really a
>> > pointer.  The logic of the compiler causes it to use the structure
>> > data as specified in the standard, but 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.
>> 
>> I am not surprised.  I would have found it totally baffling when I was
>> learning C.  I find it baffling even now, having learnt C!
>> 
>> 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've been around Usenet long enough to recognise the signs.  You are now
100% committed to this point of view and I don't think there's much
point in continuing to debate it.

> In a simplistic sense, all variables are pointers to a segment of
> program data, modifiable or otherwise.  In the real world, variable
> values may move around in and from RAM to CPU registers and back while
> being identified as a single consistent entity.  This helps to
> illustrate the difference between a language and its implementation.
>
>> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
>> expression, just as if it had been declared to be an int.  trying to
>> reconcile this with some model that says it's a pointer (when it isn't
>> one) is bound to be confusing.
>
> I was never happy with the term lvalue or rvalue.  My brain wants to
> think in terms of pointers, variables, and values.  Structures defined
> as automatic variables don't fit all that neatly in that
> classification.

Then surely that's a sign that your "pointers, variables, and values"
classification is unsuitable?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27569

On Tue, Oct 23, 2012 at 03:33:32AM +0100, Ben Bacarisse wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> 
> > On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >> 
> >> > On Mon, Oct 22, 2012 at 10:52:47AM -0700, Keith Thompson wrote:
> >> >> Steve Thompson <stevet810@gmail.com> writes:
> >> >> [...]
> >> >> > No annoyance taken, although now that I think of it it does show an
> >> >> > instance of overloaded semantics, which can be confusing.  When I was
> >> >> > less experienced with C, I was confused by the fact that variables
> >> >> > defined as structures were not pointers:
> >> >> >
> >> >> > struct point {
> >> >> > 	int x, y, z;
> >> >> > };
> >> >> >
> >> >> > struct point a;
> >> >> >
> >> >> >
> >> >> > One cannot reference 'a' (as such) in an expression even though it is
> >> >> > a pointer in the implementation because C allows one to use structures
> >> >> > as arguments to a function.  I'd never do that in my own code, but
> >> >> > some people may like the fact that they can pass complex data
> >> >> > structures around as if they were simple variables.  I think it wastes
> >> >> > resources, but of course that is less of an issue today than it was
> >> >> > when C was first developed.
> >> >> 
> >> >> I'm not sure what you mean when you say `a` "is a pointer in
> >> >> the implementation", especially after you mention "the fact that
> >> >> variables defined as structures were not pointers".
> >> >
> >> > Meaning that under the hood in the C compiler, 'a' is really a
> >> > pointer.  The logic of the compiler causes it to use the structure
> >> > data as specified in the standard, but 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.
> >> 
> >> I am not surprised.  I would have found it totally baffling when I was
> >> learning C.  I find it baffling even now, having learnt C!
> >> 
> >> 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've been around Usenet long enough to recognise the signs.  You are now
> 100% committed to this point of view and I don't think there's much
> point in continuing to debate it.

It's not a big deal; I'm not even sure there's a good reason to
discuss the difference between program objects and their instantiation
in an implementation, which are not defined by the standard.
 
> > In a simplistic sense, all variables are pointers to a segment of
> > program data, modifiable or otherwise.  In the real world, variable
> > values may move around in and from RAM to CPU registers and back while
> > being identified as a single consistent entity.  This helps to
> > illustrate the difference between a language and its implementation.
> >
> >> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
> >> expression, just as if it had been declared to be an int.  trying to
> >> reconcile this with some model that says it's a pointer (when it isn't
> >> one) is bound to be confusing.
> >
> > I was never happy with the term lvalue or rvalue.  My brain wants to
> > think in terms of pointers, variables, and values.  Structures defined
> > as automatic variables don't fit all that neatly in that
> > classification.
> 
> Then surely that's a sign that your "pointers, variables, and values"
> classification is unsuitable?

Or the lvalue/rvalue terminology is ugly.  I have no problem
understanding structures as automatic variables.  My quibble is with
their semantics.

Hypothetically, C might have been designed differently:

struct point {
	int x, y, z;
};

struct point a, b;

a.x = 1;
a.y = 2;
a.z = 3;

With two distinct assignment operators, one might get a copied
structure, or a pointer to the original.

Copy:
	b = a;

By reference:
	b := a;

Someone else wrote a message yesterday suggesting that some languages
have this form of assignment, and indeed with this scheme there is no
ambiguity as to what is really going on.  The difference between C and
this arrangement is in the definition of what 'a' is.  Of course, in
this modified C, we have to decide what to do when passing 'a' or 'b'
to a function, and if I were designing this language for real I might
decide to pass simple types by value, and structures by reference.

I'm not sure which is better in practice.  Quite apart from my
personal programming preference, the language semantics of C probably
make more sense, despite being a little confusing.  A language with
the ':=' operator as above could easily do away with pointer types,
which is an interesting thing to consider.  Without pointers, the '&'
operator could be reused to identify when a variable is being passed
by value or by reference, and thereby do away with the second ':='
assignment operator:

Copy:
	a = b;

By reference:
	a = &b;

In this paradigm variables become somewhat like inodes with a
reference count supporting hard links, at least in the hypothetical
language implementation.

Obviously this isn't C; I'm just thinking out loud about how things
might be done differently.  I would never give up pointers, as they
are the single language feature that allows C to be used to write
operating systems and device drivers, and which allow one to perform
various tricks.  One of my favorite is with an arena allocator for
fixed-sized objects.  The free list is a pointer to the free 'object'
in the array, into which I store a small structure:

struct free_list {
	int size;
	int next;
};


'size' is the size (in 'objects') of the free block, and 'next'
is an offset into the arena where the next free chunk is.  Allocations
are quick because all that is done is to decrement size by one, and
return the offset of the object.  Let's say the header for such an
arena is defined as follows:

struct arena {
	unsigned char 	 *p;
	int              o_size;
	struct free_list *f;
};

struct arena a;
int   o;


an allocation might look something like this:

if(a->f) {
    o = (((unsigned char)a->f - a->p) / a->o_size) + (a->f->size--);
} else {
    return(-1);
}

if(!a->f->size) {
    if(a->f->next != -1)
        a->f = (struct free_list *)((unsigned char *)p + (a->f->next * a->o_size))
    else
        a->f = NULL;
}

That returns an effective index into a->p for an array of objects of
size a->o_size.  There would be an access macro to work out the actual
address of the object.  The scheme can also be modified to return
pointers which can be assigned directly to an arbitrary pointer type.
The following could be encapsulated in a macro to hide the ugly
details from the application program text, or the allocation function
could simply be declared to return a void * type as with malloc().

struct foo *o;

o = (void *)(((unsigned char *) a->f) + (a->f->size-- * a->o_size));


Either one is super fast, and on machines with out a FPU, it's
still quick when o_size is a power of two.  The free operation is
slightly more complicated since I have to walk the free list to find
a free chunk adjacent to the free block, or insert one in the list.
Fragmentation can slow things down quite a lot, but allocations are
always fast, and there is no waste as there is with the standard
malloc.  Coalescing free-list nodes automatically occurs during the
free operation.  The free function trivially detects a bad pointer, as
well as objects which are already free.

This is why I like C.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27581

"Steve Thompson" <stevet810@gmail.com> wrote in message
news:45fj92.pJU.yDawq@gmail.com...

> Hypothetically, C might have been designed differently:
>
> struct point {
> int x, y, z;
> };
>
> struct point a, b;
>
> a.x = 1;
> a.y = 2;
> a.z = 3;

If you're going to the trouble of redesigning the language, at least make it
possible to write:

 a={1,2,3};

> With two distinct assignment operators, one might get a copied
> structure, or a pointer to the original.
>
> Copy:
> b = a;
>
> By reference:
> b := a;

C currently assigns by value, and always does a  shallow copy. The above is
handled as follows:

struct point *A,*B;

A=B;     /* copy by reference */
*A=*B;   /* copy by value */

Where 'reference' and 'value' refer to the targets of the pointers. However
the copy by value is only one level deep. (To do a proper deep copy involves 
recursing through any nested pointers in the struct, which can point to any 
other kinds of objects. It gets hairy, and would be an entirely different 
kind of language. I don't know if that's what you had in mind.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#27596

On Tue, Oct 23, 2012 at 04:45:19PM +0100, BartC wrote:
> "Steve Thompson" <stevet810@gmail.com> wrote in message
> news:45fj92.pJU.yDawq@gmail.com...
> 
> >Hypothetically, C might have been designed differently:
> >
> >struct point {
> >int x, y, z;
> >};
> >
> >struct point a, b;
> >
> >a.x = 1;
> >a.y = 2;
> >a.z = 3;
> 
> If you're going to the trouble of redesigning the language, at least make it
> possible to write:
> 
> a={1,2,3};

I suppose if I was designing a language there's a lot of things I
might do for the convenience of its user community.

> >With two distinct assignment operators, one might get a copied
> >structure, or a pointer to the original.
> >
> >Copy:
> >b = a;
> >
> >By reference:
> >b := a;
> 
> C currently assigns by value, and always does a  shallow copy. The above is
> handled as follows:

I assume you mean to say that a structure defined as in the following
would be copied in its entirety:

struct trapezoid {
  int          colour;
  struct point v[4];
};

> struct point *A,*B;
> 
> A=B;     /* copy by reference */
> *A=*B;   /* copy by value */
> 
> Where 'reference' and 'value' refer to the targets of the pointers. However
> the copy by value is only one level deep. (To do a proper deep copy 
> involves recursing through any nested pointers in the struct, which can 
> point to any other kinds of objects. It gets hairy, and would be an 
> entirely different kind of language. I don't know if that's what you had in 
> mind.)

My ruminations had not gone as far as to consider nested structures
included by reference.  I suppose that with my fictional example, a
copy by value would necessarily include nested structures because the
language might not have pointers.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27598

"BartC" <bc@freeuk.com> writes:
[...]
> A=B;     /* copy by reference */
> *A=*B;   /* copy by value */
>
> Where 'reference' and 'value' refer to the targets of the pointers. However
> the copy by value is only one level deep. (To do a proper deep copy involves 
> recursing through any nested pointers in the struct, which can point to any 
> other kinds of objects. It gets hairy, and would be an entirely different 
> kind of language. I don't know if that's what you had in mind.)

What would a "proper" deep copy do with a recursive data structure,
for example where two nodes point to each other?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27605

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnmwzddlho.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
> [...]
>> A=B;     /* copy by reference */
>> *A=*B;   /* copy by value */
>>
>> Where 'reference' and 'value' refer to the targets of the pointers.
>> However
>> the copy by value is only one level deep. (To do a proper deep copy
>> involves
>> recursing through any nested pointers in the struct, which can point to
>> any
>> other kinds of objects. It gets hairy, and would be an entirely different
>> kind of language. I don't know if that's what you had in mind.)
>
> What would a "proper" deep copy do with a recursive data structure,
> for example where two nodes point to each other?

That's where it gets even more hairy I guess.

My experience of this is with structures and pointers maintained by the
language, where circular definitions don't exist. The deep copy routine can
still be called recursively though. (In fact it's *because* deep copy is
done by assignments, that the pointers were generally well-behaved; this 
could be done without reference counting and without using GC.)

So it probably wouldn't work with explicit pointers controlled by the
programmer.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#27600

"BartC" <bc@freeuk.com> writes:

> "Steve Thompson" <stevet810@gmail.com> wrote in message
> news:45fj92.pJU.yDawq@gmail.com...
>
>> Hypothetically, C might have been designed differently:
>>
>> struct point {
>> int x, y, z;
>> };
>>
>> struct point a, b;
>>
>> a.x = 1;
>> a.y = 2;
>> a.z = 3;
>
> If you're going to the trouble of redesigning the language, at least make it
> possible to write:
>
> a={1,2,3};

You can so something very similar already, though your are obliged to
repeat the type:

  a = (struct point){1, 2, 3};

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27597

Steve Thompson <stevet810@gmail.com> 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?

> In a simplistic sense, all variables are pointers to a segment of
> program data, modifiable or otherwise.  In the real world, variable
> values may move around in and from RAM to CPU registers and back while
> being identified as a single consistent entity.  This helps to
> illustrate the difference between a language and its implementation.

So a char object is really a pointer to char, an int object is
really a pointer to int, and a char** object is really a char**?

I think you're simply adding an extra -- and unnecessary -- level
of indirection, and of confusion.

There may also be some confusion between pointer *objects* and
pointer *values* (i.e., addresses).

If I define an object of struct type and perform some operation
on it (say, a simple assignment), the generated code might very
well refer to the address of the object.  There is no *object*
of pointer type, either explicitly or implicitly.

Struct objects are very often manipulated via pointers (simulating
by-reference argument passing, for example), but that's a coding
convention, not anything inherent to the language.

A struct object is a struct object, just as a scalar object is a
scalar object.  The distinction you see between structs and scalars
doesn't exist.  (Certainly there's a distinction, but it's not the
one you're talking about.)

>> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
>> expression, just as if it had been declared to be an int.  trying to
>> reconcile this with some model that says it's a pointer (when it isn't
>> one) is bound to be confusing.
>
> I was never happy with the term lvalue or rvalue.  My brain wants to
> think in terms of pointers, variables, and values.  Structures defined
> as automatic variables don't fit all that neatly in that classification.

C's definitions of the terms lvalue and rvalue is not consistent with
their original meanings.

Originally, an expression could be evaluated in two different ways,
depending on the context in which it appears.  Given an assignment:

    int x = 42;
    int y;
    y = x;

The expression `x` (on the right side of the assignment, thus
"rvalue") is evaluated *for its rvalue*, which is 42, whereas
the expresison `y` (on the left side, thus "lvalue" is evaluated
*for its lvalue*, which is the identify of the object named "y",
regardless of what value it happens to contain.  (Either can be a
more complex expression, for example `arr[func(42)].member = abs(x)
+ 42;`, so there can be some non-trivial computation involved in
determining an lvalue.)

The C standard changed the meaning of "lvalue", so it refers to the
expression `y` itself, rather than to the result of evaluating it.
The standard doesn't use the term "rvalue" other than in a footnote,
which mentions in passing that an rvalue is the result of an
expression.

See N1337 6.3.2.1.

To oversimplify, an lvalue in C is an expression that designates
an object.  Note carefully that *designating* an object needn't
involve generating a *pointer* to an object, or equivalently
computing the address of an object.  A simple example:

    int x = 42;
    register int y;
    y = x;

`y` is an lvalue, but it refers to an object that has no address.
The same thing happens if `y` is a bit field.

Dropping the "register" keyword doesn't make any real conceptual
difference -- nor does making `x` and `y` structures rather than
scalars.

You're right: "Structures defined as automatic variables don't fit
all that neatly in that classification" (of pointers, variables,
and values).  The problem is not with the language, it's with your
way of thinking about it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27606

On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
> Steve Thompson <stevet810@gmail.com> 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.

> > In a simplistic sense, all variables are pointers to a segment of
> > program data, modifiable or otherwise.  In the real world, variable
> > values may move around in and from RAM to CPU registers and back while
> > being identified as a single consistent entity.  This helps to
> > illustrate the difference between a language and its implementation.
> 
> So a char object is really a pointer to char, an int object is
> really a pointer to int, and a char** object is really a char**?

No, a char ** object is a pointer to a char ** object.
 
> I think you're simply adding an extra -- and unnecessary -- level
> of indirection, and of confusion.
> 
> There may also be some confusion between pointer *objects* and
> pointer *values* (i.e., addresses).

Let me say again that I am not talking about addresses as might be
referenced in object code.  Perhaps it will clarify that I am thinking
of something like the phase space of the compiler as it is building
the tree representing the source code of the program.
 
> If I define an object of struct type and perform some operation
> on it (say, a simple assignment), the generated code might very
> well refer to the address of the object.  There is no *object*
> of pointer type, either explicitly or implicitly.

That could depend on the way the compiler is designed.
 
> Struct objects are very often manipulated via pointers (simulating
> by-reference argument passing, for example), but that's a coding
> convention, not anything inherent to the language.

Agreed.
 
> A struct object is a struct object, just as a scalar object is a
> scalar object.  The distinction you see between structs and scalars
> doesn't exist.  (Certainly there's a distinction, but it's not the
> one you're talking about.)
> 
> >> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue
> >> expression, just as if it had been declared to be an int.  trying to
> >> reconcile this with some model that says it's a pointer (when it isn't
> >> one) is bound to be confusing.
> >
> > I was never happy with the term lvalue or rvalue.  My brain wants to
> > think in terms of pointers, variables, and values.  Structures defined
> > as automatic variables don't fit all that neatly in that classification.
> 
> C's definitions of the terms lvalue and rvalue is not consistent with
> their original meanings.
> 
> Originally, an expression could be evaluated in two different ways,
> depending on the context in which it appears.  Given an assignment:
> 
>     int x = 42;
>     int y;
>     y = x;
> 
> The expression `x` (on the right side of the assignment, thus
> "rvalue") is evaluated *for its rvalue*, which is 42, whereas
> the expresison `y` (on the left side, thus "lvalue" is evaluated
> *for its lvalue*, which is the identify of the object named "y",
> regardless of what value it happens to contain.  (Either can be a
> more complex expression, for example `arr[func(42)].member = abs(x)
> + 42;`, so there can be some non-trivial computation involved in
> determining an lvalue.)
> 
> The C standard changed the meaning of "lvalue", so it refers to the
> expression `y` itself, rather than to the result of evaluating it.
> The standard doesn't use the term "rvalue" other than in a footnote,
> which mentions in passing that an rvalue is the result of an
> expression.
> 
> See N1337 6.3.2.1.

That does put it in perspective.

> To oversimplify, an lvalue in C is an expression that designates
> an object.  Note carefully that *designating* an object needn't
> involve generating a *pointer* to an object, or equivalently
> computing the address of an object.  A simple example:
> 
>     int x = 42;
>     register int y;
>     y = x;
> 
> `y` is an lvalue, but it refers to an object that has no address.
> The same thing happens if `y` is a bit field.
> 
> Dropping the "register" keyword doesn't make any real conceptual
> difference -- nor does making `x` and `y` structures rather than
> scalars.

See my comment above regarding the compiler's phase space, although
I'm not quite sure that is the best term to use in describing what I
am thinking.
 
> You're right: "Structures defined as automatic variables don't fit
> all that neatly in that classification" (of pointers, variables,
> and values).  The problem is not with the language, it's with your
> way of thinking about it.

I didn't say that the language is wrong; I think I was merely implying
that bits of it are very confusing.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27609

Steve Thompson <stevet810@gmail.com> writes:
> On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote:
>> Steve Thompson <stevet810@gmail.com> 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"?

How much do you know about the internal workings of compilers?

>> > In a simplistic sense, all variables are pointers to a segment of
>> > program data, modifiable or otherwise.

No, a variable is not a pointer to a chunk of memory, it *is* a chunk of
memory (which can contain a value at execution time).

More precisely, the C standard doesn't define the word "variable", but I
presume that a "variable" is a kind of "object", which is defined as a
"region of data storage in the execution environment, the contents of
which can represent values".  Not a pointer in sight.

>> >                                         In the real world, variable
>> > values may move around in and from RAM to CPU registers and back while
>> > being identified as a single consistent entity.  This helps to
>> > illustrate the difference between a language and its implementation.
>> 
>> So a char object is really a pointer to char, an int object is
>> really a pointer to int, and a char** object is really a char**?

Sorry, what I meant to write is that a char** object is really (in your
model) a char***, i.e., a pointer to a char**.

> No, a char ** object is a pointer to a char ** object.

Was that really what you meant to type?  I messed up the number of *s,
so I can hardly criticize you for doing the same thing, but I'd like to
know what you meant.

In your model, as I understand it, an int object is really a pointer to
int, or an int*.  It would follow that a char** object is really a
pointer to a char**, or a char***.  Or am I misunderstanding you?

In fact, an int object is an int object.  I find that so obvious
that it seems odd to have to state it.  For an operation on such
an object, a compiler might have to generate code that determines
that object's address.  That does not in any sense imply that an
int object is "really" a pointer.  You can construct a pointer to
an int object, but the pointer and the object it points to are two
different things.

>> I think you're simply adding an extra -- and unnecessary -- level
>> of indirection, and of confusion.
>> 
>> There may also be some confusion between pointer *objects* and
>> pointer *values* (i.e., addresses).
>
> Let me say again that I am not talking about addresses as might be
> referenced in object code.  Perhaps it will clarify that I am thinking
> of something like the phase space of the compiler as it is building
> the tree representing the source code of the program.

And we're getting even farther afield from the actual semantics of a C
program.

An object doesn't even exist during compilation.  Memory for it
is allocated as the program is executed.  Pointers (either pointer
objects or pointer values) do not exist until the program executes.
The "phase space" of the compiler is irrelevant.

When you claim that a struct object is "really" a pointer, are you
referring to something that exists internally to a compiler during
compilation?  If so, of what possible use is it to understanding
what a struct object is?

>> If I define an object of struct type and perform some operation
>> on it (say, a simple assignment), the generated code might very
>> well refer to the address of the object.  There is no *object*
>> of pointer type, either explicitly or implicitly.
>
> That could depend on the way the compiler is designed.

Perhaps.  But an object of pointer-to-struct type is a region
of memory holding the address of the struct object.  Why would a
compiler allocate and initialize such a pointer object, or generate
code to do so, in the absence of C code to take the addrss of the
struct object?

>> Struct objects are very often manipulated via pointers (simulating
>> by-reference argument passing, for example), but that's a coding
>> convention, not anything inherent to the language.
>
> Agreed.

So where do these "pointers" you keep talking about come from?
In what sense do they exist?

[big snip]

> See my comment above regarding the compiler's phase space, although
> I'm not quite sure that is the best term to use in describing what I
> am thinking.

I'm pretty sure it isn't.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27611

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnzk3cvlzy.fsf@nuthaus.mib.org...
> Steve Thompson <stevet810@gmail.com> writes:

>> No, a char ** object is a pointer to a char ** object.
>
> Was that really what you meant to type?  I messed up the number of *s,
> so I can hardly criticize you for doing the same thing, but I'd like to
> know what you meant.
>
> In your model, as I understand it, an int object is really a pointer to
> int, or an int*.  It would follow that a char** object is really a
> pointer to a char**, or a char***.  Or am I misunderstanding you?
>
> In fact, an int object is an int object.  I find that so obvious
> that it seems odd to have to state it.  For an operation on such
> an object, a compiler might have to generate code that determines
> that object's address.

For every variable of type T, there will be an address of the variable of 
type T* (at least, before compiler optimisation gets to work on it). That 
address (or pointer) will be a constant value though, just like the constant 
8258 is value of type int that doesn't need storage. Such an address is also 
automatically dereferenced by a HLL when you just write the name of the 
variable; so the T* aspects of it get overlooked.

That's how you might get your char*** pointer from char**. Of course ST 
might have been thinking of an implementation with an actual stored char*** 
pointer, not a constant one, in which case the address of that, if his 
language allows it, would be char****!

>>> I think you're simply adding an extra -- and unnecessary -- level
>>> of indirection, and of confusion.

Whoever said that bit is right. I think a diagram is called for.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#27617

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnzk3cvlzy.fsf@nuthaus.mib.org...
>> Steve Thompson <stevet810@gmail.com> writes:
>
>>> No, a char ** object is a pointer to a char ** object.
>>
>> Was that really what you meant to type?  I messed up the number of *s,
>> so I can hardly criticize you for doing the same thing, but I'd like to
>> know what you meant.
>>
>> In your model, as I understand it, an int object is really a pointer to
>> int, or an int*.  It would follow that a char** object is really a
>> pointer to a char**, or a char***.  Or am I misunderstanding you?
>>
>> In fact, an int object is an int object.  I find that so obvious
>> that it seems odd to have to state it.  For an operation on such
>> an object, a compiler might have to generate code that determines
>> that object's address.
>
> For every variable of type T, there will be an address of the variable of 
> type T* (at least, before compiler optimisation gets to work on it).

First, the word "variable" is a bit ambiguous.  Is it synonymous
with "object"?  Usually the meaning is clear enough, but in this
context it's important to be very clear what we're talking about --
and the standard provides no definition of the word "variable".

And what do you mean that "there will be" an address of the variable?
Given a declaration `some_type obj;` the expression &obj can be
evaluated, and is of type some_type* -- but are you saying there's some
sense in which that value exists somewhere just because the object
exists?

>                                                                      That 
> address (or pointer) will be a constant value though, just like the constant 
> 8258 is value of type int that doesn't need storage.

Depends on what you mean by "constant".  It cannot in general be
evaluated at compile time, as 8258 can.  It can be evaluated at link
time if the variable is an object with static storage duration,
but not if it has automatic storage duration.  And of course bit
fields and register objects don't have addresses.

>                                                      Such an address is also 
> automatically dereferenced by a HLL when you just write the name of the 
> variable; so the T* aspects of it get overlooked.

The expression `obj` refers to the object of that name.  I don't see
how it's useful to think of that expression as taking the address of
`obj` and then dereferencing that address.

> That's how you might get your char*** pointer from char**. Of course ST 
> might have been thinking of an implementation with an actual stored char*** 
> pointer, not a constant one, in which case the address of that, if his 
> language allows it, would be char****!

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

>>>> I think you're simply adding an extra -- and unnecessary -- level
>>>> of indirection, and of confusion.
(that was me)

> Whoever said that bit is right. I think a diagram is called for.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27623

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnr4oovaar.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:

>> For every variable of type T, there will be an address of the variable of
>> type T*

> First, the word "variable" is a bit ambiguous.  Is it synonymous
> with "object"?

I meant 'name'.

> Depends on what you mean by "constant".  It cannot in general be
> evaluated at compile time, as 8258 can.  It can be evaluated at link
> time if the variable is an object with static storage duration,
> but not if it has automatic storage duration.

It's true that with automatic variables the concept is not so simple; their
addresses might need evaluating. Yet neither are they implemented as actual
pointers in a way that is accessible by the program.

>>                                                      Such an address is
>> also
>> automatically dereferenced by a HLL when you just write the name of the
>> variable; so the T* aspects of it get overlooked.
>
> The expression `obj` refers to the object of that name.  I don't see
> how it's useful to think of that expression as taking the address of
> `obj` and then dereferencing that address.

There's a connection with what ST might have been on about regarding the
manipulation of struct objects, compared with primitives (in native code,
the dereferencing of an object of arbitrary size, like a struct, is not as 
straightforward as with a primitive type).

(Other than that, thinking of A as really meaning *(&A) I have found
extremely useful.)

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

I agree.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#27644

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnr4oovaar.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> For every variable of type T, there will be an address of the variable of
>>> type T*
>
>> First, the word "variable" is a bit ambiguous.  Is it synonymous
>> with "object"?
>
> I meant 'name'.

Ok, what exactly do you mean by "name"?  The standard doesn't give
a single definition of "name", but it seems to mean "identifier".
See, for example, the definitions of "external name" and "internal
name" in N1570 6.4.2.1p5.

Given:

    int foobar;

do we have an *object" foobar of type int, but the *variable*
foobar is an identifier with 6 letters?  And given:

    int foobar;
    {
        double foobar;
    }

do we have only one "variable", because both objects have the same name?

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

[snip]

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

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27652

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lna9vbvghx.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> 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 

[toc] | [prev] | [next] | [standalone]

#27657

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lna9vbvghx.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> 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.
There's nothing mysterious or contradictory about that.

> 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".
Nothing in your followup answers that question.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27661

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnsj93tobp.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:

> But I'm still interested in what you mean by the word "variable".
> Nothing in your followup answers that question.

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

 

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web