473,883 Members | 1,772 Online

# pruning a linear singly linked list

Hi,

I have a linear singly linked list of 100 elements. I would like to
prune it [i.e delete some nodes] such that only user specified elements
(say only the elements 1, 13, 78 and 100 of the original list) survive
after pruning.

Can somebody show me how to do this ? I am a scientist and not a
computer engineer/student. This will help me develop an application in

Cheers,
Anand.

Apr 23 '06
59 4270
> Ben Pfaff wrote:
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[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Now that's ironic. :)

Beauty lies in the beholder of the eye :-)

Apr 24 '06 #41
Russell Shaw a écrit :
CBFalconer wrote:
For the hard of reading, I repeat "It doesn't allow you to do
anything you couldn't do without it". That is, IMNSHO, an adequate
argument for labeling it as "pointless" .

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

If we were in the middle ages I would be burned alive. :-)
Apr 24 '06 #42
Keith Thompson wrote:
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:
Richard Heathfield wrote:
jacob navia said:

Keith Thompson a écrit :

>C99 allows a trailing comma on an enumerator list.
>
What was before an extension is now in the standard.

Why?

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.

The trailing commas are *very* useful for making algorithmically generated
C code easier.

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 just makes things mathematically consistant in an algorithm, instead
of having to special-case the first or last entry. When appending or
truncating lists delimited by commas, a whole class of potential comma
bugs is eliminated.
Apr 24 '06 #43
jacob navia wrote:
Nick Keighley a écrit :
Bill Pursell wrote: I'm at the "extensions are Evil, they rot your teeth, they make your
hair fall out" end of the spectrum.
a little tongue in cheek...
Yes but, as you say in the next line:
To be more realistic extensions of some
sort are always necessary in real world programs.

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.

<snip>

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...). With this
extension you could access c with both A.B.c and A.c.

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"...
The other party argued "well it's there and it's useful so why not use it?"
to my "If you can avoid an extension then do so". I work on systems
that can outlive their hardware so I consider this a wise course.
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.
--
Nick Keighley

Apr 24 '06 #44
CBFalconer wrote:
Ben Pfaff wrote:
CBFalconer <cb********@yah oo.com> writes:
Notwithstanding the fact that some over enthusiastic writers
recommend using those extensions, the fact is that GNU makes it
easy to avoid them and use standards conformant coding practices.
Microsoft makes it hard. I recall that on VC6 one couldn't turn
up the warning level without having the system headers fill the
error messages.

It's not a problem with GCC specifically because GCC doesn't
report warnings in the system headers by default (there's an
option you can pass to enable them).

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

#pragma warning(1234:di sable)
#include <windows.h>
#pragma warning(1234:en able)

cl /W4 /WX /c whatever.c
(Haven't done this in some years, so the syntax is probably wrong.)

boa
Apr 24 '06 #45
Keith Thompson <ks***@mib.or g> writes:
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:
Richard Heathfield wrote:
jacob navia said:

Keith Thompson a icrit :

>C99 allows a trailing comma on an enumerator list.
>
What was before an extension is now in the standard.

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

The trailing commas are *very* useful for making algorithmically generated
C code easier.

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.)
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless
Apr 24 '06 #46
jacob navia wrote:
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!!!

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.c om, 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
Apr 24 '06 #47
In article <44************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.net> wrote:
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
Apr 24 '06 #48
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.

Apr 24 '06 #49
Ben Pfaff <bl*@cs.stanfor d.edu> writes:
Keith Thompson <ks***@mib.or g> writes:
Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes: [snip]
The trailing commas are *very* useful for making algorithmically generated
C code easier.

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

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 24 '06 #50

This thread has been closed and replies have been disabled. Please start a new discussion.