My sides. This is the most hilarious and accurate summary of every org where I’ve worked.

Thank you.

That gave me a good 5 minutes of chuckling and smiling. Thank you.

At some point we had to wear deodorant and a collared shirt, boom we became engineers.

In all seriousness just accept their advice and see it for what it is. Someone trying to help you with limited view of the scope. As long as they don't impose their view I think your take is extremely bad.

It reads like you had experts giving you advise on how to improve things, and instead not only did you ignored their advise but you went to the extent of mindlessly disparaging their help.

Is it actually complicated? There’s only the rule of 0 - either your class isn’t managing resources directly & has none of the 5 default methods defined explicitly (destructor, copy constructor/assignment, move constructor/assingment), or it manages 1 and exactly 1 resource and defines all 5. Following that simple rule gives you exception safety & perfect RAII behavior. Of all the things in C++, it seemed like the most straightforward rule to follow mechanically.

BTW, the rule of 3 is from pre-C++11 - the addition of move construct/move assignment makes it the rule of 5 which basically says if you define any of those default ones you must define all of them. But the rule of 0 is far stronger in that it gives you prescriptive mechanical rules to follow for resource management.

It’s much easier to do RAII correctly in Rust because of the ecosystem of the language + certain language features that make it more ergonomic (e.g. Borrow/AsRef/Deref) + some ownership guarantees around moves unless you make the type trivially copyable which won’t be the case when you own a resource.

    test "arena allocator" {
        var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
        defer arena.deinit();
        const allocator = arena.allocator();

        _ = try allocator.alloc(u8, 1);
        _ = try allocator.alloc(u8, 10);
        _ = try allocator.alloc(u8, 100);
    }

Like the autorelease pool found in Objective-C of yore? I always liked that solution and sometimes implemented in plain C too.

It is not very complicated at all; just a discipline to follow (or not if you know what you are doing) once learnt - https://en.cppreference.com/w/cpp/language/rule_of_three

Incidentally i use it as 4/6/0 by including the default ctor in the set.

I'm afraid you're complaining about entirely unrelated things.

It's one thing to claim that C++ structs have this or that trait. It's a entirely different thing to try to pin bugs and developer mistakes on how a language is designed.

I think this glances over what structs actually are in C++, and unwittingly portrays them as something different.

Structs in C++ are definitely exact like structs in C. Or they can be, if that's what you're aiming for. If you include a C header file that defines a struct in a C++ program, you build it, and you use instances of that struct to pass them to C programs, everthing just works.

The detail you need to be mindful of is that C structs support a subset of all the features supported by C++ classes, and once you start to use those features C++ also allows implementations to forego some constraints.

If you expect to use a struct in C++ but still define it in a way that you make it include features that are not supported in C then you can't pin that on the language.

https://learn.microsoft.com/en-us/cpp/cpp/trivial-standard-l...

Using C-like structs is a very common use case, to the point that the standard explicitly defines the concept of standard layout and builds upon that to specify the concept of a standard layout type. A struct/class that is a standard layout type, which means it's a POD type, corresponds exactly with C structs. They are explicitly defined in terms of retaining interoperability with other languages.

100% of the using structs like they are C structs vs using class as objects is cultural not a part of the language.

Again, "traditionally", one could (ab)use C++ as "C with extras". And it wasn't uncommon, especially in resource constraint usecases, to do just that. C++ without STL or templates, or even C++ without new/delete.

This "is not C++", agree. Would a subset be enough for "using it like C-with-RAII" ?

Given the details and pitfalls the original author lists, I suspect not. It's not just C programmers who "do strange things" and make odd choices. The language itself though "lends itself to that". I've (had to) write code that sometimes-alloca'ed sometimes-malloc'ed the same thing and then "tagged" it to indicate whether it needed free() or "just" the implied drop. Another rather common antipattern is "generic embedded payloads" - the struct definition ending "char data[1]" just to be padded out by whatever creates it to whatever size (nevermind type) of that data.

Can you write _new_ C code that "does RAII" ? Probably. Just rewrite it in rust, or zig :-) Can you somehow transmogrify language, compiler, standard lib so that you can recompile existing C code, it not to "just get RAII" then at least to give you meaningful compiler errors/warnings that tell you how to change it ? I won't put money on that.

Like C, with its many hidden behaviors?

It’s not clear if you’re talking about defer or RAII

Of course, this requires buying into a set of tooling and learning a lot of specific idioms. I can't say I've used it, but from reading the docs it seems sound enough.

The issue is developers that think they are useless tools.

"Disabling" is maybe not the right way to think about it. Rust only has "implicit copying" for Copy types, so you have to at the very least #[derive(Copy,Clone)] to get this, it's true that you can't (and therefore neither can a derive macro) impl Copy on types which implement Drop and that's on purpose but you're making a concrete decision here - the answer Rust knows is never correct is something you'd have to ask for specifically, so when you ask it can say "No" and explain why.

Lots of similar behaviour in C++ is silent. Why isn't my Doodad behaving the way I expected? I didn't need to ask for it to have the behaviour I expected but the compiler concludes it can't have that behaviour, so, it doesn't, and there's nowhere for a diagnostic which says "Um, no a Doodad doesn't work like that, and here's why!"

Diagnostics are hard and C++ under-values the importance of good diagnostics. Rust recently landed work so libraries can provide improved diagnostics when you try to call them with inappropriate parameters. For example now if you try to collect() an iterator into a slice, the compiler notices that slice doesn't implement FromIterator and it asks FromIterator to explain why this can't work, whereupon FromIterator notices you were trying to use a slice and emits a diagnostic for this particular situation - if you'd tried to collect into an array it explains how you'd actually do that, since it's tricky - the slice is impossible since it's not an owning type, you need to collect into a container.

But you could gain reusability of headers to be also used in C++, not needing to reinvent the wheel with new issues (e.g. variable lifetime), and a whole lot of existing experience with RAII.

There are 2 ways to get C++-style RAII into C. The first way is to wholesale import the C++ object system into C (which means name mangling, all the different flavors of constructors, destructors, etc). Conceptually this would work, but it's never going to happen, because implementing that would be literally more work than an entire conforming C99 compiler.

The second way is to just use some special function attributes to signify that a function runs when an object is created on the stack / popped off the stack. This won't work either because the C++ object system also solves lots of other problems that this simpler system just ignores (such as, what happens when you copy an object that has a constructor function).

Another way to think about it: even if you had defined constructors and destructors for a struct, you have not solved when to call them. C++'s answer to that question is its sophisticated object model. C does not have one, and in order to answer that question, it must. It's worth noting that RAII was not a feature that was intentionally created in C++. Rather, astute early C++ developers realized it was a useful idiom made possible by C++'s object model.

I think the actual question should be "can C get automatic memory management like in C++ without having the equivalent of C++'s type system"?

Though I can't put my finger on it, my intuition says it can, if the interested people are willing to look deep enough.

Exactly this. C++ folks should not approach C like a "C++ lite". I appreciate the authors candid take on the subject.

As for defer, there is some existing precedent like GCC and Clang's __attribute__((cleanup)), but - at least for me - a simple "goto cleanup;" is usually sufficient. If I understand N3199 [1] correctly, which is the authors proposal for introducing defer in C, then "defer" would be entirely a compile-time construct. Essentially just a code transformation to inject the necessary cleanup at the right spots. If you're going to introduce defer to C then that does seem like the "best" approach IMO.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm

Unless you're writing inline assembly or intrinsics or something like that, the semantics of your target architecture are quite irrelevant. If you're reasoning about the target architecture semantics that's a pretty good indication that what you're writing is undefined behavior. Reasoning about performance characteristics of your target architecture is definitely ok though.

Yes, nothing like that is possible in C

https://godbolt.org/z/Ge4EqzznT

However, if I were to request a feature to the core language it would be: NAMESPACES. This would clean up the code significantly without introducing confusing code paradigms.

its just mean if you need that logic, in C you would write lots of verbose less safe code.

1) labels as values in standard 2) control over memory position offsets, without linker script

other than that a few more compiler implementations offering things like checked array bounds, and a focus on correctness rather than accepting the occasional compiler bug

the rough edges like switch fallthrough are rough, but easy to work around. They don't need fixing (-pedantic fixes it already, etc)

maybe more control over assembly generation, such as exposing compilation at runtime; but that is into the wishful end of wishlists

Edit: I just reread this comment and realized the beginning of it could come across as a bit condescending even though that wasn’t at all my intention. I’d edit it out, but I don’t like doing that, so my apologies if it did come across that way!

Indeed! When I was first learning C++, I found the term "RAII" quite confusing too. However, after years of experience with this term, associating "RAII" with its intended meaning has become second nature.

Having said that, there is at least one way to make better sense of "RAII" and that is considering the fact that in RAII, holding a resource is a class invariant. The resource is acquired during construction (initialisation) and released during destruction (which happens automatically when the object of the class goes out of scope). Throughout the object's lifetime, from construction to destruction, maintaining possession of the acquired resource is an invariant condition.

Although sounds simple in principle, this can get complicated pretty quickly, especially in the implementation of the copy assignment operator where we may need to carefully delete an existing resource before copying the new resource received by the operator. Problems like this led to formulating more techniques for carefully managing the resources while satisfying the class invariant. One such technique is the copy-and-swap idiom.

None of this is meant to justify the somewhat arbitrary term though. In fact, there are at least two better alternative names for RAII: Scope-Based Resource Management (SBRM) and Constructor Acquires, Destructor Releases (CADR).

The reason to do this is precisely so that the resource can be cleaned up at destruction of the object. So even if you had an acronym like RASALTOI, it would still probably be misleading

There is no such thing as IL finalizers. There are object finalizers which are highly discouraged to be used on their own.

Their most frequent application is a safety measure for objects implementing IDisposable where not calling Dispose could lead to memory leak or other form of resource starvation that must be prevented.

For example, a file handle is IDisposable, so it is naturally disposed through using statement but should a user make a mistake in a scenario where that handle has non-trivial lifecycle, once the object is no longer referenced, its finalizer will be called upon one of the Gen2 GCs by a finalizer thread, preventing the file handle leakage even if its freeing is now non-deterministic:

    // Disposed upon exiting the scope
    using var okay = File.OpenHandle("file1");

    // IDEs will complain if you do this, but if you insist,
    // the implementation will prevent you from shooting your
    // foot off even if it'll hurt until next Gen2 GC
    var leaked = File.OpenHandle("file2");

I find this an interesting thought experiment, basically types that you'd opt in to RAII. Just have a feeling that you'll need to define some notion of ownership to make it work.