References in C

[Michael Press]

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.

Yes, they have been recast.
The challenge was to readably write the predicates using
"!= 0" or "!= NULL", and I met the challenge.


recast ...
2. to improve the form of; reconstruct: as, he recast the sentence.

 

[Keith Thompson]

Le 03/07/11 23:33, Keith Thompson a écrit :

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.

I will not argue the point with you, jacob.

[snip]

 

[Shao Miller]

foo(NULL);

I should have been clearer that "the same thing" refers to some object.

Quite - "doesn't point to nothing" is the best thing about C++-style
references.[0] (Of course, there's still the possibility of "points to
thing that no longer exists", but that's a lot less common source of
bugs, in my experience).

I still don't get it. Three storage durations:

1. Static

foo_by_ref(bar);
foo_by_val(&bar);

It's pretty clear that the parameter for 'foo_by_*' will be/refer to an
object.

2. Automatic

foo_by_ref(bar);
foo_by_val(&bar);

It's pretty clear that the parameter for 'foo_by_*' will be/refer to an
object.

3. Allocated

foo_by_ref(*bar_ptr);
foo_by_val(bar_ptr);

This is a worry either way unless there is a run-time check for a valid
object, right?

So it seems that the former two don't have any safety advantage. It
seems that the latter warrants a check and doesn't have any safety
advantage. Please see below, too.

Also note Mr. A. Curry's observation (elsethread) that a C++ program
broke right where you would expect: As soon as the reference was
actually used; not at the call-site.

Ah yes. But what I'm trying to understand is the benefit/savings for not having a "no entity" case to check for.

/* Pointers, not checking for a null value */
void foo(int * const ip) {
/* Might be U. B. if 'ip' is null */
*ip = 42;
return;
}

int main(void) {
int * ip = malloc(sizeof *ip);
foo(ip);
return 0;
}

versus:

/* References, not checking for a null value */
void bar(int & i) {
i = 42;
return;
}

int main(void) {
int * ip = malloc(sizeof *ip);
/* Might be U. B. if 'ip' is null */
bar(*ip);
return 0;
}

The first point of U. B. has just been shuffled up one level.

But if a function receives/reads (as opposed to constructs) a pointer and takes appropriate responsibility...

/* Pointers, checking for a null value */
void foo(int * const ip) {
/* Callers: Please ensure 'ip' is non-null */
*ip = 42;
return;
}

int main(void) {
int * ip = malloc(sizeof *ip);
if (ip)
/* 'ip' is non-null */
foo(ip);
return 0;
}

and:

/* References, checking for a null value */
void bar(int & i) {
i = 42;
return;
}

int main(void) {
int * ip = malloc(sizeof *ip);
if (ip)
/* 'ip' is non-null */
bar(*ip);
return 0;
}

then both are safe. Thus, I think pointers and references are quite comparable in this regard, and I don't perceive this particular advantage.
[...]
Aha. I see. So can a construct like the following help to catch a reference problem, assuming the program gets through the line marked "First possible U. B."?:

/* References, checking for a valid reference */
void bar(int & i) {
/* Check for a valid reference */
if (NULL != &i)
i = 42;
return;
}

int main(void) {
int * ip = malloc(sizeof *ip);
/* First possible U. B. */
bar(*ip);
return 0;
}

 

[Shao Miller]

Other advantages are that you can be sure that they point always to the

same object, and that they are not NULL. This improves safety of
programs

I fail to understand how.

#include <assert.h>

void func(int & i) {
assert(&i);
return;
}

int main(void) {
int * ip = NULL;
func(*ip);
return 0;
}

 

[Tim Rentsch]

Yes, they have been recast.
The challenge was to readably write the predicates using
"!= 0" or "!= NULL", and I met the challenge.


recast ...
2. to improve the form of; reconstruct: as, he recast the sentence.

Apparently you think even trivial changes must amount to a
change of form. That's silly. Editing is not the same as
recasting -- the sets of examples above are different in
detail but not in form. Replacing a tire on a bicycle, even
to a different grade of tire, doesn't recast the bicycle.

 

[Michael Press]

Apparently you think even trivial changes must amount to a
change of form. That's silly. Editing is not the same as
recasting -- the sets of examples above are different in
detail but not in form. Replacing a tire on a bicycle, even
to a different grade of tire, doesn't recast the bicycle.

I take it that you agree with everything else I said,
or are you working your way up from the most trivial.

 

[Tim Rentsch]

I take it that you agree with everything else I said,

Did the revised code samples have the same semantics as the
originals? Yes.

Was doing that revising challenging? On a scale of 1 to 10,
closer to 1 than 10.

Was the revision worth doing? In the context of the
discussion, it illustrated a point of view and stimulated
further discussion, so it did add some value.

Is the revised code an improvement over the original? I'm
sure some people believe it is and other people believe it
isn't. Personally I prefer the original writings in each of
the three cases, but generally I try to avoid debates about
style issues that are just expressions of personal preference.

Were there other ways of meeting "the challenge"? I believe
there are, and I think that discussion might have been more
interesting (but then again it might not have).

The above give my reactions to what points I now think you
were, or may have been, intending to address. If there are
others I don't know what they are.

or are you working your way up from the most trivial.

Referring to the suggested revisions as a "recasting" seems to
me like a mischaracterization. That's all I meant to comment
on, because after that I didn't know what point it was you were
trying to make. I didn't judge or remark on any other content
because I wasn't sure what else you were trying to say.

 

[luser- -droog]

Any sanely designed language wouldn't have goto!

That seems extreme. Since the structured control constructs are
implemented with explicit jumps underneath, any "sanely designed
language" would be implemented in a language *not* "sanely designed".