S
Simon Saize
Hi -
What's the point of having references (&)? Why don't we just use
pointers (*)?
Thanks.
What's the point of having references (&)? Why don't we just use
pointers (*)?
Thanks.
Hi -
What's the point of having references (&)?
Why don't we just use pointers (*)?
Simon said:Hi -
What's the point of having references (&)? Why don't we just use
pointers (*)?
Hi -
What's the point of having references (&)? Why don't we just use
pointers (*)?
Thanks.
Simon said:I believe they exist in some versions of C, e.g. lcc-win which also
supports Operator Overloading.
Hi -
What's the point of having references (&)? Why don't we just use
pointers (*)?
Thanks.
jacob said:Yes, lcc-win supports references and some other good ideas from
C++.
cr88192 said:The sense of using references in ?++ instead of pointers is to
avoid annoying checking pointers for NULL
However lcc-win is not a C compiler. No compiler that supports
references is a C compiler.
There are NO references in the C language. None.
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
I believe they exist in some versions of C, e.g. lcc-win which
also supports Operator Overloading.
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.)
CBFalconer said:There are NO references in the C language. None.
Follow-ups set to remove the idiotic C and C++ cross-post.
As you may know, the C standards does NOT forbid any extensions.
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.
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++).
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.
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.