So your constructor has to be infallible. That means either you can't allocate memory in your constructor, or that all classes that are backed by dynamic memory have to have a tacked-on error state in case the constructor "fails".

An operating system can't just crash if memory allocation fails, because it's actually normal for the operating system to run out of memory. If your OS is even a little bit like Windows 95 or System V, it uses all of the "left-over" memory for the file system cache, so every time it tries to allocate memory, it probably needs to flush a page to disk, which takes long enough that the OS will also want to go back into the scheduler to try to find some more work to do while that runs.

Ironically enough, C++ has fallible allocation in the standard library in spite of being ill-suited for it (unless you have exceptions; those can support fallible allocation just fine), while Rust went with the let-it-crash approach in its standard library, despite the fact that the language itself allows you to just return an Option from all the functions that allocate memory.

I was just saying you can have an error state, like iostreams already do. It doesn't imply you give up RAII.

If you're doing that, you will often end up needing an init() method, and you arguably don't get RAII if you're not doing initialization during construction. I mean, you can write safe code this way, but if C++ hadn't backed itself into a corner by trying to make user types act like builtin types, this wouldn't even be a question. Constructors wouldn't have to be a whole domain of study unto itself, they could just be functions and you're done learning about them.

Huh? No. You can perfectly fine have a constructor that just leaves the object in an error state if it fails to acquire its resources. And a destructor that doesn't destroy unless acquisition is successful. No need for init(), though you can have that too. And your "arguably" is not arguable, it's just plain wrong. You don't have to successfully acquire something on every single invocation in order to have RAII. Otherwise e.g. initializing a smart pointer with null would suddenly imply smart pointers are not RAII...

This is the first paragraph on wikipedia:

>In RAII, holding a resource is a class invariant, and is tied to object lifetime: resource allocation (or acquisition) is done during object creation (specifically initialization), by the constructor, while resource deallocation (release) is done during object destruction (specifically finalization), by the destructor. Thus the resource is guaranteed to be held between when initialization finishes and finalization starts (holding the resources is a class invariant), and to be held only when the object is alive. Thus if there are no object leaks, there are no resource leaks.

All of this is violated if you are constructing objects in an 'invalid' state. The whole point of RAII is that you don't do this. If you have to check if the object is in an error state at the start of every method call, then you're not benefiting from RAII.

No, you're just arguing and misinterpreting things for the sake of arguing. RAII doesn't mean you absolutely have to hold a resource all the time. Like I said, nobody (other than you) says e.g. shared_ptr isn't RAII just because it can be in a null state that holds no resources. If you understand RAII you know that no benefit of RAII goes out any window if a smart pointer or some other object is initialized in a state that happens to hold nothing.

If you want to redefine things to be different just to win an argument, you can, but it's not something I'm going to continue entertaining as I'm pretty tired of it now.

Look, I said it was arguably not RAII, so I can see how one could make the point that it still works if you do it that way. But you saying "I'm just plain wrong" to say that RAII actually means resources must be allocated on initialization... I don't know what to tell you. That's literally what the acronym means.

And just because some low-level pointer primitive allows itself to have a null state doesn't mean your Files and DBConnections, etc., should have free reins to do the same.