3 ms·

Such addition is great. But there is something even better - destructors in C++. Anyone who writes C should consider using C++ instead, where destructors provid

Such addition is great. But there is something even better - destructors in C++. Anyone who writes C should consider using C++ instead, where destructors provide a more convenient way for resources freeing.

alextingle 8mo ago
C++ destructors are implicit, while defer is explicit. You can just look at the code in front of you to see what defer is doing. With destructors, you need to know what type you have (not always easy to tell), then find its destructor, and all the destructors of its parent classes, to work out what's going to happen. Sure, if the situation arises frequently, it's nice to be able to design a type that "just works" in C++. But if you need to clean up reliably in just this one place, C++ destructors are a very clunky solution.
- Panzerschrek 8mo ago
  Implicitness of destructors isn't a problem, it's an advantage - it makes code shorter. Freeing resources in an explicit way creates too much boilerplate and is bug-prone. > With destructors, you need to know what type you have (not always easy to tell), then find its destructor, and all the destructors of its parent classes, to work out what's going to happen Isn't it a code quality issue? It should be clear from class name/description what can happen in its destructor. And if it's not clear, it's not that relevant.
  - L-4 8mo ago
    > Implicitness of destructors isn't a problem It's absolutely a problem. Classically, you spend most of your time reading and debugging code, not writing it. When there's an issue pertaining to RAII, it is hidden away, potentially requiring looking at many subclasses etc.
mathisfun123 8mo ago
i write C++ every day (i actually like it...) but absolutely no one is going to switch from C to C++ just for dtors.
- Pay08 8mo ago
  Weren't dtors the reason GCC made the switch?
  - uecker 8mo ago
    I don't think so. As a contributor to GCC, I also wished it hadn't.
    - Pay08 8mo ago
      Why do you think so?
      - uecker 8mo ago
        For two reasons: First, where C++ features are used, it make the code harder to understand rather than easier. Second, it requires newer and more complex toolchains to build GCC itself. Some people still maintain the last C version of GCC just to keep the bootstrap path open.
        Pay08 8mo ago
        I'm very far from compiler development, but in my experience, while C++ is hard to read, the equivalent C code would be much more unreadable.
        uecker 8mo ago
        This is not my experience at all. In fact, my experience is where C++ is used in GCC it became harder to read. Note that GCC was written in C and then introduced C++ features later so this is not hypothetical. In general, I think clean C code is easier to read than C++ due to much less complexity and not having language features that make it more difficult to understand by hiding crucial information from the reader (overloading, references, templates, auto, ..).
amluto 8mo ago
I think destructors are different, not better. A destructor can’t automatically handle the case where something doesn’t need to be cleaned up on an early return until something else occurs. Also, destructors are a lot of boilerplate for a one-off cleanup.
- Panzerschrek 8mo ago
  > A destructor can’t automatically handle the case where something doesn’t need to be cleaned up on an early return It can. An object with destructor doing clean-up should be created only after such clean-up is needed. In case of a file, for example, a file object should be created at file opening, so that it can close the file in its destructor.
  - amluto 8mo ago
    That’s fine when one wants to write a whole class for something. But sometimes a cleanup path is genuinely a one-off, and using something like defer is nice.
Someone 8mo ago
For the cases where a destructor isn’t readily available, you can write a defer class that runs a lambda passed to its constructor in its destructor, can’t you? Would be a bit clunky, but that can (¿somewhat?) be hidden in a macro, if desired.
flohofwoe 8mo ago
Desctructors are only comparable when you build an OnScopeExit class which calls a user-provided lambda in its destructor which then does the cleanup work - so it's more like a workaround to build a defer feature using C++ features. The classical case of 'one destructor per class' would require to design the entire code base around classes which comes with plenty of downsides. > Anyone who writes C should consider using C++ instead Nah thanks, been there, done that. Switching back to C from C++ about 9 years ago was one of my better decisions in life ;)

alextingle 8mo ago

C++ destructors are implicit, while defer is explicit. You can just look at the code in front of you to see what defer is doing. With destructors, you need to know what type you have (not always easy to tell), then find its destructor, and all the destructors of its parent classes, to work out what's going to happen. Sure, if the situation arises frequently, it's nice to be able to design a type that "just works" in C++. But if you need to clean up reliably in just this one place, C++ destructors are a very clunky solution.

Panzerschrek 8mo ago
Implicitness of destructors isn't a problem, it's an advantage - it makes code shorter. Freeing resources in an explicit way creates too much boilerplate and is bug-prone. > With destructors, you need to know what type you have (not always easy to tell), then find its destructor, and all the destructors of its parent classes, to work out what's going to happen Isn't it a code quality issue? It should be clear from class name/description what can happen in its destructor. And if it's not clear, it's not that relevant.
- L-4 8mo ago
  > Implicitness of destructors isn't a problem It's absolutely a problem. Classically, you spend most of your time reading and debugging code, not writing it. When there's an issue pertaining to RAII, it is hidden away, potentially requiring looking at many subclasses etc.

mathisfun123 8mo ago

i write C++ every day (i actually like it...) but absolutely no one is going to switch from C to C++ just for dtors.

Pay08 8mo ago
Weren't dtors the reason GCC made the switch?
- uecker 8mo ago
  I don't think so. As a contributor to GCC, I also wished it hadn't.
  - Pay08 8mo ago
    Why do you think so?
    - uecker 8mo ago
      For two reasons: First, where C++ features are used, it make the code harder to understand rather than easier. Second, it requires newer and more complex toolchains to build GCC itself. Some people still maintain the last C version of GCC just to keep the bootstrap path open.
      - Pay08 8mo ago
        I'm very far from compiler development, but in my experience, while C++ is hard to read, the equivalent C code would be much more unreadable.
        uecker 8mo ago
        This is not my experience at all. In fact, my experience is where C++ is used in GCC it became harder to read. Note that GCC was written in C and then introduced C++ features later so this is not hypothetical. In general, I think clean C code is easier to read than C++ due to much less complexity and not having language features that make it more difficult to understand by hiding crucial information from the reader (overloading, references, templates, auto, ..).

amluto 8mo ago

I think destructors are different, not better. A destructor can’t automatically handle the case where something doesn’t need to be cleaned up on an early return until something else occurs. Also, destructors are a lot of boilerplate for a one-off cleanup.

Panzerschrek 8mo ago
> A destructor can’t automatically handle the case where something doesn’t need to be cleaned up on an early return It can. An object with destructor doing clean-up should be created only after such clean-up is needed. In case of a file, for example, a file object should be created at file opening, so that it can close the file in its destructor.
- amluto 8mo ago
  That’s fine when one wants to write a whole class for something. But sometimes a cleanup path is genuinely a one-off, and using something like defer is nice.

Someone 8mo ago

For the cases where a destructor isn’t readily available, you can write a defer class that runs a lambda passed to its constructor in its destructor, can’t you? Would be a bit clunky, but that can (¿somewhat?) be hidden in a macro, if desired.

flohofwoe 8mo ago

Desctructors are only comparable when you build an OnScopeExit class which calls a user-provided lambda in its destructor which then does the cleanup work - so it's more like a workaround to build a defer feature using C++ features. The classical case of 'one destructor per class' would require to design the entire code base around classes which comes with plenty of downsides. > Anyone who writes C should consider using C++ instead Nah thanks, been there, done that. Switching back to C from C++ about 9 years ago was one of my better decisions in life ;)