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

301–310 of 536 posts

Re: The Development of the C Language (1993)

#301

Post by badsectoracula »

camel-cdr wrote: post #250
badsectoracula wrote: post #227

Earlier quoted context omitted.

It it technically possible in that C macros are supposedly Turing complete, but i mean i want something like being able to add a value to a variable, iterate through values (proper list would be neat but i'd be ok with a string of space separate values), etc.

> It it technically possible in that C macros are supposedly Turing complete It isn't Turing complete, because it will always terminate, but you can make the execution time (number of execution steps) arbitrary large exponential in respect to the number of source lines. There are a few libraries that implement that. https://github.com/rofl0r/chaos-pp : Quite high level implementation, that supports arbitrary precisio…

> It isn't Turing complete, because it will always terminate

Well, i wrote "supposedly" because i didn't try it myself but found a post[0] that claims it is. The example is even about making loops.

But the point is that these aren't only way too hacky but also slow down compilation. I did use some of my own preprocessor hacks when i wanted to do some fancy stuff with it at the past to implement an RTTI system that allowed automatic serialization of structs with nesting and references and while it worked (x-macros FTW), it was cumbersome and slowed down compilation so much that at the end i found it both much simpler and faster (in compilation time) to replace a ton of preprocessor macros with a code generator and a couple of #includes that included the generated code.

[0] https://stackoverflow.com/questions/3136686/is-the-c99-prepr...

Re: The Development of the C Language (1993)

#302

Post by zabzonk »

pjmlp wrote: post #211
zabzonk wrote: post #184

Earlier quoted context omitted.

> Petzold did the same on his highly acclaimed book takes me back. i thought it was crap. i used to work at The Instruction Set (one of UK's biggest tech training companies at the time) and everyone hated the Windows/C course based on Petzold. my boss came up to me (somehow I was the windows guy in a unix company) and said "we need a new windows course" and me said "OK, i need a framemaker license and to work at home…

Around 1991. I mostly programmed on Windows 3.x with TPW and TC++, alongside OWL. Those nice Borland manuals. For me, in what concerns C programming for Windows 3.x, the "Programmer's introduction to Windows 3.1" was a much better book. Mainly due to its coverage of windowsx and message macros. It's on the Internet Archive. https://archive.org/details/programmersintro00myer

> Around 1991.

how do you know that?

Re: The Development of the C Language (1993)

#303

Post by synergy20 »

c_crank wrote: post #296
synergy20 wrote: post #282

Earlier quoted context omitted.

I dreamed about a simplified c++, that is better/safer than c but much simpler than existing c++, call it c+, a subset c++ that enhances c but not bringing in all those c++ complexities that I 99% do not need in daily coding.

There is such a language called D.

sadly no time to pick a new languages these days. will just cherry pick c++ features and build my own subset of it and call it c+ myself, this seems the quickest way to get daily coding done fast for me.

Re: The Development of the C Language (1993)

#305

Post by chlorion »

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…

>If a line of code doesn't look like a function call, it's not calling anything.

In C, if you for example write past the bounds of an array or otherwise do something that causes UB, there is no guarantee that the code you wrote in the source file is actually going to be what's ran.

If an attacker can clobber the stack (for example), the control flow you see in the source code and the actual control flow of the program are not the same.

In the worst case, an attacker can get your program to execute arbitrary code of their own choosing!

Maybe some consider this unrelated to the no implicit control flow thing, but I think when UB caused by a trivial mistake can alter your control flow, you have much bigger worries than an operator being sugar for calling a function.

I consider UB and arbitrary code execution exploits to be a case of implicit control flow!

Re: The Development of the C Language (1993)

#306

Post by gnuvince »

synergy20 wrote: post #282
zabzonk wrote: post #130

Earlier quoted context omitted.

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

I dreamed about a simplified c++, that is better/safer than c but much simpler than existing c++, call it c+, a subset c++ that enhances c but not bringing in all those c++ complexities that I 99% do not need in daily coding.

There are many new languages that describe themselves as taking C, adding some good stuff (slices, defer), removing some of the bad stuff (textual includes) and adding some of their own spice. One might have the right mix of features for you: Zig, Odin, C3, Hare, Jai.

Re: The Development of the C Language (1993)

#307

Post by starcraft2wol »

chongli wrote: post #203
marcosdumay wrote: post #181

Earlier quoted context omitted.

The control flow is the same; you evaluate the parameters, and then evaluate the operator. Just like any other function call, there's nothing implicit or hidden. The only difference is that you can't create other operators with the same name for different types. And whether something is called or run inline is always decided by the compiler. Modern C doesn't promise you any relation between the way you break down you…

Just like any other function call, there's nothing implicit or hidden. The implicit part is the question of whether an operator is built-in or overloaded. In C, every operator is built-in, so you can look at a block of code and see that there are NO function calls in it. With something like C++, you must treat every operator like a function call. With C, if I write: a += b; I can be VERY confident that this line of c…

> With C++ (or other operator-overloaded language), I cannot

All programming requires people to follow reasonable conventions. In C++ if you make a dereference operator with non-constant time, or an equality operator which doesn't follow equality semantics, the programmer messed up. It's like giving a function a misleading name, like `doThis()` and it doesn't.

Note that Java is filled with these kinds of conventions, such as overloading `equals`. How can you be certain it actually obeys equality semantics? You have to trust the programmer.

Re: The Development of the C Language (1993)

#308

Post by pjmlp »

bathMarm0t wrote: post #294
pjmlp wrote: post #264

Earlier quoted context omitted.

Are the Arduino and ESP32 microcontrollers? Hint, might check their libraries/SDKs before answering.

Don't think I'm too crazy but last time I checked: 1. Yes they are microcontrollers. 2. Yes they use C/C++. (check the libraries/SDKs, 1 layer under the hood it's all .h/.cpp files, and most of the arduino calls are just #defines)

So it isn't only C.

Re: The Development of the C Language (1993)

#309

Post by pjmlp »

zabzonk wrote: post #302
pjmlp wrote: post #211

Earlier quoted context omitted.

Around 1991. I mostly programmed on Windows 3.x with TPW and TC++, alongside OWL. Those nice Borland manuals. For me, in what concerns C programming for Windows 3.x, the "Programmer's introduction to Windows 3.1" was a much better book. Mainly due to its coverage of windowsx and message macros. It's on the Internet Archive. https://archive.org/details/programmersintro00myer

> Around 1991. how do you know that?

Because you asked me about the date I got the book?

Re: The Development of the C Language (1993)

#310

Post by kaba0 »

tejuis wrote: post #159
coliveira wrote: post #126

Earlier quoted context omitted.

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.

Same here, no problems with undefined behavior. Also, no memory issues either after done with code finalization using Valgrind.

“no memory issues in the tested state space”. That’s the only thing Valgrind can say. But it says nothing how a run with different input would behave, it just might segfault/leak/use after free/UB.
Post reply on HN