5 ms·

Going from memory here, since I can't find any references. I believe there are problems in the handling of exceptions in constructors and destructors, which pe

by Retra 8y ago

Going from memory here, since I can't find any references. I believe there are problems in the handling of exceptions in constructors and destructors, which permeates into other parts of the language such as how arrays are constructed, etc. For one, the only way a constructor can fail is through an exception, and that's pretty heavy-handed for a language which markets itself as "don't pay for what you don't use." So you can't do RAII in C++ without exception handling. (Note that Rust solves this by not even having constructors.) There are also some problems with exceptions being slow code paths, but that probably varies by compiler.

mehrdadn 8y ago
You can do RAII without exception handling... you just don't throw from the constructor. There's no stipulation you have to throw from your constructor.
- notriddle 8y ago
  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.
  - mehrdadn 8y ago
    I was just saying you can have an error state, like iostreams already do. It doesn't imply you give up RAII.
- Retra 8y ago
  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.
  - mehrdadn 8y ago
    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...
    - Retra 8y ago
      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.
      - mehrdadn 8y ago
        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.
bogomipz 8y ago
Thanks for the detailed explanations. Cheers.

by Retra 8y ago

mehrdadn 8y ago

You can do RAII without exception handling... you just don't throw from the constructor. There's no stipulation you have to throw from your constructor.

notriddle 8y ago
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.
- mehrdadn 8y ago
  I was just saying you can have an error state, like iostreams already do. It doesn't imply you give up RAII.
Retra 8y ago
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.
- mehrdadn 8y ago
  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...
  - Retra 8y ago
    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.
    - mehrdadn 8y ago
      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.

bogomipz 8y ago

Thanks for the detailed explanations. Cheers.