Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #22223 > unrolled thread
| Started by | zgene <nospam@nospam.com> |
|---|---|
| First post | 2012-06-13 21:41 +0000 |
| Last post | 2012-06-14 23:21 +0000 |
| Articles | 20 on this page of 97 — 29 participants |
Back to article view | Back to comp.lang.c
What a stupid gcc! zgene <nospam@nospam.com> - 2012-06-13 21:41 +0000
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-13 18:01 -0400
Re: What a stupid gcc! Noob <root@127.0.0.1> - 2012-06-14 13:00 +0200
Re: What a stupid gcc! Nomen Nescio <nobody@dizum.com> - 2012-06-14 14:33 +0200
Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 14:46 +0100
Re: What a stupid gcc! Noob <root@127.0.0.1> - 2012-06-14 18:19 +0200
Re: What a stupid gcc! Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-13 18:06 -0400
Re: What a stupid gcc! jt@toerring.de (Jens Thoms Toerring) - 2012-06-13 22:19 +0000
Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 09:47 +0100
Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 14:37 +0100
Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-13 17:05 -0600
Re: What a stupid gcc! Nick Bowler <nbowler@draconx.ca> - 2012-06-14 00:09 +0000
Re: What a stupid gcc! Varun Tewari <tewari.varun@gmail.com> - 2012-06-14 03:14 -0700
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-14 06:56 -0400
Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-17 07:18 +0000
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-17 11:47 +0100
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-17 09:31 -0400
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-18 12:34 +0100
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-18 08:18 -0400
Re: What a stupid gcc! gwowen <gwowen@gmail.com> - 2012-06-18 05:42 -0700
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-18 09:39 -0400
Re: What a stupid gcc! Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-06-18 09:06 -0400
Re: What a stupid gcc! ImpalerCore <jadill33@gmail.com> - 2012-06-18 07:18 -0700
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-19 00:13 -0700
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 11:28 +0100
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:30 -0400
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-20 00:16 -0700
Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-17 15:52 +0100
Re: What a stupid gcc! Noob <root@localhost> - 2012-06-18 09:07 +0200
Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-18 09:03 +0000
Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-18 16:02 +0000
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-18 19:40 +0100
Re: What a stupid gcc! Noob <root@localhost> - 2012-06-18 23:52 +0200
Re: What a stupid gcc! Ike Naar <ike@iceland.freeshell.org> - 2012-06-18 23:09 +0000
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 01:30 +0100
Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 13:03 +1200
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 06:34 -0400
Re: What a stupid gcc! Ike Naar <ike@sverige.freeshell.org> - 2012-06-19 08:43 +0000
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 11:00 +0100
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:05 -0400
Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 23:21 +1200
Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 23:22 +1200
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 13:45 +0100
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 15:23 +0100
Re: What a stupid gcc! Ike Naar <ike@iceland.freeshell.org> - 2012-06-19 16:14 +0000
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 18:01 +0100
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 13:59 -0400
Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-19 15:29 -0600
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 18:22 +0100
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 21:13 +0100
Re: What a stupid gcc! Lew Pitcher <lpitcher@teksavvy.com> - 2012-06-19 16:27 -0400
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 16:38 -0400
Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 09:47 -0400
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 22:44 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:39 -0700
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 10:55 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 04:11 -0700
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 12:36 +0100
Re: What a stupid gcc! David Brown <david@westcontrol.removethisbit.com> - 2012-06-21 15:33 +0200
Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-21 14:15 +0000
Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 09:37 -0400
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-20 14:54 +0100
Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 18:19 -0400
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 00:13 +0100
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 02:09 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 02:05 -0700
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 11:49 +0100
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 14:24 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-22 00:38 -0700
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 13:37 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:57 -0700
Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 11:46 +0100
Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-21 14:37 -0400
Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-21 19:38 +0000
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:41 -0700
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 12:28 +0100
Re: What a stupid gcc! Kaz Kylheku <kaz@kylheku.com> - 2012-06-19 15:05 +0000
Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 09:37 +1200
Re: What a stupid gcc! ImpalerCore <jadill33@gmail.com> - 2012-06-18 15:18 -0700
Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-18 23:21 +0000
Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 11:26 +1200
Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-19 01:46 +0000
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:19 -0400
Re: What a stupid gcc! Stephen Sprunk <stephen@sprunk.org> - 2012-06-19 08:01 -0500
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 09:25 -0400
Re: What a stupid gcc! Les Cargill <lcargill99@comcast.com> - 2012-06-19 12:57 -0500
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 14:59 -0400
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 01:36 +0100
Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-19 01:48 +0000
Re: What a stupid gcc! Les Cargill <lcargill99@comcast.com> - 2012-06-18 19:50 -0500
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-19 00:19 -0700
Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 12:56 +0100
Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-20 00:26 -0700
Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-20 06:31 -0400
Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-18 00:18 -0600
Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-18 09:15 +0000
Re: What a stupid gcc! Kaz Kylheku <kaz@kylheku.com> - 2012-06-14 23:21 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-06-20 09:37 -0400 |
| Message-ID | <28Gdna63UOSAT3zSnZ2dnUVZ_g-dnZ2d@bestweb.net> |
| In reply to | #22420 |
On 6/19/2012 4:13 PM, BartC wrote: [...] > I started my comments in this thread about the disadvantages of just > declaring variables anywhere as needed. > > Then I found out about block scopes and all the extra hassle they introduce, > making such declarations even more problematic. (And why is a block so > special anyway? Surely it's only used when you need two or more statements > instead of one.) > > I'm sorry if no-one else can see the problems (duplicate declarations, > clutter, separating related variables, scattered declarations, trickier > editing because you have to keep moving the declarations around, worrying > about scope, shadowing, anonymity, etc). Ahh... So you want all declarations to be global scope, always? That eliminates the ability to do recursion (the "int i" within the function is a global reference to the single "int i" variable within the program). That eliminates the ability to create a "local" variable within a small block of code (I can't have a small loop use "int x,y", as that would simply be the same as the "double x,y" used elsewhere). That eliminates basically everything useful about scope, because it eliminates scope entirely. > My point of view is also an implementer's one: with variables declared at > the top, the symbol table has a simple, tidy structure: > > M Module > FN Function > A Variable > B Variable > C Variable > > Module M, function FN, containing variables A,B,C; very easy. Now you > introduce block scopes, and multiple versions of 'A', 'B', 'C' all with > different types, scopes and lifetimes. The symbol table is no longer so > tidy, it now needs to be full of anonymous 'blocks'. > > Given that the preference is this newsgroup is for small functions (usually > small enough to fit in a window), what's the point of adding this extra > complexity? How could one write a "small function" if it couldn't create variables that are available only within its scope? -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-06-20 14:54 +0100 |
| Message-ID | <jrskm1$jpv$1@dont-email.me> |
| In reply to | #22433 |
"Kenneth Brody" <kenbrody@spamcop.net> wrote in message news:28Gdna63UOSAT3zSnZ2dnUVZ_g-dnZ2d@bestweb.net... > On 6/19/2012 4:13 PM, BartC wrote: > [...] >> I started my comments in this thread about the disadvantages of just >> declaring variables anywhere as needed. >> >> Then I found out about block scopes and all the extra hassle they >> introduce, >> making such declarations even more problematic. (And why is a block so >> special anyway? Surely it's only used when you need two or more >> statements >> instead of one.) >> >> I'm sorry if no-one else can see the problems (duplicate declarations, >> clutter, separating related variables, scattered declarations, trickier >> editing because you have to keep moving the declarations around, worrying >> about scope, shadowing, anonymity, etc). > > Ahh... So you want all declarations to be global scope, always? No. Function scope, file scope, and project-wide. > That eliminates the ability to do recursion (the "int i" within the > function is a global reference to the single "int i" variable within the > program). It doesn't. >That eliminates the ability to create a "local" variable within a small >block of code (I can't have a small loop use "int x,y", as that would >simply be the same as the "double x,y" used elsewhere). That eliminates >basically everything useful about scope, because it eliminates scope >entirely. No-one has said anything of the kind. Scope would still exist across modules, across one module, and across one function. I'm saying it doesn't need to be across individual blocks too, given that a typical function is small. > Given that the preference is this newsgroup is for small functions > (usually >> small enough to fit in a window), what's the point of adding this extra >> complexity? > > How could one write a "small function" if it couldn't create variables > that are available only within its scope? We're talking about adding extra block scopes to a 10- or 20-line function that already has local variables valid throughout the function. How small a scope do you need: per line, per statement, or per expression? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-06-20 18:19 -0400 |
| Message-ID | <pOednUXiQILn0X_SnZ2dnUVZ_sudnZ2d@bestweb.net> |
| In reply to | #22435 |
On 6/20/2012 9:54 AM, BartC wrote:
> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
> news:28Gdna63UOSAT3zSnZ2dnUVZ_g-dnZ2d@bestweb.net...
>> On 6/19/2012 4:13 PM, BartC wrote:
[...]
>>> I'm sorry if no-one else can see the problems (duplicate declarations,
>>> clutter, separating related variables, scattered declarations, trickier
>>> editing because you have to keep moving the declarations around, worrying
>>> about scope, shadowing, anonymity, etc).
>>
>> Ahh... So you want all declarations to be global scope, always?
>
> No. Function scope, file scope, and project-wide.
So this:
void foo(void)
{
int i;
...
}
should (in your opinion) create a variable "i" of type integer with a scope
of the braces that encloses the declaration (ie: the function "foo"), but:
void foo(void)
{
...
if ( bar )
{
int i;
...
}
...
}
should behave differently, and give "i" some scope other than the braces
that enclose the declaration?
[...]
>> That eliminates the ability to create a "local" variable within a small
>> block of code (I can't have a small loop use "int x,y", as that would
>> simply be the same as the "double x,y" used elsewhere). That eliminates
>> basically everything useful about scope, because it eliminates scope
>> entirely.
>
> No-one has said anything of the kind. Scope would still exist across modules,
> across one module, and across one function. I'm saying it doesn't need to be
> across individual blocks too, given that a typical function is small.
if ( foo.type == MyInteger )
{
int num;
num = foo.integer;
... do stuff with int ...
}
else if ( foo.type == MyFloat )
{
float num;
num = foo.floating;
... do stuff with float ...
}
[...]
>> How could one write a "small function" if it couldn't create variables
>> that are available only within its scope?
>
> We're talking about adding extra block scopes to a 10- or 20-line function
> that already has local variables valid throughout the function.
>
> How small a scope do you need: per line, per statement, or per expression?
Why should the scope of a variable declared inside the outermost braces of a
function be different from a variable within some other set of braces?
What's difficult about the concept that the scope is the innermost set of
braces that enclose the declaration?
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-06-21 00:13 +0100 |
| Message-ID | <jrtljp$fdc$1@dont-email.me> |
| In reply to | #22444 |
"Kenneth Brody" <kenbrody@spamcop.net> wrote in message
news:pOednUXiQILn0X_SnZ2dnUVZ_sudnZ2d@bestweb.net...
> On 6/20/2012 9:54 AM, BartC wrote:
>> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
>> news:28Gdna63UOSAT3zSnZ2dnUVZ_g-dnZ2d@bestweb.net...
>>> On 6/19/2012 4:13 PM, BartC wrote:
> [...]
>>>> I'm sorry if no-one else can see the problems (duplicate declarations,
>>>> clutter, separating related variables, scattered declarations, trickier
>>>> editing because you have to keep moving the declarations around,
>>>> worrying
>>>> about scope, shadowing, anonymity, etc).
>>>
>>> Ahh... So you want all declarations to be global scope, always?
>>
>> No. Function scope, file scope, and project-wide.
>
> So this:
>
> void foo(void)
> {
> int i;
> ...
> }
>
> should (in your opinion) create a variable "i" of type integer with a
> scope of the braces that encloses the declaration (ie: the function
> "foo"), but:
>
> void foo(void)
> {
> ...
> if ( bar )
> {
> int i;
> ...
> }
> ...
> }
>
> should behave differently, and give "i" some scope other than the braces
> that enclose the declaration?
Until a few days ago, I'd never even considered that variables could be
declared local to a block. You second example was, to me, just a convenient
way of declaring 'i' near the place where you started using it, but would
have exactly the same scope as the ones at function level (ie. declared at
the top of the function).
Now it seems the 'i' is limited to it's immediately enclosing braces, which
doesn't appear so useful. Suppose it's an if-else statement, both branches
having code that uses a variable 'i' of the same type; why bother declaring
two distinct versions of it?
> [...]
>>> That eliminates the ability to create a "local" variable within a small
>>> block of code (I can't have a small loop use "int x,y", as that would
>>> simply be the same as the "double x,y" used elsewhere). That eliminates
>>> basically everything useful about scope, because it eliminates scope
>>> entirely.
>>
>> No-one has said anything of the kind. Scope would still exist across
>> modules,
>> across one module, and across one function. I'm saying it doesn't need to
>> be
>> across individual blocks too, given that a typical function is small.
>
> if ( foo.type == MyInteger )
> {
> int num;
> num = foo.integer;
> ... do stuff with int ...
> }
> else if ( foo.type == MyFloat )
> {
> float num;
> num = foo.floating;
> ... do stuff with float ...
> }
I accept that it does allow you to do stuff like this, but it really doesn't
seem a very good idea, using the same identifier for two different types,
within a few lines of each other in the same function.
Imagine you're trying to read such a function, and your eyes jump from one
part of the function to another. First num is a int; fine. Now you jump to
the 'do stuff with float' part, and you have to do a double take. From this
point on, you can't trust anything you see; what type is 'num' going to have
next time you see it? Maybe these are two nested blocks in a loop, and you
break from one to the other. You have to trace the code, character by
character counting blocks, to match the use of 'num' with it's correct
declaration.
Sorry, but these possibilities which everyone else thinks are great, to me
just seem nightmarish.
> [...]
>>> How could one write a "small function" if it couldn't create variables
>>> that are available only within its scope?
>>
>> We're talking about adding extra block scopes to a 10- or 20-line
>> function
>> that already has local variables valid throughout the function.
>>
>> How small a scope do you need: per line, per statement, or per
>> expression?
>
> Why should the scope of a variable declared inside the outermost braces of
> a function be different from a variable within some other set of braces?
> What's difficult about the concept that the scope is the innermost set of
> braces that enclose the declaration?
What is a set of braces? C uses braces to:
- Enclose the statements of a function body (which can't have just one
non-block statement).
- Enclose an initialiser expression or list
- Group several ordinary statements into one. C statements such as while,
for and if only allow one statement in a loop body or each branch of the
'if', so {, } are a mechanism for allowing more than one.
The syntax could have used entirely different symbols for these
requirements. Having a local scope for a function body, that's fine; every
language except Basic has that. But what's so special about a compound
statement that it ought to have it's own private set of variables?
On just about every other occasion where the complexity of a function grows
beyond about 3 lines, I'm constantly told it needs to split into
sub-functions. Now entire, self-contained sub-programs can be created in
each branch of a minor 'if' in a minor 'for' loop in a dusty corner of a
function, and that is perfectly OK?
In a different kind of forum from comp.lang.c, I would almost start to
suspect a wind-up!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-21 02:09 +0100 |
| Message-ID | <0.1bc999164d1494874d01.20120621020953BST.87pq8tpj1a.fsf@bsb.me.uk> |
| In reply to | #22447 |
"BartC" <bc@freeuk.com> writes:
<snip>
> Having a local scope for a function body, that's fine;
> every language except Basic has that. But what's so special about a
> compound statement that it ought to have it's own private set of
> variables?
I hope you won't think me rude (and please tell me to mind my own
business if you think the question impertinent) but what programming
languages have had experience of? Block structure like this has been
around since... actually I don't know but Algol had it in the late 50s.
I had to think hard to come up with a structured language without it,
but Pascal is a rare example. It has nested function declarations, but
plain blocks can't nest declarations.
Your question "what's so special about a compound statement" is, to my
mind, the wrong way round. What's so special about the block that forms
a function body that it alone is allowed to contain declarations?
> On just about every other occasion where the complexity of a function
> grows beyond about 3 lines, I'm constantly told it needs to split into
> sub-functions. Now entire, self-contained sub-programs can be created
> in each branch of a minor 'if' in a minor 'for' loop in a dusty corner
> of a function, and that is perfectly OK?
My liking for small helper functions is in fact thwarted by the fact
that C's syntax takes a leaf out of your book. While variable
declarations can be nested in enclosed blocks, function definitions
can't be. Perhaps it would be done more often if one could do this:
int some_function(int l, int m, int n, int mat[l][m][n])
{
int none_zero()
{
for (int i = 0; i < l; i++)
for (int j = 0; j < m; j++)
for (int k = 0; k < n; k++)
if (mat[i][j][k] == 0)
return 0;
return 1;
}
if (none_zero()) /* ... */
/* do stuff */
if (/*still */ none_zero()) /* ... */
/* ... */
}
(yes, I know gcc allows such things when not is standard C mode.)
> In a different kind of forum from comp.lang.c, I would almost start to
> suspect a wind-up!
No, I think you've just had a very different exposure to programming
languages and that's affected what you think is usual, helpful,
troublesome and so on.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nick_keighley_nospam@hotmail.com |
|---|---|
| Date | 2012-06-21 02:05 -0700 |
| Message-ID | <0e8125ed-8ad9-43a0-bfbd-0c90f762702f@googlegroups.com> |
| In reply to | #22458 |
On Thursday, June 21, 2012 2:09:53 AM UTC+1, Ben Bacarisse wrote:
> "BartC" <bc@freeuk.com> writes:
> > Having a local scope for a function body, that's fine;
> > every language except Basic has that.
and COBOL, of course
> > But what's so special about a
> > compound statement that it ought to have it's own private set of
> > variables?
>
> I hope you won't think me rude (and please tell me to mind my own
> business if you think the question impertinent) but what programming
> languages have had experience of? Block structure like this has been
> around since... actually I don't know but Algol had it in the late 50s.
I think they invented it. It's often credited by other languages that don't at first glance look very Algolly.
> I had to think hard to come up with a structured language without it,
> but Pascal is a rare example. It has nested function declarations, but
> plain blocks can't nest declarations.
oh, that's a surprise, I thought it allowed it. Long time since I wrote any Pascal.
> Your question "what's so special about a compound statement" is, to my
> mind, the wrong way round. What's so special about the block that forms
> a function body that it alone is allowed to contain declarations?
quite
> > On just about every other occasion where the complexity of a function
> > grows beyond about 3 lines, I'm constantly told it needs to split into
> > sub-functions. Now entire, self-contained sub-programs can be created
> > in each branch of a minor 'if' in a minor 'for' loop in a dusty corner
> > of a function, and that is perfectly OK?
>
> My liking for small helper functions is in fact thwarted by the fact
> that C's syntax takes a leaf out of your book. While variable
> declarations can be nested in enclosed blocks, function definitions
> can't be. Perhaps it would be done more often if one could do this:
>
> int some_function(int l, int m, int n, int mat[l][m][n])
> {
> int none_zero()
> {
> for (int i = 0; i < l; i++)
> for (int j = 0; j < m; j++)
> for (int k = 0; k < n; k++)
> if (mat[i][j][k] == 0)
> return 0;
> return 1;
> }
>
> if (none_zero()) /* ... */
> /* do stuff */
> if (/*still */ none_zero()) /* ... */
> /* ... */
> }
>
> (yes, I know gcc allows such things when not is standard C mode.)
yes i miss this sometimes
> > In a different kind of forum from comp.lang.c, I would almost start to
> > suspect a wind-up!
>
> No, I think you've just had a very different exposure to programming
> languages and that's affected what you think is usual, helpful,
> troublesome and so on.
and learns them in a manner that seems odd to me.
but then my first language was Algol-60 and I avidly read the "Revised Report on the Algorithmic Language Algol 60". I'm always disappointed when other languages fail to match this document.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-06-21 11:49 +0100 |
| Message-ID | <jruu98$dg8$3@dont-email.me> |
| In reply to | #22458 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.1bc999164d1494874d01.20120621020953BST.87pq8tpj1a.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
> <snip>
>> Having a local scope for a function body, that's fine;
>> every language except Basic has that. But what's so special about a
>> compound statement that it ought to have it's own private set of
>> variables?
>
> I hope you won't think me rude (and please tell me to mind my own
> business if you think the question impertinent) but what programming
> languages have had experience of?
For the past 30 years, mainly my own ones. C is the only mainstream language
I know well enough (although you might dispute that..) to use seriously if
I needed to. For runtime libraries, I've partly relied on C's for the last
15 years on so.
And before that, the usual Algol, Cobol, Pascal etc that were common on CS
degree courses in the late 70s. Plus a year of Fortran.
> Block structure like this has been
> around since... actually I don't know but Algol had it in the late 50s.
I'm aware that Algol-60 had loads of complicated stuff (eg. call-by-name),
which I never used and partly didn't understand. It didn't hinder any
programming I had to do.
> I had to think hard to come up with a structured language without it,
> but Pascal is a rare example. It has nested function declarations, but
> plain blocks can't nest declarations.
Good decision to avoid those. (But then it introduced 'case' into
records...)
> Your question "what's so special about a compound statement" is, to my
> mind, the wrong way round. What's so special about the block that forms
> a function body that it alone is allowed to contain declarations?
'The block that forms a function body'. Why call it a block, why not just a
function body? It happens to use {,} delimiters that are the same as those
used on block statements, but that's all. What about the 'block' that forms
a module body? You don't think of it as a block, because {,} aren't used to
delimit it; it uses beginning/end of file instead.
> My liking for small helper functions is in fact thwarted by the fact
> that C's syntax takes a leaf out of your book. While variable
> declarations can be nested in enclosed blocks, function definitions
> can't be. Perhaps it would be done more often if one could do this:
>
> int some_function(int l, int m, int n, int mat[l][m][n])
> {
> int none_zero()
> {
> for (int i = 0; i < l; i++)
> for (int j = 0; j < m; j++)
> for (int k = 0; k < n; k++)
> if (mat[i][j][k] == 0)
> return 0;
> return 1;
> }
>
> if (none_zero()) /* ... */
> /* do stuff */
> if (/*still */ none_zero()) /* ... */
> /* ... */
> }
> (yes, I know gcc allows such things when not is standard C mode.)
OK. But would such nested functions only be allowed at the top of the
function, or anywhere in the body? (Where they would be presumably be
limited to the enclosing block scope.)
(I'm working on two languages and two compilers at the moment. I found I
could get nested functions for free (by commenting out a line that reported
them as an error!)
It worked too, provided the nested function didn't try to access the
variables of the immediately surrounding scope (I believe this was
impossible anyway because name resolution didn't allow it).
That was interesting to know, but I then put the error-check back in. Nested
functions I can just about see a use for, but allowing a whole symbol table
hierarchywherever I happen to have a few statements in a row, I can't see
much use for at all.
BTW these languages don't have blocks statements, only Algol-68-style
'serial clauses'. (And I know the latter does have multiple nested scopes,
but it has a lot of other stuff that makes implementation difficult too.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-21 14:24 +0100 |
| Message-ID | <0.8f7e0216437cb1feac66.20120621142405BST.878vfgpzm2.fsf@bsb.me.uk> |
| In reply to | #22474 |
"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.1bc999164d1494874d01.20120621020953BST.87pq8tpj1a.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>> <snip>
>>> Having a local scope for a function body, that's fine;
>>> every language except Basic has that. But what's so special about a
>>> compound statement that it ought to have it's own private set of
>>> variables?
>>
>> I hope you won't think me rude (and please tell me to mind my own
>> business if you think the question impertinent) but what programming
>> languages have had experience of?
>
> For the past 30 years, mainly my own ones. C is the only mainstream language
> I know well enough (although you might dispute that..) to use seriously if
> I needed to. For runtime libraries, I've partly relied on C's for the last
> 15 years on so.
Maybe the 30 years working on your own languages has led to a kind of
isolationism, but that surprises me. If I'd spent decades working on my
own languages, I'd expect to have gained a huge experience of other
languages. I'd want to know what everyone else was doing, both in
theory and in practice.
Maybe you have studied what other languages do and you've decided,
rationally, that they are wrong. If so, that debate might be
interesting (but not here -- it's wildly off-topic).
> And before that, the usual Algol, Cobol, Pascal etc that were common on CS
> degree courses in the late 70s. Plus a year of Fortran.
>
>> Block structure like this has been
>> around since... actually I don't know but Algol had it in the late 50s.
>
> I'm aware that Algol-60 had loads of complicated stuff (eg. call-by-name),
> which I never used and partly didn't understand. It didn't hinder any
> programming I had to do.
Block structure isn't complicated -- adding special cases is
complicated. C is full of special cases. They are all there for a
reason but explaining them is almost always about implementation not
programming. In my perfect CS syllabus, C would be taught as an
example language in a course about compilers. It's no bad thing to
learn C, but if you learn it as you learn how to compiler it you
understand almost all of the special cases with no extra effort.
<snip>
>> Your question "what's so special about a compound statement" is, to my
>> mind, the wrong way round. What's so special about the block that forms
>> a function body that it alone is allowed to contain declarations?
>
> 'The block that forms a function body'. Why call it a block, why not just a
> function body? It happens to use {,} delimiters that are the same as those
> used on block statements, but that's all. What about the 'block' that forms
> a module body? You don't think of it as a block, because {,} aren't used to
> delimit it; it uses beginning/end of file instead.
No, I do think of it as a block -- a badly broken block with all kinds
of special rules. Restrictions on array types and the form of
initialisers, no statements allowed, special permission to define
functions, etc, etc.
I call the body of a function a block (speaking generally here, not
specifically about C) because I want to have as few 'entities' in the
language as possible. It's a sort of Occam's razor in language design.
In fact I'd have gone further, had I been designing C. I'd have made
the "body" of a function into an expression and have one kind of
expression be a block that can have a value. One of C's predecessors,
BCPL, had this in the form of a "valof" expression:
LET sub(x, y) = add(x, neg(y))
LET add(x, y) = VALOF
$( LET a = x+y
IF 0<=a<modulus RESULTIS a
ELSE RESULTIS a-modulus
$)
The idea is to permit everything anywhere, and to give everything the
most general form possible. This is tempered by other considerations
such the ease of producing an efficient implementation.
>> My liking for small helper functions is in fact thwarted by the fact
>> that C's syntax takes a leaf out of your book. While variable
>> declarations can be nested in enclosed blocks, function definitions
>> can't be. Perhaps it would be done more often if one could do this:
>>
>> int some_function(int l, int m, int n, int mat[l][m][n])
>> {
>> int none_zero()
>> {
>> for (int i = 0; i < l; i++)
>> for (int j = 0; j < m; j++)
>> for (int k = 0; k < n; k++)
>> if (mat[i][j][k] == 0)
>> return 0;
>> return 1;
>> }
>>
>> if (none_zero()) /* ... */
>> /* do stuff */
>> if (/*still */ none_zero()) /* ... */
>> /* ... */
>> }
>
>> (yes, I know gcc allows such things when not is standard C mode.)
>
> OK. But would such nested functions only be allowed at the top of the
> function, or anywhere in the body? (Where they would be presumably be
> limited to the enclosing block scope.)
The benefit (usually to the implementor) of the restriction has to be
weighed against the benefit of having a simpler -- more general --
language specification for the programmer, so I'd always want to ask
"why am I making this restriction?" rather than "would it be useful to
allow X here?".
> (I'm working on two languages and two compilers at the moment. I found I
> could get nested functions for free (by commenting out a line that
> reported them as an error!)
>
> It worked too, provided the nested function didn't try to access the
> variables of the immediately surrounding scope (I believe this was
> impossible anyway because name resolution didn't allow it).
>
> That was interesting to know, but I then put the error-check back
> in. Nested functions I can just about see a use for, but allowing a
> whole symbol table hierarchywherever I happen to have a few statements
> in a row, I can't see much use for at all.
>
> BTW these languages don't have blocks statements, only Algol-68-style
> 'serial clauses'. (And I know the latter does have multiple nested scopes,
> but it has a lot of other stuff that makes implementation difficult too.)
Comments about your own languages are not very helpful without an
explanation of the design goals. What are they to be used for? Who are
they aimed at? What hardware and software environment must they work
within? Without any of that, all I have to go on is plain fact: that
you decided to one thing rather than another.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nick_keighley_nospam@hotmail.com |
|---|---|
| Date | 2012-06-22 00:38 -0700 |
| Message-ID | <54e03c62-6007-42d4-b0b7-4d9041cda868@googlegroups.com> |
| In reply to | #22474 |
On Thursday, June 21, 2012 11:49:31 AM UTC+1, Bart wrote:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.1bc999164d1494874d01.20120621020953BST.87pq8tpj1a.fsf@bsb.me.uk...
> > "BartC" <bc@freeuk.com> writes:
> >> Having a local scope for a function body, that's fine;
> >> every language except Basic has that. But what's so special about a
> >> compound statement that it ought to have it's own private set of
> >> variables?
> >
> > I hope you won't think me rude (and please tell me to mind my own
> > business if you think the question impertinent) but what programming
> > languages have had experience of?
>
> For the past 30 years, mainly my own ones. C is the only mainstream language
> I know well enough (although you might dispute that..) to use seriously if
> I needed to. For runtime libraries, I've partly relied on C's for the last
> 15 years on so.
>
> And before that, the usual Algol, Cobol, Pascal etc that were common on CS
> degree courses in the late 70s. Plus a year of Fortran.
>
> > Block structure like this has been
> > around since... actually I don't know but Algol had it in the late 50s.
> I'm aware that Algol-60 had loads of complicated stuff (eg.
> call-by-name), which I never used and partly didn't understand.
> It didn't hinder any programming I had to do.
I don't think block scoping is complicated- particularly as dozens of languages copied the idea. I also don't recall any other "weird stuff". Call by name was a bit of a fu. If C did it it might look like this
int sum (int a, int n)
{
int total = 0;
int i;
for (i = 0; i < n; i++)
total += a;
return total;
}
sum (10, i) => 100
so far so innocuous
int b [] = {1, 2, 3};
sum (b[i], 3) => 6
the function acts more like a macro
<snip>
> BTW these languages don't have blocks statements, only Algol-68-style
> 'serial clauses'. (And I know the latter does have multiple nested
> scopes, but it has a lot of other stuff that makes implementation
> difficult too.)
Algol-68 was very "innovative". Too innovative. It started with an incomprehensible definition and went down hill from there.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-22 13:37 +0100 |
| Message-ID | <0.eed4fc273c7dab0aa455.20120622133744BST.87r4t7o73b.fsf@bsb.me.uk> |
| In reply to | #22521 |
nick_keighley_nospam@hotmail.com writes:
> On Thursday, June 21, 2012 11:49:31 AM UTC+1, Bart wrote:
<snip>
>> I'm aware that Algol-60 had loads of complicated stuff (eg.
>> call-by-name), which I never used and partly didn't understand.
>> It didn't hinder any programming I had to do.
>
> I don't think block scoping is complicated- particularly as dozens of
> languages copied the idea. I also don't recall any other "weird
> stuff". Call by name was a bit of a fu. If C did it it might look like
> this
>
> int sum (int a, int n)
> {
> int total = 0;
> int i;
>
> for (i = 0; i < n; i++)
> total += a;
>
> return total;
> }
>
> sum (10, i) => 100
> so far so innocuous
i is undeclared. You probably meant sum(10, 10)?
> int b [] = {1, 2, 3};
> sum (b[i], 3) => 6
> the function acts more like a macro
No. sum(b[i], 3) would depend on the value of i in the scope of the
call. Call by name is more like a macro with hygienic names -- the 'i'
in argument expression b[i] can't be bound by the 'i' local to sum.
Whilst the mechanism was, err... powerful, it was not mad!
To get what you want, you'd have to pass the "outer" i by name as well:
int sum (int x, int a, int n) // assume call-by-name
{
int total = 0;
for (x = 0; x < n; x++)
total += a;
return total;
}
int i; // value irrelevant
sum(i, b[i], 3)
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nick_keighley_nospam@hotmail.com |
|---|---|
| Date | 2012-06-21 01:57 -0700 |
| Message-ID | <b7b45743-cf3e-48be-8666-9d2275e1c1a5@googlegroups.com> |
| In reply to | #22447 |
On Thursday, June 21, 2012 12:13:25 AM UTC+1, Bart wrote:
> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
> news:pOednUXiQILn0X_SnZ2dnUVZ_sudnZ2d@bestweb.net...
<snip>
[why block scope?]
> > if ( foo.type == MyInteger )
> > {
> > int num;
> > num = foo.integer;
> > ... do stuff with int ...
> > }
> > else if ( foo.type == MyFloat )
> > {
> > float num;
> > num = foo.floating;
> > ... do stuff with float ...
> > }
>
> I accept that it does allow you to do stuff like this, but it really doesn't
> seem a very good idea, using the same identifier for two different types,
> within a few lines of each other in the same function.
>
> Imagine you're trying to read such a function, and your eyes jump from one
> part of the function to another. First num is a int; fine. Now you jump to
> the 'do stuff with float' part, and you have to do a double take. From this
> point on, you can't trust anything you see; what type is 'num' going to have
> next time you see it? Maybe these are two nested blocks in a loop, and you
> break from one to the other. You have to trace the code, character by
> character counting blocks, to match the use of 'num' with it's correct
> declaration.
>
> Sorry, but these possibilities which everyone else thinks are great, to me
> just seem nightmarish.
don't try programming in a dynamically typed language then!
func fred ()
{
var = 1.02; // var is a float
some_code ()
var = "hello"; // now it's a string
}
[this isn't any particular language- Python or scheme can do this
sort of stuff but with different syntax]
I'm also not saying it's necessarily a good idea to do it willy-nilly.
<snip>
> On just about every other occasion where the complexity of a function grows
> beyond about 3 lines, I'm constantly told it needs to split into
> sub-functions.
I wish someone had told the guy who wrote the software I'm maintaining that...
> Now entire, self-contained sub-programs can be created in
> each branch of a minor 'if' in a minor 'for' loop in a dusty corner of a
> function, and that is perfectly OK?
>
> In a different kind of forum from comp.lang.c, I would almost start to
> suspect a wind-up!
take a look a some idiomatic C++. One argument is you don't declare anything
until you know how to initialise it.
There are an awful lot of languages that allow block scope variables!
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-06-21 11:46 +0100 |
| Message-ID | <jruu98$dg8$2@dont-email.me> |
| In reply to | #22469 |
<nick_keighley_nospam@hotmail.com> wrote in message
news:b7b45743-cf3e-48be-8666-9d2275e1c1a5@googlegroups.com...
> On Thursday, June 21, 2012 12:13:25 AM UTC+1, Bart wrote:
> [why block scope?]
>> I accept that it does allow you to do stuff like this, but it really
>> doesn't
>> seem a very good idea, using the same identifier for two different types,
>> within a few lines of each other in the same function.
...
>> Sorry, but these possibilities which everyone else thinks are great, to
>> me
>> just seem nightmarish.
>
> don't try programming in a dynamically typed language then!
>
> func fred ()
> {
> var = 1.02; // var is a float
> some_code ()
> var = "hello"; // now it's a string
> }
>
> [this isn't any particular language- Python or scheme can do this
> sort of stuff but with different syntax]
I've been working with dynamic languages of this kind for years (designing
and implementing them too).
You can argue that in this example, there is only one type involved
('variant'), but two different values for it (1.02 and "hello"). It's not
the same as the C example, which has stricter kinds of typing.
Also someone looking at this code will know it's a dynamic language and will
not have any expectations about the precise type of the value of 'var'.
(Having said that, most variables in a dynamic language will tend to have
just the one type of value.)
> There are an awful lot of languages that allow block scope variables!
But from various source codes I've seen, not used very often. Or only used
for the ability to define variables half-way down a function; the
block-scope properties are irrelevant.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-06-21 14:37 -0400 |
| Message-ID | <0_KdnS1it_h89H7SnZ2dnUVZ_tKdnZ2d@bestweb.net> |
| In reply to | #22447 |
On 6/20/2012 7:13 PM, BartC wrote:
> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
[...]
>> if ( foo.type == MyInteger )
>> {
>> int num;
>> num = foo.integer;
>> ... do stuff with int ...
>> }
>> else if ( foo.type == MyFloat )
>> {
>> float num;
>> num = foo.floating;
>> ... do stuff with float ...
>> }
>
> I accept that it does allow you to do stuff like this, but it really doesn't
> seem a very good idea, using the same identifier for two different types,
> within a few lines of each other in the same function.
>
> Imagine you're trying to read such a function, and your eyes jump from one
> part of the function to another. First num is a int; fine. Now you jump to
> the 'do stuff with float' part, and you have to do a double take. From this
> point on, you can't trust anything you see; what type is 'num' going to have
> next time you see it? Maybe these are two nested blocks in a loop, and you
> break from one to the other. You have to trace the code, character by
> character counting blocks, to match the use of 'num' with it's correct
> declaration.
I'm not saying I'm likely to use such code, though I could see doing so with
macros that generate the "do stuff" portion.
> Sorry, but these possibilities which everyone else thinks are great, to me
> just seem nightmarish.
I don't know if they're "great", but I would certainly call them "convenient".
Now, I have been bitten once (and, AFAIK, only once) by C's scope rules.
I'm posting details in a new thread -- "C scope and struct definitions" --
to ask about it. Every other time, I find it very convenient to create
variables for a small if/for/whatever section of code (not to mention "#if
DEBUG" sections) without having to worry about name collision.
[...]
> On just about every other occasion where the complexity of a function grows
> beyond about 3 lines, I'm constantly told it needs to split into
> sub-functions. Now entire, self-contained sub-programs can be created in
> each branch of a minor 'if' in a minor 'for' loop in a dusty corner of a
> function, and that is perfectly OK?
While I'm not a big fan of "big" functions, I think everyone has a different
idea of just _when_ a function has gotten "too big" and should be split up.
That said, I do have to maintain an app that includes a 1600+ line main()
that someone else wrote [mumble mumble] years ago. (Talk about "feature
creep" run amok.) It's been on my "to do" list for years to redo it, but
it's one of those "if it ain't broke..." things. (Yes, many people would
call a 1600+ line function "broke", but it runs correctly.)
> In a different kind of forum from comp.lang.c, I would almost start to
> suspect a wind-up!
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Andrew Smallshaw <andrews@sdf.lonestar.org> |
|---|---|
| Date | 2012-06-21 19:38 +0000 |
| Message-ID | <slrn3vfsju6u1d.r3k.andrews@sdf.lonestar.org> |
| In reply to | #22489 |
On 2012-06-21, Kenneth Brody <kenbrody@spamcop.net> wrote: > > While I'm not a big fan of "big" functions, I think everyone has a different > idea of just _when_ a function has gotten "too big" and should be split up. > > That said, I do have to maintain an app that includes a 1600+ line main() > that someone else wrote [mumble mumble] years ago. (Talk about "feature > creep" run amok.) It's been on my "to do" list for years to redo it, but > it's one of those "if it ain't broke..." things. (Yes, many people would > call a 1600+ line function "broke", but it runs correctly.) Personally I'm not a big fan of concrete rules in that respect. The "four pages of one function is too much" sentiment expressed earlier is a little naive in my opinion. I've written thousand line _switch_statements_ before now: we're only talking about 70 cases of 15 lines each hit that mark. They can be perfectly managable since you're frequently talking about relatively 'flat' code without a lot of dependencies between one section and the next. It's the amount of _context_ that needs to be kept in mind when reviewing code that determines how difficult to understand it is, and that is a different metric to how _long_ it is. That's actually one of the main advantages of block scoping - it is clear that you don't need to worry about something that is out of scope. OTOH I can think of other functions - one particularly 'clever' data structure in particular - around here where even 70 line functions are too long to be easily digested. That one case in particular I've looked long and hard at how it could be subdivided further and eventually came to the conclusion that it can't in any sensible manner - the coupling between the various portions is simply too tight. _That's_ a problematic case: functions an order of magnitude longer need not be. -- Andrew Smallshaw andrews@sdf.lonestar.org
[toc] | [prev] | [next] | [standalone]
| From | nick_keighley_nospam@hotmail.com |
|---|---|
| Date | 2012-06-21 01:41 -0700 |
| Message-ID | <3db56fd3-9946-466a-891b-05caea8275c3@googlegroups.com> |
| In reply to | #22435 |
On Wednesday, June 20, 2012 2:54:02 PM UTC+1, Bart wrote: > "Kenneth Brody" <kenbrody@spamcop.net> wrote in message > news:28Gdna63UOSAT3zSnZ2dnUVZ_g-dnZ2d@bestweb.net... > > On 6/19/2012 4:13 PM, BartC wrote: > > [...] > >> I started my comments in this thread about the disadvantages of just > >> declaring variables anywhere as needed. > >> > >> Then I found out about block scopes and all the extra hassle they > >> introduce, > >> making such declarations even more problematic. (And why is a block so > >> special anyway? Surely it's only used when you need two or more > >> statements > >> instead of one.) > >> > >> I'm sorry if no-one else can see the problems (duplicate declarations, > >> clutter, separating related variables, scattered declarations, trickier > >> editing because you have to keep moving the declarations around, worrying > >> about scope, shadowing, anonymity, etc). > > > > Ahh... So you want all declarations to be global scope, always? > > No. Function scope, file scope, and project-wide. > > > That eliminates the ability to do recursion (the "int i" within the > > function is a global reference to the single "int i" variable within the > > program). > > It doesn't. > > >That eliminates the ability to create a "local" variable within a small > >block of code (I can't have a small loop use "int x,y", as that would > >simply be the same as the "double x,y" used elsewhere). That eliminates > >basically everything useful about scope, because it eliminates scope > >entirely. > > No-one has said anything of the kind. Scope would still exist across > modules, > across one module, and across one function. I'm saying it doesn't need to be > across individual blocks too, given that a typical function is small. > > > Given that the preference is this newsgroup is for small functions > > (usually > >> small enough to fit in a window), what's the point of adding this extra > >> complexity? > > > > How could one write a "small function" if it couldn't create variables > > that are available only within its scope? > > We're talking about adding extra block scopes to a 10- or 20-line function > that already has local variables valid throughout the function. > > How small a scope do you need: per line, per statement, or per expression? for (int i = 0; i < 10; i++) sum += i; I believe C++ now allows declarations in whils and ifs (?)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-06-21 12:28 +0100 |
| Message-ID | <0.d8c9cd98c92bf4145888.20120621122854BST.87ehp8q4y1.fsf@bsb.me.uk> |
| In reply to | #22466 |
nick_keighley_nospam@hotmail.com writes: > On Wednesday, June 20, 2012 2:54:02 PM UTC+1, Bart wrote: <snip> >> How small a scope do you need: per line, per statement, or per >> expression? Per expression can be useful. Algol-68, famous for it's orthogonality, made no distinction between a block and a sub-expression. You could write: 2 * (INT i; read(i); i) as an expression if you so wished. > for (int i = 0; i < 10; i++) sum += i; > > I believe C++ now allows declarations in whils and ifs (?) Yes, and switch too. Also in the *second* position of a 'for' statement so that it remains a sort of enhanced 'while'. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-06-19 15:05 +0000 |
| Message-ID | <20120619082119.735@kylheku.com> |
| In reply to | #22378 |
On 2012-06-18, Ike Naar <ike@iceland.freeshell.org> wrote: > Why don't you go one step further and declare > retval, temp, i, j, and k as global variables? In part, for the same reason why you don't keep them block scope local, but stick "static" on them.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-06-19 09:37 +1200 |
| Message-ID | <a49lc0F7l4U1@mid.individual.net> |
| In reply to | #22331 |
On 06/17/12 10:47 PM, BartC wrote: > > > "Jorgen Grahn"<grahn+nntp@snipabacken.se> wrote in message > news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid... >> On Thu, 2012-06-14, Varun Tewari wrote: >>> Its simply not stupid, its a simple fact the C++/Java allow >>> decalaration anywhere in the code, but C wants them the first thing >>> when you code. That's all >> >> You could say that "declarations only at the start of block" was a >> stupid design ... I'm very happy this got changed, and it should >> probably have happened earlier, when 'const' and such things were >> introduced. >> >> Now all that remains is to educate the users. Most code I read >> doesn't even use the C89 "at the start of block" rule. It lumps all >> the variables at the start of the function -- even those that are only >> used and only make sense inside some loop, two pages down ... > > But what happens when the code defines a variable two pages into a function, > but you happen to be reading some code using that same variable four pages > into the function! Then you (or the original authour) are doing something very very wrong. > Where do you go to find the definition? At the start of a > function is usually a good place! You don't always know that a variable is > only used once. C is the only language I know that had (in the last century) such restrictive declaration rules. You wouldn't see this argument on a forum for another language. If old C's declaration rules were such a good idea, why have thy been ignored by most (all?) subsequent languages? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2012-06-18 15:18 -0700 |
| Message-ID | <cbe60af5-c293-4b8a-8171-bb1ab069f507@j25g2000yqn.googlegroups.com> |
| In reply to | #22373 |
On Jun 18, 5:37 pm, Ian Collins <ian-n...@hotmail.com> wrote: > On 06/17/12 10:47 PM, BartC wrote: > > > > > > > > > > > > > "Jorgen Grahn"<grahn+n...@snipabacken.se> wrote in message > >news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid... > >> On Thu, 2012-06-14, Varun Tewari wrote: > >>> Its simply not stupid, its a simple fact the C++/Java allow > >>> decalaration anywhere in the code, but C wants them the first thing > >>> when you code. That's all > > >> You could say that "declarations only at the start of block" was a > >> stupid design ... I'm very happy this got changed, and it should > >> probably have happened earlier, when 'const' and such things were > >> introduced. > > >> Now all that remains is to educate the users. Most code I read > >> doesn't even use the C89 "at the start of block" rule. It lumps all > >> the variables at the start of the function -- even those that are only > >> used and only make sense inside some loop, two pages down ... > > > But what happens when the code defines a variable two pages into a function, > > but you happen to be reading some code using that same variable four pages > > into the function! > > Then you (or the original authour) are doing something very very wrong. > > > Where do you go to find the definition? At the start of a > > function is usually a good place! You don't always know that a variable is > > only used once. > > C is the only language I know that had (in the last century) such > restrictive declaration rules. You wouldn't see this argument on a > forum for another language. If old C's declaration rules were such a > good idea, why have thy been ignored by most (all?) subsequent languages? I struggle with this when writing libraries because there is a choice between supporting the widest range of environments versus having the flexibility to group variables closer to their scope. As of now, I'm still (grudgingly) writing variables at the beginning of the block. I don't think for short functions or small numbers of variables that it detracts much from readability, but I do miss for loop initializer declarations. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | Paul J Gans <gansno@panix.com> |
|---|---|
| Date | 2012-06-18 23:21 +0000 |
| Message-ID | <jrod56$oum$1@reader1.panix.com> |
| In reply to | #22373 |
Ian Collins <ian-news@hotmail.com> wrote: >On 06/17/12 10:47 PM, BartC wrote: >> >> >> "Jorgen Grahn"<grahn+nntp@snipabacken.se> wrote in message >> news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid... >>> On Thu, 2012-06-14, Varun Tewari wrote: >>>> Its simply not stupid, its a simple fact the C++/Java allow >>>> decalaration anywhere in the code, but C wants them the first thing >>>> when you code. That's all >>> >>> You could say that "declarations only at the start of block" was a >>> stupid design ... I'm very happy this got changed, and it should >>> probably have happened earlier, when 'const' and such things were >>> introduced. >>> >>> Now all that remains is to educate the users. Most code I read >>> doesn't even use the C89 "at the start of block" rule. It lumps all >>> the variables at the start of the function -- even those that are only >>> used and only make sense inside some loop, two pages down ... >> >> But what happens when the code defines a variable two pages into a function, >> but you happen to be reading some code using that same variable four pages >> into the function! >Then you (or the original authour) are doing something very very wrong. >> Where do you go to find the definition? At the start of a >> function is usually a good place! You don't always know that a variable is >> only used once. >C is the only language I know that had (in the last century) such >restrictive declaration rules. You wouldn't see this argument on a >forum for another language. If old C's declaration rules were such a >good idea, why have thy been ignored by most (all?) subsequent languages? I'd think the argument works the other way. Back when C was new the other dominant language was FORTRAN. Later came both Basic, Algol, and Cobol. All were strongly typed languages. Of these only C survives to any major extent, proving, it seems to me, that it was the most *successful* of these languages. Indeed, it also shows that perhaps in spite of its strong typing, it has held up under the barrage of "new" languages. -- --- Paul J. Gans
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web