References and pointers

S

Simon Saize

Hi -

What's the point of having references (&)? Why don't we just use
pointers (*)?

Thanks.
 
S

Simon Saize

I believe they exist in some versions of C, e.g. lcc-win which also
supports Operator Overloading.
 
M

Martin Ambuhl

Simon said:
Hi -

What's the point of having references (&)? Why don't we just use
pointers (*)?

There really was no need to post this to comp.lang.c. In C we have no
"references", so the question is pointless. If your aim is to actually
learn about the rationale for C++ using these (and there is one,
although it is because of other features of C++ that we in comp.lang.c
do without quite happily), the folks in comp.lang.c++ should be able to
help. However, your crossposting suggests that your aim is to start
another pointless language war; if so, I hope no one rises to the bait.

Follow-ups restricted to comp.lang.c++, where the question actually
makes sense.
 
A

Alexey Stepanyan

Hi -

What's the point of having references (&)? Why don't we just use
pointers (*)?

Thanks.

The sense of using references in ó++ instead of pointers is to avoid
annoying checking pointers for NULL

For example if you have a function that accepts reference as a
paramater you do not have to check the reference
for NULL ( 0 ) before using it because references cannot be NULL but
if you have a pointer you should always check it
for NULL before you invoke member functions otherwise you might get
access violation error.
 
J

jacob navia

Simon said:
I believe they exist in some versions of C, e.g. lcc-win which also
supports Operator Overloading.

Yes, lcc-win supports references and some other good ideas from C++.
 
C

cr88192

Hi -

What's the point of having references (&)? Why don't we just use
pointers (*)?

Thanks.

<
The sense of using references in ?++ instead of pointers is to avoid
annoying checking pointers for NULL

For example if you have a function that accepts reference as a
paramater you do not have to check the reference
for NULL ( 0 ) before using it because references cannot be NULL but
if you have a pointer you should always check it
for NULL before you invoke member functions otherwise you might get
access violation error.
as noted by others, references are non-standard in C (as such, they are only
really valid in C++, and it is good not to confuse C and C++, as they are
different languages).


however, it is also nicer to be able to type:
x=3;
than:
*rx=3;

this can actually matter some with more non-trivial argument types (char as
'char *'), where the common practice becomes to extract the value from the
pointer, work on it, and store it back before return (this is a very common
pattern in things like parsers, ...).

reason:
int foo(char **rs)
{
....
}

rs++; //wont do what you want
*rs++; //seems like it would work, but it does not (does something
different)
(*rs)++; //is problematic IME.

so, afaik, about the only really safe option here is:
*rs=*rs+1;

so, common is to have to be like:
int foo(char **rs)
{
char *s;
....
s=*rs;
....
*rs=s;
return(i);
}


so, references can have some uses...
 
C

CBFalconer

jacob said:
Yes, lcc-win supports references and some other good ideas from
C++.

However lcc-win is not a C compiler. No compiler that supports
references is a C compiler.

Follow-up set to c.l.c. c.l.c++ crossposts are idiotic.
 
C

CBFalconer

cr88192 said:
The sense of using references in ?++ instead of pointers is to
avoid annoying checking pointers for NULL

There are NO references in the C language. None.

Follow-ups set to remove the idiotic C and C++ cross-post.
 
R

Richard Heathfield

CBFalconer said:
However lcc-win is not a C compiler. No compiler that supports
references is a C compiler.

Wrong. The Standard does not forbid compilers from offering extensions, as
long as (a) required diagnostic messages are still produced and (b)
strictly conforming programs are not affected. If lcc-win32, when invoked
in conforming mode, diagnoses C++ reference syntax as being erroneous,
then that's all it has to do to remain conforming.
 
R

Richard Heathfield

CBFalconer said:

There are NO references in the C language. None.

Actually, there are. For example, see Translation Phase 8: "All external
object and function references are resolved. Library components are linked
to satisfy external references to functions and objects not defined in the
current translation."

It's just that "reference" means something different in C++ than it does in
C.
 
C

CBFalconer

Richard said:
CBFalconer said:

Wrong. The Standard does not forbid compilers from offering
extensions, as long as (a) required diagnostic messages are still
produced and (b) strictly conforming programs are not affected.
If lcc-win32, when invoked in conforming mode, diagnoses C++
reference syntax as being erroneous, then that's all it has to do
to remain conforming.

I think a simple example will refute this. If I write:

foo(&thing);

I expect to call foo, passing the address of thing, and I expect
that the code for foo will access that address by *bar (where bar
is the parameter name in foo). If we have C++ references, we will
omit the * (and label the parameter differently). I.E. we now need
two different prototypes:

void foo(T *bar) and void foo(T &bar)

which MUST be called differently and used differently to access
thing:

*bar and bar

Since I know you have a family, what the devil are you doing
fooling with a computer in the first two hours of 2008?
 
R

Richard Heathfield

CBFalconer said:
I think a simple example will refute this. If I write:

foo(&thing);

I expect to call foo, passing the address of thing, and I expect
that the code for foo will access that address by *bar (where bar
is the parameter name in foo). If we have C++ references, we will
omit the * (and label the parameter differently). I.E. we now need
two different prototypes:

void foo(T *bar) and void foo(T &bar)

which MUST be called differently and used differently to access
thing:

*bar and bar

Yes, that's about right - and yes, that would constitute a perfectly
legitimate extension. The compiler would be required to issue a diagnostic
message (typically this reads something like "non-standard extension
used... yadayadayada"), and of course a strictly conforming program would
still have to work properly. I don't see anything in your reply that
demonstrates a refutation of this extension being legitimate.
 
J

James Kanze

I believe they exist in some versions of C, e.g. lcc-win which
also supports Operator Overloading.

If the language supports operator overloading and references,
it's not C. If a compiler supports them, then it is not a C
compiler. (And presumably, discussion of it isn't relevant in
comp.lang.c.)
 
J

jacob navia

James said:
If the language supports operator overloading and references,
it's not C. If a compiler supports them, then it is not a C
compiler. (And presumably, discussion of it isn't relevant in
comp.lang.c.)

As you may know, the C standards does NOT forbid any extensions.
The extensions in lcc-win are done according to the specifications
for extensions: no new keywords.
 
C

cr88192

CBFalconer said:
There are NO references in the C language. None.

Follow-ups set to remove the idiotic C and C++ cross-post.

please try to make it more clear who you are responding to...
this comes off seeming like I had written the text you are responding to,
but I did not.


now, it can be noted that they don't exist, as a standard feature, but there
are a few implementations that have them as extensions. so, if one defines C
as "only that which is found in the standard", your statement is correct. if
we instead define "C" in terms of existing implementation and coding
practice, then it is only true for the majority of implementations and
coders.


it is much the same as if, for example, someone writes: "I brang all them
beers in back my truck" (or, alternatively "I be rollin' in da hood with mah
gat and fatty bling").

does these kind of constructions exist in English:
apparently, they do, and there are many people who speak this way.
to say that constructions like this don't exist, or that they are as such no
longer speaking English, is incorrect.

now, if we ask if these constructions are valid (as per normative rules, or
by some specific definition as to what constitutes the language), then we
can validly argue that they are not.

or, we can be even more fussy:
are R's following a vowel to be pronounced as a full R sound, a soft R, or
to be shifted to A, AU, or a Schwa?
what about the 'ing' suffix? N followed by an asperated G, a softened
composite sound, or shifted to a plain N sound?
....
 
R

Richard Heathfield

jacob navia said:
As you may know, the C standards does NOT forbid any extensions.

Correct. Indeed, it explicitly allows them. As long as the implementation
diagnoses extensions that constitute syntax errors and constraint
violations, and as long as the extension doesn't break strictly conforming
programs, it can still provide those extensions and yet qualify as a C
compiler.
 
J

James Kanze

As you may know, the C standards does NOT forbid any extensions.
The extensions in lcc-win are done according to the specifications
for extensions: no new keywords.

If they result in syntax that wouldn't be legal C, a C compiler
is required to output a diagnostic. And regardless, they aren't
C, and certainly aren't relevant to comp.lang.c (and even less
comp.lang.c++).
 
J

jacob navia

James said:
If they result in syntax that wouldn't be legal C, a C compiler
is required to output a diagnostic. And regardless, they aren't
C, and certainly aren't relevant to comp.lang.c (and even less
comp.lang.c++).

OK. That's your opinion.

I disagree.
 
C

CBFalconer

Richard said:
CBFalconer said:

Yes, that's about right - and yes, that would constitute a
perfectly legitimate extension. The compiler would be required to
issue a diagnostic message (typically this reads something like
"non-standard extension used... yadayadayada"), and of course a
strictly conforming program would still have to work properly. I
don't see anything in your reply that demonstrates a refutation
of this extension being legitimate.

The point is that the only usage difference is in the calling
module. The actual receiving code is exactly the same (although it
may not be written identically). So now we need two different
prototypes for the same function. Look at the assembly code for
the destination module, and at the disassembly of the same code.
 

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

Similar Threads


Members online

No members online now.

Forum statistics

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

Latest Threads

Top