Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: What's new in C? (http://www.velocityreviews.com/forums/t954999-re-whats-new-in-c.html)

Jorgen Grahn 11-30-2012 08:50 PM

Re: What's new in C?
 
On Thu, 2012-11-29, Cal Dershowitz wrote:
> It's been forever since I posted as OP in c.l.c. When I was learning C
> from Dan Pop, the authors of unleashed, Chris Torek, Keith and even
> Chuck before he was wrong all the time, there was always the tension
> between dos and linux platforms, Topic Zealotry: there is no topic but
> the topic, but also there was good, topical and honest disagreements
> about C itself.
>
> There seemed to be a significant numbers of individuals and companies
> who were just going to keep on working with C90, while others and I went
> toward C99.
>
> I'm wondering how it all turned out. While the C specification is
> concise and small, the C family of users and applications is
> monstrously-large.
>
> Did embedded systems eventually embrace newer C?


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.

/Jorgen

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

Jens Gustedt 11-30-2012 10:35 PM

Re: What's new in C?
 
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.

Jens


Jorgen Grahn 12-05-2012 03:26 AM

Re: What's new in C?
 
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 .

gwowen 12-06-2012 07:49 AM

Re: What's new in C?
 
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.

Jorgen Grahn 12-08-2012 07:55 AM

Re: What's new in C?
 
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 .

BartC 12-08-2012 01:29 PM

Re: What's new in C?
 


"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


Jorgen Grahn 12-08-2012 03:23 PM

Re: What's new in C?
 
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 .

Martin Shobe 12-08-2012 05:46 PM

Re: What's new in C?
 
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

Malcolm McLean 12-08-2012 06:45 PM

Re: What's new in C?
 
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

BartC 12-08-2012 06:55 PM

Re: What's new in C?
 
"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




All times are GMT. The time now is 08:00 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.