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

The Unreasonable Effectiveness of C

damienkatz.net

Post reply on HN
Print view View original

191–200 of 394 posts

Re: The Unreasonable Effectiveness of C

#191

Post by 16s »

AshleysBrain wrote: post #31

I always get bashed for saying I like C++, but I genuinely don't get how C programmers manage without code like this: std::map > foo; One line and you've set up a nontrivial data structure with automatic memory management. No macro horrors (which are a diabolical way of implementing what C++ templates do well). Since you can code like C in C++, I'm not sure why more people don't use C-with-templates as a programming…

I up-voted you because I agree with you. And let me tell you that in the "real world" of systems programming (where stuff gets done), C++ is widely used and loved by engineers. It's not hip and popular to say that, but it's true from what I have seen over the last 15 years.

Re: The Unreasonable Effectiveness of C

#192

Post by dspeyer »

pimentel wrote: post #111

"C is a weak, statically typed language" Wouldn't that imply that a variable of one type could be coerced into another type? I would say C is strong typed...

    int i;
    float f = *(float*)&i;
I'm not saying you should do this, but you can.

Or to use an example the author didn't regret:

    struct foo {
      int a;
      int b;
      int c;
    }__attribute__((packed));

    void print(foo* f) {
      int *p = f;
      int i;
      for (i=0; i

Re: The Unreasonable Effectiveness of C

#193

Post by dspeyer »

madhadron wrote: post #53

Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…

Is there any way for software, even in assembly, to make intelligent use of on-cpu ram caches? I thought they were completely abstracted by the hardware.

Re: The Unreasonable Effectiveness of C

#194

Post by aidenn0 »

madhadron wrote: post #104
DigitalJack wrote: post #74

Earlier quoted context omitted.

I'm pretty ignorant about this stuff, so please don't think I'm trolling. I'm confused when you speak of a virtual machine with regard to C... can you explain what you mean by this? I had to wikipedia the Burroughs machine. I guess the big deal is that it's a stack machine? It looks very interesting and I plan to read more about it. But I guess I don't understand why that is a hindrance to C. The JVM is a stack machi…

The Burroughs was a stack machine, but that's only the beginning. Look at how it handled addressing hunks of memory. Bounds checked memory block references were a hardware type, and they were the only way to get a reference to a block of memory. So basically, null pointers didn't exist at the hardware level, nor out of bounds writes to arrays or strings. Similarly, code and data were distinguished in memory (by high…

"C defines a virtual machine consisting of a single, contiguous block of memory with consecutive addresses"

This is 100% false. The C standard makes no mention whatsoever of memory. I don't know much about the burroughs machine, but it sounds like it would map very well to the C virtual machine:

C permits an implementation to provide a reversible mapping from pointers to "sufficiently large integers" but does not require it.

A pointer to an object is only valid in C (i.e. only has defined behavior) if it is never accessed outside the bounds of the object it points to.

Converting between data pointers and function pointers is not required to work in the C standard either.

C does require that you have a NULL pointer that has undefined behavior if you dereference this, but this could be trivially done by the runtime by allocating a single unit of memory for it.

Re: The Unreasonable Effectiveness of C

#195

Post by chadzawistowski »

alexkus wrote: post #18
henrik_w wrote: post #10

Earlier quoted context omitted.

Agree completely about zero build time! I've been using IntelliJ IDEA for Java development for the last 4 years, and before that I used C and C++ using Emacs for 7 years. I am way more productive in IntelliJ IDEA than I was before. One reason is the instant feedback on syntax errors when I type the code. I don't need to compile to see them, as I used to in C and C++. Another reason is the navigation support you get i…

That's the IDE not the language. Java, itself, does not highlight your syntax errors. Nor does C. There are IDEs out there that will do exactly the same thing for you for your C code.

The difficulty of writing static analysis software does depend on the language, though. In Visual Studio, for example, intellisense and autocompletion are vastly superior in C# compared to C++.

As a matter of interest, which C IDEs are you referring to? I'd like to check them out.

Re: The Unreasonable Effectiveness of C

#196

Post by Locke1689 »

groby_b wrote: post #189
madhadron wrote: post #104

Earlier quoted context omitted.

The Burroughs was a stack machine, but that's only the beginning. Look at how it handled addressing hunks of memory. Bounds checked memory block references were a hardware type, and they were the only way to get a reference to a block of memory. So basically, null pointers didn't exist at the hardware level, nor out of bounds writes to arrays or strings. Similarly, code and data were distinguished in memory (by high…

No, C does not define a single contiguous block of memory with consecutive addresses. It _does_ qualify that pointers are scalar types, but that does not imply contiguity or consecutive addresses (with the exception of arrays) There is no requirement in C that you be able to execute data. You certainly could have a C implementation that bounds-checks strings and arrays. (See e.g. http://www.doc.ic.ac.uk/~phjk/BoundsC…

I would argue that C's problem is not that it's too strictly defined, but that it's too poorly defined. An in-depth look into all the cases of undefined behavior in C will show what I mean.

You want to really understand C? Read this[0]. John really understands C.

[0] http://blog.regehr.org/

Re: The Unreasonable Effectiveness of C

#198

Post by xyzzy123 »

rayiner wrote: post #177
xyzzy123 wrote: post #171

Earlier quoted context omitted.

Well that is how memory, the hardware we have and also all normal operating systems work, but if you want to discuss other stuff we can do that too :) Try serious debugging and you will find that all your preconceptions are confirmed, yet it's still hard to know WTF is going on.

The "memory is just a giant array of bytes" abstraction hasn't been true ever since DRAM has existed (because DRAM is divided into pages), ever since caches were introduced, and certainly isn't true now that even commodity mulch-processors are NUMA with message-passing between memory nodes.

Look if we want to be super anal about shit all memory is slowly discharging capacitors with basically random access times based on how busy the bus circuity is with our shit this week. It turns out that memory is really complicated stuff if you look at it deeply, but the magic of modern computer architecture is that you get to (hopefully) keep your shelf model for as long as you can. If you were to try to model actual memory latency: here's a shortcut: you can't. That's why everyone bullshits it.

Re: The Unreasonable Effectiveness of C

#199

Post by jasonkostempski »

geophile wrote: post #81
BenDaglish wrote: post #75

Earlier quoted context omitted.

I have very much the same pre/history, along with years of Perl. Then I discovered Go, and can't recommend it highly enough for exactly the reasons and specific case you state.

I attended a tutorial on Go, and while I liked much of what I heard, the tutorial was so poorly done that I did not leave with a good high-level understanding. I also left with the impression that it is very early days with Go, in the sense that several parts of the language are evolving. (Or maybe I have this impression because the presenter loved diving into ratholes.)

If you have an hour go through http://tour.golang.org/#1. If you're like me and can't enjoy a new language without connecting it to the network and passing some JSON around, check out http://golang.org/doc/articles/wiki/ and take a look at http://golang.org/pkg/encoding/json/#Marshal (if, also like me, you're picky about field name casing, pay attention to the little bit about `json:"myName"`)

Re: The Unreasonable Effectiveness of C

#200

Post by asveikau »

cageface wrote: post #2

C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…

As someone who's happy writing C, has written a lot of C at work and at home, I have to say "C fad" sounds a bit weird.

What I see talking to people and looking at forums (this one for example) is the exact opposite of a C fad. Frankly I wish it were the other way. I encounter fewer and fewer people with C knowledge, and especially fewer people who say they are happy writing C. New college grads sure as hell don't graduate in large numbers knowing C, even if a good chunk of them can churn out acceptable Java.

Post reply on HN