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

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

Pointers, constant values

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

Contents

  Pointers, constant values Alla _ <modelling.data@gmail.com> - 2015-10-16 00:49 -0700
    Re: Pointers, constant values Philip Lantz <prl@canterey.us> - 2015-10-16 01:49 -0700
    Re: Pointers, constant values James Kuyper <jameskuyper@verizon.net> - 2015-10-16 09:41 -0400
      Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 08:55 -0700
    Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 08:25 -0700
      Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 09:11 -0700
        Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 12:06 -0700
          Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 12:55 -0700
      Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 17:49 +0100
        Re: Pointers, constant values Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-16 13:23 -0400
          Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 19:34 +0100
            Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 12:05 -0700
          Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 12:18 -0700
        Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 12:13 -0700
          Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 20:33 +0100
            Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 13:01 -0700
              Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 21:09 +0100
                Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 13:41 -0700
            Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-16 21:07 +0100
              Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 21:20 +0100
                Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-16 22:02 +0100
                  Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-16 22:21 +0100
                    Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 14:39 -0700
                      Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 15:26 -0700
                        Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 15:44 -0700
                          Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 16:58 -0700
                            Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 17:28 -0700
                    Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-16 22:50 +0100
                      Re: Pointers, constant values supercat@casperkitty.com - 2015-10-16 15:14 -0700
                      Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-17 01:23 +0100
                        Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 19:39 +0100
                          Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-17 22:42 +0100
                            Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 00:31 +0100
                              Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-18 02:11 +0100
                                Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 11:59 +0100
                                  Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-18 12:12 +0100
                                    Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-18 12:28 +0100
                                    Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 23:16 +0100
                                      Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-18 23:34 +0100
                                        Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 01:45 +0100
                                          Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-19 11:51 +0100
                                            Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 12:55 +0100
                                              Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-19 13:51 +0100
                                                Re: Pointers, constant values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 06:02 -0700
                                                  Re: Pointers, constant values supercat@casperkitty.com - 2015-10-19 07:02 -0700
                                                    Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-19 15:39 +0100
                                                      Re: Pointers, constant values supercat@casperkitty.com - 2015-10-19 08:54 -0700
                                                        Re: Pointers, constant values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 09:14 -0700
                                                          Re: Pointers, constant values supercat@casperkitty.com - 2015-10-19 10:21 -0700
                                                            Re: Pointers, constant values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 12:57 -0700
                                                Re: Pointers, constant values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 21:20 +0000
                                                  Re: Pointers, constant values supercat@casperkitty.com - 2015-10-20 20:50 -0700
                                                    Re: Pointers, constant values glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 04:58 +0000
                                          Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-19 08:40 -0700
                                            Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 20:17 +0100
                            Re: Pointers, constant values supercat@casperkitty.com - 2015-10-17 16:44 -0700
                              Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 11:52 +0100
                                Re: Pointers, constant values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 05:15 -0700
                                  Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:54 +0100
                                    Re: Pointers, constant values Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:09 -0700
                                Re: Pointers, constant values supercat@casperkitty.com - 2015-10-18 07:55 -0700
                                  Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:47 +0100
                                    Re: Pointers, constant values supercat@casperkitty.com - 2015-10-18 15:37 -0700
                                      Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 00:10 +0100
                                        Re: Pointers, constant values supercat@casperkitty.com - 2015-10-18 19:04 -0700
          Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-16 21:13 +0100
        Re: Pointers, constant values Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:27 +1300
          Re: Pointers, constant values Bartc <bc@freeuk.com> - 2015-10-17 00:56 +0100
    Re: Pointers, constant values Les Cargill <lcargill99@comcast.com> - 2015-10-16 12:37 -0500
      Re: Pointers, constant values James Kuyper <jameskuyper@verizon.net> - 2015-10-16 14:22 -0400
    Re: Pointers, constant values Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-16 18:57 +0000
      Re: Pointers, constant values Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-16 20:40 +0100
        Re: Pointers, constant values Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-16 20:46 +0000
          Re: Pointers, constant values Keith Thompson <kst-u@mib.org> - 2015-10-16 14:24 -0700
            Re: Pointers, constant values Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 12:43 +0000
    Re: Pointers, constant values Siri Cruz <chine.bleu@yahoo.com> - 2015-10-16 13:20 -0700
      Re: Pointers, constant values supercat@casperkitty.com - 2015-10-17 13:59 -0700

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

#73207

On Sunday, October 18, 2015 at 5:53:03 AM UTC-5, Ben Bacarisse wrote:
> supercat writes:
> >     void processCommand(int command, char (*dat)[size], int size);
> 
> The size parameter must come before the parameter that refers to it.

I'd never used that feature, but thought I'd seen some examples the other
way.

> What use-case do you have in mind?  The most common use I've seen of
> this pattern is in numerical work for passing a 2D arrays with a
> run-time "stride".  In those cases, pointers to zero-length arrays are
> not common (nor are they particularly useful degenerate cases).

How about a function to perform a remote command while passing zero or
more parameters?  While one could use a separate function for the "no
parameters" case, it's often necessary to wrap such functions in other
functions which e.g. acquire a resource, perform a command, and release
a resource; using a separate function for the "no-parameters case" would
require having a separate wrapper for that case as well.

Of course, in practice everyone works around this by passing a simple
pointer type for the parameter rather than an array, but my point was that
this is an example of a situation where someone is "effectively" passing
an array but where the array syntax wouldn't work.

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

#73233

supercat@casperkitty.com writes:

> On Sunday, October 18, 2015 at 5:53:03 AM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>> >     void processCommand(int command, char (*dat)[size], int size);
>> 
>> The size parameter must come before the parameter that refers to it.
>
> I'd never used that feature, but thought I'd seen some examples the other
> way.
>
>> What use-case do you have in mind?  The most common use I've seen of
>> this pattern is in numerical work for passing a 2D arrays with a
>> run-time "stride".  In those cases, pointers to zero-length arrays are
>> not common (nor are they particularly useful degenerate cases).
>
> How about a function to perform a remote command while passing zero or
> more parameters?

Why not

  void processCommand(int command, char *dat[], int n_params);

?

<snip>
-- 
Ben.

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

#73250

On Sunday, October 18, 2015 at 3:47:45 PM UTC-5, Ben Bacarisse wrote:
> Why not
> 
>   void processCommand(int command, char *dat[], int n_params);

The previous question was about why code should receive a pointer to a
data item rather than a pointer to a suitably-sized variable-length array;
I suggested that the latter approach won't work if the size is zero, and
and I offered a common use case where that could happen.  I'm not quite
clear whether you're intentionally passing a double-indirect pointer,
but in any case your prototype passes some kind of pointer that has nothing
to do with any kind of array.

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

#73253

supercat@casperkitty.com writes:
<snip>
> The previous question was about why code should receive a pointer to a
> data item rather than a pointer to a suitably-sized variable-length array;
> I suggested that the latter approach won't work if the size is zero, and
> and I offered a common use case where that could happen.

Right.  I think I miss-attributed what you see as such a common case.
Your common case is simply using an array to pass some data, the length
of which might be zero.  I took the "common case" to be the code -- a
pointer to a VLA whose size might be zero.  But your point was rather
that VLAs are *particularly* bad when using the already rather atypical
idea of passing a pointer to an array type.  They fail in the common
case where the array has zero size.

I think these things get complicated when there are too many
hypotheticals.  Presumably you would write

  void processCommand(int command, char *dat, int size);

to pass data (that might be zero length).  But, hypotheticaly, if forced
to use Bart's "pass an array as a pointer to the array" you'd write

  void processCommand(int command, char (*dat)[], int size);

with the data running from (*dat)[0] to (*dat)[size-1].  Your point (if
I now understand it) is that one can't, hypothetically, go further and
use a VLA here -- you have to use a pointer to an incomplete array type.

The trouble is I was trying to imagine a case where you'd *want* to use
a VLA, and the possibility of a zero size would a common problem!

<snip>
-- 
Ben.

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

#73259

On Sunday, October 18, 2015 at 6:10:40 PM UTC-5, Ben Bacarisse wrote:
> ...                                                     Your point (if
> I now understand it) is that one can't, hypothetically, go further and
> use a VLA here -- you have to use a pointer to an incomplete array type.

Right, and so far as I can tell a pointer to an incomplete array type ends
up decaying to a pointer to the element type anyway.

> The trouble is I was trying to imagine a case where you'd *want* to use
> a VLA, and the possibility of a zero size would a common problem!

Actually, I consider that a problem with VLAs in general; if, for example,
one wants to make a copy of the passed-in data (which might have length
zero) one can't use a VLA for that unless one adds extra logic to force
the minimum length of the array (which one would end up not using anyhow)
to one.

I really wish that C had never added the restriction that objects must
have non-zero size.  While the meaning of subracting pointers to zero-sized
objects would be rather murky, a simple solution to that would be to say
that pointer arithmetic is only legal for types whose size isn't fixed at
zero, and pointer-subtraction of two pointers to zero-sized VLA types would
yield zero if the pointers were equal, or Undefined Behavior otherwise.
Otherwise, I would suggest that there are many places where zero-sized
arrays could be useful, and flexible array members don't take care of all
of them.  For example, is there any decent way in C99 (or even any later
version) to create structure with a static or automatic storage class that
contains a flexible array member that is populated with data?  In some
C dialects, one could do:

    struct THING_BASE { int size; char dat[0]; }
    struct { THING_BASE base; char dat[4]} my_quad = { {4}, {1,2,3,4} };

and "my_quad.dat" would overlay "my_quad.base.dat", but trying to use a
flexible array member in that fashion won't work.  One could try:

    union {
      struct { int size; char dat[4]; } dat;
      struct THING_BASE head;
    } my_quad = { {4, { 1,2,3,4 } } };

and that would almost work, except that I don't think C99 allows structs
containing flexible array members in unions.  One could try various kinds
of pointer hackery, but those would run afoul of the strict aliasing rule.

Consequently, centuries after some brilliant mathematician discovered the
value of "zero", compilers still make things needlessly complicated by
refusing to acknowledge its existence and usefulness.

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

#73067

Keith Thompson <kst-u@mib.org> writes:

> Bartc <bc@freeuk.com> writes:
<snip>
>>                                                      C allows you to
>> pass a pointer to an actual array, if not the array itself:
>>
>>  int array_sum(int (*array)[], int n);
<snip>
>> However this also now requires proper array dereferencing and
>> indexing, not just applying an offset to an arbitrary pointer which
>> can be to anything:
>>
>>  (*array)[i]
>
> That won't compile unless you have something between the [] in the
> declaration.

It does compile, and I think it should.  You can't subscript it
(i.e. data[0][i] is not valid) because you can't do arithmetic on a
pointer to an incomplete type, but the * is fine.  What constraint do
you see being broken here?

-- 
Ben.

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

#73101

Bartc wrote:
> On 16/10/2015 16:25, Keith Thompson wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>> [...]
>>> int array_sum (int array[], const int n);
>>
>> One piece of advice:
>>
>> The parameter declaration
>>       int array[]
>> really means
>>       int *array
>>
>> There is no such thing as an array parameter in C, but it uses
>> array-like syntax to define pointer variables.
>>
>> My advice is *not* to take advantage of that special-case rule.  It's a
>> pointer, so define it as a pointer:
>>
>>       int array_sum (int *array, const int n);
>
>> Not everyone will agree with this; some will argue that using the []
>> notation is a reminder that it points to an element of an array, not
>> just a single int object.
>
> But 'int *array' *is* a pointer to a single element. C allows you to
> pass a pointer to an actual array, if not the array itself:
>
>    int array_sum(int (*array)[], int n);
>
> However this also now requires proper array dereferencing and indexing,
> not just applying an offset to an arbitrary pointer which can be to
> anything:
>
>    (*array)[i]

Which is something of a mess.

You really need references to force correct passing and use of arrays to 
functions.  For example in C++,

void f( int (&array)[10] );

can only be passed and array of 10 ints.

-- 
Ian Collins

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

#73113

On 16/10/2015 23:27, Ian Collins wrote:
> Bartc wrote:

>> However this also now requires proper array dereferencing and indexing,
>> not just applying an offset to an arbitrary pointer which can be to
>> anything:
>>
>>    (*array)[i]
>
> Which is something of a mess.
>
> You really need references to force correct passing and use of arrays to
> functions.  For example in C++,
>
> void f( int (&array)[10] );
>
> can only be passed and array of 10 ints.

C can do that too: void f(int (*array)[10]);

-- 
Bartc

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

#73050

Alla _ wrote:
> Hello!
>
<snip>
>
> Does int * const array_end = array + n; mean that the pointer
> array_end has a constant value of array[0] + n, or that it will not
> be able to change the value of (array + n)?
>

So these are modestly different:

int const array_end *       = array + n;
int const array_end * const = array + n;
int       array_end * const = array + n;

One means "the pointer cannot be changed."
The other means "the thing being pointed to cannot be changed."

I never remember which is which and have to look it up
every time :) Or put a line of code in ( to be
removed quickly ) to test it.

(the first  "const" is the "pointed to" and the second
is about the pointer itself ).

"Read it backwards."/"the spiral rule".

http://stackoverflow.com/questions/1143262/what-is-the-difference-between-const-int-const-int-const-and-int-const

And just to make it worse, there are subleties in const-ness
between C++ and 'C' but I don't think these apply to this
particular case.

> Thank you!
>

-- 
Les Cargill

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

#73051

On 10/16/2015 01:37 PM, Les Cargill wrote:
> Alla _ wrote:
>> Hello!
>>
> <snip>
>>
>> Does int * const array_end = array + n; mean that the pointer
>> array_end has a constant value of array[0] + n, or that it will not
>> be able to change the value of (array + n)?
>>
> 
> So these are modestly different:
> 
> int const array_end *       = array + n;
> int const array_end * const = array + n;
> int       array_end * const = array + n;

The syntax specified for pointer declarators is

T * type-qualifier-listopt D

Where T is the type pointed at, and D is another declarator. A pointer
declaration cannot end with either the '*' or a type-qualifier like
'const'. array_end is in the wrong location in every one of those
declarations. In each case, it should be moved just before the '=':

    int const *       array_end1 = array + n;
    int const * const array_end2 = array + n;
    int       * const array_end2 = array + n;

> One means "the pointer cannot be changed."
> The other means "the thing being pointed to cannot be changed."
> 
> I never remember which is which and have to look it up
> every time :) Or put a line of code in ( to be
> removed quickly ) to test it.

If you move the type specifier ('int') all the way to the left, there's
a simple rule that works for many object declarations (it gets a little
more complicated when functions and pointers to functions are involved):

If you move all qualifier as far left as they can go without moving them
past a  '*', then the thing that appears to the right of any given
sequence of qualifiers is, after removing any other qualifiers that it
itself contains, a model of an expression that refers to the thing
qualified by those qualifiers.

Thus, the first 'const' says that *array_end1 is const-qualified. The
second 'const' applies to '* const array_end2', from which you should
remove the other 'const', so it says that *array_end2 is const
qualified. The third 'const' say that array_end2 is itself
const-qualified, just as the fourth 'const' says that array_end3 is
const qualified.
-- 
James Kuyper

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

#73055

On Fri, 2015-10-16, Alla _ wrote:
> Hello!
>
> I have not yet solved issues discussed in my
> previous posts; I will get back to them tomorrow.
> Meanwhile, following recommendations, I am reading
> the chapter on pointers. 
>
> I would be grateful for your help in understanding 
> few questions on using constants.
>
> char c = 'x';
> char * const char_pointer = &c; means that the pointer
> variable char_pointer will always be pointing to 
> char variable named c, therefore char_pointer = &d
> will be an error.
>
> Does this mean (I am trying to make sure I understand
> this correctly) that char c can equal anything, and its
> value can be changed within a program a few times, but 
> char_pointer will always point to c and its changing
> values?

That's an excellent way of describing it!

That "const" makes 'char_pointer' more or less another name for 'c'.
Or maybe more correctly, another way to access the value stored under
the name 'c'.

If what I wrote confuses you, please ignore it and go back to the
books ... I'm a lousy teacher.

(I didn't read the rest.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#73061

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2015-10-16, Alla _ wrote:
>> Hello!
>>
>> I have not yet solved issues discussed in my
>> previous posts; I will get back to them tomorrow.
>> Meanwhile, following recommendations, I am reading
>> the chapter on pointers. 
>>
>> I would be grateful for your help in understanding 
>> few questions on using constants.
>>
>> char c = 'x';
>> char * const char_pointer = &c; means that the pointer
>> variable char_pointer will always be pointing to 
>> char variable named c, therefore char_pointer = &d
>> will be an error.
>>
>> Does this mean (I am trying to make sure I understand
>> this correctly) that char c can equal anything, and its
>> value can be changed within a program a few times, but 
>> char_pointer will always point to c and its changing
>> values?
>
> That's an excellent way of describing it!
>
> That "const" makes 'char_pointer' more or less another name for 'c'.
> Or maybe more correctly, another way to access the value stored under
> the name 'c'.

I think you meant o write that '*char_pointer' is more or less another
name for 'c'.

<snip>
-- 
Ben.

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

#73072

On Fri, 2015-10-16, Ben Bacarisse wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Fri, 2015-10-16, Alla _ wrote:
...

>>> Does this mean (I am trying to make sure I understand
>>> this correctly) that char c can equal anything, and its
>>> value can be changed within a program a few times, but 
>>> char_pointer will always point to c and its changing
>>> values?
>>
>> That's an excellent way of describing it!
>>
>> That "const" makes 'char_pointer' more or less another name for 'c'.
>> Or maybe more correctly, another way to access the value stored under
>> the name 'c'.
>
> I think you meant o write that '*char_pointer' is more or less another
> name for 'c'.

No, I omitted the * intentionally, but perhaps I shouldn't have -- I
/did/ say I'm a lousy teacher!  My reasoning was something like
"'char_pointer' is more or less another another name for 'c' (but you
have to decorate it a bit first)".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#73085

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2015-10-16, Ben Bacarisse wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Fri, 2015-10-16, Alla _ wrote:
> ...
>
>>>> Does this mean (I am trying to make sure I understand
>>>> this correctly) that char c can equal anything, and its
>>>> value can be changed within a program a few times, but 
>>>> char_pointer will always point to c and its changing
>>>> values?
>>>
>>> That's an excellent way of describing it!
>>>
>>> That "const" makes 'char_pointer' more or less another name for 'c'.
>>> Or maybe more correctly, another way to access the value stored under
>>> the name 'c'.
>>
>> I think you meant o write that '*char_pointer' is more or less another
>> name for 'c'.
>
> No, I omitted the * intentionally, but perhaps I shouldn't have -- I
> /did/ say I'm a lousy teacher!  My reasoning was something like
> "'char_pointer' is more or less another another name for 'c' (but you
> have to decorate it a bit first)".

I think you're conflating "pointer to something" with "name of
something".  They're similar concepts, but IMHO it's best to keep them
distinct.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#73284

On Fri, 2015-10-16, Keith Thompson wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Fri, 2015-10-16, Ben Bacarisse wrote:
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>
>>>> On Fri, 2015-10-16, Alla _ wrote:
>> ...
>>
>>>>> Does this mean (I am trying to make sure I understand
>>>>> this correctly) that char c can equal anything, and its
>>>>> value can be changed within a program a few times, but 
>>>>> char_pointer will always point to c and its changing
>>>>> values?
>>>>
>>>> That's an excellent way of describing it!
>>>>
>>>> That "const" makes 'char_pointer' more or less another name for 'c'.
>>>> Or maybe more correctly, another way to access the value stored under
>>>> the name 'c'.
>>>
>>> I think you meant o write that '*char_pointer' is more or less another
>>> name for 'c'.
>>
>> No, I omitted the * intentionally, but perhaps I shouldn't have -- I
>> /did/ say I'm a lousy teacher!  My reasoning was something like
>> "'char_pointer' is more or less another another name for 'c' (but you
>> have to decorate it a bit first)".
>
> I think you're conflating "pointer to something" with "name of
> something".  They're similar concepts, but IMHO it's best to keep them
> distinct.

I find it helpful to think in terms of "name of something" some of the
time (especially with const pointers or C++ references), but you're
right: dropping that idea on a newbie without a deeper discussion is
probably not wise.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#73069

In article <5b2ab074-7644-4798-9b90-a3ae47e1f2b8@googlegroups.com>,
 Alla _ <modelling.data@gmail.com> wrote:

There's actually a straightforward to deal with this, but it requires maving an 
implicit property into the type system that blows most people's mind.

C like nearly all procedural languages (excepting Algol 68) has variableness 
which is not included in the type system. The C nomenclature is 'lvalues' and is 
similar to the C++ reference notion with the & type modifier. If you borrow & 
and read T& as an lvalue (or variable) of type T, you can express the complete 
types of these declarations as

> int main (void)
> {
>     int values[5] = {3, 7, -9, 5, 2};

        values is int*

> }


> int array_sum (int array[], const int n)

        array is int*&
        n is int const&

> {
>     int sum = 0;
>     int *pointer;
>     int * const array_end = array + n;

        sum is int&
        pointer is int*&
        array_end is int* const&
        
> }

You can then define the allowed types of operators as
        (T&) = (T) -> (T) unless T is T' const
        *(T*) -> (T&)
        &(T&) -> (T*)
        (T*) + integer -> (T*)
        integer + (T*) -> (T*)
        (T*)[integer] -> *(T* + integer) -> *(T*) -> (T&)
        (T&) -> (T) and (T const&) -> (T) as a coercion from a lvalue to a value
= used to initialise a declaration is different from = used as assigns and allows
        (T&) = (T)
        (T const&) = (T)
        (T) = (T)

Then the declaration of value equates value to a pointer to an initialised array 
of integer where 'array of T' here means an addressable block of contiguous T.

array is declared as variable integer pointer with an implicit initialisation of 
(int*&)array = (int*)values for this call.

n is declared as a constant variable integer with an implicit initialisation of 
(int&)n = (int)5 for this call.

(int&)sum is initialised to (int)0.

(int*&)pointer is not initialised.

(int* const&)array_end is initialsed to (int*&)array + (int).
        (int* const&) = (int*&)+(int const&)
        (T* const&) = (T*&)+(T const&)  T = int
        (T* const&) = (T*&)+(T)         coercion (T const&)->(T)
        (T* const&) = (T*)+(T)          coercion (T&)->(T)
        (T* const&) = (T*)              pointer addition
These is a valid initialisation and means
        array_end is initialised to the pointer addition
        of value of the pointer variable array plus the
        the value of the integer variable n.
        
> Does int * const array_end = array + n; mean that the pointer
> array_end has a constant value of array[0] + n, or that it will not 
> be able to change the value of (array + n)?

The * operator is not applied to array, so the pointer value of array, not the 
value of an element of the array.

It could modify (array+n) if this were a pointer to an element of the array, but 
because it is not (the last element is (array+n-1), the assignment to the array 
is undefined.

To declare you cannot assign through the pointer that would be
        int const * const array_end = array + n;
which declares array as (int const* const&).


And, yes, that C screwed up and uses prefix and postfix type modifiers makes the 
notation unnecessarily complicated compared to something like Pascal.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
When is a Kenyan not a Kenyan? When he's a Canadian.
That's People's Commissioner Siri Cruz now. Punch!

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

#73155

On Friday, October 16, 2015 at 3:21:10 PM UTC-5, Siri Cruz wrote:
> And, yes, that C screwed up and uses prefix and postfix type modifiers makes the 
> notation unnecessarily complicated compared to something like Pascal.

I miss Pascal.  People complain about verbosity, but if one recognizes the 
legitimacy of some near universal extensions, I would posit that:

   var
     ptrs1,ptrs2 : Array[0..257] of ^Array[0..5] of ^Integer;

makes things pretty clear what levels of indirection exist where (I recall
that in standard Pascal, it would have been necessary to define separate
types for each nested constituent, but a lot of compilers accepted the
"all-at-once" syntax.

[toc] | [prev] | [standalone]

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

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

csiph-web