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

[Daniel T.]

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?

[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

[Howard]

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

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.

I have to disagree about the need to always check pointers for NULL. A
program should only need to check for NULL pointers if the design of the
program intentionally allows and expects pointers to be NULL under certain
conditions. If there is a requirement (by the calling code) that the
pointer it wants to use is not NULL, then any NULL pointer you encounter is
an ERROR, and it's just as acceptable to let it crash by using it as it is
to check it and then throw (or whatever). Unexpected NULL pointers are best
handled (in my opinion) by assertions, to help (but not guarantee) catching
programming mistakes during development. If you have production code which
generates a NULL pointer when a NULL pointer is not expected and allowed,
then you need to fix the part of the program that allowed the NULL to occur
in the first place, not add code to check if it's NULL. Of course, if your
program expects and allows NULL pointers on purpose, then checking for that
condition is perfectly acceptable. But in general, adding NULL pointer
checks everywhere is a poor practice, IMO.

-Howard

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

[Salt_Peter]

On Dec 31, 1:31 pm, Simon Saize <[e-mail]:

Hi -

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

Thanks.

Because references can do things pointers can't in C++ (the reverse is
true as well).
C++ references benefits includes declaring and implementing operators.
They also support polymorphic calls, just like pointers do.
References make the code's intentions clear and unambiguous.
(doesn't mean C++ is better, in some respects it does mean its safer)
References can offer guarentees that pointers can't.
For example:

void foo(const int& r)
{
// do stuff
}

guarentees that reference r, if accessed within that function body,
will refer to the original integer.
That relationship is indestructeable.

On the other hand, since a pointer_to_const is reseatable:

void foo(const int* p)
{
int x(88);
p = &x; // oops
// do stuff
}

and a const pointer_to_const can be const_cast away:

void foo(const int* const p)
{
int x(88);
int* p_ = const_cast<int*>(p);
p_ = &x; // oops
// do stuff
}

a pointer of any flavour is unable to offer the same guarentee a
reference can.
void foo(const int& r) clearly states the intentions of the code.
There is no uncertainty.

[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

[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

[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

[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

[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")

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

[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

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

[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"

[Richard Harter]

On Wed, 2 Jan 2008 14:03:01 -0800 (PST), James Kanze
<ja*********@gmail.comwrote:

>On Jan 2, 1:02 pm, Richard Heathfield <[e-mail]:

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

When was the charter eliminated? It has one 15 years ago, when
I was still reading it regularly. (15 years ago, it was
impossible to create a group without a charter.)

At the time the process of adding new groups was established the
existing news groups were grandfathered in. They didn't have
charters; the whole idea of having charters was an innovation.
Charters weren't created for the grandfathered groups.
Comp.lang.c (formerly net.lang.c) was one of the grandfathered
groups. It didn't have a charter; it doesn't have a charter.

[Richard Heathfield]

James Kanze said:

On Jan 2, 1:02 pm, Richard Heathfield <[e-mail]:

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

When was the charter eliminated?

Never, because it never existed.

It has one 15 years ago, when
I was still reading it regularly.

No, it didn't.

(15 years ago, it was
impossible to create a group without a charter.)

25 years ago, however, it was not impossible.

comp.lang.c++ had a charter

Given your incorrect assertion about comp.lang.c, I have to remain
sceptical about this claim about comp.lang.c++. Sorry.

<snip>

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

Certainly. As long as there is a diagnostic if the input is ill
formed according to the C standard.

Well, the C standard doesn't define "ill formed" as far as I know - but if
the program contains any syntax errors or constraint violations, including
those caused by the use of extensions, a diagnostic message is required.
That doesn't mean the provision of the extension is forbidden, or that
such provision renders the implementation non-conforming (as you had
suggested).

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.

Nevertheless, *with* a diagnostic message, it can remain one.

--
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, 11:42 pm, Keith Thompson <[e-mail]:

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

James Kanze <[e-mail]:

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 said, people quoted it (or claimed to), and posted links to
it. Where it actually came from, I don't know---c.l.c does
predate my own participation in news. But there was definitely
something that was considered by many or most as its charter.

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.

That's probably true. It might not be a charter in the sense
that it was the basis of a vote when the newsgroup was created,
but at least when I was active in the group (up until about
1993/1994), it was treated as a charter.

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",

That's not my phrase, and I don't really agree with it (unless
you take a very liberal view as to what you understand by
"pre-standard K&R C". The charter, or whatever served in its
place, certainly didn't say anything about "standard C".

The difference, of course, is that long long is (and was) widely
implemented, by a large number of different C compilers. That
made it, by a sort of a consensus, C, even if it wasn't standard
C. Similarly, a bug in a compiler which means that there is
some strange but legal code which it doesn't compiler doesn't
mean that the compiler isn't a C compiler.

But I think you'd agree with me that there is a very great
difference between implementing long long a bit before the
standard said you could, and adding operator overloading,
references, and who knows what all else to your compiler.
There's not a precise line where it stops being C, but there are
some limits, somewhere.

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.

That's not the way I understand it. Similarly, I consider long
long on topic in clc++, even though the version of the standard
which consacrates it hasn't been formally adopted yet. (The
issue isn't quite the same, of course, because there is a very
strong consensus in the C++ committee that integral types in C++
will be compatible with C, and that whatever C adopts in this
regard will make it into the next version of the C++ standard.)

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