C Craft • Hacker News Board

Re: C Craft

#51

Post by holygoat » Sat, Dec 19, 2009, 1:50 AM UTC

jlangenauer wrote: post #49

Locke1689 wrote: post #20

Earlier quoted context omitted.

His warning against using #ifdef is also misplaced. I have written assembler (GAS) using the GAS x86 asm preprocessor to write portable x86/x86-64 assembly code in one file. Far simpler and shorter than writing the same code in two files. Basically, whenever he says "never" do something he means he doesn't like to do it. For example, his answer to not having a multi-level function break is a nested helper function. G…

I'm curious about this too - why is mmap so bad?

It's not always bad -- very often it's the right thing to do. Just not "always".

Re: C Craft

#52

Post by holygoat » Sat, Dec 19, 2009, 1:53 AM UTC

Locke1689 wrote: post #50

mbreese wrote: post #26

Earlier quoted context omitted.

I'm curious: are the standard IO functions that much more efficient than a mmap'd file? What makes you choose one over the other? I usually just use standard IO, unless I have a large file that might be randomly accessed by multiple processes. In that case I'll use a mmap. But, I don't code in C very much anymore, so I was wondering how much of a difference there really is.

Mostly because mmap is not portable. If you're writing a Linux specific version of your code then mmap is fine. If you foresee running your code on other platforms then you shouldn't use it. Basically, there's a reason why it's called "standard" IO. Generally you shouldn't use system calls unless you are absolutely, 100% sure that your code will only ever need to work on one system.

I've worked on a project that successfully uses memory mapping on all the major OSes.

mmap is (allegedly) portable across Unixes:

http://opengroup.org/onlinepubs/007908775/xsh/mmap.html

and you can do the same thing (with a few more hoops) on Windows.

Re: C Craft

#53

Post by gprisament » Sat, Dec 19, 2009, 1:57 AM UTC

I'm a huge proponent of C programming, but I have to say this article is not very compelling. Object-oriented programming is just as important in C as it is in C++, it's just the syntax is different.

I think my high regard for C comes from work experience: the C projects I've worked on have been less of disastrous messes than the C++ projects I've worked on. It's hard to pinpoint why, because on a small scale C++ is very nice. But I've noticed that once > 10 people get involved, C++ projects become more bug-prone and difficult to understand and fix.

I especially love ADTs in C. C++ encourages you to declare public and private and protected class members in a single class declaration in a single header file. Yes, you can work around this (ie, have a single private member m_priv), but I haven't seen it done much in practice. In C, on the otherhand, it's much easier to separate implementation details from the public interface. Put "typedef struct Foo * FooHandle" in the public header and the structure definition in the .c file. This is common practice in C and very elegant. As a coworker once put it, "I don't like the way people put private members in header files in C++... it's like seeing the class's underwear".

Re: C Craft

#54

Post by Locke1689 » Sat, Dec 19, 2009, 3:21 AM UTC

holygoat wrote: post #52

Locke1689 wrote: post #50

Earlier quoted context omitted.

Mostly because mmap is not portable. If you're writing a Linux specific version of your code then mmap is fine. If you foresee running your code on other platforms then you shouldn't use it. Basically, there's a reason why it's called "standard" IO. Generally you shouldn't use system calls unless you are absolutely, 100% sure that your code will only ever need to work on one system.

I've worked on a project that successfully uses memory mapping on all the major OSes. mmap is (allegedly) portable across Unixes: http://opengroup.org/onlinepubs/007908775/xsh/mmap.html and you can do the same thing (with a few more hoops) on Windows.

There's no guarantee that it will be portable and act the same (even across the POSIX systems). I'm not saying you should never use it, just that it shouldn't your automatic answer to everything.

Re: C Craft

#55

Post by jrockway » Sat, Dec 19, 2009, 6:22 AM UTC

jacobolus wrote: post #48

jrockway wrote: post #31

Earlier quoted context omitted.

My comment should have read, "there isn't much good about C."

Really, you should have just skipped it, because it’s a tired cliché that adds nothing to the discussion. There’s plenty to learn from C, if only in how to drive adoption of a language by making it an indispensable part of a useful system (in this case, UNIX). But the other side of this argument is also pretty tired after decades, so I’ll leave it there.

Marketing a language is of little use to hackers writing internal applications. What matters is good programming practice, which is often ignored in favor of "but ls uses it". This is not good.

Re: C Craft

#56

Post by kelnos » Sat, Dec 19, 2009, 9:32 AM UTC

holygoat wrote: post #52

Locke1689 wrote: post #50

Earlier quoted context omitted.

Mostly because mmap is not portable. If you're writing a Linux specific version of your code then mmap is fine. If you foresee running your code on other platforms then you shouldn't use it. Basically, there's a reason why it's called "standard" IO. Generally you shouldn't use system calls unless you are absolutely, 100% sure that your code will only ever need to work on one system.

I've worked on a project that successfully uses memory mapping on all the major OSes. mmap is (allegedly) portable across Unixes: http://opengroup.org/onlinepubs/007908775/xsh/mmap.html and you can do the same thing (with a few more hoops) on Windows.

Many people may not care, but mmap() often doesn't exist on hardware without a MMU.

Re: C Craft

#57

Post by fauigerzigerk » Sat, Dec 19, 2009, 2:30 PM UTC

silentbicycle wrote: post #29

sireat wrote: post #13

C provides my daily bread and I absolutely love the language. That said, sometimes(I mean often) it does hurt when I have to work at a higher abstraction level in some fancier language and I keep thinking on what is going behind the scenes.

Running a profiler can reassure you that while yes, your HLL code may be doing decadently inefficient things for sake of developer convenience, most of the time it has a negligible effect on overall performance. Just rewrite those parts in C if you have to and you can get the best of both worlds.

If only it were that simple. Rewriting in C means a lot more than coding in C. It means that you're dealing with an entirely different deployment scenario and different platform dependencies.

Your build system needs to support it. Your testing procedures need support it. In some cases the platform does not support it at all (Google App Engine).

But most importantly, how many Ruby/Python/PHP developers are able to write safe C code? How many of them would you trust to write server side C code that could bring down the system or introduce hard to find memory leaks?

Re: C Craft

#58

Post by eru » Sun, Dec 20, 2009, 3:44 AM UTC

russell wrote: post #46

stonemetal wrote: post #40

Earlier quoted context omitted.

Perhaps because it isn't a coding issue, it is a design issue and the fact that advocates of any stripe tend to gloss over the problems with whatever they are advocating.

I agree with you, but designs are often constrained by what the tools expose or consider important. Believe me you dont get consulting jobs by saying Java inheritance is over-rated and that maybe more functional and less OO would be a better choice.

Do you want to imply that you get the consulting jobs by saying the opposite --- or by being more intelligent than those statements altogether?

Re: C Craft

#59

Post by eru » Sun, Dec 20, 2009, 3:50 AM UTC

chasingsparks wrote: post #43

The footnote on the entry page is telling: This classic shows why the design of the data structures is the true heart of programming, and why language choice is almost irrelevant. (In hindsight, this is obvious after considering how we program humans: textbooks can be written in any language; the tricky part is presenting the content clearly.) I recently have concluded the same thing. I suppose all programmers reach…

> This classic shows why the design of the data structures is the true heart of programming, and why language choice is almost irrelevant

The `almost' is important. E.g. on the one hand you won't use any of Okasaki's beautiful purely functional data structures in a language without garbage collection like C. And on the other hand you will shy away from data structures that require mutation in a pure language like Haskell.

Re: C Craft

#60

Post by sorbits » Sun, Dec 20, 2009, 5:07 PM UTC

mbreese wrote: post #26

Locke1689 wrote: post #20

Earlier quoted context omitted.

His warning against using #ifdef is also misplaced. I have written assembler (GAS) using the GAS x86 asm preprocessor to write portable x86/x86-64 assembly code in one file. Far simpler and shorter than writing the same code in two files. Basically, whenever he says "never" do something he means he doesn't like to do it. For example, his answer to not having a multi-level function break is a nested helper function. G…

I'm curious: are the standard IO functions that much more efficient than a mmap'd file? What makes you choose one over the other? I usually just use standard IO, unless I have a large file that might be randomly accessed by multiple processes. In that case I'll use a mmap. But, I don't code in C very much anymore, so I was wondering how much of a difference there really is.

I did benchmarks on OS X (10.5) between asynchronous IO, mmap, stdio, and normal unix open/read (disabling caching) — it all came down to about the same after I had fiddled with page size, prefetch size, etc. to optimize each.

This of course depends on your OS (and version). My advice would be to pick API based on “semantics” (or need for portability). If you need to read through a file, use the API intended for that because mmap will not be optimized for that access pattern, but stdio will.