Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Difference between these pointer syntaxes Date: Fri, 19 Aug 2016 18:25:59 -0700 Organization: None to speak of Lines: 96 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="30449"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XzEcEf717HVlt/EowS49D" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:wYeeBtg6ij91MQVhqmLeTfhtU2w= sha1:BjNOvSUz9Z9xq7KevNQyQwHZsaw= Xref: csiph.com comp.lang.c:92524 Les Cargill writes: > Tim Rentsch wrote: >> Keith Thompson writes: >> >>> BartC writes: >>> [...] >>>> This is why a list of pitfalls can be more important than constantly >>>> having the entire set of array/pointer interactions in your mind. >>> >>> Fine, I find it easier to start with an understanding of how they >>> interact, but it's your call. >>> >>> All I ask at this point is that you stop trying to explain array/pointer >>> interactions to others. If you find yourself saying that arrays and >>> pointers are "the same", you've got it wrong, and you should avoid >>> confusing others. >> >> His goal is to confuse other people. > > By no means. Look, my operating ... methods for dealing > with pointers and arrays take up a lot less space > than what passes for verbiage on the subject, both here and in > various books. > > All the "standard" based stuff is fine for what it is, but it's almost > completely useless in deriving a working knowledge of the language. It > may well be actively damaging. *It's confusing*. That's the problem. I disagree. I *understand* the rules in the standard, and I know how to derive the behavior of various constructs from those rules. I know they can be confusing, but for most people the confusion only lasts until they figure out just what the rules are (and *unlearn* the idea that "arrays are just pointers"). If you start with that premise, *maybe* you can be a successful C programmer by memorizing some exceptions and/or avoiding some constructs. But I'm not convinced that it's possible to form a coherent and correct mental model of C that includes the idea that "arrays are just pointers". And even if it is possible, I expect that you'd need far more exceptions, many with far weaker justifications, than the handful that are currently in the standard. And your hypothetical static_allocate() didn't help -- or perhaps more to the point it didn't help *me*. (It reminds me of the epicycles that Ptolemaic astronomers had to introduce to make their geocentric model consistent with observations. Ptolemy might have found Kepler's description of a heliocentric system with elliptical orbits ugly and unacceptable, but it has the considerable virtue that it works. Perhaps I'm stretching the analogy too far.) The discussions here have been complicated largely because we've had to spend a lot of time talking about what arrays *aren't*. I think it would be a lot simpler if we could ignore the misconceptions and just explain what arrays *are*. (And by "arrays" I mean array types, array objects, array expressions, array values, and so forth.) (Note to BartC: None of what I'm saying has to do with whether C's rules are good, or acceptable, or elegant, or whatever. I'm only discussing what those rules actually *are*, not expressing an opinion about their virtues.) > I'm attempting to demonstrate that *two simple rules* define all > the differences between them in practice. I don't recall you stating what those two simple rules are. > The standard is a critical document, very important indeed. But it's > barely even English and it's certainly not clear English. The very fact > that this thread exists at all is abundant evidence of that. > >> Asking him to stop probably >> only makes things worse. > > Done. After all, I have no wish to continue to disambiguate between > what "a pointer" and "a pointer object" mean. Hint: the same bloody > thing :) Meaning no offense, but seriously.... The phrase "a pointer" is also used to refer to "a pointer value". See, for example, the standard's description of the malloc() function, which returns "a pointer to the new object" or "a null pointer". And the distinction is particularly important when talking about the relationship between arrays and pointers. "An array is just a pointer". An array *what*? Object? Expression? Value? It matters. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"