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

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

youtube.com

Post reply on HN
Print view View original

31–40 of 132 posts

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

#31

Post by flohofwoe »

pjmlp wrote: post #30
flohofwoe wrote: post #19

Earlier quoted context omitted.

> 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.

> allows for out parameters

Out parameters are mostly a legacy feature from the time when C compilers didn't allow struct return values though, or implemented this inefficiently (besides, out parameters via pointers works too).

> memory addresses without the unsafety of dealing with pointers

I never understood the "increased safety" argument. C++ references can become dangling just as easily as pointers, and arguable they're even worse, because most of the time they look like regular value types.

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

#32

Post by varajelle »

flohofwoe wrote: post #29
varajelle wrote: post #24

Earlier quoted context omitted.

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 tex…

I was referring to the things from the video, where RAII and generic types are emulated with complex macros. And where std::string(_view) is re-invented

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

#33

Post by flohofwoe »

varajelle wrote: post #32
flohofwoe wrote: post #29

Earlier quoted context omitted.

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 tex…

I was referring to the things from the video, where RAII and generic types are emulated with complex macros. And where std::string(_view) is re-invented

Fair point, but cleanup and string handling are hardly problems where C++ has a monopoly, or even particularly good solutions to offer ;)

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

#34

Post by flohofwoe »

amadvance wrote: post #8
dthul wrote: post #5

Earlier quoted context omitted.

I agree. `crop_to_cat(img)` now has to be concerned with handling a possibly invalid image even though this method doesn't make sense for an invalid image. It muddies the type signature of the method and instead of `Image -> Image` (or possibly `Image -> Either Image Error`) it has to read `Either Image Error -> Either Image Error`. What if I want to apply that method to a valid image? I either need to wrap the image…

Not to mention that you also lose the error context. That boolean "is_valid" flag is not really informative of what happened. For example, if the image to load doesn't exist, you may want to print/log such path. The goto looks like a better approach.

You can just as well use a nested common error struct which has more detailed error information instead of just an "is_valid" bool, and also turn the whole return value into a tagged union to save some space (so the return value either contains a success value, or error data, but not both).

You just don't have the high-level syntax sugar to create or deal with tagged unions in C.

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

#35

Post by praptak »

harry8 wrote: post #10
lmilcin wrote: 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…

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.

> If you can program C well, C++ isn't going to be too much of a problem for you.

I only agree that understanding C helps somewhat, e.g. by avoiding the traps of not thinking hard about the underlying memory model. But it won't help you with template metaprogramming or how exceptions can break your supposedly memory-safe code: https://herbsutter.com/gotw/_102/

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

#36

Post by mettamage »

Y_Y wrote: post #15
varajelle wrote: post #13

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.

I'm distinguishing between a hobby perspective and a professional perspective.

IMO that really depends on the project size and goal of the project. I've written a C++ project of about 1000 lines (algobot trader with some optimized data structures in keeping the order book consistent). I've written it in VS Code, used a GUI debugger and I haven't really paid for anything.

Meanwhile, I have this friend that programs so much C++ that his mantra is "in C++ assume all tools are broken." When I hear his horror stories, oh dear! Heisenbugs come by every 2 to 3 months.

So for small projects that aren't touching the lower OS/systems level parts, you're not paying any extra costs. However, the deeper and further you go, I'd fully agree.

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

#37

Post by Y_Y »

varajelle wrote: post #23
Y_Y wrote: 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…

Introducing complexity into the build system, error messages, my mental model, interoperation between different parts of the code, other developers are often unfamiliar with less popular parts of the language, modern stuff especially sucks for portability between compilers and OSes. That's just my experience of course, and it doesn't mean I don't profit from writing and selling cpp-based software every day.

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

#38

Post by wruza »

varajelle wrote: post #13
lmilcin wrote: 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.

Ah, right. And all these “my move constructor wasn’t called” — “one of subfields had non-moveable field” and other arcane topics, which only C++ forums have, are just little implementation details. C++ is good when you believe it is Curly Visual Basic with some AOT speed and is an implicitness nightmare when you really care.

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

#39

Post by lmilcin »

pjmlp wrote: post #28
varajelle wrote: post #13

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.

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, debuggi…

> 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

And why do you think this is so?

When I was starting with embedded development I missed C++ as I felt compelled to reinvent same things that were given in C++.

But then I grew up to learn there is a hefty price to pay for it and in embedded development those problems are blown due to properties of the environment and types of projects you build.

It is one thing for a game to be constantly crashing and it is another if this is happening to an embedded device.

When you develop embedded code it is way more important to understand exact consequences of your actions and C++ is trying to hide those from you as much as possible.

There are also other requirements like being able to easily ascertain the amount of stack used, ability to use exclusively statically allocated memory, etc. that are conflicting with C++ or at least making it difficult to enforce them in C++.

I am very happy to see Rust is overtaking C++ in embedded and is an answer to C problems without creating (too many) of its own.

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

#40

Post by pjmlp »

flohofwoe wrote: post #31
pjmlp wrote: post #30

Earlier quoted context omitted.

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.

> allows for out parameters Out parameters are mostly a legacy feature from the time when C compilers didn't allow struct return values though, or implemented this inefficiently (besides, out parameters via pointers works too). > memory addresses without the unsafety of dealing with pointers I never understood the "increased safety" argument. C++ references can become dangling just as easily as pointers, and arguable…

Out parameters are a welcomed feature of all memory safe systems programming languages, only missed from C and BCPL.

C++ references surely are safer than pointer that can point to whatever they feel like and aren't initialized to any safe value.

There is a difference between being 100% fully safe, which they aren't, and being safer than plain unsafe pointers Assembly style.

Post reply on HN