Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO C is increasingly moronic

varnish-cache.org

Post reply on HN
Print view View original

101–110 of 175 posts

Re: ISO C is increasingly moronic

#101

Post by jshen »

mbell wrote: post #90
jshen wrote: post #55

Earlier quoted context omitted.

Nothing you said negates his argument. Why didn't the committee ad them to the constitution itself when it was passed?

They didn't agree about the inclusion of the articles and they wanted to get the constitution signed and proposed to the states for ratification ASAP. Thus those that wanted to get the Bill of Rights in there were promised "it would be coming soon" which appeased them enough to "sign off " on the constitution and those that had some issue with the articles were happy that they weren't initially included. Keep in mind…

Right, that's what phkamp was saying. That the committee was a messy process that produced an artifact that needed to be fixed right out the gate, and didn't get up to a decent standard for a long long time.

Re: ISO C is increasingly moronic

#103

Post by haberman »

tptacek wrote: post #96
haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_ functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD. This is so much of a win that I don't understand why everyone doesn't do it: * Cross-platform counted/allocat…

> I'm going to tend to believe PHK if he thinks explicit structure packing is a win, noting at the same time how unlikely it is that any implementation of it is going to be a performance bottleneck compared with I/O.

I've spent a lot of my life writing parsers for various network formats, and one thing that I can say with authority is that at both my current company (Google) and at my previous company (Amazon) the CPU cost of parsing bytes off the network was noticeable enough to spend significant resources optimizing.

I haven't done benchmarks myself about eg. bitvectors, but I'm pretty sure I've heard that the performance of packed bitvectors is noticeably slower than non-packed. I also think the cost would be comparable to 64-bit math on 32-bit processors (ie. an overhead of 3-5 instructions per operation), which is a non-trivial cost.

Re: ISO C is increasingly moronic

#104

Post by adgar »

haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

> Simple expressions like x.y++ could end up being much more expensive than expected.

He's talking about pulling protocol packets off the wire - who increments values in a packet like that? Typically all you ever do is pull the relevant fields out into your own structure or pass them off as arguments to a function call. Which will always involve unaligned reads from buffer somewhere.

The only real way I can see it being misused in a way that results in poor performance is if you read data into an explicitly-packed struct and then pass a reference to it around everywhere, reading from it willy-nilly instead of extracting the values once.

Re: ISO C is increasingly moronic

#105

Post by techdmn »

haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

Sometimes I wonder if C++ deserves more credit for /saving/ C, by absorbing all the crap that might otherwise have been added. :)

Re: ISO C is increasingly moronic

#106

Post by haberman »

adgar wrote: post #104
haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

> Simple expressions like x.y++ could end up being much more expensive than expected. He's talking about pulling protocol packets off the wire - who increments values in a packet like that? Typically all you ever do is pull the relevant fields out into your own structure or pass them off as arguments to a function call. Which will always involve unaligned reads from buffer somewhere . The only real way I can see it b…

If you're just going to extract the values once, why not just write the code to actually do that instead of trying to play tricks with memcpy()? Those tricks won't even work in many cases where certain fields indicate the length of certain other fields (which is quite common).

When I first started programming in C I also had this fantasy that I could parse network formats with memcpy(). Since then I've become convinced that writing the actual parsing code is for the best.

Re: ISO C is increasingly moronic

#107

Post by mark_h »

tptacek wrote: post #96
haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_ functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD. This is so much of a win that I don't understand why everyone doesn't do it: * Cross-platform counted/allocat…

+1 for Hanson's book in general (which I think I might have initially read on your recommendation anyway!). I don't do a huge amount of C programming these days, but it was a huge eye-opener.

Re: ISO C is increasingly moronic

#108

Post by aidenn0 »

zb wrote: post #59
api wrote: post #10

Nothing good ever came from a committee.

Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

Most of the K&R isms were already gone before C89, ANSI just standardized those. I learned C from a pre-ANSI book and it definitely wasn't that K&Rish

Re: ISO C is increasingly moronic

#109

Post by StephenFalken »

phkamp wrote: post #69
zb wrote: post #59

Earlier quoted context omitted.

Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

You're probably right about that, ANSI did a couple of good things, but I'm not sure I think they came out in the black in the end. ISO on the other hand, seems like a total disaster.

It's interesting to note the bumpy road that lead to the final standardization of C as ANSI X3.159-1989, as documented on the following post:

http://groups.google.com/group/comp.lang.c/msg/991b9116ffa83...

Dennis Ritchie spend part of that time fighting against the introduction of several new features he felt were not the proper future of the language. Unfortunately, he had little to no involvement on the C99 standardization process. The final outcome was a butchered language. I'm sticking to C89/C90 on all my C development, no matter what.

"I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99 standard is much bulkier, and though the committee has signaled that much of their time was spent in resisting feature-suggestions, there are still plenty of accepted ones to digest. I certainly don't desire additional ones, and the most obvious reaction is that I wish they had resisted more firmly." --dmr

Re: ISO C is increasingly moronic

#110

Post by aliguori »

plq wrote: post #75
aliguori wrote: post #51

Earlier quoted context omitted.

Yes, I realize this, but since it's only "reserved" in the specification and the compiler doesn't enforce this, there is a massive amount of code that does this today. The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code. Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards co…

> Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee. How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.

If the goal is to allow the introduction of new keywords, then it's fairly simple. Don't parse anything in the form __[a-z0-9$_] as anything but a keyword.

Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.

Post reply on HN