reference type for C

[roland.arthaud]

I like the reference type that has been introduced with C++
I wondered why isn't that feature retrofitted in C.
Is there something hindering it?

thx - roar -

 

[Malcolm McLean]

I like the reference type that has been introduced with C++

I wondered why isn't that feature retrofitted in C.

Is there something hindering it?

thx - roar -

References are really just pointers in disguise, though in C++ they have the
feature that they can never be null.
In C, it's better to keep everything explicit. That's the design principle
of the language, to expose as much as possible of the underlying machine
operations to the programmer. So if you're passed an address, you can
examine its bits to see which area of memory it came from, for example.

 

[James Kuyper]

I like the reference type that has been introduced with C++
I wondered why isn't that feature retrofitted in C.
Is there something hindering it?

Reference types in C++ don't allow you do anything that can't also be
done, with slightly different syntax, using pointers. Syntactic
convenience is often sufficient to justify a feature, such as += or ++;
but in this case the increased convenience is relatively minor. I'm not
saying that this can't be done - but there's just not a lot of demand
for it. There is a minor inconvenience: because references and pointers
provide 2 different ways of doing the same thing, wherever the C++
standard says something about pointers, it often has to also say
something similar about references. Adding references to C would require
adding similar text in a great many places in the C standard.

 

[ralph]

I like the reference type that has been introduced with C++
I wondered why isn't that feature retrofitted in C.
Is there something hindering it?

Object-oriented programming (and design/analysis) has a concept of
Identity. A Reference in OO is simply a thingy containing enough
information to uniquely refer to, allow access to, a specific object.

C++ is an OOPL, essentially designed to facilitate coding OO
solutions, thus it is no surprise that C++ provides a 'reference'
thingy.

While EVERYBODY and his friends and family *knows* a C++ reference is
a 'pointer', after all they are implemented as 'pointers' (albeit with
a few restrictions) - the fact is the C++ standard goes to great
lengths to NOT define how a reference is implemented.

As C has no need to introduce another higher-level concept it boils
down to what Mr. Kuyper pointed out - "syntactic
convenience".

-ralph

 

[Martin Shobe]

Reference types in C++ don't allow you do anything that can't also be
done, with slightly different syntax, using pointers.

While this isn't the place to go too deep into C++'s bag of tricks.
there are things that you can do with references that you can't do with
pointers. For example, you can extend the lifetime of a temporary.

Martin Shobe

 

[BGB]

(actually wrote earlier today, but I had accidentally sent as an email...).

Reference types in C++ don't allow you do anything that can't also be
done, with slightly different syntax, using pointers. Syntactic
convenience is often sufficient to justify a feature, such as += or ++;
but in this case the increased convenience is relatively minor. I'm not
saying that this can't be done - but there's just not a lot of demand
for it. There is a minor inconvenience: because references and pointers
provide 2 different ways of doing the same thing, wherever the C++
standard says something about pointers, it often has to also say
something similar about references. Adding references to C would require
adding similar text in a great many places in the C standard.

albeit there is a possible lazier solution:
a reference is (formally) just a slight syntactic sugar over a pointer.
(IOW: just define it as being a pointer... possibly just leaving a NULL
reference as undefined behavior).

maybe the behavior is: a variable declared as a reference will always
behave as-if it was being operated on with a the '*' operator.


possibly a keyword could be added both for declarations, and partly to
take the role of the '&' operator in these cases ('_Ref' in an
expression canceling out its use in a declaration, giving access to the
raw pointer).


say, if added as a keyword:
int foo(_Ref int r) //internally 'int *r'
{
r=3; //declaration suppresses need for explicit "*r"
}

int i;
foo(&i); //creates pointer/reference to int
foo(_Ref i); //would do basically the same thing as &i here

int bar(_Ref int r)
{
int *pr;
pr=_Ref r; //maybe less conceptually ambiguous than '&r'.
...
_Ref r=pr; //maybe allow assigning references
}

optionally, the compiler could add sanity checks as-needed to try to
avoid NULL references.


alternatively, it could be possible to just mimic the C++ behavior.

 

[Ian Collins]

Reference types in C++ don't allow you do anything that can't also be
done, with slightly different syntax, using pointers.

It's probably fairer to say reference types in C wouldn't allow you do
anything that can't also be done, with slightly different syntax, using
pointers.

In C++, they enable rather a lot.

 

[roland.arthaud]

Thanks for your contributions so far.

I'd like to remind though that the question was : is there anything in the C standard so far that would hinder implementation of this feature.

I don't want to duplicate here all the discussions one can see on the web re. the feature in C++ (esp. ref being pointers in disguise in the implementation)

(and if you wonder why I would like to have it in C : reference cannot be made to refer to another var after it is defined / I know you can go throughhoops to make this statement false, and *yes* I like the syntactic sugar that reference can make code more "unobstructed" for uses of const pointers)-- but again, please no rant about my own tastes.

 

[gwowen]

albeit there is a possible lazier solution:
a reference is (formally) just a slight syntactic sugar over a pointer.
(IOW: just define it as being a pointer... possibly just leaving a NULL
reference as undefined behavior).

In non-pathological usage, a C++ reference cannot be null. That's
caught at compile time, which is a *massive* win over introducing
another bit of undefined behaviour.

A C++ reference-to-T cannot be mistaken for the the start of any array
of T, or an iterator into a collection of T's, so you can't do pointer
arithmetic on them.

NULL pointer dereferences and incorrect pointer arithmetic are two of
the most common causes of bugs in C/C++ programs.

To say "you can't do anything with a reference that you can't do with
a pointer" is to miss the point. The things that you *can't* do to a
reference are a feature (but can do to a pointer).

In C, a pointer is one-or-more of "a reference to an object", "an
iterator into an array of objects", "the address of some memory", "a
reference to nothing".

In C++, a reference is "a reference to an object".

I don't consider that restriction to be "slight syntactic sugar". It
actually allows the compiler to do type checking so that the function
caller's and the function writer's intentions are the same.

Of course, they'll never be introduced to C, because C of the
minimalist nature of C. Introducing new types similar to old types -
regardless of the type safety advantages - will not happen.

 

[James Kuyper]

On 05/17/2013 06:38 AM, gwowen wrote:
....

A C++ reference-to-T cannot be mistaken for the the start of any array
of T, or an iterator into a collection of T's, so you can't do pointer
arithmetic on them.

Given
int original;
int &reference = original;
int *pointer = &original;

then reference corresponds to *pointer, and &reference corresponds to
pointer. You can do pointer arithmetic on &reference.

 

[Ian Collins]

On 05/17/2013 06:38 AM, gwowen wrote:
....

Given
int original;
int &reference = original;
int *pointer = &original;

then reference corresponds to *pointer, and &reference corresponds to
pointer. You can do pointer arithmetic on &reference.

You can do pointer arithmetic on &original, so what's your point?

 

[James Kuyper]

You can do pointer arithmetic on &original, so what's your point?

That the difference between references and pointers is primarily
syntactic, and that the inability to do pointer arithmetic on references
does NOT constitute an exception to that fact - a single operator is the
only syntactic difference between a reference and something that you can
indeed to pointer arithmetic on. Properly, I should have used

int * const pointer = & original;

to make the analogy closer.

 

[roland.arthaud]

For me, gowen has been the best advocate for why reference is a very good thing to have in C.

I would also say that using a reference has a semantic value (the alias role) for the reader of the code, which (as gowen said) is lost if one used the army-knife-pointer - in that sense it helps legibility.

But what I am hearing is that it will never make it, either because people might not see the value of it, or because you can do without it or even because updating the standard would be too difficulte -- sob...

 

[Ed Prochak]

While this isn't the place to go too deep into C++'s bag of tricks.
there are things that you can do with references that you can't do with
pointers. For example, you can extend the lifetime of a temporary.


Martin Shobe

I don't get it. In C I can control the lifetime of everything. I don't have a garbage collector taking things away behind my back. So I don't see this as an advantage of references.

ed

 

[Malcolm McLean]

In non-pathological usage, a C++ reference cannot be null. That's
caught at compile time, which is a *massive* win over introducing
another bit of undefined behaviour.

Most aircraft crashes are caused by controlled flight into terrain.
Most errors can be corrected by automatic systems. But not the pilot
explicitly telling the aircraft to fly into a mountain, because, from
the aircraft's point of view, everything is correct an normal.

Undefined behaviour is bad, but it's only "undefined" from the point of view
of the c standard. Null pointer defererences can and usually are defined
to stop the program with an error message. Depending on the situation,
that's usually a lot better than wrong results.

NULL pointer dereferences and incorrect pointer arithmetic are two of
the most common causes of bugs in C/C++ programs.

Pointer arithmetic is seldom necessary and usually indicates old-fashioned
programming. Pointers usually point either to structures or arrays, and
don't need modifying.
Null pointer dereferences are a bug, but they aren't usually the root cause
of a bug. If a pointer that should be valid is in fact null, then usually
that's because there's a logic error somewhere upstream. So you have to fix
the bug at the place the pointer became null, not where it was dereferenced..
References might help slightly, but you can't overcome logic errors with
syntactical constructs. The flip of references can't be null is that you
can't use null as a sentinel. If you use a special "empty" sentinel value,
you've got far more potential for logic errors than if you use null pointers.

 

[Ike Naar]

On 05/17/2013 06:38 AM, gwowen wrote:
...

Given
int original;
int &reference = original;
int *pointer = &original;

then reference corresponds to *pointer, and &reference corresponds to
pointer. You can do pointer arithmetic on &reference.

Alternatively, one can view a reference not as some kind of pointer,
but as another name for a given object.
Consider the two code fragments:

int original;
int &reference = original;
// point A

and

int reference;
int &original = reference;
// point A

The situation at point A in the first fragment is indistinguishable
from the situation at point A in the second fragment.
At both locations, 'original' and 'reference' have type 'int' and refer to
a common object. At point A, it's impossible to tell which one of 'original'
or 'reference' is the original object, and which one is the reference.

Isn't it a bit odd, then, to regard 'reference' as some kind of pointer
in the first code fragment, but not in the second fragment?

 

[Paul N]

Thanks for your contributions so far.

I'd like to remind though that the question was : is there anything in the C standard so far that would hinder implementation of this feature.

I don't want to duplicate here all the discussions one can see on the webre. the feature in C++ (esp. ref being pointers in disguise in the implementation)

(and if you wonder why I would like to have it in C : reference cannot bemade to refer to another var after it is defined / I know you can go through hoops to make this statement false, and *yes* I like the syntactic sugarthat reference can make code more "unobstructed" for uses of const pointers) -- but again, please no rant about my own tastes.

I don't think there's anything in the standard that would hinder
having references. In particular, if a function is called before a
prototype has been seen, and so the compiler rashly treats it as a
call-by-value rather than a call-by-reference, it will complain when
it does see the prototype.

I think it's more a matter of philosophy. In C's predecessor BCPL,
everything was the same type, so it could be arranged that calling a
function simply involved bunging the arguments on the stack and the
function could simply reel them off. (Or, indeed, use the stack
locations as where to store the parameters.) C does of course have
types, but I think it would be considered a leap too far for a
function call that looks like it is referring to a variable to
actually be pushing a disguised pointer instead. If you want a laguage
with different trade-offs, then C++ is there and waiting; but if you
don't, then you don't.

[PS I hope the above comes out OK as regarding line lnegths and
quoting - I'm using the old Google groups which seemed to do this
right, but this time it looks suspicious.]

 

[Noob]

In non-pathological usage, a C++ reference cannot be null. That's
caught at compile time, which is a *massive* win over introducing
another bit of undefined behaviour.

I had thought "restrict" might help:

$ cat ref.c
int foo(int *restrict const p) { return *p; }
int bar(void) { return foo(0); }
$ gcc -std=c99 -pedantic-errors -Wall -Wextra -Os -S ref.c
/* NO WARNING */

I expected a warning.
(AFAIU, restrict pointers must be valid, foo(0) is not allowed.)
Perhaps I should test with something more recent than 4.6.3

Regards.

 

[SG]

I like the reference type that has been introduced with C++

What do you like about it?
What would it enable in C that was not possible before?

It's like Ian said: There are a lot of situations where references
help a lot in C++. I don't see these kinds of situations in C.

I wondered why isn't that feature retrofitted in C.
Is there something hindering it?

I guess there has to be enough bang for the buck. Is there?

Cheers!
SG

 

[Martin Shobe]

I don't get it. In C I can control the lifetime of everything. I don't have a garbage collector taking things away behind my back. So I don't see this as an advantage of references.

ed

In C++, some expressions result in the creation of temporary objects.
Usually these objects are destroyed when the program has finished
evaluating the expression[1] they were created in. If a temporary object
is bound to a reference, then (with a few exceptions) the object isn't
destroyed until the reference is. Garbage collection (which C++ isn't
required to have) has nothing to do with it.

Martin Shobe

[1] This expression is the one referred to in the C++ standard as the
full-expression.