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

151–160 of 175 posts

Re: ISO C is increasingly moronic

#151

Post by myhnaccount108 »

jshen wrote: post #101
mbell wrote: post #90

Earlier quoted context omitted.

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.

Opponents of BofR claimed that was the broken part because it was redundant (and potentially dangerous) to enumerate rights not explicitly granted to the government. Also the built in amendment process allowed the document to adapt as the country evolved, while allowing the highest priority requirements to be met in the first iteration.

Re: ISO C is increasingly moronic

#152

Post by swah »

haberman wrote: post #139
tptacek wrote: post #123

Earlier quoted context omitted.

In the sense that your parsing strategy influences your I/O strategy and, in particular, may incur extra copies, I buy this. The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more. I've done a fair bit of high performance network code (not for Amazon or Google, but, for instance, for code watch…

> The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more. I can speak better to Google, since it's my more recent experience. Google's internal data format is Protocol Buffers (and all the code is open-sourced, as you probably know). The C++ code that is generated to parse Protocol Buffers is f…

Is that on your 20%? I noticed you use Lua :)

Re: ISO C is increasingly moronic

#153

Post by tkahn6 »

tptacek wrote: post #125
tkahn6 wrote: post #87

Earlier quoted context omitted.

Can anyone explain why this needs to be a macro? What does this get you over a plain function?

The idiomatic way you'd express a generic tailq in C with functions is with void-stars, which cost 4-8 bytes and incur the costs of indirecting through another memory address and, probably, of allocating lots of fiddly little structs at random times. The macro version expresses the same generalized logic but embeds the link pointers in the structure you're queueing.

Thanks! Helpful as always.

Re: ISO C is increasingly moronic

#155

Post by anacrolix »

alexis-d wrote: post #46
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

"For an example of what happens when you break compatibility in the name of "progress" see Python3, which years on is still not installed by default anywhere, and probably never will be." Python 3 is the default on some Linux distros (e.g. Arch Linux)...

I didn't see this. Python3 will become the default on many OS. The real problem here is that Python3 has done significant damage to Python's popularity.

Re: ISO C is increasingly moronic

#156

Post by gsg »

JoshTriplett wrote: post #146
gsg wrote: post #131

Earlier quoted context omitted.

The goal is not just to allow for new keywords. Reserved identifiers are also intended to be used in system headers to protect implementation code from the unfortunate effect of user defined symbols. Go and read your /usr/include/stdio.h (or equivalent). It will be filled with such symbols. Obviously the compiler must lex them exactly as it would unreserved symbols. This is an unfortunately legacy of C's decision to…

System headers could use a #pragma _SystemIdentifiers, much like TeX's "makeatletter" and "makeatother" that allow packages to use @ in the name of internal symbols to avoid conflicts. I do think compilers ought to have warnings for using identifiers in the reserved namespace. Most projects probably wouldn't trip over the ^_[A-Z] reserved space; however, numerous projects would trip over the reservation of any identi…

That would require changing every single existing header that currently contains reserved identifiers. Do you have any idea how much work that is? Even if you could somehow magically enumerate and alter them all - and test them, since the necessary renaming of identifiers in non-system headers might introduce a bug - legacy versions would be floating around for years.

Conceptually a warning is a nice idea, but it just isn't practical.

Re: ISO C is increasingly moronic

#157

Post by SomeOtherGuy »

ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

>Doesn't seem like the author really thought some of this through

Yeah, he says the same thing at the bottom:

>Poul-Henning

I guess it would be nice if he warned you up front, but at least he does include the warning.

Re: ISO C is increasingly moronic

#159

Post by groovy2shoes »

ajross wrote: post #41
reacweb wrote: post #38

Earlier quoted context omitted.

breakage of pre-existing code is really a poor excuse for such craziness. Seriously do you prefer an error message during compilation that is easy to understand and not so difficult to fix or a language so tricky that nobody can read the huge reference manual. I fully agree with the author. Seek and hang the culprits !

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses .

One of those carcasses happens to be C99.

Re: ISO C is increasingly moronic

#160

Post by tptacek »

haberman wrote: post #139
tptacek wrote: post #123

Earlier quoted context omitted.

In the sense that your parsing strategy influences your I/O strategy and, in particular, may incur extra copies, I buy this. The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more. I've done a fair bit of high performance network code (not for Amazon or Google, but, for instance, for code watch…

> The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more. I can speak better to Google, since it's my more recent experience. Google's internal data format is Protocol Buffers (and all the code is open-sourced, as you probably know). The C++ code that is generated to parse Protocol Buffers is f…

Bad-ass. I'm happy to be wrong if it solicits comments like this. :)
Post reply on HN