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

To become a good C programmer (2011)

fabiensanglard.net

Post reply on HN
Print view View original

111–120 of 135 posts

Re: To become a good C programmer (2011)

#111

Post by boomlinde »

earenndil wrote: post #42
xscott wrote: post #30

Earlier quoted context omitted.

The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argu…

What I wonder is, why didn't they add new *printf functions? So you could say 'printf("int64: %d64", x)'

Backward compatibility. Your example would impose additional constraints on the %d specifier that would likely break existing code. What if you want an int immediately followed by literal ”64”?

Re: To become a good C programmer (2011)

#112

Post by markus_zhang »

yters wrote: post #93
markus_zhang wrote: post #86

I think for us laymen, the most difficult thing is to find a good reason to use C frequently. I have a few "legitimate" (in the sense that C is actually suitable for those) non-embedded projects that I'd like to take on in the future when I have time to pick up C: 1 - Recreate some of the Linux command line tools, including a command line interface similar to BASH; 2 - Implement a fully functional compiler or byte-co…

C + knowing the Linux API and what is done in kernel vs user space can lead to very efficient Linux software. Since much consumer software these days is a webapp with a Linux backend, this sort of embedded optimization can make good consumer sense.

It's a pity that it's almost impossible for a non programmer to find a C/C++ job nowadays. Much of the deeper knowledge takes too much time and effort to master from outside of the field so I guess most people don't go this way.

Re: To become a good C programmer (2011)

#113

Post by zelly »

wwweston wrote: post #28

One of the things I tend to think about these days is return on investment. I spent several years at the beginning of my career being a bad and then mediocre C programmer, and once I found a few other languages, I got the sense that being a mediocre-to-good programmer in these languages would be much easier, and that seems to have been borne out. Late into a career investing in other areas, what's the advantage of be…

> Late into a career investing in other areas, what's the advantage of becoming a good C programmer? Especially in a time where Rust and Go are viable options?

It is the most popular programming language. There is a lot of code written in it. Most jobs involve maintaining extant code. So it's good for that. It's safe to say there will be a need for C programmers for the next 100 years.

Re: To become a good C programmer (2011)

#114

Post by zelly »

zenhack wrote: post #58
jason0597 wrote: post #31

Earlier quoted context omitted.

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day! Go is probably never going to run on microcontrollers due to its very big overhead. C perfectly ma…

> Every single design decision about C was made with the computer in mind. The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues: First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because th…

Yes, the "high performance" argument for C is a joke at this point. Modern programs are not bound by ALU heavy cycles. It's all about cache locality. C does not help besides forcing you, out of lack of expressiveness, to stick to simplistic data structures without too much indirection. Where it fails is at being unable to inline well (sans spooky LTO magic) because it effectively has no type system, bottlenecking your instruction cache where C++/Rust/Java would create optimized code. If C really were made to map to hardware, it would have a better story (at the language level) for heterogenous computing, SIMD, vectorization, etc. But instead vendors had to create DSLs for these things, because of course the base language doesn't support it, because it's not low level.

Being tedious and almost as unexpressive as asssembly does not make a low level language.

C doesn't map to the machine and never did. Compilers and chip vendors map to C.

Further reading: https://queue.acm.org/detail.cfm?id=3212479

Re: To become a good C programmer (2011)

#115

Post by GuB-42 »

edoo wrote: post #59
GuB-42 wrote: post #49

Earlier quoted context omitted.

C is still king in embedded systems. It is also great at making you aware of the machine. In C, very little is happening behind the scene. If you want something to happen, you need write some code. Objects will not initialize themselves, allocated memory will not free itself, no smart reference mechanisms, just explicit pointers. This understanding of the machine will help understanding why higher level langages beha…

Language fluency is very important but real programming is program architecture. Learning C++ or spending time with object oriented paradigms in general will boost your C abilities.

I agree with you 100%. Learning an object oriented language will make you a better C programmer just as learning C will make you a better, say, Java programmer.

My point is that learning C is definitely worth it. Not only it has real life applications but it will help you become a better programmer in general. But it doesn't mean you should limit yourself to C. Go and Rust are good too, and even the most hated languages (ex: PHP) can teach valuable lessons.

Re: To become a good C programmer (2011)

#116

Post by BubRoss »

UncleMeat wrote: post #82
porknubbins wrote: post #74

Earlier quoted context omitted.

True, but if it is still possible to be a C programmer who can more or less imagine what assembly will be generated (at lower levels of optimization at least) by their C code, then isn't the real issue that x86 assembly abstracts away a lot of hardware info about caches, pipelines, microcodes etc? In that case how can a low level exist on x86?

I'm not sure that's true. There was a highly upvoted post recently on both HN and /r/programming that claimed to have a better sorting algo than libc's sort. After hundreds of comments across both forums, looking into compiler explorer showed that the key difference was inlining. As a C++ person, basically all micro-optimizations start at "look at the damn assembly" since people really suck at predicting what code wi…

How does inlining happening in C++ mean that the asm in C isn't predictable?

Even with inlining the point is mostly the same - there aren't small program changes that lead to big changes in what is generated.

Re: To become a good C programmer (2011)

#117

Post by madmax96 »

naasking wrote: post #98
nomel wrote: post #61

Earlier quoted context omitted.

> CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything > they don't show up in the language at all... requires knowing things that the code wouldn't suggest at all I'm utterly confused at this. It's trivial to layout memory as you please, where you please, very directly, in C. Set a pointer to and address and write to it. Better yet, I can define a packed struct th…

> It's trivial to layout memory as you please, where you please, very directly, in C It wasn't trivial before fixed width integral types, which is fairly recent in C terms (C99), and it's still far more complicated than it needs to be. Furthermore, the fact that C is the defacto language of performance means that our hardware has been constrained by needing to run C programs well in order to compete. Think of all the…

>see how powerful and versatile GPUs have become because they didn't carry that legacy.

GPUs are the best example for why C is a good lower-level high-level language, seeing how CUDA is programmed in C/C++.

Do you have any examples of architectures that could exist if only they weren't constrained by legacy C?

Re: To become a good C programmer (2011)

#118

Post by jason0597 »

manfredo wrote: post #44
jason0597 wrote: post #31

Earlier quoted context omitted.

Rust isn't viable for embedded platforms, at least not yet. It's not as easy to compile it to the most obscure ISAs as C, and the little support it has for stuff like STM32 is restricted to just that group of microcontrollers and doesn't support the entire ARM range. Maybe in the future? I'm looking forward to that day! Go is probably never going to run on microcontrollers due to its very big overhead. C perfectly ma…

> Go is probably never going to run on microcontrollers due to its very big overhead. My employer runs go on micro controllers. Definitely suboptimal, but as long as the cost of increasing hardware capacity to accommodate Go is feasible then it's a viable option.

Isn't it counter productive to go out of your way to find better hardware to fit your language choice? Why not choose a lighter language?

Re: To become a good C programmer (2011)

#119

Post by nwellnhof »

dfox wrote: post #23
hazeii wrote: post #19

Earlier quoted context omitted.

Really? No longer an MS user but occasionally my code gets ported to Windows so would like to know more.

MSVC in C mode is essentially C89 plus extensions needed to compile C++/C99-isms present in Windows SDK and DDK headers. And Microsoft seems to be mostly interested in whether the compiler is able to build NT kernel and drivers and nothing much else.

That's not true for quite some time. Visual Studio 2013 added many C99 features that aren't in C++ like compound literals or designated initializers.

Re: To become a good C programmer (2011)

#120

Post by naasking »

madmax96 wrote: post #117
naasking wrote: post #98

Earlier quoted context omitted.

> It's trivial to layout memory as you please, where you please, very directly, in C It wasn't trivial before fixed width integral types, which is fairly recent in C terms (C99), and it's still far more complicated than it needs to be. Furthermore, the fact that C is the defacto language of performance means that our hardware has been constrained by needing to run C programs well in order to compete. Think of all the…

>see how powerful and versatile GPUs have become because they didn't carry that legacy. GPUs are the best example for why C is a good lower-level high-level language, seeing how CUDA is programmed in C/C++. Do you have any examples of architectures that could exist if only they weren't constrained by legacy C?

> GPUs are the best example for why C is a good lower-level high-level language, seeing how CUDA is programmed in C/C++.

CUDA is not C or C++. That you can program GPUs in a C/C++-like language does not entail that C/C++ is a natural form of expression for that architecture.

> Do you have any examples of architectures that could exist if only they weren't constrained by legacy C?

Turing tarpit means that every architecture could be realized, but that doesn't make it a particularly efficient or a natural fit for the hardware.

For instance, consider that every garbage collected language must distinguish pointers from integer types, but no such distinction exists in current hardware, and the bookkeeping required can incur significant performance and memory constraints (edit: C also makes this distinction but it doesn't enforce it).

Lisp machines and tagged hardware architectures do make such a distinction though, and so more naturally fit. With such distinctions, you could even have a hardware GC.

Post reply on HN