References and pointers

[Simon Saize]

Hi -

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

Thanks.

[Richard Heathfield]

Simon Saize said:

Hi -

What's the point of having references (&)?

In C, they don't exist. I suggest you remove comp.lang.c from the
crosspost.

Why don't we just use pointers (*)?

We do.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Simon Saize]

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

On 31/12/2007 18:43, Daniel T. wrote:

Simon Saize <bl***@nospam.invalidwrote:

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

References were added to the language to facilitate operator overloading
in C++. Do they even exist in C?

[Martin Ambuhl]

Simon Saize wrote:

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.

[Alexey Stepanyan]

On 31 ÄÅË, 21:31, Simon Saize <[e-mail]:

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.

[jacob navia]

Simon Saize wrote:

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++.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[cr88192]

"Alexey Stepanyan" <al*************@yahoo.comwrote in message
news:a2**********************************@i7g2000p rf.googlegroups.com...
On 31 ???, 21:31, Simon Saize <[e-mail]:

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...

[CBFalconer]

cr88192 wrote:

Simon Saize <[e-mail]:

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

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.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

Simon Saize wrote:

>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++.

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.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

jacob navia wrote:

>Simon Saize wrote:

>>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++.

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

CBFalconer said:

<snip>

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>jacob navia wrote:

>>Simon Saize wrote:

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++.

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.

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?

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[James Kanze]

On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:

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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[jacob navia]

James Kanze wrote:

On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:

>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.)

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[James Kanze]

On Jan 1, 2:06 pm, jacob navia <[e-mail]:

James Kanze wrote:

On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:

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.)

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++).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[jacob navia]

James Kanze wrote:

On Jan 1, 2:06 pm, jacob navia <[e-mail]:

>James Kanze wrote:

>>On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:
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.)

>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++).

OK. That's your opinion.

I disagree.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

[Cross-post to comp.lang.c++ dropped]
jacob navia <ja***@nospam.comwrites:

James Kanze wrote:

>On Jan 1, 2:06 pm, jacob navia <[e-mail]:

>>James Kanze wrote:
On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:
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.)

>>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++).

OK. That's your opinion.

I disagree.

Ok, let's follow this line of reasoning.

A C compiler could provide extensions to do nearly anything, as long
as the extensions don't affect the behavior of any strictly conforming
program, and as long as a diagnostic is still issued for any violation
of a syntax rule or contstraint. Such a compiler could implement all
of Fortran, or all of Lisp, or all of Intercal or Befunge, or HTML, or
English, as long as it issues the required diagnostic. (There are
some highly obfuscated programs that are legal Fortran and legal C
with different meanings; let's say those are treated as C in
conforming mode.)

I presume you recognize that there's a point at which such extensions
become off-topic. Where, in your opinion, is that point? It's my
opinion that lcc-win's extensions are beyond the scope of this
newsgroup, partly because comp.compilers.lcc already exists; you
obviously disagree. What *would* be off-topic, and why do you draw
the line where you do?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tomás Ó hÉilidhe]

Simon Saize <bl***@nospam.invalidwrote in comp.lang.c:

Hi -

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

Thanks.

I don't know if anyone's interested, but I have a little trick for
implementing references in C:

The function "CopyUntilNull" copies TChar's from psrc to pdest, but it
also updates the calling function's pointer. You'd use it like so:

TChar buf[NUM],
*p = buf;

CopyUntilNull(&p,some_array_1);
CopyUntilNull(&p,some_array_2); /* p has incremented value */
CopyUntilNull(&p,some_array_3); /* p has incremented value */

Here's the function that simulates taking a reference to a pointer:

void CopyUntilNull(TChar **const ppdest, TChar const *psrc)
{
# define pdest (*ppdest)

/* Now pdest is an L-value, just as if the
function parameter had been TChar *&pdest */

while (*++pdest = *++psrc);

# undef pdest
}

This isn't a magnificient example of my "trick" (i.e. it'd be more
efficient to use a local pointer and then set *ppdest at the very end so
as to have one level of indirection instead of two), but you get the
idea.

--
Tomás Ó hÉilidhe

[Tomás Ó hÉilidhe]

"Tomás Ó hÉilidhe" <to*@lavabit.comwrote in comp.lang.c:

while (*++pdest = *++psrc);

That sort of is and isn't a typo. I had to alter the code slightly before
posting (to remove crap people didn't need to see). But of course it would
make more sense as:

while (*pdest++ = *psrc++);

--
Tomás Ó hÉilidhe

[CBFalconer]

cr88192 wrote:

"CBFalconer" <cb********@yahoo.comwrote in message

>cr88192 wrote:

>>Simon Saize <[e-mail]:

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

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.

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.

You wrote the line beginning "The sense of ...", and it was (and
is) so marked. I don't see your problem.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[cr88192]

"CBFalconer" <cb********@yahoo.comwrote in message
news:47***************@yahoo.com...

cr88192 wrote:

>"CBFalconer" <cb********@yahoo.comwrote in message

>>cr88192 wrote:
Simon Saize <[e-mail]:

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

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.

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.

You wrote the line beginning "The sense of ...", and it was (and
is) so marked. I don't see your problem.

no, I did not.

note the:
<
and

>

around that chunk of text.
OE was failing to properly quote, so I added said quotes manually.

now, you attribute to me the text I was responding to.
that is what I was objecting to.
another clue should have been this:
in most casual text, I don't capitalize.
in the case of that text, the poster does capitalize, and uses a different
set of gramatic patterns.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

cr88192 wrote:

>"CBFalconer" <cb********@yahoo.comwrote in message

>>cr88192 wrote:
Simon Saize <[e-mail]:

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

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.

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.

You wrote the line beginning "The sense of ...", and it was (and
is) so marked. I don't see your problem.

No, cr88192 didn't *originally* write that line; Alexey Stepanyan did.
But cr88192 quoted Alexey's text by preceding it with a line
containing just "<", and following it with a line containing just ">",
rather than the traditional "" prefix on each line.

cr88192: if you want correct attributions, use the conventional
quoting conventions.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[cr88192]

"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...

CBFalconer <cb********@yahoo.comwrites:

>cr88192 wrote:

>>"CBFalconer" <cb********@yahoo.comwrote in message
cr88192 wrote:
Simon Saize <[e-mail]:
>
>What's the point of having references (&)? Why don't we just
>use pointers (*)?
>
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.

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.

You wrote the line beginning "The sense of ...", and it was (and
is) so marked. I don't see your problem.

No, cr88192 didn't *originally* write that line; Alexey Stepanyan did.
But cr88192 quoted Alexey's text by preceding it with a line
containing just "<", and following it with a line containing just ">",
rather than the traditional "" prefix on each line.

cr88192: if you want correct attributions, use the conventional
quoting conventions.

OE does this annoying thing, far too often, of leaving out all the ''s. I
have not been able to figure out why, or how to fix it, so often, I am lazy
and just use the '< ... >' convention.

otherwise, I have to go and manually add '' to damn near every line, and
this is most often not worthwhile.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

CBFalconer said:

<snip>

The point is that the only usage difference is in the calling
module.

Er, so?

The actual receiving code is exactly the same (although it
may not be written identically).

It doesn't look the same to me. In one case, you have T *bar, and in the
other, you have T& bar.

So now we need two different
prototypes for the same function.

This is not obvious to me. They take different parameter types, so they
can't be the same function.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kanze]

On Jan 1, 7:09 pm, jacob navia <[e-mail]:

James Kanze wrote:

On Jan 1, 2:06 pm, jacob navia <[e-mail]:

James Kanze wrote:
On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:
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.)

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++).

OK. That's your opinion.

I disagree.

The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

As for opinion, yes: add references, operator overloading, and
who kows what all else to C, and you no longer have C, but
rather a crippled and broken C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Richard Heathfield]

James Kanze said:

On Jan 1, 7:09 pm, jacob navia <[e-mail]:

>James Kanze wrote:

On Jan 1, 2:06 pm, jacob navia <[e-mail]:
James Kanze wrote:

<snip>

>>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.
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.

The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

The comp.lang.c group has no charter. I'm not sure about comp.lang.c++ - to
which this thread is crossposted - but I would guess that it doesn't have
a charter either; and even if it does, it's very unlikely that it
constrains the group to subjects relevant only to C implementations!

I agree with you, however, that extensions are not considered topical in
comp.lang.c (nor, as far as I'm aware, in comp.lang.c++).

Nevertheless, I think you're wrong to suggest that an implementation that
provides extensions cannot be a C implementation. The ISO C Standard
explicitly permits extensions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart C]

"James Kanze" <ja*********@gmail.comwrote in message
news:34**********************************@v4g2000h sf.googlegroups.com...

>As for opinion, yes: add references, operator overloading, and
who kows what all else to C, and you no longer have C, but
rather a crippled and broken C++.

Operator overload already exists I think for basic types.

If extending the basic types, by making them bigger and better for example,
it's natural to extend the operators to those as well, otherwise they will
be a bit clunky to use.

But perhaps those extensions should just be built-in rather than exposing
the mechanism for doing so.

It seems allowing the user (programmer) to create those extensions is what
is the objection here (c++-ifying the language) rather than just having this
stuff magically exist in the compiler as optional enhancements.

Bart

[Army1987]

James Kanze wrote:

On Dec 31 2007, 8:07 pm, Simon Saize <[e-mail]:

>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.)

If that support doesn't break any strictly conforming C program, and if the
compilers emits a diagnostic message whenever operator overloading and/or
references are used, it is a C compiler (provided that it correctly
compiles C programs, that is).

--
Army1987 (Replace "NOSPAM" with "email")

[Army1987]

jacob navia wrote:

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.

That's not the specification for extensions. For example, having a new
keyword __asm__ does not make an implementation nonconforming, but having
wctype_t defined in stdio.h does.

Understanding the reason of this is left as an exercise.
--
Army1987 (Replace "NOSPAM" with "email")

[Army1987]

Keith Thompson wrote:

A C compiler could provide extensions to do nearly anything, as long
as the extensions don't affect the behavior of any strictly conforming
program, and as long as a diagnostic is still issued for any violation
of a syntax rule or contstraint. Such a compiler could implement all
of Fortran, or all of Lisp, or all of Intercal or Befunge, or HTML, or
English, as long as it issues the required diagnostic. (There are
some highly obfuscated programs that are legal Fortran and legal C
with different meanings; let's say those are treated as C in
conforming mode.)

The existence of such an implementation would have funny consequences on
the definition of "conforming program" in the C standard (4#7).

(Indeed, any text file which does not contain a line beginning with
"#error", " # error" or similar would be a conforming program if a
conforming implementation of C perverse enough existed.)

--
Army1987 (Replace "NOSPAM" with "email")

[Army1987]

Alexey Stepanyan wrote:

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.

Neither can a pointer parameter be NULL, if the function is called
properly.
--
Army1987 (Replace "NOSPAM" with "email")

[Army1987]

cr88192 wrote:

OE does this annoying thing, far too often, of leaving out all the ''s. I
have not been able to figure out why, or how to fix it, so often, I am lazy
and just use the '< ... >' convention.

Neither have I, so I switched to another newsreader. (To another OS,
indeed, though OE's quoting behavior wasn't the (only) reason why I did
the latter.)

>
otherwise, I have to go and manually add '' to damn near every line,
and this is most often not worthwhile.

>--
Keith Thompson (The_Other_Keith) <ks***@mib.org[...] "We must do
something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Don't quote stuff not relevant to your reply. 99.9% of times this includes
signatures.

--
Army1987 (Replace "NOSPAM" with "email")

[Richard Heathfield]

Army1987 said:

<snip>

(Indeed, any text file which does not contain a line beginning with
"#error", " # error" or similar would be a conforming program if a
conforming implementation of C perverse enough existed.)

Yes, precisely so, which is why "conforming program" is a useless
description. It's too loose. Fortran programs are conforming C programs.

"Strictly conforming", on the other hand, is too tight.

I prefer "clc-conforming".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jameskuyper]

Army1987 wrote:

Alexey Stepanyan wrote:

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.

Neither can a pointer parameter be NULL, if the function is called
properly.

The difference is that it's easy to make the mistake of calling a
function with a null pointer. In C++ it's much harder to make the
corresponding mistake with a function taking a reference.

I wouldn't say that this feature is the only or even the main reason
for using references in C++; operator overloading is the primary
reason they exist. However, the fact that it's much harder to
accidentally create an unusable reference than an unusable pointer is
a very nice side benefit.

Note: it's quite feasible to for a reference to become unusable after
it is initialized with a useable value, by ending the lifetime of the
object that it refers to, but the same is true for pointers. C++
provides a few additional ways that this can happen, but C++ also
contains a number of features that help avoid having that happen -
overall I think that risk is about equally great in both languages.

[Martin Ambuhl]

James Kanze wrote:

The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

c.l.c, being older than charters has none. Having no charter, c.l.c.
cannot have one that insists on anything. It continues as one of the
oldest and most successful newsgroups because of the vigilance of
regular posters in attempting to persuade others to stick to C which has
application across platforms, namely the C of one of the standards from
ANSI C89 on or of pre-standard K&R C. Particular implementations,
mainstream or otherwise, tend to have their own newsgroups or mailing
lists, or, when they do not, one easily started. Suggestions for
changes in the standard language are best taken care of in comp.std.c.
People who transgress this by repeated plugging their own non-standard
implementations and repeatedly asserting that their non-standard
extensions should be accepted as C -- their wisdom exceeds that of the
user community and standards-making bodies -- are nothing more than
saboteurs.

[Antoninus Twink]

On 2 Jan 2008 at 15:58, Richard Heathfield wrote:

Army1987 said:

<snip>

>(Indeed, any text file which does not contain a line beginning with
"#error", " # error" or similar would be a conforming program if a
conforming implementation of C perverse enough existed.)

Yes, precisely so, which is why "conforming program" is a useless
description. It's too loose. Fortran programs are conforming C programs.

"Strictly conforming", on the other hand, is too tight.

I prefer "clc-conforming".

You mean, "RJH-conforming".

Typical of this group - they throw the rulebook at everyone in sight
when actually they've made it all up themselves.

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

Alexey Stepanyan wrote:

>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.

Neither can a pointer parameter be NULL, if the function is called
properly.

For certain values of "properly":

printf("NULL = %p\n", (void*)NULL);

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"cr88192" <cr*****@hotmail.comwrites:
[...]

OE does this annoying thing, far too often, of leaving out all the ''s. I
have not been able to figure out why, or how to fix it, so often, I am lazy
and just use the '< ... >' convention.

otherwise, I have to go and manually add '' to damn near every line, and
this is most often not worthwhile.

I would argue that it is worthwhile -- and there should be an easier
way to do it. (There are certainly multiple ways under Unix; I assume
you're using Windows, so I can't offer any suggestions other than
switching to a better newsreader.)

You're seeing the consequences of your laziness. There is no
'< ... >' convention that I'm aware of, and your use of it is
causing real problems.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 2 Jan 2008 at 15:58, Richard Heathfield wrote:

>Army1987 said:

<snip>

>>(Indeed, any text file which does not contain a line beginning with
"#error", " # error" or similar would be a conforming program if a
conforming implementation of C perverse enough existed.)

Yes, precisely so, which is why "conforming program" is a useless
description. It's too loose. Fortran programs are conforming C programs.

"Strictly conforming", on the other hand, is too tight.

I prefer "clc-conforming".

You mean, "RJH-conforming".

Typical of this group - they throw the rulebook at everyone in sight
when actually they've made it all up themselves.

So true. So true.

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

<snip>

>The point is that the only usage difference is in the calling
module.

Er, so?

>The actual receiving code is exactly the same (although it
may not be written identically).

It doesn't look the same to me. In one case, you have T *bar, and
in the other, you have T& bar.

>So now we need two different prototypes for the same function.

This is not obvious to me. They take different parameter types,
so they can't be the same function.

Look at the generated machine code, i.e. the exercised module
(which I suggested before, and you snipped). They will probably be
identical. For example, assuming & means a referenced parameter:

int foo(int &bar) { int foo(int *bar) {
return bar; return *bar;
} /* C++foo */ } /* Cfoo */

will probably have generated code something like:

load sp-1
ldindirect
return

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Richard Heathfield wrote:

James Kanze said:

.... snip ...

>

>The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

The comp.lang.c group has no charter. I'm not sure about
comp.lang.c++ - to which this thread is crossposted - but I would
guess that it doesn't have a charter either; and even if it does,
it's very unlikely that it constrains the group to subjects
relevant only to C implementations!

Not any more (crossposted) if people respect the followup. Such a
crosspost is pure idiocy, since the languages are different.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

cr88192 wrote:

"CBFalconer" <cb********@yahoo.comwrote in message

>cr88192 wrote:

>>"CBFalconer" <cb********@yahoo.comwrote in message
cr88192 wrote:
Simon Saize <[e-mail]:
>
>What's the point of having references (&)? Why don't we just
>use pointers (*)?
>
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.

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.

You wrote the line beginning "The sense of ...", and it was (and
is) so marked. I don't see your problem.

no, I did not. note the:
<
and

around that chunk of text.

I.E. you yourself fouled up the quoting mechanism. The
aforementioned '<' and '>' were on separate lines. Thus the
referenced material was marked as being originated by you.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

cr88192 wrote:

"Keith Thompson" <ks***@mib.orgwrote in message

.... snip ...

>

>cr88192: if you want correct attributions, use the conventional
quoting conventions.

OE does this annoying thing, far too often, of leaving out all the
''s. I have not been able to figure out why, or how to fix it,
so often, I am lazy and just use the '< ... >' convention.

otherwise, I have to go and manually add '' to damn near every
line, and this is most often not worthwhile.

OE is intrinsically broken. Always has been. Access mozilla.com
and download Thunderbird.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

>>So now we need two different prototypes for the same function.

This is not obvious to me. They take different parameter types,
so they can't be the same function.

Look at the generated machine code

C doesn't require an implementation to generate machine code.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kanze]

On Jan 2, 6:53 pm, Martin Ambuhl <[e-mail]:

James Kanze wrote:

The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

c.l.c, being older than charters has none.

It had one 15 years ago. At least, people quoted it, and posted
links to it.

Having no charter, c.l.c. cannot have one that insists on
anything. It continues as one of the oldest and most
successful newsgroups because of the vigilance of regular
posters in attempting to persuade others to stick to C which
has application across platforms, namely the C of one of the
standards from ANSI C89 on or of pre-standard K&R C.

In sum, what is commonly understood to be "C".

Presumably, even before C99 was adopted, something like "long
long" would have been acceptable, because "long long" was
supported by a large number of C compilers.

Particular implementations, mainstream or otherwise, tend to
have their own newsgroups or mailing lists, or, when they do
not, one easily started. Suggestions for changes in the
standard language are best taken care of in comp.std.c.
People who transgress this by repeated plugging their own
non-standard implementations and repeatedly asserting that
their non-standard extensions should be accepted as C -- their
wisdom exceeds that of the user community and standards-making
bodies -- are nothing more than saboteurs.

I agree whole heartedly.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[jacob navia]

James Kanze wrote:

[big snip]

Certainly. As long as there is a diagnostic if the input is ill
formed according to the C standard. If lcc-win compiles
something along the lines of:

struct S operator+( struct S&, struct S& ) ;

without a diagnostic, it isn't a C compiler. (Change operator
to __operator, of course, and it could be.)

I should include
<operators.h>
with
#define __operator operator

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Wed, 02 Jan 2008 23:13:43 +0100, jacob navia wrote:

James Kanze wrote:

[big snip]

>Certainly. As long as there is a diagnostic if the input is ill formed
according to the C standard. If lcc-win compiles something along the
lines of:

struct S operator+( struct S&, struct S& ) ;

without a diagnostic, it isn't a C compiler. (Change operator to
__operator, of course, and it could be.)

I should include
<operators.h>
with
#define __operator operator

I hope you mean

#define operator __operator

Yes, if user code includes a non-standard header, the behaviour is no
longer defined by the standard, so you can do whatever you want,
including defining new keywords or identifiers regardless of name.

However, this would not let you handle the syntax error for references in
general. If you want

struct S __operator+( struct S&, struct S& ) ;

to get accepted without a diagnostic, it would make sense for

struct S plus( struct S&, struct S& ) ;

to get accepted just as well. However, in the second case, there is a
syntax error which must be diagnosed.

Something you might be able to do is make each non-standard header start
with an implementation-specific pragma disabling warnings for extensions,
but I don't know how practical that is.

[Al Balmer]

On Wed, 2 Jan 2008 12:43:57 +1000, "cr88192" <cr*****@hotmail.com>
wrote:

>OE does this annoying thing, far too often, of leaving out all the ''s. I
have not been able to figure out why, or how to fix it, so often, I am lazy
and just use the '< ... >' convention.

What '< ... >' convention? Anyway, the problem is very easy to solve -
get a different newsreader. There are many available, even free, which
do a much better job. If you must insist on using OE, look for a free
program named OE-Express, which will make OE into a reasonable
approximation of a real newsreader.

--
Al Balmer
Sun City, AZ

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Heathfield wrote:

>>CBFalconer said:

So now we need two different prototypes for the same function.

This is not obvious to me. They take different parameter types,
so they can't be the same function.

Look at the generated machine code

C doesn't require an implementation to generate machine code.

It requires something on which to run. Not a constant something.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

I'm dropping the comp.lang.c++ cross-post, since the following applies
only to comp.lang.c.

James Kanze <ja*********@gmail.comwrites:

On Jan 2, 6:53 pm, Martin Ambuhl <[e-mail]:

>James Kanze wrote:

The charter of the group is not my opinion. Neither is the
contents of the C standard. One thing the charter insists on is
that the subject be relevant to all (or at least most)
mainstream C implementations.

>c.l.c, being older than charters has none.

It had one 15 years ago. At least, people quoted it, and posted
links to it.

That contradicts my understanding.

As I understand it, comp.lang.c was renamed from net.lang.c during the
Great Renaming. The net.lang.c newsgroup was created before charters
were required for newsgroup creation. There was a posted message
(that's been quoted here) describing the suggested subject matter for
net.lang.c, but it wasn't a "charter" in the modern formalized sense.

Usenet has evolved considerably since then, including the creation of
comp.std.c. (If comp.std.c didn't exist, comp.lang.c presumably would
be the place to discuss proposed changes to the standard.)

>Having no charter, c.l.c. cannot have one that insists on
anything. It continues as one of the oldest and most
successful newsgroups because of the vigilance of regular
posters in attempting to persuade others to stick to C which
has application across platforms, namely the C of one of the
standards from ANSI C89 on or of pre-standard K&R C.

In sum, what is commonly understood to be "C".

Presumably, even before C99 was adopted, something like "long
long" would have been acceptable, because "long long" was
supported by a large number of C compilers.

That doesn't follow from what you quoted; was it meant to?

Before C99, "long long" was an extension. If the topic of discussion
is to be "one of the standards from ANSI C89 on or of pre-standard K&R
C", then "long long" would have been off-topic before the adoption of
C99. It would have been topical in comp.std.c (discussing the
then-proposed new standard) or in a newsgroup for a specific system or
compiler.

[snip]

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"