Live data from Hacker News

Modern C and What We Can Learn from It [video]

youtube.com

21–30 of 132 posts

Re: Modern C and What We Can Learn from It [video]

#21
post #9

Earlier quoted context omitted.

In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++. I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were…

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

> for almost no extra costs

No way. The mental costs alone are staggering.

My standard observation was that to program C++ properly I always needed an entire shelf of books at hand and I used them daily.

The fact that C++ still can't deliver an FFI/name-mangling/v-table/etc. standard that everybody can agree on tells me that it's too complex.

Re: Modern C and What We Can Learn from It [video]

#22
post #16
post #10

Earlier quoted context omitted.

If you can program C well, C++ isn't going to be too much of a problem for you. The reverse is not necessarily true. If I were hiring on a C++ project I'd definitely want to talk to someone who is genuinely good at C - they may not want to talk of course.

I have been programming professionally for over 20 years in languages ranging from assembly to Lisp and everything inbetween and applications from embedded to Linux kernel, to OS, to backend systems to algorithmic trading. That I don't touch C++ is my choice because after years of development I decided that most of all I value simple and readable code, working with people who like to write simple and readable code or…

yep. That's a reasonable view. Hence:

>> they may not want to talk of course.

C++ as an indicator of dud project, poor team and programmer lack of taste is valid. It isn't necessarily always true but there's no reason for you to care if you've gone that way and it worked.

Re: Modern C and What We Can Learn from It [video]

#23
post #15

Earlier quoted context omitted.

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

Maybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.

What are these costs? Performance costs? Most of C++ abstraction are zero costs. There is always the possibility of misusing them, but you can also misuse C libraries. Learning costs? This is compensated by the fact that you don't have to re learn each project convention in C to emulate the same feature. Compile time costs? Yeah, that can be annoying. Costs of more bugs? In my experience, the better type system makes it unlikely.

Re: Modern C and What We Can Learn from It [video]

#24
post #21

Earlier quoted context omitted.

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

> for almost no extra costs No way. The mental costs alone are staggering. My standard observation was that to program C++ properly I always needed an entire shelf of books at hand and I used them daily . The fact that C++ still can't deliver an FFI/name-mangling/v-table/etc. standard that everybody can agree on tells me that it's too complex.

I would argue that you pay a harder mental cost in C because each project has to reinvent its own convention to emulate C++ features, and also because C allow for less abstraction which makes reasoning about the whole program more difficult

I don't see the relation with the fact that msvc and GCC have chosen different c++ ABI. That's not telling anything about the complexity of the language.

Re: Modern C and What We Can Learn from It [video]

#25
Anyone who wants a very good modern C book that's only 272 pages, take a look at 'Effective C - An Introduction to Professional C Programming by Robert C. Seacord. [1]. It's from 2020.

Robert Seacord is a Technical Director at NCC Group where he develops and delivers secure coding training in C, C++, and other languages. Seacord is an expert on the C Standards committee. > That's some solid credentials. He focuses on secure C code in the book.

Here's a short article on why he wrote the book [2].

[1] https://nostarch.com/Effective_C

[2] https://ieeexplore.ieee.org/document/9237323

Re: Modern C and What We Can Learn from It [video]

#26
post #15

Earlier quoted context omitted.

Maybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.

What are these costs? Performance costs? Most of C++ abstraction are zero costs. There is always the possibility of misusing them, but you can also misuse C libraries. Learning costs? This is compensated by the fact that you don't have to re learn each project convention in C to emulate the same feature. Compile time costs? Yeah, that can be annoying. Costs of more bugs? In my experience, the better type system makes…

Yes, also the huge benefits C++ offers in structuring large programs makes it well worth it to switch, even if one does not want the more fancy features of it.

Re: Modern C and What We Can Learn from It [video]

#27
post #20

Earlier quoted context omitted.

Unfortunately the restrictions added in C++20 make designated initialization quite pointless for any structs or classes with more than a handful items. Having to remember the order of initialization is too much hassle in this case.

That's what I thought too, until I actually used them extensively. The compiler tells you the correct order when you get it wrong, and I'm sure if you used an IDE (I don't) it would help you as well. And that was with Vulkan, everything in that API is done by creating structs with way too many members.

That sounds like a game of Tetris though, with or without IDE support ;) It would have been better if C++ treated structs like C structs, not like classes, but too late for that I guess.

Re: Modern C and What We Can Learn from It [video]

#28
post #9

Earlier quoted context omitted.

In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++. I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were…

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

I wish, althought C++ was born on the same building as C (kind of) and has enjoyed first class support on UNIX, it has hardly taken its place at the kernel level or syscalls.

So most UNIX/POSIX projects, even new ones, will default to C.

Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors, debugging tools, available libraries.

Arduino and mbed are the exceptions, not the rule.

Even Microsoft despite all their security talk around Azure Sphere, just releases a pure C SDK for it.

Which is while I tend to rant about C, I also argue that tooling improvements related to security are more than welcomed, and knowledge about best practices when coding in C should be more widespread.

It is the COBOL of systems programming languages (about 10 years younger) and it isn't going away for the foreseable future.

Re: Modern C and What We Can Learn from It [video]

#29
post #21

Earlier quoted context omitted.

> for almost no extra costs No way. The mental costs alone are staggering. My standard observation was that to program C++ properly I always needed an entire shelf of books at hand and I used them daily . The fact that C++ still can't deliver an FFI/name-mangling/v-table/etc. standard that everybody can agree on tells me that it's too complex.

I would argue that you pay a harder mental cost in C because each project has to reinvent its own convention to emulate C++ features, and also because C allow for less abstraction which makes reasoning about the whole program more difficult I don't see the relation with the fact that msvc and GCC have chosen different c++ ABI. That's not telling anything about the complexity of the language.

If you feel the need to emulate C++ features in C then you're just writing C code with a C++ mindset.

Getting back to the "C way" takes a couple of months to get C++ out of your system first ;)

Of course for some types of problems, C++ is indeed the better language than C, but very often other languages are even better suited (e.g. I turn to Python for most problem where C doesn't work well, for instance munching text files)

Re: Modern C and What We Can Learn from It [video]

#30
post #11

Earlier quoted context omitted.

I prefer C, but I technically write C++ because my “C code” sometimes uses references instead of pointers. (Why did that never become a C feature, anyway? It’s completely independent from OO/exceptions/templates/etc.) Luckily, in most any environment you can name, installing a C compiler actually implicitly installs a C++ compiler as well; so I can hand my “C code” library to people and tell them it’s C, and the fact…

> Why did that never become a C feature, anyway? I would rather ask, why did C++ add another reference type next to pointers ;) PS: the important part is that libraries have a C API, whether the implementation underneath is written in C or C++ isn't all that important. But IMHO once you're restricted to a C API anyway, writing the implementation in C too makes more sense because there's fewer situations where the imp…

Because that allows for out parameters and referring to memory addresses without the unsafety of dealing with pointers, something that even ALGOL and PL/I supported.
Post reply on HN