A doubly linked-list in C

F

Flash Gordon

CBFalconer said:
Flash Gordon wrote:
.... snip ...

Disagree. It has the concept, but it isn't named a 'reference'.
It is implemented by passing a pointer (by value) to the item to be
'referenced'.

Well, it turns out we are both wrong about that.
Note the additional flexibility. That pointer itself can be
'referenced'. The code using that 2nd level of referencing can
access the first pointer (with one *) or the original item (with
two *s).

I think I grasped all that quite a few years ago. In fact, I know I did.
I've been doing far more complex stuff than that for years.
You can't play these games with languages that have
fundamental references.

In C++ (which has references in the sense people often means, rather
than just what the C standard uses) you also have pointers. So you can
play all the games in C++ that you can play in C. So it isn't as simple
as your simple statement implies.
 
F

Flash Gordon

<snip corrections to a lot of the things rkiesling got wrong, none of
which were addressed>
Those readers who associate C with fingerpainting can find
another article to read now.

You think that understanding the language is equivalent to finger painting?
I didn't want to start a flamewar about this, but I don't
see what's so horribly difficult about the concept of a
label referring to a piece of memory, then dereferencing it,
perhaps with another notation, to access the actual contents
of the memory; i.e., the data that the program is actually
working on.

Nothing. What do you find so hard about the concept that an array is not
a pointer and so will never compare equal to a null pointer? Or the
concept that the C standard defines the NULL macro and how null pointer
constants work in such a way that they work as expected in the
situations being talked about in this thread?
I should add that a C compiler won't prevent a
programmer from making a mistake if they're really
determined to do things *their way*,

In this case it is *your* way that is wrong and seems to show a failure
to understand the concepts.
but C programming tools
are not a substitute for an understanding of the interaction
between the program and the hardware.

I know a lot about that as well (years spent programming in different
assemblers for embedded systems), but it is not relevant to what was
being discussed.
 
G

Guest


don't quote sigs.

You stated by suggesting Kaz was wrong. Now he isn't Utterly
Perfect but the chances of a relativly inexperienced C programming
catching Kaz out is low. Check is past postings.

You have been contradicted by several other regulars.
perhaps it is time to consider that you might be the
one that is in the wrong?
Those readers who associate C with fingerpainting can find
another article to read now.

I didn't want to start a flamewar about this,

this isn't a flamewar. It's just you were wrong on
some easily verifiable technical issues.
but I don't
see what's so horribly difficult about the concept of a
label referring to a piece of memory, then dereferencing it,
perhaps with another notation, to access the actual contents
of the memory; i.e., the data that the program is actually
working on.  I should add that a C compiler won't prevent a
programmer from making a mistake if they're really
determined to do things *their way*, but C programming tools
are not a substitute for an understanding of the interaction
between the program and the hardware.

which you lack. You need to understand the distinction
between arrays and pointers. You need to understand
that

NULL == p and p == NULL

are equivalent,even if you consider one to
be preferable to the other
 
S

Stefan Ram

Ian Collins said:
That concept depends on whether there reader is familiar with languages
that *do* support references and passing by reference. Best keep
phraseology unambiguous in a programming group.

C supports references, even true function references.
From ISO/IEC 9899:1999 (E):

»... by use of its associated header (assuredly generating
a true function reference) ...«

(All the following quotations are from ISO/IEC 9899:1999 (E), too.)

There are several kinds of references in C:

One kind are those references that are resolved by the linker:

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

»Because cels has external linkage and is referenced, an
external definition has to appear in another translation
unit (see 6.9); the inline definition and the external
definition are distinct and either may be used for the
call.«

»An inline definition of a function with external linkage
shall not contain a definition of a modifiable object with
static storage duration, and shall not contain a reference
to an identifier with internal linkage.«

»... it shall first be included before the first reference
to any of the functions or objects ...«

»... may be included after the initial reference to the
identifier ...«

There there are references to types:

»... Provided that a library function can be declared
without reference to any type defined in a header ...«

And some values might provide references to entities:

»A pointer type may be derived from a function type, an
object type, or an incomplete type, called the referenced
type. A pointer type describes an object whose value
provides a reference to an entity of the referenced type.
A pointer type derived from the referenced type T is
sometimes called "pointer to T". The construction of a
pointer type from a referenced type is called "pointer
type derivation".«

(The standard adds even more meanings to the word »reference«,
which the reader can find using a full-text search.)

According to me, the general meaning of the word, compatible
with all uses in ISO/IEC 9899:1999 (E), is as follows:
»A reference to an entity e is a piece of information about where
to locate/reach this entity e, it is a specification/description
of the (abstract) location of e.«
 
J

jacob navia

Ian said:
That concept depends on whether there reader is familiar with languages
that *do* support references and passing by reference. Best keep
phraseology unambiguous in a programming group.

Well lcc-win supports references (in the C++ sense)
 
I

Ian Collins

Stefan said:
C supports references, even true function references.
From ISO/IEC 9899:1999 (E):

But not pass by reference, even though a pointer may reference a value,
the pointer is still passed by value.
 
K

Kaz Kylheku

But not pass by reference, even though a pointer may reference a value,
the pointer is still passed by value.

``Pass by reference'', of course, refers to the referenced object, not to the
pointer.

Both views are simultaneously correct. The pointer is being passed by value,
causes the object to be passed by reference.

A pointer is a reference (normativee text in C99). The referenced object is
in fact passed from the caller to the callee, and it is passed by means of
a pointer i.e. reference.
 
K

Keith Thompson

Kaz Kylheku said:
A pointer is a reference (normativee text in C99). The referenced object is
in fact passed from the caller to the callee, and it is passed by means of
a pointer i.e. reference.

I suggest that, even though the standard uses the term, calling C
pointers "references" is likely to cause confusion among programmers
who have been exposed to both C and C++ -- particularly those who
think "C/C++" is a language. (For those unfamiliar with C++, it has a
feature it calls "references" which are distinct from pointers, and
which do not occur in C.)
 
P

Phil Carmody

Richard Heathfield said:
Kaz Kylheku said:



The object isn't passed at all. It is the object's address that is
passed. int foo; bar(foo); passes foo but bar cannot update it. int
foo; baz(&foo) allows baz to update foo, but foo is not passed.
&foo is.

You seem to be under the impression that "passed" is a synonym for
"passed by value" or "copied" or something similar. It is not.

Please attempt to unambiguously describe a mechanism for passing
by reference.

Phil
 
I

Ian Collins

Phil said:
You seem to be under the impression that "passed" is a synonym for
"passed by value" or "copied" or something similar. It is not.

Please attempt to unambiguously describe a mechanism for passing
by reference.

The mechanism is an implementation detail, but the use is clear. If an
integer n is passed by reference, n = 42; within the called function
will update the caller and the callee's instance of n. If n is passed
by value, only the callee's instance is updated.

Maybe the C way via a pointer should be referred to as "indirect pass by
reference" since one has to dereference the pointer to update the value.
 
M

Mark Wooding

Phil Carmody said:
You seem to be under the impression that "passed" is a synonym for
"passed by value" or "copied" or something similar. It is not.

I disagree. I'd deduce that he's under the impression that `passed'
means `processed by the runtime's argument-passing mechanism'.
Please attempt to unambiguously describe a mechanism for passing
by reference.

Been there. Done that. In comp.lang.python of all places, but C arrays
got a good airing at the time, so C people may get some benefit. My
(hopefully explicit) objective was to define both pass-by-value and
pass-by-reference in language-independent ways, so that they
corresponded with conventional usage.

Some terms which I use in specific (but, I hope, not unusual) ways are
defined in

http://groups.google.com/group/comp.lang.python/msg/aeb981a2300a6a09

together with informal definitions for pass-by-value and
pass-by-reference; more formal definitions appear in

http://groups.google.com/group/comp.lang.python/msg/a477ff5fa4c0f326

(search for `i should have made this explicit' for the first part, and
`work through it again' for the second).

Finally, the whole thing reduced to soundbites:

http://groups.google.com/group/comp.lang.python/msg/e2cae868d24f2d98

(I'm in the process of tidying up those Usenet articles and turning them
into an approximately coherent blog article.)

Note: I'm trying to describe the (apparent) behaviour of a language with
respect to passing actual arguments to functions (or procedures); it
doesn't at all deal with indirect effects -- e.g., if you pass a
pointer, the callee might be able to dereference the pointer and mutate
its referent, but this is a result of the type of data passed (i.e., a
pointer), and not because of the argument passing mechanism itself.

-- [mdw]
 
J

jameskuyper

rkiesling wrote:
....
Those readers who associate C with fingerpainting can find
another article to read now.

I doubt that there are any such readers, but your comment suggests
that you disagree. In what way do you think they are making that
association? Do you have any particular people in mind whose comments
made you believe that they have made such an association? If so, could
you please identify those people, and the comments that they made that
led you to this conclusion?

I'm not being deliberately obtuse. I understand that your comment was
intended to convey criticism of some group of people, and from context
I suspect that this group might include myself. But your comment
failed to achieve it's goal, in that I (at least) don't understand
what criticism it's intended to convey.
 
P

Phil Carmody

Ian Collins said:
The mechanism is an implementation detail, but the use is clear.

What bit about "Please attempt to unambiguously describe a mechanism
for passing by reference" makes you think I'm not asking for such
implementation details?
If
an integer n is passed by reference, n = 42; within the called
function will update the caller and the callee's instance of n. If n
is passed by value, only the callee's instance is updated.

Yeah. I know.
Maybe the C way via a pointer should be referred to as "indirect pass
by reference" since one has to dereference the pointer to update the
value.

Or more simply "pass by address", or even "pass by pointer", as the
thing being used to refer to the object is its address or equivalently
a pointer to it.

Phil
 
P

Phil Carmody

Mark Wooding said:
I disagree. I'd deduce that he's under the impression that `passed'
means `processed by the runtime's argument-passing mechanism'.

And if I were to define multiplication as "processed by the runtime's
arithmetic mechanism", then "const int i = 2*3;" wouldn't be either a
multiplication or an assignment if the compiler optimises it sufficiently?
Your separation of what can be done at compile time and runtime seems
artificial. Separation between what is done by the caller, and what is
done by the callee does make sense, as that distinguishes pass-by-name
and pass-by-reference. C cannot intrinsically do pass-by-name.

Phil
 
P

Phil Carmody

Richard Heathfield said:
Mark Wooding said:


Right - and that is the *only* meaning that the C Standard has for
"pass". (I checked, but Phil Carmody may wish to counter-check.)
The Standard uses the term both for passing to functions and to
function-like macros.

Counter-checked - searched for "runtime". Only found 1 hit, at
the top of 6.6. Nothing to do with calling functions at all.

Try again.

Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference. It
clearly mentions the passing of things which are not objects (and
indicates that the mechanism for doing this is by taking their
address).

Phil
 
P

Phil Carmody

Phil Carmody said:
Counter-checked - searched for "runtime". Only found 1 hit, at
the top of 6.6. Nothing to do with calling functions at all.

Try again.

Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference. It
clearly mentions the passing of things which are not objects (and
indicates that the mechanism for doing this is by taking their
address).

Not just non-object, but it also explicitly passes arrays (by their
address).

Phil
 
K

Keith Thompson

Phil Carmody said:
Or don't bother. The C standard clearly and consistently describes
the mechanism of passing by address as passing by reference. It
clearly mentions the passing of things which are not objects (and
indicates that the mechanism for doing this is by taking their
address).

The phrase "by reference" occurs exactly once in N1256, in a context
having nothing to do with argument passing.

The phrase "by value" occurs exactly once, in the index, pointing to
6.5.2.2, which discusses function calls.

Please provide a citation for "passing by reference" in the standard.
 
P

Phil Carmody

Richard Heathfield said:
Phil Carmody said:


It seems to me that you're being either deliberately obtuse or
accidentally obtuse. I'm not sure which.


Okay. You seem to be under the impression that "passed" is not a
synonym for "passed by value" or "copied" or something similar (see
cited text, above). But it is. The Standard bears this out.


C&V please.

A pointer type is described as a reference in 6.2.5 Types para 20.
Therefore passing a pointer is passing a reference.

Phil
 
P

Phil Carmody

Keith Thompson said:
The phrase "by reference" occurs exactly once in N1256, in a context
having nothing to do with argument passing.

The phrase "by value" occurs exactly once, in the index, pointing to
6.5.2.2, which discusses function calls.

Please provide a citation for "passing by reference" in the standard.

Oh gawd, it's the Keith/Richard tag team.

See (a) answer to Richard or (b) Kaz's earlier post which set you
two off on your little tizz in the first place.

Phil
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top