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

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

Why C has Pointers.

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

Contents

  Why C has Pointers. curixinfotech <curixinfotech.54dl3z@no-mx.forums.yourdomain.com.au> - 2011-12-07 07:22 -0500
    Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-07 04:35 -0800
    Re: Why C has Pointers. Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-07 07:58 -0500
      Re: Why C has Pointers. Mike Manilone <zhtx10@gmail.com> - 2011-12-07 13:15 +0000
        Re: Why C has Pointers. Bill Reid <hormelfree@gmail.com> - 2011-12-08 06:29 -0800
    Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-07 14:50 +0100
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 11:01 -0800
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 20:49 +0100
        Re: Why C has Pointers. Brian <nospam@nospam.com> - 2011-12-07 20:00 +0000
          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-07 15:30 -0500
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-07 12:43 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-07 13:09 -0800
            Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 19:39 +0100
              Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-08 14:16 -0500
                Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@hotmail.it> - 2011-12-08 20:23 +0100
      Re: Why C has Pointers. Kaz Kylheku <kaz@kylheku.com> - 2011-12-07 20:48 +0000
        Re: Why C has Pointers. Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-12-07 22:07 +0100
        Re: Why C has Pointers. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-10 07:34 +0000
    Re: Why C has Pointers. August Karlstrom <fusionfile@gmail.com> - 2011-12-07 16:16 +0100
    Re: Why C has Pointers. Borax Man <rotflol2@hotmail.com> - 2011-12-08 18:32 +1100
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:20 -0800
        Re: Why C has Pointers. André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-12-08 13:44 +0100
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-09 05:04 -0800
            Re: Why C has Pointers. gazelle@shell.xmission.com (Kenny McCormack) - 2011-12-09 14:59 +0000
              Re: Why C has Pointers. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-09 20:19 -0800
              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-10 07:36 -0800
    Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-08 00:12 -0800
    Re: Why C has Pointers. Cong Wang <xiyou.wangcong@gmail.com> - 2011-12-15 07:26 +0000
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 08:51 -0800
      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-17 10:10 -0800
        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 14:28 -0600
          Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 15:00 -0600
          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 13:55 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:27 -0600
              Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 01:26 +0000
                Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 22:34 -0600
                  Re: Why C has Pointers. "Philip Lantz" <prl@canterey.us> - 2011-12-17 23:48 -0800
                    Re: Why C has Pointers. superpollo <superpollo@tznvy.pbz> - 2011-12-18 11:06 +0100
                  Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-18 13:44 +0000
                  Re: Why C has Pointers. pete <pfiland@mindspring.com> - 2011-12-18 11:05 -0500
                  Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-18 11:50 -0500
                  Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:10 -0800
                    Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 16:03 -0600
                      Re: Why C has Pointers. Barry Schwarz <schwarzb@dqel.com> - 2011-12-27 14:40 -0800
                      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:08 -0800
                        Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-27 20:09 -0600
                          Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 23:00 -0800
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:53 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:39 -0500
                      Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:14 -0500
                        Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-27 15:36 -0800
                          Re: Why C has Pointers. James Kuyper <jameskuyper@verizon.net> - 2011-12-27 18:53 -0500
                      Re: Why C has Pointers. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-28 13:20 +0000
                  Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-28 08:42 -0800
                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 20:36 -0800
                  Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 04:56 +0000
                    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 21:37 -0800
                      Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 05:42 +0000
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 08:08 -0800
                          Re: Why C has Pointers. Robert Wessel <robertwessel2@yahoo.com> - 2011-12-18 10:36 -0600
                          Re: Why C has Pointers. Seebs <usenet-nospam@seebs.net> - 2011-12-18 18:50 +0000
                          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:39 -0800
                          Re: Why C has Pointers. gordonb.1i27q@burditt.org (Gordon Burditt) - 2011-12-21 22:34 -0600
                        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 07:56 -0800
                          Re: Why C has Pointers. John Tsiombikas <nuclear@member.fsf.org> - 2011-12-19 18:38 +0000
                            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 13:47 -0800
                              Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 02:58 -0800
                                Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-28 03:21 -0800
              Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-18 13:07 -0800
                Re: Why C has Pointers. "io_x" <a@b.c.invalid> - 2011-12-19 04:02 +0100
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:35 -0800
            Re: Why C has Pointers. ralph <nt_consulting64@yahoo.net> - 2011-12-17 18:41 -0600
          Re: Why C has Pointers. John Bode <jfbode1029@gmail.com> - 2011-12-19 05:14 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 09:50 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 15:48 -0800
          Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 00:21 -0800
            Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-10 01:03 -0800
      Re: Why C has Pointers. Keith Thompson <kst-u@mib.org> - 2011-12-17 11:45 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-17 15:18 -0800
        Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-19 14:10 -0800
          Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-20 10:46 -0800
    Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:15 +0100
      Re: Why C has Pointers. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-12-17 19:19 +0100
        Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800
    Re: Why C has Pointers. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-18 11:05 -0800
      Re: Why C has Pointers. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-19 02:48 -0800

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

#14699

On 2011-12-18, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
> If there is any boundary checking on a machine, 
> what does that mean in the execution speed?

This varies widely, from "you can't detect it" to "noticeable slowdown".

> Happy programming?

They exist because there's a market for them.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14746

On Dec 18, 4:08 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
> > On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> > >  In the language design C is easy to be mixed with assembly.
>
> > That, too, is an oversimplification.
>
> > > If one needs boundary checking  of an array,  other higher level programming
> > > languages are  better options.
>
> > Could be, but the fact is, there are bounds-checking implementations.  The
> > claim that there's no bounds-checking in C is not really generally true.
>
> > -s
>
> If there is any boundary checking on a machine,
> what does that mean in the execution speed?

the program runs slower

> Happy programming?

what makes you happier fast programs that crash or give wrong answers
or correct programs?

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

#14847

>> Could be, but the fact is, there are bounds-checking implementations.  The
>> claim that there's no bounds-checking in C is not really generally true.

Most any machine capable of generating a SIGSEGV has at least a
form of very loose bounds checking, with the checking done in
hardware.  It may not always trigger if you go a *little* out of
bounds, but often will if you go *way* out of bounds.  It's sort
of like GPS that warns you most of the time if you're on the wrong
continent.

> If there is any boundary checking on a machine, 
> what does that mean in the execution speed?

Since the OS generally uses the same mechanism to prevent processes
from clobbering each other, and it won't let you turn it off unless
perhaps you install your code as a driver, there is no alternative
so you can't measure it.

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

#14755

On Sunday, December 18, 2011 1:42:59 PM UTC+8, Seebs wrote:
> On 2011-12-18, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> >  In the language design C is easy to be mixed with assembly. 
> 
> That, too, is an oversimplification.
> 
> > If one needs boundary checking  of an array,  other higher level programming
> > languages are  better options. 
> 
> Could be, but the fact is, there are bounds-checking implementations.  The
> claim that there's no bounds-checking in C is not really generally true.
> 
> -s
> -- 
> Copyright 2011, all wrongs reversed.  Peter Seebach / usenet...@seebs.net
> http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
> http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my opinions.

In a virtual memory system of a descent OS, 
there's no studpid checking in the ap level. 

But if someone is writing AP in the real memory of some machine, 
it is still no need to check in C in the release version by a professional
programmer.

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

#14760

On 2011-12-19, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
>
> In a virtual memory system of a descent OS, 
> there's no studpid checking in the ap level. 

What is the ap level?
All virtual memory systems I'm aware of use page-level protection at
least. That is, invalid accesses to unmapped or protected pages are
trapped by the system and are used to either kill the application or
perform demand paging.

> But if someone is writing AP in the real memory of some machine, 
> it is still no need to check in C in the release version by a professional
> programmer.

I don't see how writing code as a profession or as a hobby has anything
to do with this.

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

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

#14770

On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:
> On 2011-12-19, 88888 Dihedral <dihedr...@googlemail.com> wrote:
> >
> > In a virtual memory system of a descent OS, 
> > there's no studpid checking in the ap level. 
> 
> What is the ap level?
> All virtual memory systems I'm aware of use page-level protection at
> least. That is, invalid accesses to unmapped or protected pages are
> trapped by the system and are used to either kill the application or
> perform demand paging.
> 
> > But if someone is writing AP in the real memory of some machine, 
> > it is still no need to check in C in the release version by a professional
> > programmer.
> 
> I don't see how writing code as a profession or as a hobby has anything
> to do with this.
> 

Writing code as a hobby is good toward a professional programmer.

Many engineers just write programs in the open source of sourceforge site
for fun. 
 

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

#15087

On Dec 19, 9:47 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:
> > On 2011-12-19, 88888 Dihedral <dihedr...@googlemail.com> wrote:
>
> > > In a virtual memory system of a descent OS,
> > > there's no studpid checking in the ap level.
>
> > What is the ap level?
> > All virtual memory systems I'm aware of use page-level protection at
> > least. That is, invalid accesses to unmapped or protected pages are
> > trapped by the system and are used to either kill the application or
> > perform demand paging.
>
> > > But if someone is writing AP in the real memory of some machine,
> > > it is still no need to check in C in the release version by a professional
> > > programmer.
>
> > I don't see how writing code as a profession or as a hobby has anything
> > to do with this.
>
> Writing code as a hobby is good toward a professional programmer.

not if they take a "this is only a hobby so quality doesn't matter"
attitude. Pretty soon hobby attitudes leak through to professional
programs. What sort of hobby is it where you don't care?

> Many engineers just write programs in the open source of sourceforge site
> for fun.

and they write shit?

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

#15092

Nick Keighley於 2011年12月28日星期三UTC+8下午6時58分40秒寫道：
> On Dec 19, 9:47 pm, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > On Tuesday, December 20, 2011 2:38:58 AM UTC+8, John Tsiombikas wrote:
> > > On 2011-12-19, 88888 Dihedral <dihe...@googlemail.com> wrote:
> >
> > > > In a virtual memory system of a descent OS,
> > > > there's no studpid checking in the ap level.
> >
> > > What is the ap level?
> > > All virtual memory systems I'm aware of use page-level protection at
> > > least. That is, invalid accesses to unmapped or protected pages are
> > > trapped by the system and are used to either kill the application or
> > > perform demand paging.
> >
> > > > But if someone is writing AP in the real memory of some machine,
> > > > it is still no need to check in C in the release version by a professional
> > > > programmer.
> >
> > > I don't see how writing code as a profession or as a hobby has anything
> > > to do with this.
> >
> > Writing code as a hobby is good toward a professional programmer.
> 
> not if they take a "this is only a hobby so quality doesn't matter"
> attitude. Pretty soon hobby attitudes leak through to professional
> programs. What sort of hobby is it where you don't care?
> 
> > Many engineers just write programs in the open source of sourceforge site
> > for fun.
> 
> and they write shit?

Not really at all, some are experiments and some are excellent. 

Nowadays programmers can sharpen their programming skills very fast in the 
open source projects. I remembered in the old days of workstations and mainframes. One had to pay service fees for those vendors of trivial settings 
from time to time  after installing new software packages that conflicted 
some packages installed.    

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

#14705

ralph <nt_consulting64@yahoo.net> writes:
> On Sat, 17 Dec 2011 13:55:44 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>ralph <nt_consulting64@yahoo.net> writes:
>>[...]
>>> I have trouble understanding the constant confusion between arrays and
>>> pointers. Way back when (and we are talking many moons ago <g>) when I
>>> started out in C my mentor explained it very simply in these terms in
>>> the first couple of days.
>>>
>>> 1) There is a difference between declarations and definitions.
>>> Remember which you are dealing with and when.
>>> 2) A pointer is a "variable", an array is a "constant"
>>
>>That doesn't really make sense.  An array variable is not a constant:
>>
>>    int arr[10];
>>    arr[5] = 42;
>>
>>I suppose what it means is that an array name, when it appears in an
>>expression (in most but not all context) decays to a pointer to the
>>array's first element, and that pointer value cannot be modified.  But I
>>think that saying an array is a constant just reinforces the confusion
>>between arrays and pointers.
>>
>
> I disagree. 
>
> Once the beginner gets it through his head that you can never do an
> assignment to 'arr' you resolve a ton of the questions we get around
> here. That as close to the definition of a "constant" as you can get.

That's not what the word "constant" means, though.  It's a bit closer to
what "const" means ("constant" and "const" are very different concepts
in C).

It's true that you can't assign to an array, and just saying that is
probably enough for a beginner.  But eventually you're going to want to
understand *why* you can't assign to an array -- and the reason is that
the array name is converted to a pointer to the first element.  That
pointer is a *value*, not an object/variable, and so you can't assign to
the pointer either, any more than you can do "42 = 43;".

>>> 3) The array name evaluates to the address of the first element in the
>>> array.
>>
>>This applies to any expression of array type, not just the name of a
>>declared array object.  But it doesn't apply in all contexts.
>>Specifically, an expression of array type is converted to a pointer to
>>the array object's first element *unless* it's:
>>
>>    The operand of a unary "sizeof" operator (sizeof arr gives you the
>>    same of the array, not of a pointer);
>>
>>    The operand of a unary "&" operator (&arr gives you the address of
>>    the array object; it's the same memory location as the address of
>>    its first element, but it's of a different type);
>>
>>    A string literal in an initializer used to initialize an array
>>    object.  In
>>        char arr[6] = "hello";
>>    the *value* of "hello" is copied into arr.
>>
>
> Yep. But what's the big deal. 

The big deal is that that's how the language works.  And the big deal is
that it's important to understand that "sizeof arr" gives you the size
of the array itself.  Your explanation that "The array name evaluates to
the address of the first element in the array" implies that "sizeof arr"
would yield the size of a pointer.

> And of course I disagree that it actually matters to the beginner that
> the address is of a "different type". Semantically and syntactically
> it comes out the same. Plenty of time to get into vague language
> later.

It *should* matter.  The difference in type between a pointer to an int
and a pointer to an array of int might not be the first thing you need
to learn, but you certainly should learn it at some point.

> Actually in some implementations whether "hello" gets copied and when
> if gets copied if it does depends on context. Again, why add
> confusion?

I'm trying to add understanding.  The underlying concepts are actually
fairly straightforward, but there are special-case rules involving
arrays and pointers (the decay of array expressions and the adjustment
of array parameters to pointer parameters) that, while convenient, cause
confusion.  IMHO, trying to each arrays and pointers in terms of the way
those special-case rules make them *look*, plants the seeds of further
confusion down the line.

I've seen far too many people saying that arrays are "really" just
pointers.

[...]

>>> 6) Since an array name is an address it can be used as a pointer that
>>> is initialized to point to the first element in the array. 
>>
>>In most contexts; see above.  It would be clearer to say that an array
>>name *decays to* an address (or pointer value).  And I wouldn't use the
>>word "initialized".
>>
>
> I would. And again what does 'decay' meant to the beginner?
> In code the name "arr" is changed to, or evaluates to, the address of
> the first element.

Ok, so don't use the word "decay".  The standard doesn't; it describes
it as a conversion (and perhaps I should have as well).  The term
"decay" is commonly used to describe the process, though.

[...]

>>> 9) The array operator evaluates to a storage map equation, eg.
>>>     type ar[i] := *(a + (i * sizeof(type))
>>
>>I'm not sure what syntax you're using.  What does "type" mean here?  And
>>C pointer arithmetic is already scaled by the size of the pointed-to
>>type.
>>
>>arr[i] is by definition equivalent to *(arr + i).
>>
>
> Think about it. 

I have, at great length.

Again, can you explain what you mean by "type"?  The equation makes more
sense without it.

Most of your equation, apart from the ":=", is valid C syntax:

    ar[i] := *(a + (i * sizeof(type))

which tends to imply that you're using the "+" operator as defined by C.
But in fact, you're using a "+" operator that adds a specified number of
*bytes* to a pointer value; that's not how C's "+" operator works.

It's certainly worth explaining that the addition is scaled by the size
of the pointed-to type, but using a C expression that doesn't have the
semantics you're assuming is not a good way to do it.

> You say that now, but you come back later in other response to point
> out "sizes". That "already scaled" is because the compiler knows the
> type, and he knows the type because you declared it.

I'm not aware that I've written anything that contradicts what I'm
saying here.  If I have, please point it out.

[snip]

Incidentally, when posting a followup, please feel free to snip any
quoted material that you're not responding to.

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

#14729

"Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio
news:lnaa6p4mic.fsf@nuthaus.mib.org...
> ralph <nt_consulting64@yahoo.net> writes:
> Again, can you explain what you mean by "type"?  The equation makes more
> sense without it.
>
> Most of your equation, apart from the ":=", is valid C syntax:
>
>    ar[i] := *(a + (i * sizeof(type))
>
> which tends to imply that you're using the "+" operator as defined by C.
> But in fact, you're using a "+" operator that adds a specified number of
> *bytes* to a pointer value; that's not how C's "+" operator works.

type  *a;

a[i] should be *((type*)((char*)a+(i*sizeof(type))) right?

> It's certainly worth explaining that the addition is scaled by the size
> of the pointed-to type, but using a C expression that doesn't have the
> semantics you're assuming is not a good way to do it.

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

#14669

On Sunday, December 18, 2011 4:28:14 AM UTC+8, ralph wrote:
> On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schw...@dqel.com>
> wrote:
> 
> >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> ><dihedr...@googlemail.com> wrote:
> >
> >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >>> hi
> >>> my Q is on the c language tell me now why c has pointers.
> >>> parshant
> >>> 
> >>> 
> >>> -- 
> >>> curixinfotech
> >>> ------------------------------------------------------------------------
> >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
> >>
> >>OK, I'll explain how to use a pointer in C without any knowledge in the 
> >>hardware or assembly here.
> >>// 
> >>int i;
> >>int a[3]={ 1,2,3} ; // an array of 3 integers
> >>int* ptr1; // Note the star should be right after int, not initialize
> >>int* ptr2; // not initialized
> >>
> >>ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
> >
> >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
> >which, in the general case, they are not.  ptr1 is simply a pointer
> >that points to the start of a.  Even though they share some
> >similarities in the language syntax, a pointer is a completely
> >different type than an array.  Calling one an alias of the other just
> >breeds unnecessary confusion.
> >
> 
> I agree. 
> 
> I have trouble understanding the constant confusion between arrays and
> pointers. Way back when (and we are talking many moons ago <g>) when I
> started out in C my mentor explained it very simply in these terms in
> the first couple of days.
> 
> 1) There is a difference between declarations and definitions.
> Remember which you are dealing with and when.
> 2) A pointer is a "variable", an array is a "constant"
> 3) The array name evaluates to the address of the first element in the
> array.
> 4) A pointer is a variable that holds the address of another variable
> or an array.
> 5) All pointers must be intialized before you use them.
> 6) Since an array name is an address it can be used as a pointer that
> is initialized to point to the first element in the array. 
> 7) *variable means the contents of the variable.

 *variable is easy to be miss-understood

 *ptr_variable is different from ptr_variable

 *variable if used for non-pointer variables, the compiler 
will say something, thus you are right in the general sense in C,
but not clear enough for novices 

   

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

#14671

On Sat, 17 Dec 2011 15:35:49 -0800 (PST), 88888 Dihedral
<dihedral88888@googlemail.com> wrote:

>On Sunday, December 18, 2011 4:28:14 AM UTC+8, ralph wrote:
>> On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schw...@dqel.com>
>> wrote:
>> 
>> >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
>> ><dihedr...@googlemail.com> wrote:
>> >
>> >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>> >>> hi
>> >>> my Q is on the c language tell me now why c has pointers.
>> >>> parshant
>> >>> 
>> >>> 
>> >>> -- 
>> >>> curixinfotech
>> >>> ------------------------------------------------------------------------
>> >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
>> >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
>> >>
>> >>OK, I'll explain how to use a pointer in C without any knowledge in the 
>> >>hardware or assembly here.
>> >>// 
>> >>int i;
>> >>int a[3]={ 1,2,3} ; // an array of 3 integers
>> >>int* ptr1; // Note the star should be right after int, not initialize
>> >>int* ptr2; // not initialized
>> >>
>> >>ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
>> >
>> >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
>> >which, in the general case, they are not.  ptr1 is simply a pointer
>> >that points to the start of a.  Even though they share some
>> >similarities in the language syntax, a pointer is a completely
>> >different type than an array.  Calling one an alias of the other just
>> >breeds unnecessary confusion.
>> >
>> 
>> I agree. 
>> 
>> I have trouble understanding the constant confusion between arrays and
>> pointers. Way back when (and we are talking many moons ago <g>) when I
>> started out in C my mentor explained it very simply in these terms in
>> the first couple of days.
>> 
>> 1) There is a difference between declarations and definitions.
>> Remember which you are dealing with and when.
>> 2) A pointer is a "variable", an array is a "constant"
>> 3) The array name evaluates to the address of the first element in the
>> array.
>> 4) A pointer is a variable that holds the address of another variable
>> or an array.
>> 5) All pointers must be intialized before you use them.
>> 6) Since an array name is an address it can be used as a pointer that
>> is initialized to point to the first element in the array. 
>> 7) *variable means the contents of the variable.
>
> *variable is easy to be miss-understood
>
> *ptr_variable is different from ptr_variable
>
> *variable if used for non-pointer variables, the compiler 
>will say something, thus you are right in the general sense in C,
>but not clear enough for novices 
>

I disagree. (Naturally. <g>)

This ...
> *ptr_variable is different from ptr_variable

is all about context.

You only get an error or in trouble if you use *variable on a
NON-Address - whether constant or 'variable'.

I firmly believe, and several years of teaching C confirms for me,
that it is when ones starts straying from the simple that confusion is
introduced.

-ralph

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

#14751

On Saturday, December 17, 2011 2:28:14 PM UTC-6, ralph wrote:
> On Sat, 17 Dec 2011 10:10:09 -0800, Barry Schwarz <schw...@dqel.com>
> wrote:
> 
> >On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> ><dihedr...@googlemail.com> wrote:
> >
> >>On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >>> hi
> >>> my Q is on the c language tell me now why c has pointers.
> >>> parshant
> >>> 
> >>> 
> >>> -- 
> >>> curixinfotech
> >>> ------------------------------------------------------------------------
> >>> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> >>> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
> >>
> >>OK, I'll explain how to use a pointer in C without any knowledge in the 
> >>hardware or assembly here.
> >>// 
> >>int i;
> >>int a[3]={ 1,2,3} ; // an array of 3 integers
> >>int* ptr1; // Note the star should be right after int, not initialize
> >>int* ptr2; // not initialized
> >>
> >>ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
> >
> >If that were true, the sizeof(a) and sizeof(ptr1) would be equal
> >which, in the general case, they are not.  ptr1 is simply a pointer
> >that points to the start of a.  Even though they share some
> >similarities in the language syntax, a pointer is a completely
> >different type than an array.  Calling one an alias of the other just
> >breeds unnecessary confusion.
> >
> 
> I agree. 
> 
> I have trouble understanding the constant confusion between arrays and
> pointers. Way back when (and we are talking many moons ago <g>) when I
> started out in C my mentor explained it very simply in these terms in
> the first couple of days.
> 
> 1) There is a difference between declarations and definitions.
> Remember which you are dealing with and when.
> 2) A pointer is a "variable", an array is a "constant"

A pointer is a pointer, an array is an array.  They are completely different animals with different behavior.

Array *expressions* may not be the target of an assignment, because the language definition says so.  No need to invoke anything about "constants", which is annoyingly inaccurate.  

> 3) The array name evaluates to the address of the first element in the
> array.

In most circumstances, an expression with type "N-element array of T" will be *replaced* with a pointer expression of type "pointer to T" that evaluates to the location of the first element in the array.  The exceptions to this rule are when the array expression is an operand of either the sizeof or unary & operators, or when the array expression is a string literal that is being used to initialize another array in a declaration.

> 4) A pointer is a variable that holds the address of another variable
> or an array.
> 5) All pointers must be intialized before you use them.
> 6) Since an array name is an address it can be used as a pointer that
> is initialized to point to the first element in the array. 

In most circumstances, an expression with type "N-element array of T" will be *replaced* with a pointer expression of type "pointer to T" that evaluates to the location of the first element in the array.  The exceptions to this rule are when the array expression is an operand of either the sizeof or unary & operators, or when the array expression is a string literal that is being used to initialize another array in a declaration.

> 7) *variable means the contents of the variable.
> 8) &variable means the address of the variable.
> 9) The array operator evaluates to a storage map equation, eg.
>     type ar[i] := *(a + (i * sizeof(type))

The subscript operation a[i] is *defined* as *(a + i); pointer arithmetic takes the type of the pointer into account, so you're always referring to the i'th *element* of the array.

> 10) In all "pointer" operations you are either chewing on an address
> or the contents (value) at that address. Simple deconstrution of the
> even the most complex expression will quickly reveal which it is.
> 
> I've since learned how to restate the above in fancier terminology,
> but those simple rules have stuck and served me well from my second
> week in C to today - thirty plus years later.
> 
> -ralph

Simple but imprecise.  I've discovered over the last 20+ years that it's better to be precise at the expense of brevity if you want people to really understand how the C language behaves.  

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

#14695

Yes, you do know how C's pointer works. 

It is just my personal style to separate the declaration of a pointer
and an assignment of a pointer by the RHS in another line clearly.  

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

#15671

Barry Schwarz於 2011年12月18日星期日UTC+8上午2時10分09秒寫道：
> On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> <dihedr...@googlemail.com> wrote:
> 
> >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> hi
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >> 
> >> 
> >> -- 
> >> curixinfotech
> >> ------------------------------------------------------------------------
> >> curixinfotech's Profile: http://forums.yourdomain.com.au/member.php?userid=134
> >> View this thread: http://forums.yourdomain.com.au/showthread.php?t=3319
> >
> >OK, I'll explain how to use a pointer in C without any knowledge in the 
> >hardware or assembly here.
> >// 
> >int i;
> >int a[3]={ 1,2,3} ; // an array of 3 integers
> >int* ptr1; // Note the star should be right after int, not initialize
> >int* ptr2; // not initialized
> >
> >ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
> 
> If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

Why do you care about the size of an array declared on the stack?

Everything on the stack is to be popped out in the exit of a function in C. 

But a pointer allocated in the heap is different. 

 

> which, in the general case, they are not.  ptr1 is simply a pointer
> that points to the start of a.  Even though they share some
> similarities in the language syntax, a pointer is a completely
> different type than an array.  Calling one an alias of the other just
> breeds unnecessary confusion.

A pointer defines an alias to a variable. Don't you get it in C or assembly?

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

#15679

for some reason "Dihedral" has revived this ancient topic

On Jan 9, 11:48 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> Barry Schwarz於 2011年12月18日星期日UTC+8上午2時10分09秒寫道：
> > On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> > <dihedr...@googlemail.com> wrote:
> > >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:


> > >> my Q is on the c language tell me now why c has pointers.

you never explained why you wanted to know this or what sort answer
would satisfy you.


> > >OK, I'll explain how to use a pointer in C without any knowledge in the
> > >hardware or assembly here.

and then you plummet into implementaion specifics like a fish into
water...

> > >int i;
> > >int a[3]={ 1,2,3} ; // an array of 3 integers
> > >int* ptr1; // Note the star should be right after int, not initialize

this is an opinion not a fact. It is quite common (more common?) for C
programmers to do the opposite of what you suggest.

> > >int* ptr2; // not initialized
>
> > >ptr1=a; // Read this as  to make ptr1 to be an alias of a.

no. Not really.

> > If that were true, the sizeof(a) and sizeof(ptr1) would be equal\

exactly. It also isn't an alias.

> Why do you care about the size of an array declared on the stack?

as usual dihedral inhabits a universe not co-terminus with our own.

becuase it might blow the stack? the point is 'ptr1' is NOT an alias
for 'a' because **they have different behaviour***

Also, how do you know these identifiers refer to automatic variables?
The indentation indicates otherwise.

> Everything on the stack is to be popped out in the exit of a function in C.

dihedral spouts irrelevence again

> But a pointer allocated in the heap is different.

why? The alias stuff nonsense no matter where they are allocated

> > which, in the general case, they are not.  ptr1 is simply a pointer
> > that points to the start of a.  Even though they share some
> > similarities in the language syntax, a pointer is a completely
> > different type than an array.  Calling one an alias of the other just
> > breeds unnecessary confusion.

yes

> A pointer defines an alias to a variable. Don't you get it in C or assembly?

just repeating nonsense doesn't make it true. Argument ad Goebbels

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

#15680

Nick Keighley於 2012年1月10日星期二UTC+8下午4時21分05秒寫道：
> for some reason "Dihedral" has revived this ancient topic
> 
> On Jan 9, 11:48 pm, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > Barry Schwarz於 2011年12月18日星期日UTC+8上午2時10分09秒寫道：
> > > On Sat, 17 Dec 2011 08:51:33 -0800 (PST), 88888 Dihedral
> > > <dihe...@googlemail.com> wrote:
> > > >On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> 
> 
> > > >> my Q is on the c language tell me now why c has pointers.
> 
> you never explained why you wanted to know this or what sort answer
> would satisfy you.
> 
> 
> > > >OK, I'll explain how to use a pointer in C without any knowledge in the
> > > >hardware or assembly here.
> 
> and then you plummet into implementaion specifics like a fish into
> water...
> 
> > > >int i;
> > > >int a[3]={ 1,2,3} ; // an array of 3 integers
> > > >int* ptr1; // Note the star should be right after int, not initialize
> 
> this is an opinion not a fact. It is quite common (more common?) for C
> programmers to do the opposite of what you suggest.
> 
> > > >int* ptr2; // not initialized
> >
> > > >ptr1=a; // Read this as  to make ptr1 to be an alias of a.
> 
> no. Not really.
> 
> > > If that were true, the sizeof(a) and sizeof(ptr1) would be equal\
> 
> exactly. It also isn't an alias.
> 
> > Why do you care about the size of an array declared on the stack?
> 
> as usual dihedral inhabits a universe not co-terminus with our own.
> 
> becuase it might blow the stack? the point is 'ptr1' is NOT an alias
> for 'a' because **they have different behaviour***
> 
> Also, how do you know these identifiers refer to automatic variables?
> The indentation indicates otherwise.
> 
> > Everything on the stack is to be popped out in the exit of a function in C.
> 
> dihedral spouts irrelevence again
> 
> > But a pointer allocated in the heap is different.
> 
> why? The alias stuff nonsense no matter where they are allocated
> 
> > > which, in the general case, they are not.  ptr1 is simply a pointer
> > > that points to the start of a.  Even though they share some
> > > similarities in the language syntax, a pointer is a completely
> > > different type than an array.  Calling one an alias of the other just
> > > breeds unnecessary confusion.
> 
> yes
> 
> > A pointer defines an alias to a variable. Don't you get it in C or assembly?
> 
> just repeating nonsense doesn't make it true. Argument ad Goebbels

I am not interested to argue with ASSEMBLY IDIOTS.

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

#14660

88888 Dihedral <dihedral88888@googlemail.com> writes:
> On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
>> my Q is on the c language tell me now why c has pointers.
>> parshant
>
> OK, I'll explain how to use a pointer in C without any knowledge in the 
> hardware or assembly here.
> // 
> int i;
> int a[3]={ 1,2,3} ; // an array of 3 integers
> int* ptr1; // Note the star should be right after int, not initialize

Why should the * be adjacent to "int"?  My own preferred style (and, I
think, that of most C programmers) is:

    int *ptr1;

The syntax of declarations in C follows (more or less) the syntax of
expressions; "declaration follows use".  So "int *ptr;" says that *ptr
is an int -- from which it follows that ptr is a pointer to an int,
i.e., an int*.

This layout follows the grammar more closely, and makes an (admittedly
unwise) declaration like this:

    int *pointer, not_a_pointer;

easier to understand.

But there is a school of thought that prefers to put the * next to the
type name.  That seems to be the usual convention in C++.  That's ok if
you avoid declaring multiple variables in one declaration (which you
should probably do anyway).

Note that the same principle might suggest:

    int[3] arr;

which is of course a syntax error.

> int* ptr2; // not initialized
>
> ptr1=a; // Read this as  to make ptr1 to be an alias of a. 

That's not necessarily a good way to think of it.  Since "a" is an array
object the expression consisting of its name decays to a pointer to its
first element.  That pointer value is then stored in ptr1.  ptr1 points
to the first element of a.  To show that it's not a true alias, consider
sizeof a vs. sizeof ptr1.

> for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
> for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
> //This is a shadow copy. 
> ptr1[0]=6; ptr2[1]=6;
> for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
> // a[0]=? a[1]=?
>
> //Deep copy is different.
> ptr2=malloc(3*sizeof(int)); // get another array from the heap 
> // if (ptr2==NULL) then raise an error!!!
> memcpy(ptr2,ptr1,3*sizeof(int)); // make a deep copy 
> ptr2[0]=-6; *(ptr+2)=-6; 
>
> for(i=0;i<3;i++)  printf("The value of a[%d]=%d.\n", i, a[i]);
> for(i=0;i<3;i++)  printf("The value of ptr1[%d]=%d.\n", i, ptr1[i]);
> for(i=0;i<3;i++)  printf("The value of ptr2[%d]=%d.\n", i, ptr2[i]);

Read section 6 of the comp.lang.c FAQ, <http://c-faq.com>.

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

#14668

On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:
> 88888 Dihedral <dihedr...@googlemail.com> writes:
> > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >
> > OK, I'll explain how to use a pointer in C without any knowledge in the 
> > hardware or assembly here.
> > // 
> > int i;
> > int a[3]={ 1,2,3} ; // an array of 3 integers
> > int* ptr1; // Note the star should be right after int, not initialize
> 
> Why should the * be adjacent to "int"?  My own preferred style (and, I
> think, that of most C programmers) is:
> 
>     int *ptr1;
> 
int** (*methods[ ])() ;

How do you read this? 

int* (*methods2[ ])() ;

int* (*methods3[ ])( int* (*functor)(), int* ) ;

methods, methods2, and methods3 are different arrays of functors. 

It is easy to use functors to perform tricks in functional programming. 
 

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

#14773

On Sunday, December 18, 2011 3:45:14 AM UTC+8, Keith Thompson wrote:
> 88888 Dihedral <dihedr...@googlemail.com> writes:
> > On Wednesday, December 7, 2011 8:22:56 PM UTC+8, curixinfotech wrote:
> >> my Q is on the c language tell me now why c has pointers.
> >> parshant
> >
> > OK, I'll explain how to use a pointer in C without any knowledge in the 
> > hardware or assembly here.
> > // 
> > int i;
> > int a[3]={ 1,2,3} ; // an array of 3 integers
> > int* ptr1; // Note the star should be right after int, not initialize
> 
> Why should the * be adjacent to "int"?  My own preferred style (and, I
> think, that of most C programmers) is:
> 
>     int *ptr1;
> 
> The syntax of declarations in C follows (more or less) the syntax of
> expressions; "declaration follows use".  So "int *ptr;" says that *ptr
> is an int -- from which it follows that ptr is a pointer to an int,
> i.e., an int*.
> 
> This layout follows the grammar more closely, and makes an (admittedly
> unwise) declaration like this:
> 
>     int *pointer, not_a_pointer;
> 
> easier to understand.
> 
> But there is a school of thought that prefers to put the * next to the
> type name.  That seems to be the usual convention in C++.  That's ok if
> you avoid declaring multiple variables in one declaration (which you
> should probably do anyway).
> 
> Note that the same principle might suggest:
> 
>     int[3] arr;
> 
> which is of course a syntax error.
> 
> > int* ptr2; // not initialized
> >
> > ptr1=a; // Read this as  to make ptr1 to be an alias of a. 
> 
> That's not necessarily a good way to think of it.  Since "a" is an array
> object the expression consisting of its name decays to a pointer to its
> first element.  That pointer value is then stored in ptr1.  ptr1 points
> to the first element of a.  To show that it's not a true alias, consider
> sizeof a vs. sizeof ptr1.

I do not allocate arrays in the auto mode  very often in C. 
But for an example, I just have to show the silly array allocated in the 
auto mode. 

Normally I allocate a buffer from the heap by malloc. 
Also I wrote functions that could  return  pointers  and have to clean up
local buffers correctly before exiting the function. 

 

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

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

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

csiph-web