Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28771 > unrolled thread

What's new in C?

Back to article view | Back to comp.lang.c

Contents

  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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#28938

On Fri, 2012-11-30, Jens Gustedt wrote:
> Am 30.11.2012 21:50, schrieb Jorgen Grahn:
>
>> For the one I'm working on: we're talking about going C99, but it
>> never happens.  And the Linux kernel seems stuck with C90 for some
>> reason.
>
> No, that is much too imprecise to be true. The linux kernel uses its
> own C dialect which is a pragmatic mixture of C89, C99 and gcc
> specific features. They have some C99 that they disallow in the
> kernel, some for good reasons, e.g I can easily be convinced that VLA
> are not such a good idea in an OS kernel. Whether or not to allow
> mixed declarations and statement (which Linus definitively doesn't
> want) is more a matter of taste and/or coding style.

True. It's the ban on mixed declarations which annoys me, and the
feature which "defines" C99 for me personally.  No big surprise that
Linus is against it I guess ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#28968

On Dec 5, 3:26 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:

> True. It's the ban on mixed declarations which annoys me, and the
> feature which "defines" C99 for me personally.  No big surprise that
> Linus is against it I guess ...

And yet, something tells me that if mixed declarations were allowed,
no-one would've ever written:

static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
{
  struct sock *sk = tun->sk;
  unsigned int mask = 0;

  if (!tun) return POLLERR;
  // oops, check gets compiled out, bad stuff happens...
}

Of course, there are C89 constructs that mitigate that error, but none
as natural as declaring a variable at initialisation time.

[toc] | [prev] | [next] | [standalone]

#28970

On 12/06/2012 12:49 AM, gwowen wrote:
> On Dec 5, 3:26 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
>> True. It's the ban on mixed declarations which annoys me, and the
>> feature which "defines" C99 for me personally.  No big surprise that
>> Linus is against it I guess ...
>
> And yet, something tells me that if mixed declarations were allowed,
> no-one would've ever written:
>
> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
> {
>    struct sock *sk = tun->sk;
>    unsigned int mask = 0;
>
>    if (!tun) return POLLERR;
>    // oops, check gets compiled out, bad stuff happens...
> }
>
> Of course, there are C89 constructs that mitigate that error, but none
> as natural as declaring a variable at initialisation time.
>

lol!

some very good writing in this thread.

peace.
-- 
Cal

[toc] | [prev] | [next] | [standalone]

#29055

On Thu, 2012-12-06, gwowen wrote:
> On Dec 5, 3:26 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>
>> True. It's the ban on mixed declarations which annoys me, and the
>> feature which "defines" C99 for me personally.  No big surprise that
>> Linus is against it I guess ...
>
> And yet, something tells me that if mixed declarations were allowed,
> no-one would've ever written:
>
> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
> {
>   struct sock *sk = tun->sk;
>   unsigned int mask = 0;
>
>   if (!tun) return POLLERR;
>   // oops, check gets compiled out, bad stuff happens...
> }
>
> Of course, there are C89 constructs that mitigate that error, but none
> as natural as declaring a variable at initialisation time.

Ugh.  Yeah, it would be interesting to read Linus' rationale for not
allowing it.  (Although based on earlier rants of his, I suspect it
would just leave me puzzled and angry.  His good sense shows in his
designs, not so much in his writings.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#29060

"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
news:slrnkc5sjo.1jc.grahn+nntp@frailea.sa.invalid...
> On Thu, 2012-12-06, gwowen wrote:

>> And yet, something tells me that if mixed declarations were allowed,
>> no-one would've ever written:
>>
>> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
>> {
>>   struct sock *sk = tun->sk;
>>   unsigned int mask = 0;
>>
>>   if (!tun) return POLLERR;
>>   // oops, check gets compiled out, bad stuff happens...
>> }
>>
>> Of course, there are C89 constructs that mitigate that error, but none
>> as natural as declaring a variable at initialisation time.
>
> 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!)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29063

On Sat, 2012-12-08, BartC wrote:
>
>
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
> news:slrnkc5sjo.1jc.grahn+nntp@frailea.sa.invalid...
>> On Thu, 2012-12-06, gwowen wrote:
>
>>> And yet, something tells me that if mixed declarations were allowed,
>>> no-one would've ever written:
>>>
>>> static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
>>> {
>>>   struct sock *sk = tun->sk;
>>>   unsigned int mask = 0;
>>>
>>>   if (!tun) return POLLERR;
>>>   // oops, check gets compiled out, bad stuff happens...
>>> }
>>>
>>> Of course, there are C89 constructs that mitigate that error, but none
>>> as natural as declaring a variable at initialisation time.
>>
>> 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.

(No, actually I've heard another one: "it becomes so painful to
maintain for long functions that you're encouraged to split it into
smaller functions".  I don't buy such arguments.)

If you really have more arguments, I'm interested and willing to
listen.

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.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#29066

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
news:slrnkc6mr9.1jc.grahn+nntp@frailea.sa.invalid: 

> On Sat, 2012-12-08, BartC wrote:
>>
>>
>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message 
>> news:slrnkc5sjo.1jc.grahn+nntp@frailea.sa.invalid...
>>> On Thu, 2012-12-06, gwowen wrote:
>>
>>>> And yet, something tells me that if mixed declarations were
>>>> allowed, no-one would've ever written:
>>>>
>>>> static unsigned int tun_chr_poll(struct file *file, poll_table *
>>>> wait) {
>>>>   struct sock *sk = tun->sk;
>>>>   unsigned int mask = 0;
>>>>
>>>>   if (!tun) return POLLERR;
>>>>   // oops, check gets compiled out, bad stuff happens...
>>>> }
>>>>
>>>> Of course, there are C89 constructs that mitigate that error, but
>>>> none as natural as declaring a variable at initialisation time.
>>>
>>> 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.
> 
> (No, actually I've heard another one: "it becomes so painful to
> maintain for long functions that you're encouraged to split it into
> smaller functions".  I don't buy such arguments.)

That sounds like a reason to allow it to me.

[snip]

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#29069

On Saturday, December 8, 2012 3:23:23 PM UTC, Jorgen Grahn wrote:
> On Sat, 2012-12-08, BartC wrote:
> 
> 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.
> 
> (No, actually I've heard another one: "it becomes so painful to
> maintain for long functions that you're encouraged to split it into
> smaller functions".  I don't buy such arguments.)
> 
A function is a unit, and variables have meaning within that unit.

If N means "the number of employees", then it makes sense if N means that
thoughout the whole function. If it means "the bitpattern that represents
the Latin glyph N", again it should mean that in the whole function.

So it's natural to have a glossary at the start of the function.

unsigned char *N; /* bit pattern for N */
double theta; /* anticlockwise angle */
int x, y; /* top left Cartesian co-ordinates */

--
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#29075

On Sat, 2012-12-08, Malcolm McLean wrote:
> On Saturday, December 8, 2012 3:23:23 PM UTC, Jorgen Grahn wrote:
>> On Sat, 2012-12-08, BartC wrote:
>> 
>> 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.
>> 
>> (No, actually I've heard another one: "it becomes so painful to
>> maintain for long functions that you're encouraged to split it into
>> smaller functions".  I don't buy such arguments.)
>> 
> A function is a unit, and variables have meaning within that unit.
>
> If N means "the number of employees", then it makes sense if N means that
> thoughout the whole function. If it means "the bitpattern that represents
> the Latin glyph N", again it should mean that in the whole function.

Sure. I think everyone agrees about that.

> So it's natural to have a glossary at the start of the function.
>
> unsigned char *N; /* bit pattern for N */
> double theta; /* anticlockwise angle */
> int x, y; /* top left Cartesian co-ordinates */

Your example also happens to be a good counterexample.

The documentation for N, theta, x and y is incorrect the point of
declaration. 'theta' might well be an angle further down into the
function, but at this point it's just garbage.

That's why I prefer 'theta' to show up at initialization time:

  const double theta = some_trigonometry_stuff(x, y);

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#29071

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

For example, a 3-deep nested for-loop all using 'i' as the index variable!

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.

If you've been editing and have introduced new identifiers, more care is
needed to find the outermost block that contains all uses of that name (get
it wrong by one block, and a later use could unintentionally shadow a global
version of the name) for a location of the declaration.

When editing involves deleting, inserting, moving or modifying lines that
include the declaration of a name, you might have to find a new home for the
declaration. Or maybe you insert another use of the name before the
declaration. It makes maintenance harder.

If it's ever necessary to refer to a name, outside of the program (in a
phone call, email, etc) you might not be able to say variable A in function
F, if there's more than one!

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.

(This need not be the case; an implementation may decide it's easier to just
allocate all the distinct names as one block, on entry for the function.
Such an implementation is sensible! Unless there are VLAs involved..)

If a variable is initialised in a block, then it might be reinitialised if
that block is reexecuted; you might only need it initialised once per
function entry.

Generally, it makes a function look untidy and cluttered, IMO, having the
declarations scattered randomly through the code, makes maintenance more
difficult (and sometimes trickier), and makes it harder to see at a glance
all the names that are used. Declarations at the top makes it easier to
group related names together, perhaps with a comment applied to the group.

(Mixed declarations are like reading a play where the list of characters is
scattered through the text instead of just before Act I!)

Also, mixed declarations may not always be allowed.

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

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#29074

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!
>
> 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!

You can do that in C89.

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

If a function is long enough for this to be a problem, you have bigger 
things to worry about than mixed declarations and code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#29078

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:aihiijFmkj3U1@mid.individual.net...
> BartC wrote:

>> For example, a 3-deep nested for-loop all using 'i' as the index
>> variable!
>
> You can do that in C89.

Do you have an example? That is meaningful I mean.

Although nothing is stopping you anyway from using the same index variable,
because they are all the same variable, it's going to cause difficulties, so
it doesn't happen.

But with mixed declarations it will work, because all the 'i's are distinct.
However, it's just confusing

(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!)

> If a function is long enough for this to be a problem, you have bigger
> things to worry about than mixed declarations and code.

And if a function is short, there's less to gain from localising all the
declarations.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29079

BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:aihiijFmkj3U1@mid.individual.net...
>> BartC wrote:
>
>>> For example, a 3-deep nested for-loop all using 'i' as the index
>>> variable!
>>
>> You can do that in C89.
>
> Do you have an example? That is meaningful I mean.

int main(void) {
   int i;

   for( i = 0; i < 10; ++i ) {
     int i;
     for( i = 0; i < 10; ++i ) {
     }
   }
}

> Although nothing is stopping you anyway from using the same index variable,
> because they are all the same variable, it's going to cause difficulties, so
> it doesn't happen.
>
> But with mixed declarations it will work, because all the 'i's are distinct.
> However, it's just confusing
>
> (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!)

Isn't that what C99 added?

>> If a function is long enough for this to be a problem, you have bigger
>> things to worry about than mixed declarations and code.
>
> And if a function is short, there's less to gain from localising all the
> declarations.

My point was that one of the common reasons for not liking mixed 
declarations and code is it doesn't sit well with badly written code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#29084

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:aihlkjFac7cU1@mid.individual.net...
> BartC wrote:
>> "Ian Collins" <ian-news@hotmail.com> wrote in message

>>> You can do that in C89.
>>
>> Do you have an example? That is meaningful I mean.
>
> int main(void) {
>   int i;
>
>   for( i = 0; i < 10; ++i ) {
>     int i;
>     for( i = 0; i < 10; ++i ) {
>     }
>   }
> }
>
>> Although nothing is stopping you anyway from using the same index
>> variable,
>> because they are all the same variable, it's going to cause difficulties,
>> so
>> it doesn't happen.
>>
>> But with mixed declarations it will work, because all the 'i's are
>> distinct.
>> However, it's just confusing
>>
>> (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!)
>
> Isn't that what C99 added?

It seems I misunderstood was being discussed. I thought it was declarations
at the top vs. block declarations. Not block declarations vs. genuinely
anywhere.

Which I consider even more wrong.

If, for example, you have to fill in the declarations in a newly written
functions (if like me you leave such matters until the code is at a first
draft); it means searching backwards for the first occurrence of each name,
and paying attention to block structure, instead of just sticking them all
at the top where they belong. And where they don't spoil the lines of the 
function with all these incongruous declarations.

Then you have to edit the code and have to keep moving the declarations
around ...

But I suppose it's people's choice if they want to make life more difficult.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29085

BartC wrote:
>
> It seems I misunderstood was being discussed. I thought it was declarations
> at the top vs. block declarations. Not block declarations vs. genuinely
> anywhere.
>
> Which I consider even more wrong.
>
> If, for example, you have to fill in the declarations in a newly written
> functions (if like me you leave such matters until the code is at a first
> draft); it means searching backwards for the first occurrence of each name,
> and paying attention to block structure, instead of just sticking them all
> at the top where they belong. And where they don't spoil the lines of the
> function with all these incongruous declarations.
>
> Then you have to edit the code and have to keep moving the declarations
> around ...

Which yet again emphasises my earlier point (that you conveniently 
snipped): one of the common reasons for not liking mixed declarations 
and code is it doesn't sit well with badly written code.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#29086

"BartC" <bc@freeuk.com> writes:
[...]
> It seems I misunderstood was being discussed. I thought it was declarations
> at the top vs. block declarations. Not block declarations vs. genuinely
> anywhere.

As we've said, the former has existed since the 1970s; the latter was
added in C99.

> Which I consider even more wrong.
>
> If, for example, you have to fill in the declarations in a newly written
> functions (if like me you leave such matters until the code is at a first
> draft); it means searching backwards for the first occurrence of each name,
> and paying attention to block structure, instead of just sticking them all
> at the top where they belong. And where they don't spoil the lines of the 
> function with all these incongruous declarations.
>
> Then you have to edit the code and have to keep moving the declarations
> around ...
>
> But I suppose it's people's choice if they want to make life more difficult.

You seem to be ignoring the arguments several people are making
that the ability to mix declarations and statements can make life
*easier*.

If you want to put all your declarations at the top of each function,
of course you're free to do so.  But if you wanted to impose your
preference on anyone else (not that you've said you want to do that),
you'd be about 13 years too late.

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

#29082

"BartC" <bc@freeuk.com> writes:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:aihiijFmkj3U1@mid.individual.net...
>> BartC wrote:
>>> For example, a 3-deep nested for-loop all using 'i' as the index
>>> variable!
>>
>> You can do that in C89.
>
> Do you have an example? That is meaningful I mean.
>
> Although nothing is stopping you anyway from using the same index variable,
> because they are all the same variable, it's going to cause difficulties, so
> it doesn't happen.

What do you mean by "they are all the same variable"?

Using C99 syntax:

    for (int i = 0; i < 100; i ++) {
        for (int i = 0; i < 100; i ++) {
            // ...
        }
    }

The outer and inner "i" are two distinct objects (that happen to
have the same name).  If you say they're the same variable, then
you're using a very different definition of "variable" than I do.

> But with mixed declarations it will work, because all the 'i's are distinct.
> However, it's just confusing
>
> (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.

>> If a function is long enough for this to be a problem, you have bigger
>> things to worry about than mixed declarations and code.
>
> And if a function is short, there's less to gain from localising all the
> declarations.

What you gain is the ability to initialize a variable using information
that's not available at the top of the function (or block).  Do you
really not find that useful?

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

#29087

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnhanwntum.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>> news:aihiijFmkj3U1@mid.individual.net...
>>> BartC wrote:
>>>> For example, a 3-deep nested for-loop all using 'i' as the index
>>>> variable!
>>>
>>> You can do that in C89.
>>
>> Do you have an example? That is meaningful I mean.
>>
>> Although nothing is stopping you anyway from using the same index
>> variable,
>> because they are all the same variable, it's going to cause difficulties,
>> so
>> it doesn't happen.
>
> What do you mean by "they are all the same variable"?

I thought the C89 reference meant declarations all being in a single block
at the top of the function. Then all the 'i' variables must be the same one.

>> (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 mean this:

void tenhellos(void) {
 for (i=1; i<=10; ++i) printf("hello\n");
}

No declaration needed; it will default to int. Although I'm not sure
whether, if an 'i' *has* been declared outside, whether it should use that
same i, or create a distinct version. Probably the former, so that you can
control the type, and so you can pick up the value of i outside the loop.
(You're going to tell me now that that's undefined...)

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

(No? I've looked at all the for-loops in my recent C project.

Out of 66 loops, 24 are used just for repeating N times. The other 42
iterate over A to B, by 1. All those other fancy variations aren't used at
all. In fact I use macros TO() and FOR() respectively for these two cases; I
can't remember the last time I had to write a for-loop in full ... other 
than the above example!)

>> And if a function is short, there's less to gain from localising all the
>> declarations.
>
> What you gain is the ability to initialize a variable using information
> that's not available at the top of the function (or block).  Do you
> really not find that useful?

Yes, maybe. But usually an ordinary assignment would take care of that.

Maybe, also, if you wanted to cut-and-paste part of a function, it would be
handy if the declarations came with it. But then it might or might not
include the declaration. Or you might end up with a duplicate declaration. I
don't know. I just like these things at the top!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29088

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnhanwntum.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>>> news:aihiijFmkj3U1@mid.individual.net...
>>>> BartC wrote:
>>>>> For example, a 3-deep nested for-loop all using 'i' as the index
>>>>> variable!
>>>>
>>>> You can do that in C89.
>>>
>>> Do you have an example? That is meaningful I mean.
>>>
>>> Although nothing is stopping you anyway from using the same index
>>> variable, because they are all the same variable, it's going to
>>> cause difficulties, so it doesn't happen.
>>
>> What do you mean by "they are all the same variable"?
>
> I thought the C89 reference meant declarations all being in a single block
> at the top of the function. Then all the 'i' variables must be the same one.

We've established that C89 permits declarations at the top of each
block.

What do you mean by "all the 'i' variables"?  Do you mean that all the
*references* to the name 'i' must refer to the same local variable?  If
so, then there's only one variable, so the phrase "'i' variables" is
misleading.

>>> (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 mean this:
>
> void tenhellos(void) {
>  for (i=1; i<=10; ++i) printf("hello\n");
> }
>
> No declaration needed; it will default to int. Although I'm not sure
> whether, if an 'i' *has* been declared outside, whether it should use that
> same i, or create a distinct version. Probably the former, so that you can
> control the type, and so you can pick up the value of i outside the loop.
> (You're going to tell me now that that's undefined...)

Implicit declarations and defaulting to int are things the C language
has been getting away from, and adding such a feature would not be
particularly useful.  In C99, you can just write:

 void tenhellos(void) {
  for (int i=1; i<=10; ++i) printf("hello\n");
 }

(Or you can make 'i' short, or long, or any type you like.)

>> 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.
>
> (No? I've looked at all the for-loops in my recent C project.
>
> Out of 66 loops, 24 are used just for repeating N times. The other 42
> iterate over A to B, by 1. All those other fancy variations aren't used at
> all. In fact I use macros TO() and FOR() respectively for these two cases; I
> can't remember the last time I had to write a for-loop in full ... other 
> than the above example!)

I think most programmers consider:

    for (int i = 0; i < N; i ++) {
        /* ... */
    }

to be a sufficiently clear way to express "loop N times".  Having to
declare "i" even if there are no references to it in the body of the
loop is a *small* drawback, but if you want a language with no warts I
suggest looking somewhere other than C.  And as you say, you can always
define a macro (perhaps using a unique name for the loop variable).

>>> And if a function is short, there's less to gain from localising all the
>>> declarations.
>>
>> What you gain is the ability to initialize a variable using information
>> that's not available at the top of the function (or block).  Do you
>> really not find that useful?
>
> Yes, maybe. But usually an ordinary assignment would take care of that.

The point is that with an ordinary assignment, the declaration and
initialization can be widely separated, and you have to read the whole
function to be sure that a given assignment is the first (and possibly
only) assignment to that object.  If I can write:

    {
        ...
        const int foo = some_computation;
        ...
    }

all that information is in one place: "foo" is not visible before its
declaration, and has an unchanging value after it.

> Maybe, also, if you wanted to cut-and-paste part of a function, it would be
> handy if the declarations came with it. But then it might or might not
> include the declaration. Or you might end up with a duplicate declaration. I
> don't know. I just like these things at the top!

Then by all means put them there!

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

#29090

BartC wrote:
> "Keith Thompson" <kst-u@mib.org> wrote:
>>
>> What you gain is the ability to initialize a variable using information
>> that's not available at the top of the function (or block).  Do you
>> really not find that useful?
>
> Yes, maybe. But usually an ordinary assignment would take care of that.
>
> Maybe, also, if you wanted to cut-and-paste part of a function, it would be
> handy if the declarations came with it. But then it might or might not
> include the declaration. Or you might end up with a duplicate declaration. I
> don't know. I just like these things at the top!

If you feel the urge to cut and past part of a function, you should 
suppress it and extract functionality into a function on its own!

-- 
Ian Collins

[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