pruning a linear singly linked list

[Ben Pfaff]

Re: gnu extensions

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:[color=green]
>> Richard Heathfield wrote:[color=darkred]
>>> 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.[/color]
>>
>> The trailing commas are *very* useful for making algorithmically generated
>> C code easier.[/color]
>
> 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.[/color]

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

[CBFalconer]

Re: gnu extensions

jacob navia wrote:[color=blue]
> CBFalconer a écrit :
>[color=green]
>> 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.[/color]
>
> 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!!![/color]

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
"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/googlegroupsrep ly/>

[Richard Tobin]

Re: gnu extensions

In article <444CD8FD.DC265 3C3@yahoo.com>,
CBFalconer <cbfalconer@mai neline.net> wrote:[color=blue]
>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.[/color]

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

-- Richard

[tedu]

Re: gnu extensions

Richard Heathfield wrote:
[trailing enum comma][color=blue]
> 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.[/color]

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]

Re: gnu extensions

Ben Pfaff <blp@cs.stanfor d.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:[color=green]
>> Russell Shaw <rjshawN_o@s_pa m.netspace.net. au> writes:[/color][/color]
[snip][color=blue][color=green][color=darkred]
>>> The trailing commas are *very* useful for making algorithmically generated
>>> C code easier.[/color]
>>
>> 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.[/color]
>
> 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.)[/color]

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) kst-u@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.

[jacob navia]

Re: gnu extensions

Bill Pursell wrote:[color=blue]
> 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.
>[/color]

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]

Re: gnu extensions

On Sun, 23 Apr 2006 23:47:31 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.fr> wrote:
[color=blue]
>Mark McIntyre a écrit :[color=green]
>> On Sun, 23 Apr 2006 23:15:52 +0200, in comp.lang.c , jacob navia
>> <jacob@jacob.re mcomp.fr> wrote:
>>[color=darkred]
>>>THAT IS MORE PORTABLE YES![/color]
>>
>> you need to learn not to shout, and not to write enormous posts, if
>> you want people to take you seriously.[/color]
>
>No arguments, no substantive discusion,[/color]

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.
[color=blue]
>the same thing as Chuck does.[/color]

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

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: gnu extensions

On Mon, 24 Apr 2006 07:57:15 +0200, in comp.lang.c , jacob navia
<jacob@jacob.re mcomp.fr> wrote:
[color=blue]
>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"...[/color]

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
GetWindowsHandl eEx 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.
[color=blue]
>If we were in the middle ages I would be burned alive. :-)[/color]

More likely just given a clapper and cowl.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Roberto Waltman]

Re: gnu extensions

"Nick Keighley" <nick_keighley_ nospam@hotmail. com> wrote:[color=blue]
>Bill Pursell wrote:[color=green]
>> Nick Keighley' signature contains:[color=darkred]
>> > We recommend, rather, that users take advantage of the extensions of
>> > GNU C ...[/color][/color][/color]
[color=blue][color=green]
>> I would love to see some discussions about this. I'm constantly
>> changing my mind about whether or not to use extensions.[/color][/color]
[color=blue]
>I'm at the "extensions are Evil, they rot your teeth, they make your
>hair fall out" ...[/color]

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.
[color=blue]
> ... end of the spectrum[/color]

[CBFalconer]

Re: gnu extensions

Richard Tobin wrote:[color=blue]
> CBFalconer <cbfalconer@mai neline.net> wrote:
>[color=green]
>> 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.[/color]
>
> "The aim"? Whose aim? It's certainly not a generally accepted aim
> among programming language designers.[/color]

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.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
"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/googlegroupsrep ly/>

[CBFalconer]

Re: gnu extensions

tedu wrote:[color=blue]
> Richard Heathfield wrote:
> [trailing enum comma]
>[color=green]
>> 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.[/color]
>
> 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.[/color]

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.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
"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/googlegroupsrep ly/>

[Ben C]

Re: gnu extensions

["Followup-To:" header set to comp.programmin g.]
On 2006-04-24, CBFalconer <cbfalconer@yah oo.com> wrote:[color=blue]
> Richard Tobin wrote:[color=green]
>> CBFalconer <cbfalconer@mai neline.net> wrote:
>>[color=darkred]
>>> 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.[/color]
>>
>> "The aim"? Whose aim? It's certainly not a generally accepted aim
>> among programming language designers.[/color]
>
> 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.[/color]

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]

Re: gnu extensions

Ben C <spamspam@spam. eggs> writes:[color=blue]
> ["Followup-To:" header set to comp.programmin g.][/color]

No, you set it to comp.lang.c.
[color=blue]
> On 2006-04-24, CBFalconer <cbfalconer@yah oo.com> wrote:[color=green]
>> Richard Tobin wrote:[color=darkred]
>>> CBFalconer <cbfalconer@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.[/color]
>>
>> 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.[/color]
>
> 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)
> {
> ...
> }[/color]

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 */
[color=blue]
> although I agree it's pretty confusing. I tend to avoid array typedefs
> myself.[/color]

Yup.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[moi]

Re: pruning a linear singly linked list

Anando wrote:[color=blue]
> 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.[/color]

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]

Re: gnu extensions

CBFalconer <cbfalconer@yah oo.com> wrote:
[color=blue]
> Richard Tobin wrote:[color=green]
> > CBFalconer <cbfalconer@mai neline.net> wrote:
> >[color=darkred]
> >> 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.[/color]
> >
> > "The aim"? Whose aim? It's certainly not a generally accepted aim
> > among programming language designers.[/color]
>
> 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.[/color]

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

Richard