References and pointers

[Keith Thompson]

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]

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.

 

[CBFalconer]

CBFalconer said:



Er, so?


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


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

 

[CBFalconer]

James Kanze said:
.... snip ...


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.

 

[CBFalconer]

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.

 

[CBFalconer]

.... snip ...


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.

 

[Kenny McCormack]

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.

 

[Richard Heathfield]

CBFalconer said:

Look at the generated machine code

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

 

[James Kanze]

James Kanze said:

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

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!

comp.lang.c++ had a charter---maybe it was voted out during the
time I was more active in comp.lang.c++.moderated. Discussing
lcc-win as a C++ compiler would certainly be relevant there, but
if I understood the posting correctly, lcc-win is not claimed to
be a C++ compiler.

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

It depends. Extensions which are more or less universal, and
are being considered for standardization, are certainly on
topic. As are issues which affect most implementations, such as
threading (but discussion of a specific threading API wouldn't
be)---and of course, threading is also being considered for
standardization, by both the C and the C++ committee. (Because
of scheduling, the actual work is being done in the C++
committee, but the people involved are in close liaison with the
C committee, in order to ensure that whatever is adopted is
acceptable "as is" to the C committee, so that threading will be
yet another aspect where talking about C/C++ makes sense.)

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

 

[James Kanze]

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.

 

[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

 

[CBFalconer]

CBFalconer said:

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

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

 

[Harald van Dijk]

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]

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.

 

[Keith Thompson]

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

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

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]

 

[cr88192]

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

in my case, I sometimes allow pointer-parameters to be NULL, usually in cases where the value is N/A, or it would be inconvinient to provide for a variable for returning the value into.

 

[Richard Harter]

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

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.

[/QUOTE]

So true. So true.

But he has a point in this case. Neither term is much use in
practice, but there are lots of points in between which are.

Of course the meaning of "clc-conforming" is a matter of dispute...

-- Richard

 

[Chad]

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

If you have something like

int foo(char **rs)
{
....

}

The how could something like

(*rs)++;

be problematic?

 

[cr88192]

If you have something like

int foo(char **rs)
{
...

}

The how could something like

(*rs)++;

be problematic?

going by the standard, it should be fine.
however, in the past, this, and many other constructions, have caused bugs with the different versions of gcc I have used over the years...

for example, maybe around 8 or 10 years ago, I remember explicitly, that "(*rs)++;" was not behaving as it should, and the compiler was apparently interpreting it the same as "*rs++;" (or, something else incorrect and buggy).

at the time, I dealt with the issue by changing it to "*rs=*rs+1;", which fixed the problem.


around a similar time, I was having a bug with function pointers:

something along the lines of:
"int foo() { ... }"
"int (*fp)();"

"fp=foo;" did not behave correctly. rather than getting a pointer to foo, I got the first few byte OF foo...

at the time, this was fixed by instead typing:
"fp=&foo;"

and so on...