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

A critique of "How to C in 2016"

github.com

Post reply on HN
Print view View original

161–170 of 181 posts

Re: A critique of "How to C in 2016"

#161

Post by hamiltonkibbe »

lultimouomo wrote: post #102
hamiltonkibbe wrote: post #93

Earlier quoted context omitted.

You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you…

> I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable I don't think that's fair at all. It's well written and perfectly portable, under that assumption . If that assumption happens to hold for all the systems that…

Maybe "poorly-written" was a bit strong, but if you're making that assumption, you are by definition relying on un- or implementation-defined behavior.

The fact that a char is stored on silicon in the lowest 8 bits of the smallest addressable memory space really makes no difference. char arrays act just like they do on any other platform.

There aren't a lot of libraries floating around that you'd be using on a DSP, aside from vendor-supplied ones. Generally you're using a DSP because you have specific signal processing needs and power and cost requirements, which are pretty orthogonal to the requirements of most desktop development. As such, there probably isn't a huge amount of overlap between the libraries you'd be using.

Another reason for that being that quite a bit of the time you're not running an OS. There is no transparent abstraction layer that magically maps an ADC IC connected via SPI to an arbitrary group of remappable peripheral pins to /dev/adc0. I think that's kind of the big disconnect between desktop and embedded, so much of the code is specific to the processor/DSP and the arbitrary external hardware connected to it. You can't take code written for a DsPIC that uses the internal ADC and run it on an MSP430 with an internal ADC for the same reason. There isn't necessarily a POSIX layer, so it's a very different beast than writing code that works on UNIX, Linux, and OSX. Look at the Linux source and see how many architecture-specific files there are in each architecture's folder. That's what you need to get a consistant interface across different processors. Without all that non-portable abstraction code running below yours, posix- and standard-compliant code still wouldn't be portable.

As far as using the same standard, I think it's a good thing that there is agreement on what the effect of a given construct is. I think the issue comes when you expect that code written for one platform to just work(TM) on another.

Re: A critique of "How to C in 2016"

#162

Post by fithisux »

woodman wrote: post #144
fithisux wrote: post #105

The discussion usually boils down to a. We need a better C b. We need better programmers. Personally I believe C tries to hard to be high level instead of what it really is. Newer revisions should try to make it lower level. For example I never could understand why we need enums. Enums are very useful for Java or Golang which are high-level. C never needs enums. Why should I ever put const in the argument of a functi…

> For example I never could understand why we need enums. > Why should I ever put const in the argument of a function? Reducing potential state and conveying programmer intent. Both lead to safer and more performant code (by way of compiler optimizations).

What you say is incompatible with the "Cross-platform assemble", simple language ideals.

If that was the intent why not throw namespaces and other goodies in?

Re: A critique of "How to C in 2016"

#163

Post by hamiltonkibbe »

lultimouomo wrote: post #103
dietrichepp wrote: post #62

Earlier quoted context omitted.

I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."

That doesn't touch my argument. If you're code is meant to run on DSPs it will already enforce all the relevant rules; if not, you'll have to port it anyway. It's not like your compiler backend that outputs code for DSPs will just compile standard C.

All the code using non-optional c constructs will compile. If you're doing something that uses floating point math and expecting to run it on a 16-bit DSP, you're probably doing something wrong. The biggest hurdle isn't compiler support, rather converting all the floating point operations to fixed-point and ensuring that you have enough resolution such that rounding errors don't make your IIR filter unstable for example. That's really outside the scope of the discussion though, as that is just an aspect of practical DSP using fixed point math.

Re: A critique of "How to C in 2016"

#164

Post by NoGravitas »

omgtehlion wrote: post #58
pjmlp wrote: post #25

Earlier quoted context omitted.

See, that is the problem right there. Even if one does find such competent programmers, I doubt they the way C culture works it would help. Most C devs I have met, if given a memory safe systems programming language like Modula-2 or Rust, would just use SYSTEM or unsafe {} everywhere without any proof of a profiler if it really matters to the customer. As for being available everywhere, that is an historical accident…

heck, even in c# I use unsafe{} here and there ((

))

Re: A critique of "How to C in 2016"

#165

Post by GregBuchholz »

benbenolson wrote: post #115
appleflaxen wrote: post #96

> The first rule of C is don't write C if you can avoid it. My C skills are non-existent, but it occurs to me while reading the response that when two people who have so carefully considered the subject can arrive at such different places... then yes, you probably shouldn't write C if you can avoid it.

C is the only language that will run on certain strange systems, and that is the only reason that most of these quibbles even matter. It's more of an argument of "What is the most portable way to write C?" C is a very small and elegant language that never lies to you. There aren't any useless functions that are specific to one use case, and things that you don't really, really need are simply left out of the language…

>C is a very small and elegant language that never lies to you.

I've liked:

http://www.gowrikumar.com/c/index.php

..and...

https://www.google.com/search?q=expert+c+programming+deep+c+...

Re: A critique of "How to C in 2016"

#166

Post by Solarsail »

GFK_of_xmaspast wrote: post #158
lultimouomo wrote: post #131

Earlier quoted context omitted.

> Because what's going to happen two years down the road when you need to get that code working on a different platform. And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes? Here's the thing: C is already built on assumptions, which might or might not hold for a specific platform. Choosing which assumptions we ho…

If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.

Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose...

Re: A critique of "How to C in 2016"

#167

Post by GFK_of_xmaspast »

Solarsail wrote: post #166
GFK_of_xmaspast wrote: post #158

Earlier quoted context omitted.

If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.

Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose...

Your own link explains how easy it is to get different results even on the same hardware depending on compiler flags.

Re: A critique of "How to C in 2016"

#168

Post by dllthomas »

LeonidasXIV wrote: post #127
benbenolson wrote: post #111

Earlier quoted context omitted.

I'm sorry, but is this comment a joke? Have you ever read "The C Programming Language", and seen how simple C is? These arguments that the two OPs are having are important, but only when faced with obscure architectures that nearly nothing but C will run on. Conversely, JavaScript's failures are not because of the wide variety of architectures that it supports (a tiny fraction of C's), but instead on the monolithic a…

Have you read "Expert C Programming: Deep C Secrets"? That book will show you that a simple language does not mean that programming in it is simple. On a related note, I believe "The C Programming Language" is not a good book for the realities of 2016.

There's two recommendations here for "Expert C Programming".

I read it cover to cover fairly recently; I don't think there was really anything I disagreed with, but there also wasn't anything I didn't already know and wasn't already practicing. While I've been programming C a while now, that surprised me. I've decided that the book isn't bad but is probably more "help get you from beginner to intermediate" than "help get you from intermediate to expert", much less something of use to an expert (sadly, in my position).

An alternative interpretation would have it that there is just not enough to say about C that an expert-level book is likely to say things a C expert would not already know. That would argue against your point about the complexity of C. As I say, though, this has not been my conclusion.

[1] Except that Eliza was named after the character from Pygmalion - I'd somehow never put that together!

Re: A critique of "How to C in 2016"

#169

Post by snakeanus »

lmm wrote: post #146
snakeanus wrote: post #137

Earlier quoted context omitted.

ehmmmm standard C has floats and doubles. so they are valid C >Why assuming that unsigned integers overflow to 0 is fair because the standard says so In your other posts I noticed some more misunderstanding of the C standard, so I suggest not to talk about things you are not aware about.

> ehmmmm standard C has floats and doubles. so they are valid C Sure, but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation. I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying t…

>but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation.

No, not really. This reminds me the common "you can't write anything serious in C without undefined behaviour" bs.

However, if you DO have a real need of IEEE-compatible floats for whatever reason, then there is nothing wrong with checking __STDC_IEC_559__ and reporting an error if it is not defined. In fact, if you are using a system that doesn't have an IEEE float implementation, using another language won't save you.

>I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying to.

Feel free to show me what I misread. I would also suggest that you try to read the nonsensical bullshit he has been spreading in this thread.

Re: A critique of "How to C in 2016"

#170

Post by onetimePete »

logicallee wrote: post #65
dietrichepp wrote: post #41

Earlier quoted context omitted.

This comment only fans the flames of language war, it doesn't contribute to the discussion.

This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language. You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you. I've had…

That is the basic problem with show and tell with a low-level language. You either have a simple working example, with a dozen edge cases not caught. Or you have the usual check-hedge growth around Input and Output - which makes the Code hard to read. They chose the correct examples for the task- thus they where right, and your expert was wrong.
Post reply on HN