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

So you think you know C? (2016)

wordsandbuttons.online

Post reply on HN
Print view View original

221–230 of 344 posts

Re: So you think you know C? (2016)

#221

Post by pjmlp »

cperciva wrote: post #215
WalterBright wrote: post #160

Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…

Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.

Because when you work on a team, not everyone is a C Gandalf, probably not even yourself a couple of months later when fixing a bug with everyone screaming that the system is down.

Exaggerating here, but rule of thumb is that it takes twice to debug as it takes to write it, so how long do you want to take to do maintenance fixes?

Re: So you think you know C? (2016)

#222

Post by cperciva »

xondono wrote: post #218
cperciva wrote: post #215

Earlier quoted context omitted.

Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.

Can you assure that your preprocessor tricks always generate compliant code? For me writing embedded code is the ultimate test for your programming skills, since a lot of C toolchains for embedded devices (as in bare metal embedded) are unstable, only almost compliant and full of weird behaviors and hacks.

Here's an example: https://github.com/Tarsnap/libcperciva/blob/master/datastruc...

As long as you invoke use it properly, e.g.

ELASTICARRAY_DECL(PTRLIST, ptrlist, void *);

there's no way it will create non-compliant code.

Re: So you think you know C? (2016)

#223

Post by xondono »

dvdbloc wrote: post #186
pcwalton wrote: post #179

Earlier quoted context omitted.

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible. (In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious a…

What would we write drivers in then if C was obsoleted?

Is still a little early, but as someone who works at the bare metal level, Rust shows early promise.

The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast.

In any case, firmware behaves a lot like banking software, language change will take time

Re: So you think you know C? (2016)

#224

Post by cperciva »

pjmlp wrote: post #221
cperciva wrote: post #215

Earlier quoted context omitted.

Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.

Because when you work on a team, not everyone is a C Gandalf, probably not even yourself a couple of months later when fixing a bug with everyone screaming that the system is down. Exaggerating here, but rule of thumb is that it takes twice to debug as it takes to write it, so how long do you want to take to do maintenance fixes?

rule of thumb is that it takes twice to debug as it takes to write it

Ok, so... macros which let me write code faster should help with debugging time as well? ;-)

Re: So you think you know C? (2016)

#225

Post by pjmlp »

pcwalton wrote: post #179
WalterBright wrote: post #160

Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible. (In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious a…

Same here.

C++ only when Java or .NET need it's assistance, or integration with OS APIs that require C++ (NDK, WinUI, DX).

Then C only when there is no alternative (customer wants it, we only do C here, required lib is C only e.g. SDL, ...).

It is an herculean project, but maybe some day LLVM could be rewritten into something else. After all it isn't the first compiler stack, just the one that got most famous.

Re: So you think you know C? (2016)

#226

Post by pjmlp »

dvdbloc wrote: post #186
pcwalton wrote: post #179

Earlier quoted context omitted.

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible. (In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious a…

What would we write drivers in then if C was obsoleted?

Apple says the future is C++ and Swift.

Microsoft says the future is a mix of constrained C++ (Core Guidelines), Rust and AOT C#.

Google says the future is C++ and Java (as of Treble) on Android, with Go, C++ and Rust on ChromeOS and Fuchsia.

ARM says C++ on mbed.

GenodeOS says C++ and Ada.

Newton, Symbian, Bada and BeOS used C++.

C is married with UNIX, they were born to each other, other OSes have long followed other paths.

Re: So you think you know C? (2016)

#227

Post by pjmlp »

Athas wrote: post #193
dvdbloc wrote: post #186

Earlier quoted context omitted.

What would we write drivers in then if C was obsoleted?

The Oberon system has drivers in, well, Oberon (which is a high-level Pascal successor with garbage collection). Low-level memory access is done through magical peek/poke functions, in which all the dirtyness is concentrated (and these might not be allowed in user programs - not sure). This means the language as a whole is not littered with unsafe pointers just to service the tiny subset of programs that need them.

And it is used commercially.

Astrobe has been selling development kits for ARM based boards for years now.

Re: So you think you know C? (2016)

#228

Post by mhh__ »

rramadass wrote: post #214
mhh__ wrote: post #183

This is the language we still choose to trust our credit cards with.

I hope you were joking. This is just a "gotcha" quiz and not relevant at all.

I'm almost not. I made the point because this level of ambiguity and "do it yourself" is consistent throughout the language.

I know why we still use C, but the use of C is inherently prone to security problems.

C does not provide bounds checking by default, so it can be forgotten (Heartbleed) and the lack of either static checking, RAII or garbage collection (Not as a library e.g. Boehm) makes memory corruption all but inevitable.

Re: So you think you know C? (2016)

#229

Post by ogoffart »

0815test wrote: post #206
ogoffart wrote: post #178

Earlier quoted context omitted.

And that's why people claiming that C++ is more complicated than C because it has an even bigger specification miss the point. What counts is how easy to use in practice. You can get along just fine in C++ without knowing the exact aliasing rules from C or or how to specialize a template. What matters is that the extra features of C++ makes actual programming simpler, not harder. (for example destructor (RAII), stand…

> You can get along just fine in C++ without knowing the exact aliasing rules from C Nope, you can't. These are exactly the things that introduce undefined behavior (i.e. total breakage) if you aren't very careful about what you're doing at all times. Don't take my word for it, check out what the C++ designers themselves state about the issue in the C++ Core Guidelines. C/C++ is far from simple, and thinking that you…

You are absolutely right, but my point is that when you do modern C++, in the application code, it is very unlikely that you need to use reinterpret_cast in your code, and therefore you don't need to know all the subtlety about it.

So despite C++ being more complex than C, if you limit yourself to some practical subset, it is actually easier than C.

Re: So you think you know C? (2016)

#230

Post by pjmlp »

saagarjha wrote: post #197
pcwalton wrote: post #188

Earlier quoted context omitted.

Not lead designer :) But yes, Rust, or even in userspace, as newer and/or more microkernel-ish OS's allow for. Apple is doing work to allow drivers to be written in Swift...

I believe DriverKit is still C++.

Just some parts of it.

Some device classes (not to mix with OOP ones) can only be programmed with C++, while others can be developed in any compiled language able to link to the OS APIs.

There is a WWDC session on it.

Post reply on HN