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

141–150 of 175 posts

Re: ISO C is increasingly moronic

#141

Post by [deleted] »

kmm wrote: post #37
phkamp wrote: post #17

Earlier quoted context omitted.

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and ve…

No, you're wrong. The old code will have something like typedef char bool And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h

[deleted]

Re: ISO C is increasingly moronic

#142

Post by mcherm »

alexchamberlain wrote: post #136
kmm wrote: post #37

Earlier quoted context omitted.

No, you're wrong. The old code will have something like typedef char bool And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h

Your attitude is rediculous... Let code break! Make sure there is a __c1x macro and maintained projects will take 30 seconds to fix. Unmaintained projects will die, yay!

I will never purchase a compiler made by you or someone who thinks like you. Sure, it will take 30 seconds to fix your puny 2000 line program that's contained in just a handful of files all of which you control and with no code generation engines or text transformation steps in its build chain. But it wouldn't be that easy for everyone.

Re: ISO C is increasingly moronic

#143

Post by lloeki »

comex wrote: post #118
shadowfox wrote: post #115

Earlier quoted context omitted.

> C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless But doesn't most languages do this? Like java's imports (only a really small subset is included by default) or python. I would have thought that namespace separation is a good thing.

I don't use Java, but Python has a reasonably large set of builtins, and the base modules like os and sys provide a lot more - C would require a longer list of includes. Still, I would like to be able to write something like "mmap::mmap" and have Python automatically figure out what to import, keeping the namespace separation but eliminating the redundancy of explicit imports. (maybe pick something other than double…

    python -m this | head -4 | tail -1
Or use Ruby and ActiveSupport::Dependencies.

Re: ISO C is increasingly moronic

#144

Post by jronkone »

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…

> Plugins for printf()/scanf()?? Not even remotely the kind of thing that needs to be in the core language libraries.

Where then? As far as I can tell, there's no sensible way to extend the functionality of printf()/scanf(), and compilers special-case their format-strings.

Re: ISO C is increasingly moronic

#145

Post by __david__ »

phkamp wrote: post #138
tptacek wrote: post #96

Earlier quoted context omitted.

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…

The reason why struct packing would be a win is probably not performance, but code readability and less bugs. Making be/le/native conversion a job for the programmer is not only error-prone and a waste of time. The compiler could safely optimize the byte-swizzles away on non-arithmetic operations, whereas most programmers tend to covert everything before they start working on it.

Along those lines I wrote a wishful thinking, blue sky blog post a number of years ago: http://porkrind.org/missives/hardware-friendly-c-structures/

Re: ISO C is increasingly moronic

#146

Post by JoshTriplett »

gsg wrote: post #131
aliguori wrote: post #110

Earlier quoted context omitted.

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.

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 identifier containing two adjacent underscores.

Re: ISO C is increasingly moronic

#147

Post by Aissen »

For instance, neither pthreads nor C1X-threads offer a "assert I'm holding this mutex locked" facility. I will posit that you cannot successfully develop real-world threaded programs and APIs without that, or without wasting a lot of time debugging silly mistakes.

It's funny, Alan Cox thinks the same: https://plus.google.com/111104121194250082892/posts/jWjJ9897...

Re: ISO C is increasingly moronic

#148

Post by JoshTriplett »

saurik wrote: post #94
wmobit wrote: post #86

Earlier quoted context omitted.

As if MS will implement C1X. They haven't caught up to the last C standard from 12 years ago

FWIW, Microsoft does not bother with C99 not because they are lazy, but because I honestly never remember C being "the focus" at all: they have been strong backers of C++ since before I started doing Windows development (which itself was back in 1994). They mostly seem to ship a C compiler only because it is often easy to dumb down their C++ compiler to do so (and even then, C++-isms sometimes slip into their C modes…

Fortunately, there exist at least two decent C compilers for Windows that I know of: GCC and ICC. GCC provides the same FOSS compiler available on every other platform, and also allows cross-compiling from FOSS platforms to Windows, which helps when producing cross-platform binaries (to avoid needing to have a Windows system around to build release binaries). ICC doesn't use a FOSS license, and it lags behind GCC, but it does provide a replacement backend for Visual C++, which can make it more usable in some environments. Either one provides much better support for C than the Visual C++ C compiler.

Re: ISO C is increasingly moronic

#149

Post by JoshTriplett »

StephenFalken wrote: post #109
phkamp wrote: post #69

Earlier quoted context omitted.

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 standar…

The post you point at just talks at length about two features: const, which Dennis Ritchie liked but wanted changes to, and noalias, which he wanted to kill off. Const works exactly like he suggested; noalias became "restrict", which seems dead outside of a few standard library functions.

That doesn't seem to me like a pervasive sign of problems with C99. Personally, I find the C99 standard incredibly useful and I can hardly stand to write C code that can't rely on C99. I like having designated initializers. I like having a "bool" type. I like having structure literals, for use in arguments or return types. I like having the family of sized integer types, such as uint32_t and uint64_t. And I like having standardized versions of pre-existing features such as "long long", "inline", and variables declared in the middle of code.

Do you really despise all of those features?

Re: ISO C is increasingly moronic

#150

Post by rbanffy »

phkamp wrote: post #74
nitrogen wrote: post #67

Earlier quoted context omitted.

Do you think a new language (Go, maybe?) will take C's place, given your distaste for ISO's handling of the standard?

I doubt any language will replace C ever, given the penetration it has, but maybe we could get a better C2X than the crap C1X seems to be. It would require a significant fraction of programmers to agree with me that C1X is crap in the first place.

I am mostly a Python programmer who still remembers C and I won't say "crap".

I will, however, say "ugly".

Post reply on HN