Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #28771 > unrolled thread
| Started by | Cal Dershowitz <cal@example.invalid> |
|---|---|
| First post | 2012-11-28 19:41 -0700 |
| Last post | 2012-12-08 20:25 +0000 |
| Articles | 6 on this page of 86 — 20 participants |
Back to article view | Back to comp.lang.c
What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-11-28 19:41 -0700
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-28 19:15 -0800
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:43 -0700
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:45 -0500
Re: What's new in C? Noob <root@127.0.0.1> - 2012-11-29 10:36 +0100
Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 10:17 +0000
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:45 -0700
Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 09:48 +0000
Re: What's new in C? David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:50 +0100
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 05:55 -0800
Re: What's new in C? Les Cargill <lcargill99@comcast.com> - 2012-11-29 12:48 -0600
Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 10:46 +0000
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 05:31 -0800
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 14:22 +0000
Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 15:04 +0000
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 16:41 +0000
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-11-30 11:49 -0500
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 10:12 -0800
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:12 -0800
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 22:26 +0000
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 22:36 +0000
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 23:27 +0000
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:39 -0700
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 00:43 -0800
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:14 -0700
Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 12:50 +0000
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-04 05:54 -0800
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 20:51 +0000
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 16:09 -0500
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 16:19 -0500
Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 21:45 +0000
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:13 +0000
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 20:36 -0500
Re: What's new in C? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-04 20:26 -0600
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 18:48 -0800
Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-05 02:57 +0000
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-05 01:42 +0000
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:06 -0700
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:50 -0500
Re: What's new in C? JohnF <john@please.see.sig.for.email.com> - 2012-12-06 13:46 +0000
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 09:39 -0500
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-30 15:52 -0500
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:53 -0700
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 08:16 -0500
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 21:18 +0000
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 18:04 -0500
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:19 +0000
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 21:05 -0500
Re: What's new in C? Noob <root@127.0.0.1> - 2012-12-05 16:45 +0100
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:45 -0700
Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 08:12 -0500
Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-06 21:13 +0000
Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-06 09:15 -0500
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-12 18:28 -0700
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:22 -0800
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:04 -0700
Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-29 18:19 +0000
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 11:41 -0800
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-30 20:50 +0000
Re: What's new in C? Jens Gustedt <jens.gustedt@loria.fr> - 2012-11-30 23:35 +0100
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-05 03:26 +0000
Re: What's new in C? gwowen <gwowen@gmail.com> - 2012-12-05 23:49 -0800
Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:49 -0700
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 07:55 +0000
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 13:29 +0000
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 15:23 +0000
Re: What's new in C? Martin Shobe <martin.shobe@yahoo.com> - 2012-12-08 17:46 +0000
Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-08 10:45 -0800
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 19:32 +0000
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 18:55 +0000
Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 08:26 +1300
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:12 +0000
Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 09:18 +1300
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 21:21 +0000
Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 10:27 +1300
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 13:36 -0800
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 12:59 -0800
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 22:10 +0000
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 16:15 -0800
Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:23 +1300
Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:20 +1300
Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 11:32 -0800
Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:52 +0000
Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:53 +0000
Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 20:08 +0000
Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:25 +0000
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-12-09 14:20 +1300 |
| Message-ID | <aii7ajF8qafU2@mid.individual.net> |
| In reply to | #29082 |
Keith Thompson wrote:
> "BartC" <bc@freeuk.com> writes:
>>
>> (What *is* a good idea, I think, is to just auto-declare for-loop variables
>> anyway. Then the question of where to declare them is eliminated!)
>
> By "auto-declare", are you referring to the new-in-C99 feature I just
> demonstrated? I wouldn't call that "auto-declaring" (unless you're
> referring to automatic storage duration, but I don't think that's what
> you mean). You still need a declaration; the language just permits it
> to be in the header of the for-loop.
>
> Note that if the body of the loop doesn't need to refer to the variable,
> once could argue that using the same name for both loop variables is
> sensible. (I'd still want to use distinct names.)
>
> Some languages do provide a syntax to execute a loop N times without
> creating a variable that gives you the current iteration number. C's
> for-loop provides capabilities far beyond a simple counted loop, so it
> wouldn't make too much sense to add such a special case. I suppose the
> language could have had something like:
>
> repeat(100) {
> /* ... */
> }
>
> but that's probably not sufficiently useful to make it a language
> feature.
C++11 has a partly embraced that idea with its "for( auto x : v )"
syntax used to iterate over container like objects (including arrays).
iterating over arrays (and containers in C++) is such a common
construct it deserves a standard shorthand. I find PHP's foreach
construct and JavaScript's for/in statements very handy in those languages.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-12-08 11:32 -0800 |
| Message-ID | <lnlid8nxuc.fsf@nuthaus.mib.org> |
| In reply to | #29071 |
"BartC" <bc@freeuk.com> writes:
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
> news:slrnkc6mr9.1jc.grahn+nntp@frailea.sa.invalid...
>> On Sat, 2012-12-08, BartC wrote:
>
>>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
>
>>>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
>>>> allowing it.
>>>
>>> Maybe he thought that overall that were more minuses than pluses.
>>>
>>> (I can see so many things wrong with having mixed declarations, that I
>>> wouldn't know where to start. Let's say I can't see many pluses at all!)
>>
>> We are at different ends of the spectrum then. I can think of one
>> semi-reason for banning them ("I want to pretend I have a compre-
>> hensive list of what's on this function's stack, and an idea of how
>> much stack it uses") but that's about it.
>
>> If you really have more arguments, I'm interested and willing to
>> listen.
>
> I've this discussed this here before I think. My arguments weren't received
> well then either!
>
> So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
> of the same identifier within a function. They may or might not have the
> same type.
No, they don't.
> For example, a 3-deep nested for-loop all using 'i' as the index variable!
You've been able to have declarations with the same name *in nested
blocks* at least since C89, and I think K&R C allowed it too:
void func(void) {
int n;
{
double n;
}
}
What C99 added (borrowed from C++) was the ability to mix declarations
and statements in the same block, (whether that block happens to be the
outermost block of a function or not) -- but you still can't have
declarations with duplicate names in the same scope:
void func(void) {
int a;
statement();
int b; /* Illegal in C89/C90, legal in C99 */
double a; /* Illegal in all versions of C */
}
[...]
>> The argument *for* allowing it is simply:
>>
>> I can declare the variable exactly at the point where it's needed,
>> meaning I can give it a guaranteed sane initial value, and frequently
>> make it const.
>
> Yes, it makes it easy to write. But harder to read and to maintain. Maybe I
> should just have said that...
I agree it's easier to write; I don't agree that it makes it harder to
read or maintain:
void func(void) {
int x = something;
/* code that does some calculations affecting x */
const int y = value_that_depends_on(x);
/* code that uses y */
}
As Jorgen says, it means you can initialize y based on information
that's not available at the top of the function.
This is just an easier way to do what you could already do without this
feature:
void func(void) {
int x = something;
/* code that does some calculations affecting x */
{
const int y = value_that_depends_on(x);
/* code that uses y */
}
}
I *think* that any code that depends on mixed declarations and
statements can be transformed to code without mixed declarations and
statements, by adding opening and closing braces. (I could easily
be mistaken on that point; does anyone have a counterexample?)
The problem is that it can result in deeply nested blocks.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-12-09 02:52 +0000 |
| Message-ID | <0.62623714b4c878e3b54f.20121209025254GMT.87zk1olywp.fsf@bsb.me.uk> |
| In reply to | #29076 |
Keith Thompson <kst-u@mib.org> writes:
<snip>
> As Jorgen says, it means you can initialize y based on information
> that's not available at the top of the function.
>
> This is just an easier way to do what you could already do without this
> feature:
>
> void func(void) {
> int x = something;
> /* code that does some calculations affecting x */
> {
> const int y = value_that_depends_on(x);
> /* code that uses y */
> }
> }
>
> I *think* that any code that depends on mixed declarations and
> statements can be transformed to code without mixed declarations and
> statements, by adding opening and closing braces. (I could easily
> be mistaken on that point; does anyone have a counterexample?)
I think this is well-defined in C99:
#include <stdio.h>
int main(void)
{
int *ip = 0;
start:
if (ip) { printf("i=%d\n", *ip); return 0; }
int i = 42;
ip = &i;
goto start;
}
but it is undefined if i is declared in a nested block. Contrived, I
know, but counterexamples often are.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-12-09 02:53 +0000 |
| Message-ID | <0.ec075741585eca24d8df.20121209025308GMT.87wqwslywb.fsf@bsb.me.uk> |
| In reply to | #29076 |
Keith Thompson <kst-u@mib.org> writes:
<snip>
> As Jorgen says, it means you can initialize y based on information
> that's not available at the top of the function.
>
> This is just an easier way to do what you could already do without this
> feature:
>
> void func(void) {
> int x = something;
> /* code that does some calculations affecting x */
> {
> const int y = value_that_depends_on(x);
> /* code that uses y */
> }
> }
>
> I *think* that any code that depends on mixed declarations and
> statements can be transformed to code without mixed declarations and
> statements, by adding opening and closing braces. (I could easily
> be mistaken on that point; does anyone have a counterexample?)
I think this is well-defined in C99:
#include <stdio.h>
int main(void)
{
int *ip = 0;
start:
if (ip) { printf("i=%d\n", *ip); return 0; }
int i = 42;
ip = &i;
goto start;
}
but it is undefined if i is declared in a nested block. Contrived, I
know, but counterexamples often are.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2012-12-08 20:08 +0000 |
| Message-ID | <slrnkc77ik.1jc.grahn+nntp@frailea.sa.invalid> |
| In reply to | #29071 |
On Sat, 2012-12-08, BartC wrote:
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
> news:slrnkc6mr9.1jc.grahn+nntp@frailea.sa.invalid...
>> On Sat, 2012-12-08, BartC wrote:
>
>>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
>
>>>> Ugh. Yeah, it would be interesting to read Linus' rationale for not
>>>> allowing it.
>>>
>>> Maybe he thought that overall that were more minuses than pluses.
>>>
>>> (I can see so many things wrong with having mixed declarations, that I
>>> wouldn't know where to start. Let's say I can't see many pluses at all!)
>>
>> We are at different ends of the spectrum then. I can think of one
>> semi-reason for banning them ("I want to pretend I have a compre-
>> hensive list of what's on this function's stack, and an idea of how
>> much stack it uses") but that's about it.
>
>> If you really have more arguments, I'm interested and willing to
>> listen.
>
> I've this discussed this here before I think. My arguments weren't received
> well then either!
Why the "either"? I have so far just requested to hear them.
> So, mixed declarations, AIUI, allow you to have unlimited, distinct versions
> of the same identifier within a function. They may or might not have the
> same type.
>
> For example, a 3-deep nested for-loop all using 'i' as the index variable!
My reaction to that is:
(a) Why would I do something crazy like that?
(b) What does that have to do with mixed declarations?
It seems to me I can do that just as well (or badly) in C90:
int foo(void) {
for(int i=0; i<4; i++)
for(int i=0; i<5; i++) ;
return i;
}
int foo(void) {
int i;
for(i=0; i<4; i++) {
int i;
for(i=0; i<5; i++) ;
}
return i;
}
> Searching for a declaration for an identifer, instead of looking at the top
> of the function, it means searching up line-by-line counting blocks, since
> it will now be hidden in a mass of code somewhere.
OK, I see now we are talking about different things. I was talking
about the C99 feature disliked by Linus Torvalds, but you also don't
like the K&R feature which lets you declare variables at the beginning
of a block. To avoid confusion, I will not enter that second
discussion.
[snip]
> From an implementation point of view, it creates extra difficulties. Instead
> of {...} simply meaning you have 2 statements instead of 1 in the that
> if-else branch, you now have to take care of allocating and deallocating any
> variables in that block, not only at the end, but in case of a goto or break
> too.
It's a bit of a moot point though, isn't it? C compilers have AFAIK
handled this since the early 1970s.
>> The argument *for* allowing it is simply:
>>
>> I can declare the variable exactly at the point where it's needed,
>> meaning I can give it a guaranteed sane initial value, and frequently
>> make it const.
>
> Yes, it makes it easy to write. But harder to read and to maintain.
That's the exact opposite of what I meant, though. I've done a lot of
maintenance in my days, and I believe people who value ease of writing
over ease of maintenance should simply be fired.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-12-08 20:25 +0000 |
| Message-ID | <rnNws.1233133$it2.598176@fx22.am4> |
| In reply to | #29077 |
"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
news:slrnkc77ik.1jc.grahn+nntp@frailea.sa.invalid...
> On Sat, 2012-12-08, BartC wrote:
>> I've this discussed this here before I think. My arguments weren't
>> received
>> well then either!
>
> Why the "either"? I have so far just requested to hear them.
Sorry. I assumed the same people who argued for the feature then,
would still have the same views.
>> Searching for a declaration for an identifer, instead of looking at the
>> top
>> of the function, it means searching up line-by-line counting blocks,
>> since
>> it will now be hidden in a mass of code somewhere.
>
> OK, I see now we are talking about different things. I was talking
> about the C99 feature disliked by Linus Torvalds, but you also don't
> like the K&R feature which lets you declare variables at the beginning
> of a block. To avoid confusion, I will not enter that second
> discussion.
You mean, declarations don't even need to be at the start of a block now?
Then it's worse than I thought!
In that case most of my arguments apply doubly.
>> From an implementation point of view, it creates extra difficulties.
> It's a bit of a moot point though, isn't it? C compilers have AFAIK
> handled this since the early 1970s.
Maybe. It was still unnecessary in my opinion. 99% of time you're using
begin..end, {...} or whatever, simply because there is more than one
statement, nothing more.
--
Bartc
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web