Live data from Hacker News

Defer available in gcc and clang

gustedt.wordpress.com

241–250 of 262 posts

Re: Defer available in gcc and clang

#241
post #152

Earlier quoted context omitted.

Sorry, I had some other thread that involved destructors in my head. But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.

But the real-world alternatives that people use are: 1. goto, which is "spooky action at a distance" to the nth degree. It's not even safe, you can goto anywhere, even out of scope. 2. cleanup attributes, which are not standard.

>goto, which is "spooky action at a distance" to the nth degree.

it is not.

Re: Defer available in gcc and clang

#242
post #108

Earlier quoted context omitted.

To be fair, RAII is so much more than just automatic cleanup. It's a shame how misunderstood this idea has become over the years

Can you share some sources that give a more complete overview of it? I got out my 4e Stroustrup book and checked the index, RAII only comes up when discussing resource management. Interestingly, the verbatim introduction to RAII given is: > ... RAII allows us to eliminate "naked new operations," that is, to avoid allocations in general code and keep them buried inside the implementation of well-behaved abstractions.…

> Hiding heap allocations seems like it make it harder to avoid resource leaks!

Because types come in constructor / destructor pairs. When creating variables, you're forced to invoke a constructor, and when an the object's lifetime ends, the compiler will insert a destructor call for you. If you allocate on construction and de-allocate on destruction, it'll be very hard for the leak to happen because you can't forget to call the destructor

Re: Defer available in gcc and clang

#243

Earlier quoted context omitted.

It is pointless, because in Linux all you get is a virtual address. Physical backing is only allocated on first use. In other words, the first time you access a "freshly allocated" non-null pointer you may get a page fault due to insufficient physical memory.

By default, yes. You can configure it to not overcommit

Right, but as a programmer you rarely have control over that. And even if you do, you often can't handle out of memory errors gracefully.

Thus, for a typical situation it is reasonable to log the error and bail out, rather than adding extra custom error handling around every single memory allocation, which ends up being code that is never tested.

Re: Defer available in gcc and clang

#244
post #142

Earlier quoted context omitted.

Everyone reading this (you included) knows full well that unlike Zig/Rust/Odin/whatever, C++ has the special property that you can quite literally* write C code in it, AND you can implement whatever quality of life fixes you need with targeted usage of RAII+templates+macros (defer, bounds checked accesses, result types, whatever). My comment is targeted towards the programmer who is excited about features like this -…

C in C++ is a pretty terrible experience. The differences your asterisk alludes to are actually quite significant in practice: C++ doesn't let you implicitly cast from void* to other pointer types. This breaks the way you typically heap-allocate variables in C: instead of 'mytype *foo = malloc(sizeof(*foo))', you have to write 'mytype *foo = (mytype *)malloc(sizeof(*foo))'. This adds a non-trivial amount of friction…

> C in C++ is a pretty terrible experience

No I think, it the other way around, a fantastic experience; yes, you miss certain features of C, but instead you get massive benefits of C++ - above-mentioned defer, that'd work on any moderrn C++ compiler, constexpr's, a strategic use of STL while prototyping, templates etc.

> C++ doesn't let you implicitly cast from void* to other pointer types

It does, but that is not a good thing IMO anyway.

> Plenty of C APIs are really not very ergonomic when string literals aren't 'char '.

Examples? In my experience most C libraries have const char in their signatures whenever it makes sense.

> C is a much better C than C++ is.

Nonsense.

Re: Defer available in gcc and clang

#245
post #140

Earlier quoted context omitted.

You're right that it's not needed in my example but sometimes the thing that you're freeing has pointers inside it which themselves have to be freed first and in that case you need the if. There are several other issues I haven't shown like what happens if you need to free something only when the return code is "FALSE" indicating that something failed. This is not as nice as defer but up till now it was a comparative…

If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.

We are talking about C. A destructor function in C is a function that gets called when the library gets unloaded. No you shouldn't have a destructor function for it.

Re: Defer available in gcc and clang

#246
post #34

Earlier quoted context omitted.

If you're teaching them to write an assembler, then it may be worth teaching them C, as a fairly basic language with a straightforward/naive mapping to assembly. But for basically any other context in which you'd be teaching first-year CS students a language, C is not an ideal language to learn as a beginner. Teaching C to first-year CS students just for the heck of it is like teaching medieval alchemy to first-year…

I think I heard this in some cppcon video, from uni teacher who had to make students know both C and Python, so he experimented for several years learning Python first is same difficulty as learning C first (because main problem is the whole concept of programming) and learning C after Python is harder than learning Python after C (because of pointers)

Learning C after Python made me actually understand Python semantics. Python also has pointers, you just don't get to control them.

Re: Defer available in gcc and clang

#247
post #163

Earlier quoted context omitted.

C is the best language to learn as a beginner.

At no point in human history has C been the best language for beginners. C was, like Javascript, hacked together in a weekend by someone who wished they could be using a better language. It was burdened with flaws from the outset and considered archaic in its design almost immediately. The best thing that can be said about the design of C is that it's at least a structured programming language, which is damning with…

> C was, like Javascript, hacked together in a weekend by someone who wished they could be using a better language.

Citation needed. C was evolved from B as part of the development of a popular OS. It did take a lot more time and consideration than a weekend.

Re: Defer available in gcc and clang

#248
post #173

Earlier quoted context omitted.

if you do it once - why do you care about "ugly" scope_exit? btw, writing such wrappers is easy and does not require a lot of code.

What do you mean with '"ugly" scope_exit'? Do you mean why I care that I have to call the free function at every exit point of the scope? That's easy: because it's error prone. Defer is much less error prone.

your words... > C++ implementations of defer are either really ugly

I agree with @pjmlp - you need to write wrappers around the C api.

But if you.. > If I'm gonna write RAII wrappers around every tiny little thing that I happen to need to call once

use them just once.. so, why care about ugliness, just write ugly code just once? Code can't be perfect.

Re: Defer available in gcc and clang

#249
post #241

Earlier quoted context omitted.

But the real-world alternatives that people use are: 1. goto, which is "spooky action at a distance" to the nth degree. It's not even safe, you can goto anywhere, even out of scope. 2. cleanup attributes, which are not standard.

>goto, which is "spooky action at a distance" to the nth degree. it is not.

It is, just the existence of goto makes control flow significantly harder to understand. People complain about exceptions in C++ obfuscating control flow, but then they recreate exceptions using goto. The funny thing is that exceptions are just fancy goto, the assembly is almost the same.

The bigger picture of C as a language is not that it's simple, because it's not simple at all. It's inept. It doesn't give developers the tools to write simple code. So easy things become hard, and we sort of jank together solutions that kind of work but usually don't.

I like to compare it to building a shed with power tools versus only a screwdriver. Is a screwdriver simpler than a power saw and all that? Of course. Now think about building a shed. Is it simpler to do with a screwdriver? No. It's much, much more complex. You have to develop complex processes to make that work, and it's not intuitive at all.

C is a language that already makes use of implicit control flow A LOT. I don't see defer being a problem. The irony is that if C just supported these use cases out-of-the-box, it would be simpler and easier. As a concrete example, consider polymorphism in C versus C++. Both languages can do it, but one provides the tools and one doesn't. In C++ I can go to definition, I can concretely define what polymorphism is allowed and what isn't, and the type system gives me the tools to make it safe. In C, none of that is true, so when we do polymorphism with function pointers, it's much harder to understand what's actually going on, or what could be going on.

Re: Defer available in gcc and clang

#250
post #241

Earlier quoted context omitted.

>goto, which is "spooky action at a distance" to the nth degree. it is not.

It is, just the existence of goto makes control flow significantly harder to understand. People complain about exceptions in C++ obfuscating control flow, but then they recreate exceptions using goto. The funny thing is that exceptions are just fancy goto, the assembly is almost the same. The bigger picture of C as a language is not that it's simple, because it's not simple at all. It's inept. It doesn't give develop…

It is not. That `GOTO` makes things hard does not shift it to some unrelated category.

> The funny thing is that exceptions are just fancy goto

Not even close.

>I like to compare it to building a shed with power tools versus only a screwdriver.

That analogy is completely wrong in the context.

> it's not intuitive at all.

It is completely intuitive, while the "modern" languages with "helpful" magic is not.

>C is a language that already makes use of implicit control flow A LOT.

> implicit

I don't think it means what you think it means. At least the examples you mention does not justify it.

Post reply on HN