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

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

231–240 of 536 posts

Re: The Development of the C Language (1993)

#231

Post by chongli »

iudqnolq wrote: post #224
dzaima wrote: post #204

Earlier quoted context omitted.

If I see `x+y` in C, I know 100% that it'll be ~0-1 instructions, O(1), and will have the lowest latency & highest throughput that a thing can have, i.e. basically completely ignorable for figuring out the perf of a piece of code, or determining what complex things it may do (additionally, it'll hint that the operands are pointers or numbers). For `f(x,y)`, none of those may hold. With operator overloading, f(x,y) an…

However as a novice I found it unintuitive that on an embedded platform without hardware floats x/y will compile but compiles to a polyfill with quite a few instructions.

That’s the only caveat. With operator overloading, the scope for what happens on a given line of code expands dramatically. Now your entire dependency graph is part of the search space. Heck, the operator might not even terminate at all!

Re: The Development of the C Language (1993)

#232

Post by scj »

marcosdumay wrote: post #163
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

> These statements are not true in languages which support operator overloading I guess I will never understand the C and Java developers incredible fear of operator overloading. Do you have the same reaction to user-defined functions? Because they are exactly the same thing. Is it because of the bad type system that won't let you know what operator you are using?

In terms of C functions _typically_ being globally defined, mostly unique identifiers are a good thing in terms of code readability.

Of course, C functions can be passed as variables. Or in a wider scope they might be inline, macros, or ifdef'd to different functions. But those cases are _typically_ recognized as undesirable and avoided.

Java's a bit of a different story, which I can't figure out a good way to explain. It's hard to explain problems in large code bases, as a quick example rarely suffices. I've seen more than one bug caused because foo.bar(qux) called a different method of bar than the original programmer intended (both because foo's bar was overwritten and qux was a different type than expected).

Don't get me wrong, I would use operator overloading in a heartbeat if I was writing code for a math-y CS coding assignment. It's fine for code that will have a lifepsan measured in weeks / months with probably only 2 or 3 people ever looking at it.

Saying what you mean, as clearly and directly as possible, has it's perks in certain applications (large code bases, life critical code bases, code bases that will last for decades with dozens of programmers). Otherwise stated, cases where code is going to be read many times more than written.

To answer your question more directly: User definable functions aren't a problem. Re-definable functions are!

Re: The Development of the C Language (1993)

#233

Post by [deleted] »

haberman wrote: post #182
xscott wrote: post #82

Earlier quoted context omitted.

> Strict aliasing is one of the few tools we have to tell the compiler that aliasing will not occur. I can see the argument, but there's a much better way to indicate what you want with your example: void f(int16_t* a, int32_t* b) { const int16_t a0 = a[0]; for (int32_t i = 0; i Now a clean (well defined) compiler could do what you asked. I've seen other people suggest that UB is a mechanism to have these magical bac…

You are entitled to your opinion. C isn't perfect, but as someone who spends my life trying to optimize the efficiency and code size of critical loops to the max, I like the direction C has gone with UB and optimizations. It's not the right tool for every problem, but for the most size/speed critical code it's hard to beat IMO.

[deleted]

Re: The Development of the C Language (1993)

#234

Post by ntfAX »

pkkm wrote: post #68
babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

[dead]

Re: The Development of the C Language (1993)

#235

Post by oblio »

coliveira wrote: post #126
kaba0 wrote: post #80

Earlier quoted context omitted.

> It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. While it is true to a degree, I would also add that due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not poss…

People who know how to use C rarely if ever have problems with undefined behavior. I particularly have written a huge amount of C code and my bugs have never been related to undefined behavior. This is an idea that has been spread to make people even more afraid of using C/C++. While there is a possibility of finding these problems, in practice it is almost a non-issue.

> People who know how to use C rarely if ever have problems with

I think we call this "No True Scotsman".

In real life lots of people write C because they want to or have to and they generate tons of bugs from bug classes that just aren't present at all in other languages.

Re: The Development of the C Language (1993)

#236

Post by variadix »

tester756 wrote: post #65

I just wish C had better compilers Errors produced by current mainstream compilers are terrible. "Unresolved symbol" being the best they can do is some joke

What error message do you expect the linker to produce when there is a reference to a symbol that it doesn’t find in any of the object files provided?

Re: The Development of the C Language (1993)

#237

Post by dzaima »

iudqnolq wrote: post #224
dzaima wrote: post #204

Earlier quoted context omitted.

If I see `x+y` in C, I know 100% that it'll be ~0-1 instructions, O(1), and will have the lowest latency & highest throughput that a thing can have, i.e. basically completely ignorable for figuring out the perf of a piece of code, or determining what complex things it may do (additionally, it'll hint that the operands are pointers or numbers). For `f(x,y)`, none of those may hold. With operator overloading, f(x,y) an…

However as a novice I found it unintuitive that on an embedded platform without hardware floats x/y will compile but compiles to a polyfill with quite a few instructions.

Right, that's definitely quite a strong point against the C operator-function separation. There can be a good argument made for just not providing unavailable operations as operators. But, still, x/y won't touch any of your memory (assuming a non-broken stdlib), so you're still free to skip over it while scanning for a use-after-free or something.

Re: The Development of the C Language (1993)

#238

Post by jrpelkonen »

chongli wrote: post #175
marcosdumay wrote: post #163

Earlier quoted context omitted.

> These statements are not true in languages which support operator overloading I guess I will never understand the C and Java developers incredible fear of operator overloading. Do you have the same reaction to user-defined functions? Because they are exactly the same thing. Is it because of the bad type system that won't let you know what operator you are using?

I guess I will never understand the C and Java developers incredible fear of operator overloading. The answer is in the sentences right before the one you quoted: Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. Consider the use-cases for C: operating system kernels, hard real-time software, l…

I would say that C macros have inspired the development of concoctions of far greater magical qualities than, say, RAII. C programmers are not immune to violating the principle of least astonishment.

Re: The Development of the C Language (1993)

#239

Post by jstimpfle »

kevin_thibedeau wrote: post #125
mytailorisrich wrote: post #15

Earlier quoted context omitted.

> The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction. By and large memory is a contiguous array and the C representation closely matches what is actually happening, so I am curious about which platforms you have worked on.

Tagged memory architectures don't match the C model of linear memory. They're essentially obsolete now but C is still designed to accommodate them. A lot of the UB the people grouse about can generally be ignored because 99% of the platforms out there have the same behavior in areas where the standard is extra permissive for obsolete exotic hardware. Tagged memmory is dead, 1's complement is dead, big-endian is mostl…

Does the C machine model in fact consist of a single linearly addressable memory space? I think the spec mostly talks about "objects" that are linearly addressable -- not about the whole "memory" (there might not even be such a thing). Technically you aren't even allowed to compare two pointers other than for equality (relational comparisons are possible only within the same array). Just making up pointers is probably already a stretch of the spec, although you'll see lots of that in e.g. embedded projects.

(Disclaimer: I really don't know all the details of the C standards, am not a language lawyer but know enough about the language to feel quite productive in it. Please fill me in or correct me where I'm wrong).

Re: The Development of the C Language (1993)

#240

Post by matheusmoreira »

Timpy wrote: post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

I'd love to have a career in C too. To me it seems like Linux kernel development is the most obvious C programmer career path. Anyone know of alternatives?
Post reply on HN