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

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

Access structure members via pointer to an array of structures

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

Contents

  Access structure members via pointer to an array of structures Alla _ <modelling.data@gmail.com> - 2017-01-21 02:00 -0800
    Re: Access structure members via pointer to an array of structures Alla _ <modelling.data@gmail.com> - 2017-01-21 02:08 -0800
      Re: Access structure members via pointer to an array of structures Chad <cdalten@gmail.com> - 2017-01-21 07:36 -0800
        Re: Access structure members via pointer to an array of structures Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-21 11:13 -0500
      Re: Access structure members via pointer to an array of structures Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-21 11:08 -0500
        Re: Access structure members via pointer to an array of structures Chad <cdalten@gmail.com> - 2017-01-21 09:09 -0800
          Re: Access structure members via pointer to an array of structures Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-21 14:32 -0500
            Re: Access structure members via pointer to an array of structures Chad <cdalten@gmail.com> - 2017-01-21 12:57 -0800
              Re: Access structure members via pointer to an array of structures Chad <cdalten@gmail.com> - 2017-01-21 13:04 -0800
                Re: Access structure members via pointer to an array of structures Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-21 17:59 -0500
                Re: Access structure members via pointer to an array of structures cross@spitfire.i.gajendra.net (Dan Cross) - 2017-01-22 14:02 +0000
                  Re: Access structure members via pointer to an array of structures raltbos@xs4all.nl (Richard Bos) - 2017-01-22 14:17 +0000
                  Re: Access structure members via pointer to an array of structures Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:25 -0800
              Re: Access structure members via pointer to an array of structures Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-21 17:57 -0500
    Re: Access structure members via pointer to an array of structures Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-21 08:09 -0800
      Re: Access structure members via pointer to an array of structures Keith Thompson <kst-u@mib.org> - 2017-01-21 15:15 -0800
        Re: Access structure members via pointer to an array of structures Gareth Owen <gwowen@gmail.com> - 2017-01-22 08:27 +0000
          Re: Access structure members via pointer to an array of structures Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-22 11:17 +0000
            Re: Access structure members via pointer to an array of structures BartC <bc@freeuk.com> - 2017-01-22 11:44 +0000
              Re: Access structure members via pointer to an array of structures Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-22 04:27 -0800
                Re: Access structure members via pointer to an array of structures Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-22 13:32 +0000
                Re: Access structure members via pointer to an array of structures Keith Thompson <kst-u@mib.org> - 2017-01-22 07:54 -0800
              Re: Access structure members via pointer to an array of structures Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-22 13:31 +0000
            Re: Access structure members via pointer to an array of structures Gareth Owen <gwowen@gmail.com> - 2017-01-22 14:02 +0000
          Re: Access structure members via pointer to an array of structures Keith Thompson <kst-u@mib.org> - 2017-01-22 07:50 -0800
    Re: Access structure members via pointer to an array of structures Manfred <noname@invalid.add> - 2017-01-21 17:15 +0100
    Re: Access structure members via pointer to an array of structures David Brown <david.brown@hesbynett.no> - 2017-01-21 17:59 +0100
      Re: Access structure members via pointer to an array of structures Alla _ <modelling.data@gmail.com> - 2017-01-21 09:09 -0800
        Re: Access structure members via pointer to an array of structures Barry Schwarz <schwarzb@dqel.com> - 2017-01-21 09:27 -0800
          Re: Access structure members via pointer to an array of structures Alla _ <modelling.data@gmail.com> - 2017-01-21 09:30 -0800
      Re: Access structure members via pointer to an array of structures Alla _ <modelling.data@gmail.com> - 2017-01-21 09:25 -0800
    Re: Access structure members via pointer to an array of structures "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2017-01-30 22:04 +1100

Page 1 of 2  [1] 2  Next page →

#102269 — Access structure members via pointer to an array of structures

Hello!

Please, help me to find my mistake; it seems I do everything correctly 
but, most likely, I am mistaken.

I will show only a part of code to explain my issue.
I have declared an array of structures and a pointer to
that array. Then I use the pointer to populate, for now,
one member of each structure. No problems here: values
land in their correct places. But when I try to print out
those values using a pointer, I don't get those values,
only zeros. Please, see the code for clarification. 

#define DATA_SIZE 5
typedef struct data {
    int    year;
    double sales;
    int    cs_cogs;
    int    cs_gross_profit;
    int    cs_sga;
    int    cs_oper_inc;
    int    cs_dep_amor;
    int    cs_oper_prof;
    int    cs_int_exp;
    int    cs_gain_loss;
    int    cs_pretax_inc;
    int    cs_tax_exp;
    int    cs_net_inc;
} data;

in the main function I have this declaration
(I will later use malloc here, not now):

data years[DATA_SIZE];
data *dat_years = years;

Then I pass the pointer dat_years into a function:
/** Parse numbers **/
bool numbers(char *line, struct data *dat_years)
{
    char *ptr = line;
    char *not_converted = NULL;
    int count = 0;
    
    while(count < DATA_SIZE)
    {
        dat_years->sales = strtod(ptr, &not_converted);
        
        /****** Comment only for explanatory purpose (not part of my code):
       here I try to print out values; the first fprintf with dat_years->sales
       works perfectly because it is a standard access to a member via 
       a pointer; but the second one doesn't: I wonder why? 

dat_years[count].sales equals the correct number only at the beginning,
when count = 0; as soon as I increment the count and move pointer to
the next address dat_years[count].sales shows me only zeros as its values:
Loop beg: sales num 1062.000000; count 0
Loop beg2: sales[0] 1062.000000

Loop beg: sales num 1252.000000; count 1
Loop beg2: sales[1] 0.000000

Loop beg: sales num 1587.000000; count 2
Loop beg2: sales[2] 0.000000

etc.
But this member in each structure has the correct value after this 
function, and when the main function calls 
fprintf(stderr, "Main fun: sales[%i] num %f; sales[0] num %f;\n", DATA_SIZE-1, years[DATA_SIZE-1].sales, years[0].sales);
it produces a correct output:
Main fun: sales[4] num 2519.000000; sales[0] num 1062.000000;

******/

        fprintf(stderr, "Loop beg: sales num %f; count %i\n", dat_years->sales, count);
        fprintf(stderr, "Loop beg2: sales[%i] %f\n", count, dat_years[count].sales);
        
        if (not_converted > ptr)
        {
            count++;
            dat_years += (count != DATA_SIZE);
            ptr = not_converted + (*not_converted != '\0');
        }
        else
        {
            fprintf(stderr, "Incorrect data on line %s at count %i\n", line, count);
            return false;
        }
    }
    return count == DATA_SIZE;
}

Thank you!

[toc] | [next] | [standalone]

#102270

On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
<snip>
I know why - I had to pass a pointer to a pointer, because
I pass that pointer first to one function, and out of it to another function, which
I have posted above. 

first I pass it to this function:
bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)

and inside that one to:
/** Parse numbers **/ 
bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
has to be a pointer to a pointer. 

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

#102275

I think I've mentioned this before...

I think you need to take a step back, find a programming book that is meant for morons like firs, and then waste a few years of your life really learning the basics of variables, selections, and loops. Seriously. Because the route you are on will only lead you to a low paying job that has ugly men and fat women. Not that it's a bad thing. I mean, hell, that route seems to have worked for Jerry.

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

#102278

On 1/21/2017 10:36 AM, Chad wrote:
> I think I've mentioned this before...
> 
> I think you need to take a step back, find a programming book that is meant for morons like firs, and then waste a few years of your life really learning the basics of variables, selections, and loops. Seriously. Because the route you are on will only lead you to a low paying job that has ugly men and fat women. Not that it's a bad thing. I mean, hell, that route seems to have worked for Jerry.
> 
> 
> 
> 

Sorry, Chad.  I just turned down a job because I don't have the time.  I
think the customer would go up to $150K US for about six months of work,
but it has a hard deadline with severe penalties for not making the
deadline.  I have too many other things going on.

It's way above your skill level - it requires more than a toilet brush.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#102276

On 1/21/2017 5:08 AM, Alla _ wrote:
> On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
> <snip>
> I know why - I had to pass a pointer to a pointer, because
> I pass that pointer first to one function, and out of it to another function, which
> I have posted above. 
> 
> first I pass it to this function:
> bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)
> 
> and inside that one to:
> /** Parse numbers **/ 
> bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
> has to be a pointer to a pointer. 
> 

Alla, don't follow Chad's advice.  You'll end up right where he is -
cleaning toilets for a third-rate company.

You do need to listen better to what others are telling you, though.
You're getting some good advice on your coding, but you don't seem to be
absorbing it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#102284

On Saturday, January 21, 2017 at 8:08:39 AM UTC-8, Jerry Stuckle wrote:
> On 1/21/2017 5:08 AM, Alla _ wrote:
> > On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
> > <snip>
> > I know why - I had to pass a pointer to a pointer, because
> > I pass that pointer first to one function, and out of it to another function, which
> > I have posted above. 
> > 
> > first I pass it to this function:
> > bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)
> > 
> > and inside that one to:
> > /** Parse numbers **/ 
> > bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
> > has to be a pointer to a pointer. 
> > 
> 
> Alla, don't follow Chad's advice.  You'll end up right where he is -
> cleaning toilets for a third-rate company.
> 
> You do need to listen better to what others are telling you, though.
> You're getting some good advice on your coding, but you don't seem to be
> absorbing it.
> 

Homegirl, just about every programming job here requires the candidate to pass the programming end of the interview. And most of the questions these firms ask are difficult. There is no way in hell someone with a weak grasp over the basics are going to be able to answer some of these questions in the allotted time period.

However, you wouldn't know of such things because you are too busy cleaning the toilets at IBM.

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

#102296

On 1/21/2017 12:09 PM, Chad wrote:
> On Saturday, January 21, 2017 at 8:08:39 AM UTC-8, Jerry Stuckle wrote:
>> On 1/21/2017 5:08 AM, Alla _ wrote:
>>> On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
>>> <snip>
>>> I know why - I had to pass a pointer to a pointer, because
>>> I pass that pointer first to one function, and out of it to another function, which
>>> I have posted above. 
>>>
>>> first I pass it to this function:
>>> bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)
>>>
>>> and inside that one to:
>>> /** Parse numbers **/ 
>>> bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
>>> has to be a pointer to a pointer. 
>>>
>>
>> Alla, don't follow Chad's advice.  You'll end up right where he is -
>> cleaning toilets for a third-rate company.
>>
>> You do need to listen better to what others are telling you, though.
>> You're getting some good advice on your coding, but you don't seem to be
>> absorbing it.
>>
> 
> Homegirl, just about every programming job here requires the candidate to pass the programming end of the interview. And most of the questions these firms ask are difficult. There is no way in hell someone with a weak grasp over the basics are going to be able to answer some of these questions in the allotted time period.
> 
> However, you wouldn't know of such things because you are too busy cleaning the toilets at IBM.
> 

I guess you didn't have to pass a programming quiz to clean toilets.
You can't even be original.  But then a toilet cleaner never is.

And you think it was difficult?  I guess something like

int a = 5;

What is the value of "a"?  would be hard for you.  You wouldn't be able
to even clean the toilets at my customers.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#102299

On Saturday, January 21, 2017 at 11:33:00 AM UTC-8, Jerry Stuckle wrote:
> On 1/21/2017 12:09 PM, Chad wrote:
> > On Saturday, January 21, 2017 at 8:08:39 AM UTC-8, Jerry Stuckle wrote:
> >> On 1/21/2017 5:08 AM, Alla _ wrote:
> >>> On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
> >>> <snip>
> >>> I know why - I had to pass a pointer to a pointer, because
> >>> I pass that pointer first to one function, and out of it to another function, which
> >>> I have posted above. 
> >>>
> >>> first I pass it to this function:
> >>> bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)
> >>>
> >>> and inside that one to:
> >>> /** Parse numbers **/ 
> >>> bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
> >>> has to be a pointer to a pointer. 
> >>>
> >>
> >> Alla, don't follow Chad's advice.  You'll end up right where he is -
> >> cleaning toilets for a third-rate company.
> >>
> >> You do need to listen better to what others are telling you, though.
> >> You're getting some good advice on your coding, but you don't seem to be
> >> absorbing it.
> >>
> > 
> > Homegirl, just about every programming job here requires the candidate to pass the programming end of the interview. And most of the questions these firms ask are difficult. There is no way in hell someone with a weak grasp over the basics are going to be able to answer some of these questions in the allotted time period.
> > 
> > However, you wouldn't know of such things because you are too busy cleaning the toilets at IBM.
> > 
> 
> I guess you didn't have to pass a programming quiz to clean toilets.
> You can't even be original.  But then a toilet cleaner never is.
> 
> And you think it was difficult?  I guess something like
> 
> int a = 5;
> 
> What is the value of "a"?  would be hard for you.  You wouldn't be able
> to even clean the toilets at my customers.
> 

Well, there is this thing called a side effect that...

Anyways, questions like reversing a linked list without using a temporary node or writing an algorithm that convers a binary search tree to a doubly linked list aren't exactly the world's easiest question if it's a whiteboard interview.

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

#102300

Or my personal favorite. Given an array of integers N, find all the subsets that sum to some integer M in linear time. And this question is especially awesome of the interviewer is a hot woman that is wearing a skirt. Because half the time you're thinking about how you want to bend her over the desk.

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

#102304

On 1/21/2017 4:04 PM, Chad wrote:
> Or my personal favorite. Given an array of integers N, find all the subsets that sum to some integer M in linear time. And this question is especially awesome of the interviewer is a hot woman that is wearing a skirt. Because half the time you're thinking about how you want to bend her over the desk.
> 

No, YOU'RE thinking of how hot she is.  Real programmers concentrate on
the problem.

But hey - even a distraction like that wouldn't be a problem for a good
programmer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#102323

In article <00f080cf-7a15-433f-9353-78503ab54a46@googlegroups.com>,
Chad  <cdalten@gmail.com> wrote:
>Or my personal favorite. Given an array of integers N, find all the
>subsets that sum to some integer M in linear time. [snip]

Hmm. Linear time? I'm not sure that's possible.

	- Dan C.

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

#102325

cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> In article <00f080cf-7a15-433f-9353-78503ab54a46@googlegroups.com>,
> Chad  <cdalten@gmail.com> wrote:
> >Or my personal favorite. Given an array of integers N, find all the
> >subsets that sum to some integer M in linear time. [snip]
> 
> Hmm. Linear time? I'm not sure that's possible.

Given that the only remotely efficient ways I can think of require a
sorted array, I make it O(n log n) at best, and I strongly suspect
quadratic or worse.

Richard

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

#102752

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <00f080cf-7a15-433f-9353-78503ab54a46@googlegroups.com>,
> Chad  <cdalten@gmail.com> wrote:
>> Or my personal favorite.  Given an array of integers N, find all the
>> subsets that sum to some integer M in linear time.  [snip]
>
> Hmm.  Linear time?  I'm not sure that's possible.

Without some additional restrictions it definitely is not
possible.  For starters, there could be exponentially
many of them.

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

#102303

On 1/21/2017 3:57 PM, Chad wrote:
> On Saturday, January 21, 2017 at 11:33:00 AM UTC-8, Jerry Stuckle wrote:
>> On 1/21/2017 12:09 PM, Chad wrote:
>>> On Saturday, January 21, 2017 at 8:08:39 AM UTC-8, Jerry Stuckle wrote:
>>>> On 1/21/2017 5:08 AM, Alla _ wrote:
>>>>> On Saturday, January 21, 2017 at 1:00:11 PM UTC+3, Alla _ wrote:
>>>>> <snip>
>>>>> I know why - I had to pass a pointer to a pointer, because
>>>>> I pass that pointer first to one function, and out of it to another function, which
>>>>> I have posted above. 
>>>>>
>>>>> first I pass it to this function:
>>>>> bool process_line (FILE *input_file, struct data *dat_years, struct assumptions *rates)
>>>>>
>>>>> and inside that one to:
>>>>> /** Parse numbers **/ 
>>>>> bool numbers(char *line, struct data *dat_years) - and this is a mistake; it 
>>>>> has to be a pointer to a pointer. 
>>>>>
>>>>
>>>> Alla, don't follow Chad's advice.  You'll end up right where he is -
>>>> cleaning toilets for a third-rate company.
>>>>
>>>> You do need to listen better to what others are telling you, though.
>>>> You're getting some good advice on your coding, but you don't seem to be
>>>> absorbing it.
>>>>
>>>
>>> Homegirl, just about every programming job here requires the candidate to pass the programming end of the interview. And most of the questions these firms ask are difficult. There is no way in hell someone with a weak grasp over the basics are going to be able to answer some of these questions in the allotted time period.
>>>
>>> However, you wouldn't know of such things because you are too busy cleaning the toilets at IBM.
>>>
>>
>> I guess you didn't have to pass a programming quiz to clean toilets.
>> You can't even be original.  But then a toilet cleaner never is.
>>
>> And you think it was difficult?  I guess something like
>>
>> int a = 5;
>>
>> What is the value of "a"?  would be hard for you.  You wouldn't be able
>> to even clean the toilets at my customers.
>>
> 
> Well, there is this thing called a side effect that...
> 
> Anyways, questions like reversing a linked list without using a temporary node or writing an algorithm that convers a binary search tree to a doubly linked list aren't exactly the world's easiest question if it's a whiteboard interview.
> 

Not easy for you, anyway.  Not hard for a good programmer.  Pretty much
anyone who ever completed my advanced C courses could answer those easily.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#102277

On Saturday, January 21, 2017 at 10:00:11 AM UTC, Alla _ wrote:
>
>         if (not_converted > ptr)
>         {
>             count++;
>             dat_years += (count != DATA_SIZE);
>             ptr = not_converted + (*not_converted != '\0');
>         }
>         else
>         {
>             fprintf(stderr, "Incorrect data on line %s at count %i\n", line, count);
>             return false;
>         }
>#
This code looks very odd.

We've got a structure called data, and a list of them which appears to 
have been set up correctly. Due to array pointer equivalence, we
can access the member via the actual array

    year[i].cs_cogs;

or we can pass a pointer 

   void foo(data *ptr, int N)
   {
       for(i=0;i<N;i++)
         ptr[i].cogs;
   }

Now if you can't intialise all the members, start by setting them to
nul or illegal values. Unless you've been in business since the time
of the Roman Empire, year cannot be -1. So

for(i=0;i<N;i++)
  ptr[i].year = -1;

Do that for all the members first thing.

Then fill the members. For example it seems to me that you are trying 
to set up the array so that years are consecutive. If it is strict
rule that years are consecutive, it's just a case of declaring a base
and then stepping through setting year to "base + i". If you allow
some duplicates or skipped years, then of course it gets more complex,
but explain first in English where and why that happens.

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

#102305

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> We've got a structure called data, and a list of them which appears to 
> have been set up correctly. Due to array pointer equivalence, we
> can access the member via the actual array
>
>     year[i].cs_cogs;
>
> or we can pass a pointer 
>
>    void foo(data *ptr, int N)
>    {
>        for(i=0;i<N;i++)
>          ptr[i].cogs;
>    }
[...]

Why would you tell someone trying to learn C about "array pointer
equivalence"?  Arrays and pointers are not equivalent.

-- 
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]

#102308

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

> Why would you tell someone trying to learn C about "array pointer
> equivalence"?  Arrays and pointers are not equivalent.

They are occasionally

f(char *ptr){
  printf("%s - %u\n",ptr,(unsigned)sizeof(ptr));
}

f(char arr[10]){
  printf("%s - %u\n",arr,(unsigned)sizeof(arr));
}

Worst design decision in C.  Understandable in context, but *ugh*.

Also, seems to have caused BartC to go certifiably insane.

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

#102311

Gareth Owen <gwowen@gmail.com> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> Why would you tell someone trying to learn C about "array pointer
>> equivalence"?  Arrays and pointers are not equivalent.
>
> They are occasionally

"array pointer equivalence" does not suggest something occasional!

There are a number of people here determined to avoid any explanation
that simplified the issue.  Just refer to the "array to pointer
conversion" and you are much closer to the truth without implying any
false equivalence.

> f(char *ptr){
>   printf("%s - %u\n",ptr,(unsigned)sizeof(ptr));
> }
>
> f(char arr[10]){
>   printf("%s - %u\n",arr,(unsigned)sizeof(arr));
> }

There are no arrays in this code and I don't think Malcolm was talking
about the interchangeability of * and [] syntax in a parameter list.

<snip>
-- 
Ben.

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

#102315

On 22/01/2017 11:17, Ben Bacarisse wrote:
> Gareth Owen <gwowen@gmail.com> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Why would you tell someone trying to learn C about "array pointer
>>> equivalence"?  Arrays and pointers are not equivalent.
>>
>> They are occasionally
>
> "array pointer equivalence" does not suggest something occasional!
>
> There are a number of people here determined to avoid any explanation
> that simplified the issue.  Just refer to the "array to pointer
> conversion" and you are much closer to the truth without implying any
> false equivalence.
>
>> f(char *ptr){
>>   printf("%s - %u\n",ptr,(unsigned)sizeof(ptr));
>> }
>>
>> f(char arr[10]){
>>   printf("%s - %u\n",arr,(unsigned)sizeof(arr));
>> }
>
> There are no arrays in this code and I don't think Malcolm was talking
> about the interchangeability of * and [] syntax in a parameter list.

Maybe he was talking about the equivalence of 'years' and '*dat_years' 
here when used in most expression contexts:

data years[DATA_SIZE];               // [an array]
data *dat_years = years;             // [a pointer]

Or the interchangeability of * and [] (with or without a non-zero offset 
or index) when used either with 'years' or 'dat-years'. Ie. 4-way 
equivalence.

(But there was also the interchangeability of 'data' and 'struct data' 
types that grated more in the OP.)

-- 
Bartc

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

#102316

On Sunday, January 22, 2017 at 11:44:26 AM UTC, Bart wrote:
> On 22/01/2017 11:17, Ben Bacarisse wrote:
> > Gareth Owen <gwowen@gmail.com> writes:
> >
> >> Keith Thompson <kst-u@mib.org> writes:
> >>
> >>> Why would you tell someone trying to learn C about "array pointer
> >>> equivalence"?  Arrays and pointers are not equivalent.
> >>
> >> They are occasionally
> >
> > "array pointer equivalence" does not suggest something occasional!
> >
> > There are a number of people here determined to avoid any explanation
> > that simplified the issue.  Just refer to the "array to pointer
> > conversion" and you are much closer to the truth without implying any
> > false equivalence.
> >
> >> f(char *ptr){
> >>   printf("%s - %u\n",ptr,(unsigned)sizeof(ptr));
> >> }
> >>
> >> f(char arr[10]){
> >>   printf("%s - %u\n",arr,(unsigned)sizeof(arr));
> >> }
> >
> > There are no arrays in this code and I don't think Malcolm was talking
> > about the interchangeability of * and [] syntax in a parameter list.
> 
> Maybe he was talking about the equivalence of 'years' and '*dat_years' 
> here when used in most expression contexts:
> 
> data years[DATA_SIZE];               // [an array]
> data *dat_years = years;             // [a pointer]
> 
Yes, that was in Alla's code.
Someone who writes that probably doesn't understand array pointer
equivalence. (So it's far to early to bring up a technical nit about
the situations they are not equivalent).

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web