pruning a linear singly linked list

[Richard Heathfield]

Mark McIntyre said:

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

Well, I don't know. I've found a use for it oft-betimes, for example
if you're generating lists via a script,

That was the original justification for allowing it in the case of the
initialiser, but it's very simple to handle the more restrictive syntax (or
at least, those who do not find it so should possibly not be writing code
generators...).

or if you're adding or
recordering elements time to time.

<shrug> It seems like quite a language wart for such a small benefit.

 

[CBFalconer]

Well, I don't know. I've found a use for it oft-betimes, for
example if you're generating lists via a script, or if you're
adding or recordering elements time to time.

Pointless. Consider:

enum { thing1
,thing2
,thing3
} thingummies;

which can be easily extended without moving punctuation.

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

CBFalconer a écrit :

... snip ...



No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it. As has been said, it "will
make your hair fall out, and will rot your teeth".

Of course you avoid any substantial discussion:

What do you do when you have
struct a1 {
struct b {
int a;
}
}

and you change it to:
struct a1 {
struct new {
struct b {
int a;
}
}
}

OF COURSE!!!!

You change ALL your lines in the code from
a.b.a
to
a.new.b.a

Note that you can't do that automatically since you could have
a.b->a
a->b.a
a->b->a
etc.


THAT IS MORE PORTABLE YES!

At what COST ???

> No, this is a purposeless extension, only useful to convert
> portable code into non-portable code. It doesn't allow you to do
> anything you couldn't do without it.

No arguments, no substantive discusion, just assertions without any hint
of WHY should be so.

Let's discuss Chuck for a change. Discussion means exchange of ideas.
Put your ideas forward.

jacob

 

[Richard Tobin]

[/QUOTE]

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it.

So long as only gcc supports it, it's not very useful, but if it were
more widely adopted it would allow interfaces to be less pointlessly
verbose. As it is, you have to make up a name for something that has
no reason to be named.

-- Richard

 

[Mark McIntyre]

On Sun, 23 Apr 2006 23:15:52 +0200, in comp.lang.c , jacob navia

THAT IS MORE PORTABLE YES!

<snip some more>

you need to learn not to shout, and not to write enormous posts, if
you want people to take you seriously.
Mark McIntyre

 

[jacob navia]

Mark McIntyre a écrit :

On Sun, 23 Apr 2006 23:15:52 +0200, in comp.lang.c , jacob navia




<snip some more>

you need to learn not to shout, and not to write enormous posts, if
you want people to take you seriously.
Mark McIntyre

No arguments, no substantive discusion, the same thing as Chuck does.

 

[Richard Heathfield]

jacob navia said:

What do you do when you have
struct a1 {
struct b {
int a;
}
}

I fix the syntax errors, and move the definition of the inner type out to a
saner level.

 

[CBFalconer]

CBFalconer a écrit :
.... snip ...

Of course you avoid any substantial discussion:
.... snip ...

No arguments, no substantive discusion, just assertions without
any hint of WHY should be so.

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

Rather than requoting parts of the body of previous messages
multiple times, and spreading things out over pages and pages of
blank screens, I have chosen to snip out the redundancies and let
the essentials speak for themselves. I seem to be able to do this
without even shouting.

If you wish to rebuild the data structures on which your code
depends, then you can alter the structure definitions. I, for one,
am happy that the compiler points out altered usage rather than
going off and quietly making unwarrented assumptions. This
attitude may explain the high level of bug reports for lcc-win
which I note in the lcc newsgroup, and the lack of identification
as to revision, etc. of the whole package.

In case of confusion, I am not happy with your attitude.

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

 

[Ben Pfaff]

Pointless. Consider:

enum { thing1
,thing2
,thing3
} thingummies;

which can be easily extended without moving punctuation.

But it's *ugly*.

 

[Ben Pfaff]

I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__,

As someone else said, "eek!" But I'm not sure what you mean;
do you mean using the comment string /*__extension__*/ as standard
documentation, [...]

GCC lets you mark use of extensions with __extension__. Here's
one quote from the manual about it:

`-pedantic' and other options cause warnings for many GNU C
extensions. You can prevent such warnings within one
expression by writing `__extension__' before the expression.
`__extension__' has no effect aside from this.

 

[Ben Pfaff]

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

 

[Russell Shaw]

jacob navia said:


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.

 

[Bill Pursell]

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.

 

[Russell Shaw]

... snip ...

... snip ...


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

 

[Bill Pursell]

As someone else said, "eek!" But I'm not sure what you mean;
do you mean using the comment string /*__extension__*/ as standard
documentation, the way some people use /*FALLTHROUGH*/ and I
personally use /* Todo fixme bug hack */? Or do you mean naming
your functions things like

The following code generates no errors when compiled with
gcc -Wall -pedantic -ansi:

__extension__ enum {
foo,
bar,
};

int
main(void)
{
return 0;
}

struct {
union {
int i; /* henceforth "quux.i" */
double j; /* henceforth "quux.j" */
} /* unnamed */;
int b;
} quux;

that's just wrong and evil, and I didn't even know any implementors
had stooped that low.

gcc allows it. In fact, when marked with __extension__, you don't even
get a complaint with -ansi -pedantic.

'typeof' seems nice, but other than writing SUPER ULTRA FAST!!1!
macros to swap two values of arbitrary type, I've never seen a
real-world use for it.

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.

Given that the C99 standard still isn't being taught in school, widely
used, or added to GCC, after 7 years, I'm guessing that we may have
reached the point where "likely to be incorporated into the standard"
and "acceptable" are totally different things. As far as I'm concerned,
"acceptable" means either "works in Visual Studio" or "works in ISO C90",
depending on your job description. C99 has nothing to do with it --- let
alone future standards!

?!?! I thought gcc completely supported c99. I've been using
-std=c99. What aspects are not covered there? We've definitely
strayed off topic on comp.lang.c, so followups should remove it from
the distro.

 

[CBFalconer]

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.

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

 

[Keith Thompson]

?!?! I thought gcc completely supported c99. I've been using
-std=c99. What aspects are not covered there? We've definitely
strayed off topic on comp.lang.c, so followups should remove it from
the distro.

<http://gcc.gnu.org/c99status.html>

 

[Keith Thompson]

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.

 

[CBFalconer]

But it's *ugly*.

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.

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

 

[Russell Shaw]

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.