«

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

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

CBFalconer said:

> 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

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.

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

On Dec 31 2007, 8:07 pm, Simon Saize <bl...@nospam.invalid> wrote:
> 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:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Dec 31 2007, 8:07 pm, Simon Saize <bl...@nospam.invalid> wrote:
>> 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

"CBFalconer" <> wrote in message
news:...
> cr88192 wrote:
>> Simon Saize <bl...@nospam.invalid> wrote:
>>
>>> 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.


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


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

jacob navia said:

> James Kanze wrote:
>> On Dec 31 2007, 8:07 pm, Simon Saize <bl...@nospam.invalid> wrote:
>>> 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.

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.

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

On Jan 1, 2:06 pm, jacob navia <ja...@nospam.com> wrote:
> James Kanze wrote:
> > On Dec 31 2007, 8:07 pm, Simon Saize <bl...@nospam.invalid> wrote:
> >> 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:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jan 1, 2:06 pm, jacob navia <ja...@nospam.com> wrote:
>> James Kanze wrote:
>>> On Dec 31 2007, 8:07 pm, Simon Saize <bl...@nospam.invalid> wrote:
>>>> 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

Richard Heathfield wrote:
> CBFalconer said:
>> 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
>
> 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.

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