pruning a linear singly linked list

[jacob navia]

CBFalconer a écrit :

I think it is fairly pretty. But you can always add gargoyles if
you must. The point is that no new and confusing tools are needed.

Please Chuck, what can be confusing in such a simple rule like

"An optional comma is accepted after the last element" ???

If you are confused by THAT I do not see how you can even understand
other, much more complex rules!!!

 

[suresh]

Ben Pfaff wrote:
enum { thing1
,thing2
,thing3
} thingummies;
which can be easily extended without moving punctuation.

But it's *ugly*.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p\
);}return 0;}

Now that's ironic.

Beauty lies in the beholder of the eye

 

[jacob navia]

Russell Shaw a écrit :

Then C is pointless, because i can do everything in assembler

Well, that is what it runs into... Any small improvement is banned, even
the most simple things like an optional trailing comma in an
enumeration/structure definition are "too much, too confusing"...

And I am not speaking about operator overloading or other heresies.
If we were in the middle ages I would be burned alive.

 

[Nick Keighley]

Nick Keighley a écrit :

a little tongue in cheek...

Yes but, as you say in the next line:

I submit you can usually keep the *compiler* extensions down to a dull
roar (as opposed to library extensions)

There you are. Extensions ARE needed, and all languages and improvements
of software were born as extensions of some other stuff.

The C language?

Was an "extension" of BCPL,

yes but you were no longer coding BCPL. I'm not against innovation-
I've used
Python I'm looking at Perl. Innovation is good. But if you use every
goody in
your current compiler you may have problems later.

This is a very useful extension, one that I have included also in the
lcc-win32 compiler. As you can see useful extensions are that: USEFUL

we didn't use it. In fact the compiler documentation *specifically*
warned
against it (it was needed in some system headers).

and they tend to be copied by other compiler, and eventually they make
it into the standard, if the commitee agrees on "existing practice"...


It is a stupid course because:

but we got the system running *without* using the extension.

If you change the layout of the structures you have to modify ALL THOSE
LINES in your code that access that particular field!!!!!

Instead of all that work, your code A.c still works NO MATTER WHERE in
the structure you change the layout!

so don't nest structs or unions

You understand now?

Extensions are NOT just evil stuff that compiler writers find out to
"lock their users in" but are USEFUL for certain situations!

but they effectivly lock you in. Every file in a large project I know
has some
#ifdef magic in it because HP and MS do their precompiled headers
differently.

There are some pretty obscure systems out there and your choice of
compilers may be limited. PSos, Telematics-TRAX, VersaDos

When these age and die you port them to Linux. The less compiler
specific stuff you've indulged in the less pain you suffer.

Some day our old Sun based stuff may migrate to Windows. Same
argument. Some systems live a long time and entire technologies can
wax and wane ovwer their lifetime.

So innovate by all means I'll continue to use (and encourage others) to
be cautious with *unneeded* extensions.

 

[boa]

Well of course. However Microshaft, AAIR, did not provide any way
of bypassing the checks on the system headers. One would expect
those to be full of system dependant tricks. Thus the only way to
use Microshaft was without proper checking.

One tedious way was to use #pragma warning to remove warnings from
system headers. Something like this:

#pragma warning(1234:disable)
#include <windows.h>
#pragma warning(1234:enable)

cl /W4 /WX /c whatever.c


(Haven't done this in some years, so the syntax is probably wrong.)

boa

 

[Ben Pfaff]

Really? I can see that the trailing comma makes it marginally easier
to generate an enum type declaration, but keeping track of whether a
comma is needed shouldn't be *that* difficult.

It is a hassle if you want to use the C preprocessor as your
generator. Consider:

enum {
#ifdef XYZZY
abc,
#endif
#ifdef FUBAR
def,
#endif
};

Now consider how to rewrite this to never end in a comma.
(Adding a sentinel element is the easiest way, but it seems
unclean if you don't otherwise have a use for one.)

 

[CBFalconer]

CBFalconer a écrit :


Please Chuck, what can be confusing in such a simple rule like

"An optional comma is accepted after the last element" ???

If you are confused by THAT I do not see how you can even understand
other, much more complex rules!!!

When you feed such source to a compiler system that doesn't
understand it, and are suddenly faced with pages of errors, you
will regret ever using the silly (and unnecessary) facility. The
aim, from a linguistic viewpoint, should be that there is exactly
one way of achieving any desired goal, and that that way should be
fairly obvious. Real Pascal (not the Borland abortion) more or
less achieves this, C does not.

Adding an extension just to provide a different phrase for saying
the same thing is pointless and foolish. If you consider ways of
parsing the language you will also see the proclivity for further
uncaught errors involved in it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard Tobin]

The
aim, from a linguistic viewpoint, should be that there is exactly
one way of achieving any desired goal, and that that way should be
fairly obvious.

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

-- Richard

 

[tedu]

Richard Heathfield wrote:
[trailing enum comma]

No idea. It's a completely pointless extension. The only reason I can think
of for it is consistency with the equally pointless trailing comma on an
initialiser list.

it also means a diff doesn't have a bonus line removal/addition, which
aids comprehension.

unless, of course, you put the comma first, and i've never seen that in
the wild.

 

[Keith Thompson]

It is a hassle if you want to use the C preprocessor as your
generator. Consider:

enum {
#ifdef XYZZY
abc,
#endif
#ifdef FUBAR
def,
#endif
};

Now consider how to rewrite this to never end in a comma.
(Adding a sentinel element is the easiest way, but it seems
unclean if you don't otherwise have a use for one.)

Ok, that's a good argument. If the trailing comma were allowed just
for the sake of tools generating C code from scratch, I'd say it's a
silly idea; any decent tool should be able to handle whatever syntax
the language requires. But given this (quite reasonable) idiom of
using #ifdef to control an enum type declaration, allowing a trailing
comma is quite helpful. (And the fact that it makes things *slightly*
easier for code generation tools is a small bonus.)

I'm convinced.

 

[CBFalconer]

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

As an example, consider the pain and anguish to newbies caused by
the C practice of passing arrays as a pointer to the first
element. This means that the parameter may be:

T *array
or
T[]

equally well (in the parameter header). This won't get changed,
nor am I recommending such. However a better language design would
provide only one such means.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

Richard Heathfield wrote:
[trailing enum comma]

No idea. It's a completely pointless extension. The only reason
I can think of for it is consistency with the equally pointless
trailing comma on an initialiser list.

it also means a diff doesn't have a bonus line removal/addition,
which aids comprehension.

unless, of course, you put the comma first, and i've never seen
that in the wild.

Then you haven't looked. I use it routinely where I expect future
list changes to be made.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[jacob navia]

My reason for wanting to use it is probably not sound. I dislike
having excessive typedefs, so instead of "typedef uint32_t foo; foo j;
foo j_referrer", I've been tempted to do:
uint32_t j;
typeof(j) j_referrer;
It is purely syntactic sugar, and I think I'll abandon it and use the
typedef.

lcc-win32 also accepts that extension. The rationale is that if you
change the type of j from uint32_t to uint64_t you do NOT have to change
the type of the pointer!
uint32_t j;
typeof(j) *ptr_to_j;

-->

uint64_t j;
typeof(j) *ptr_to_j; // stays the same!

That is a useful extension too.

jacob

 

[Mark McIntyre]

Mark McIntyre a écrit :

No arguments, no substantive discusion,

Thats right, and the reason is that you
a) don't listen to argument and
b) don't listen to reason, substantive or not.
you simply continue with your tirades.

the same thing as Chuck does.

Perhaps, like me, he has limited patience with fools.

Mark McIntyre

 

[Mark McIntyre]

Any small improvement is banned, even
the most simple things like an optional trailing comma in an
enumeration/structure definition are "too much, too confusing"...

You see, this is why nobody bothers discussing with you any more - you
build mountains from your molehills, and worse, you invent fabrics of
lies and falsehoods to support your distorted view.

For the record: NOBODY here has _ever_ banned small improvements, we
all use real C compilers on a daily basis, improvements both small and
large included. Of course, individuals may consider some of those
extensions useless (I have no need for clrscr myself, nor yet for
GetWindowsHandleEx and its friends). This is known as Life. Live with
it.

But the point is, this group is about C *as it is today*. Not about
changing C to be different - comp.std.c is about that. Not about
extensions to C - compiler-specific groups do that. If you want to
talk about that, you have plenty of places.

If we were in the middle ages I would be burned alive.

More likely just given a clapper and cowl.

Mark McIntyre

 

[Roberto Waltman]

I'm at the "extensions are Evil, they rot your teeth, they make your
hair fall out" ...

These are the visible side effects
at the early stages. If you continue
to use extensions for a long time,
something even worst happens: your
code becomes non portable!

More seriously, I look at all extensions
as in-line assembly: do not use them
unless you have no choice and then isolate
them to small sections of code, and document
very clearly the fact that this is not C.

 

[Ben C]

["Followup-To:" header set to comp.programming.]

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

As an example, consider the pain and anguish to newbies caused by
the C practice of passing arrays as a pointer to the first
element. This means that the parameter may be:

T *array
or
T[]

equally well (in the parameter header). This won't get changed,
nor am I recommending such. However a better language design would
provide only one such means.

Isn't the reason for this at least partly so you can write things like
this:

typedef int arr_t[3];

void f(arr_t a)
{
...
}

although I agree it's pretty confusing. I tend to avoid array typedefs
myself.

 

[Keith Thompson]

["Followup-To:" header set to comp.programming.]

No, you set it to comp.lang.c.

The aim, from a linguistic viewpoint, should be that there is
exactly one way of achieving any desired goal, and that that way
should be fairly obvious.

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

As an example, consider the pain and anguish to newbies caused by
the C practice of passing arrays as a pointer to the first
element. This means that the parameter may be:

T *array
or
T[]

equally well (in the parameter header). This won't get changed,
nor am I recommending such. However a better language design would
provide only one such means.

Isn't the reason for this at least partly so you can write things like
this:

typedef int arr_t[3];

void f(arr_t a)
{
...
}

I don't think so. I'm fairly sure the use of [] for pointer
parameters predates the existence of typedef.

In fact, I think one of C's predecessors (B? BCPL?) used [] even for
pointer object declarations:

int p[]; /* declares ptr as a pointer to int */

although I agree it's pretty confusing. I tend to avoid array typedefs
myself.

Yup.

 

[moi]

Hi

Thanks for your algorithm. I was thinking of the copy to new list and
destroy old list as well - but when I copied the data it was a shallow
copy (i.e the data in the structure was not copied). Is it possible to
use memcpy or something to copy - if so could you please give a small
example of copying an element such that the data is also copied ?

Many thanks,
Anand.

You don't need to copy the whole struct, just juggle some pointers, eg:


struct list * list_split (struct list **src)
{
struct list *new , **dst;


for (new = NULL, dst = &new; *src; ) {
if (rand() & 1) {
*dst = *src;
*src = (*src)->next;
dst = &(*dst)->next;
}
else {
src = &(*src)->next;
}
}
*dst = NULL;
return new;
}

HTH,
AvK

 

[Richard Bos]

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

As an example, consider the pain and anguish to newbies caused by
the C practice of passing arrays as a pointer to the first
element. This means that the parameter may be:

T *array
or
T[]

equally well (in the parameter header). This won't get changed,
nor am I recommending such. However a better language design would
provide only one such means.

So a better language design would also not provide both while and for;
both structs and arrays?

Richard