References and pointers

[CBFalconer]

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.

 

[Keith Thompson]

[Cross-post to comp.lang.c++ dropped]

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?

 

[Tomás Ó hÉilidhe]

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]

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

 

[cr88192]

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.

 

[Keith Thompson]

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.

 

[cr88192]

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) <[email protected]>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

 

[Richard Heathfield]

CBFalconer said:

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.

 

[James Kanze]

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

 

[Richard Heathfield]

James Kanze said:

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.

 

[Bart C]

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]

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]

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]

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]

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]

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.

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

 

[Richard Heathfield]

Army1987 said:

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

 

[jameskuyper]

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]

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]

Army1987 said:



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.