References in C

S

Seebs

I outlined a stored program digital computer.
You are talking about the C abstract machine,
and that is abstracted from the spdc. The similarities
are more important than the differences.

I'm not sure of this. I think the non-relation between different objects
is a very big difference from the SPDC.
Are those details you list difficulties for you?
They are not for me, even when I get something wrong.

Not really. The big recurring difficulties for me are just ending up
with bogus pointers in one way or another -- having some spare copy of
a pointer, and not realizing it should have been invalidated, stuff like
that.

-s
 
J

James Kuyper

There is a list of storage registers holding a number.

Each storage register has an address, itself a number.

The addresses are sequential: e.g. 0, 1, 2, 3, ..., N.

The contents of a storage register can be read, and its
contents interpreted as a machine instruction and
executed.

The contents of a storage register can be interpreted
as an address, A, to fetch the contents of the storage
register at address A.

That's it. That is the only difficulty. The rest is
details and thinking straight---a chronic difficulty
for some, but not an inherent difficulty of pointers.

Pointer values are more than just the addresses of things; they are a
higher level construct than that, and most of the problems associated
with them occur at the higher level. The most important high-level
feature of pointers, which is not explicitly covered by your
description, is the fact that they can be invalid. They can become
invalid for some purposes while remaining valid for others:

1. comparison of two pointer values for equality
2. comparison of two pointer values for relative order
3. reading through the pointer value
4. writing through the pointer value

Your description of hardware addresses incorrectly implies that
comparison of addresses for equality should always be safe, and that
comparison of addresses for relative order should always produce
consistent results; there are real-world fully-conforming
implementations of C for which that's not the case for C pointer values.

Uninitialized pointer objects, and pointer objects whose representation
has been manipulated by means other than assignment through an lvalue of
a compatible type, may have trap representations. The non-existent value
of such pointer objects, and pointer values that used to point at
objects whose lifetime has since ended, have undefined behavior for all
four uses.

Null pointer values can only be compared for equality with other pointer
values; the other three uses all have undefined behavior.
Comparing pointer values for relative order that do not point within (or
one past the end of) the same array object (with single objects being
treated as 1-element arrays) has undefined behavior.

Attempting to write through a pointer value that points at an object
defined as 'const' has undefined behavior; the same is true of any
pointer value that points into the array corresponding to a string literal.
Likely we are thinking of different notions when using
the word "difficulty."

Possibly; in my experience, most of the difficulty with C pointers comes
from the necessity of avoiding the undefined behavior referred to above,
an issue not even hinted at by your description of hardware addresses.
With care, it's possible to avoid most such problems; but care is indeed
required, and it's not always easy. To say it's "no difficulty" is to
imply that such care is unnecessary.
 
A

Alan Curry

Editors and other experts in grammar and English
composition agree: when you write yourself into a
corner, then recast the sentence.

But those original "sentences" have nothing wrong with them. Brevity is
beautiful.
if ( drv != NULL
&& drv->pm != NULL
&& drv->pm->prepare != NULL)

Nearly doubling the number of tokens can't possibly be an improvement in
readability.
 
M

Michael Press

But those original "sentences" have nothing wrong with them. Brevity is
beautiful.


Nearly doubling the number of tokens can't possibly be an improvement in
readability.

Do I repeat my side of the argument now?
 
K

Keith Thompson

(e-mail address removed) (Alan Curry) writes:
[...]
Nearly doubling the number of tokens can't possibly be an improvement in
readability.

Seriously?

You read long texts faster than short ones?

Spd s nt th nl cncrn. [*]

Readability is not purely a function of either length or speed.
I could probably read a one-page C program faster than I could read
a one-line APL program, even if I knew both languages equally well
(I don't).

Is the readability of a C program improved by removing all comments and
shortening all identifiers to 1 or 2 characters? (Ok, strictly speaking
neither of those changes the number of tokens, but it's the same general
idea.)

I like to have visual cues that make it clearer what's going on.
Often those visual cues are in the form of extra tokens.
``(x ^ y) | z'' is easier (for me) to read than ``x ^ y | z'',
because the former doesn't force me to look up or remember the
relative precedence of bitwise inclusive and exclusive OR.

I find ``if (p == NULL)'' easier to read than ``if (p)'' because it
emphasizes the fact that p is a pointer.

If you find ``if (p)'' clearer, that's fine. I'm not trying
to change your mind, just saying that readability is not always
inversely related to the number of tokens.

(Unless, of course, p is actually a character. :cool:})

[*] Speed is not the only concern.
 
S

Shao Miller

But those original "sentences" have nothing wrong with them. Brevity is
beautiful.


Nearly doubling the number of tokens can't possibly be an improvement in
readability.

One pattern that I sometimes see in code is where predicates are
actually defined with either a macro or a function:

#define IS_PRIMARY_COLOUR(colour) ( \
((colour) == red) || \
((colour) == blue) || \
((colour) == yellow) \
)

And then:

if (IS_PRIMARY_COLOUR(something))
/* ... */

So:

#define IS_VALID_POINTER(ptr) (ptr)
/* ... */
if (IS_VALID_POINTER(something))
/* ... */

is perhaps more obvious while reading, by reminding you that 'something'
either is or is not a valid pointer. Whereas with:

if (!something)
/* ... */

you might not recall what 'something' is. From that perspective, I can
understand a benefit to:

if (something != NULL)
/* ... */

because like the macro, 'NULL' is a hint that 'something' is a pointer.

However, it seems a peculiarity of equality operators (and pointers)
that multiple pointer values can compare as equal with 'NULL', whereas
with other types, one is usually testing for a _particular_ value, if
I'm not mistaken. Thus I'd still sooner use the macro than the equality
operators, and constrain my use of the equality operators to comparing
particular values, where the value on the left either is or is not the
value on the right and vice versa. Comparing with 'NULL' seems more
like a classification than an identification.

But the implicit "zero/null" predicate seems pretty simple, so foo on
using the macro, despite forgetting the type of 'something'. :)

#define NONNULL(ptr) (ptr)
#define ISNULL(ptr) (!(ptr))
#define POINTS(ptr) (ptr)
 
J

JG

Of course then you have
int foo;
with (baz) {
  foo = 4; // which foo?
}
But that's something specifications are for...

What does Pascal do?

(But I agree with the other poster that it should be baz.foo, although I
could easily imagine that it would be frequently desirable to be able to
access the "uplevel" foo - something that ordinary "variable shadowing"
prevents [unless extreme measures are taken...])

--
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller=

Whats all this talk about a Shiksa Library Tour ?? What library
charges for entry tickets ??
I'm a regular listener but Steph hardly mentions which libraries she
will be touring. Why keep the cities a secret, Steph ??
 
S

Seebs

I find ``if (p == NULL)'' easier to read than ``if (p)'' because it
emphasizes the fact that p is a pointer.

See, I don't care whether p is a pointer. I care whether it's true or
not. I tend to view "p == NULL" as being in the same category as
declaring "char *ptrString" instead of "char *s". Yes, it gives more
information, but the more information is not something I really
need made explicit to work with the object, and it distracts me from
thinking at the right level.

-s
 
S

Shao Miller

See, I don't care whether p is a pointer. I care whether it's true or
not. I tend to view "p == NULL" as being in the same category as
declaring "char *ptrString" instead of "char *s". Yes, it gives more
information, but the more information is not something I really
need made explicit to work with the object, and it distracts me from
thinking at the right level.

Well it's really quite amazing how diverse people are, and how different
perspectives can be tolerated, and how sharing one's reasoning for one's
preferences can inspire. :)
 
P

Phil Carmody

Keith Thompson said:

Well, I'd be the first to nack your patches were you to try and
help readability in Nokia's meego-by-name-only linux kernel!

But these are matters of style and taste, so it's not that you're
wrong, just at odds with the spartan choices linux (if it may be
anthropomorphised) generally prefers. A quick git grep shows that
this preference is a weak one, there's plenty of more verbose
conditions in the kernel.

Phil
 
C

Chad

Well, I'd be the first to nack your patches were you to try and
help readability in Nokia's meego-by-name-only linux kernel!

But these are matters of style and taste, so it's not that you're
wrong, just at odds with the spartan choices linux (if it may be
anthropomorphised) generally prefers. A quick git grep shows that
this preference is a weak one, there's plenty of more verbose
conditions in the kernel.

And this can also lead to following creative abuse..

while(the_pope_is_gay) {
/* do something really unholy */
}
 
S

sandeep

jacob said:
Le 28/06/11 20:01, Tim Rentsch a écrit :

Excuse me if I offended you. I never intended to, and as far as I
remember I never insulted or say anything bad about you.

I respect of course your opinions, and I do think they are important
since I have always answered each one of your remarks.

But it is true that I am getting kind of paranoiac lately. I have been
trying to improve the language by working and working in this community
for around 20 years. The first versions of lcc-win are from 1995, and I
started working in this project around 1992. Yes, it must be almost 20
years.

I have accomplished nothing. All my proposals were ignored and in this
group, a hate campaign started by K Thompson and R Heathfield provoked
that most people (in this group) just think I am the "shrewd commercial"
that they described.

Nevertheless I go on working. I have developed a containers library from
scratch with the idea of standardizing it. The specifications make for
around 300 pages, all the code for a sample implementation is available.

Nothing. Not a single answer in comp.std.c. In this group some people
made positive contributions but nobody is working on that besides me.

Then, in comp.std.c somebody asks for a small improvement that I
implemented in lcc-win, and that we discussed in comp.std.c in 2002...
Almost ten years ago, and the same problem resurfaces. And I see as in
an ever repeating nightmare that nothing will ever change.

The standard is closed now, they just left a window for discussion open
for several *months* then they decided to close it. After leaving a gap
of 10 years without any discussion.

And I could go on with my "examples", but it would be unnecessary. That
is why I start getting mad/paranoiac.

jacob

Sadly my experience too in this group, is that some of the people who are
great experts in C, nevertheless are not open to any suggestions for
improvement. They will always respond negatively to any proposed
enhancement of C. Often they use scorn and ridicule. Mr Thomson and Dr
Sosman are the main two I have found like this. It is sad because truly
they have great C expertise, but no interest in developing the language
for the future!
 
C

Chad

Sadly my experience too in this group, is that some of the people who are
great experts in C, nevertheless are not open to any suggestions for
improvement. They will always respond negatively to any proposed
enhancement of C. Often they use scorn and ridicule. Mr Thomson and Dr
Sosman are the main two I have found like this. It is sad because truly
they have great C expertise, but no interest in developing the language
for the future!

I don't know this if this going to be on topic or not, but here
something one of the former netscape/AOL engineers once told me when
about people who wanted to develop C. "If you don't like then, then
create you're own f-cking programming language. Otherwise, just shut
the f-ck up, and get back to work before I write you up."
 
K

Keith Thompson

sandeep said:
Sadly my experience too in this group, is that some of the people who are
great experts in C, nevertheless are not open to any suggestions for
improvement. They will always respond negatively to any proposed
enhancement of C. Often they use scorn and ridicule. Mr Thomson and Dr
Sosman are the main two I have found like this. It is sad because truly
they have great C expertise, but no interest in developing the language
for the future!

If you're referring to me, please spell my name correctly.

You need to understand the difference between technical criticism and
"scorn and ridicule".
 
T

Tim Rentsch

Michael Press said:
Editors and other experts in grammar and English
composition agree: when you write yourself into a
corner, then recast the sentence.

if ( drv != NULL
&& drv->pm != NULL
&& drv->pm->prepare != NULL)

if ( p != NULL
&& p->detect != NULL
&& p->detect() > 0)

return suspend_ops != NULL
&& suspend_ops->valid != NULL
&& suspend_ops->valid(state) != NULL;

These haven't been recasted, just written using a
different stylistic preference -- like adding a comma
after the penultimate item in a series of three or
more.

Regardless of one's personal preferences about style
here, any programmer who doesn't immediately and easily
understand the first, shorter forms of these examples
either needs a C refresher course or shouldn't be
programming in C.
 
J

jacob navia

Le 03/07/11 23:33, Keith Thompson a écrit :
You need to understand the difference between technical criticism and
"scorn and ridicule".

hypocrisy

1. a pretense of having a virtuous character, moral or religious
beliefs or principles, etc., that one does not really possess.
2. a pretense of having some desirable or publicly approved attitude.


hypocrite

1. a person who pretends to have virtues, moral or religious beliefs,
principles, etc., that he or she does not actually possess, especially
a person whose actions belie stated beliefs.

2.
a person who feigns some desirable or publicly approved attitude,
especially one whose private life, opinions, or statements belie his or
her public statements.

http://dictionary.reference.com
 
K

Kenny McCormack

If you're referring to me, please spell my name correctly.

You need to understand the difference between technical criticism and
"scorn and ridicule".

No. You do.
 
S

Seebs

You need to understand the difference between technical criticism and
"scorn and ridicule".

I've mostly responded to sandeep with the latter, because the former is
wasted on his absolute fear and loathing of comprehension. Most of the
ideas I've seen from "sandeep" were sufficiently crazy that I do not
think technical criticism of them provides any value; they have to be
trolling, because it requires a very great dael of understanding of C to
propose stuff that bad.

Ordinary newbie programmers make much simpler mistakes, which are more
subject to technical criticism.

-s
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top