5 ms·

I don't like it. The great advantage of C is the very simple virtual machine and therefore very easy to reason about code. This bolting on language features is

by yk 5y ago

I don't like it. The great advantage of C is the very simple virtual machine and therefore very easy to reason about code. This bolting on language features is the hallmark of C++, which don't get me wrong has advantages, but in case we want the advantages we can already use C++.

eptcyka 5y ago
The feature wouldn't introduce much complexity to the abstract machine model IMO, not any more than what cleanup labels already do.
- yk 5y ago
  Cleanup labels are just a conditional jump, it's explicitly in the code. The defer feature would introduce implicit guarantees by the compiler.
- mort96 5y ago
  ..And cleanup attributes aren't in C.
dgellow 5y ago
defer has nothing to do with C++.
- dahfizz 5y ago
  C++ has try finally, which is the same thing. Instead of bloating C, anyone needing defer can use a subset of C++ that fits their needs.
  - eMSF 5y ago
    C++ has no finally blocks.
    - AnonC 5y ago
      > C++ has no finally blocks. Not in the standard, but there are compiler implementations (like Microsoft’s) that have added it.
      - jcelerier 5y ago
        I just did a gh code search (__finally lang:c++), a hundred-ish instances shows up in ~12 repos mainly related to MS / .Net: ‎ sleuthkit/scalpel‎ ‎‎ microsoft/service-fabric‎ ‎ ‎dotnet/runtime‎ ‎ ‎microsoft/Detours‎ ‎ ‎dotnet/wpf‎ ‎ ‎Chuyu-Team/VC-LTL‎ ‎ ‎apache/logging-log4net‎ ‎ ‎microsoft/Windows-classic-samples‎ ‎ ‎microsoft/winfile‎ ‎ ‎dotnet/llilc‎ ‎‎ microsoft/DirectXShaderCompiler‎ ‎ ‎dotnet/diagnostics‎ ‎‎ SoftEtherVPN/SoftEtherVPN‎ ‎ ‎microsoft/PTVS‎ ‎ ‎aybe/Windows-API-Code-Pack-1.1‎ I don't think that it's in any way meaningful, it's literally unused given that it's been there for likely 20+ years.
  - kaba0 5y ago
    You mix that up with RAII.
  - isomel 5y ago
    Maybe you're mixing up with SEH (Structured Exception Handling) which is a Microsoft extension to C that came even before C++
  - dgellow 5y ago
    So we moved from “defer” to “using a different language, with different semantics, and use the non-standard finally”.
usrbinbash 5y ago
How does "defer" make it harder to reason about the code? Especially when the alternative is a bunch of resource-flag-tests and cleanup labels? There is a reason why it was introduced in Go.
- yk 5y ago
  Because the compiler has to introduce code implicitly. The control flow is usually very explicit in C, with this feature it is less explicit.
  - pjmlp 5y ago
    Until a signal gets raised.
    - jstimpfle 5y ago
      The comment was about the generated code, not about arcane OS hacks that were introduced to add asynchronous notifications to otherwise blocking OS APIs.
      - pjmlp 5y ago
        It is part of ISO C standard library.
  - usrbinbash 5y ago
    So its better to make the control flow explicitly complicated with a bunch of labels and resource-flags and doing so inconsistently (because everyone has a slightly different view on how to implement it), than having the compiler do it in a consistent way? Pragmatic point of view: In 99% of cases, the developer doesn't care what the compiler produces and doesn't have to. A mechanism providing a complex control flow in the compiler output but is incredibly easy to read and reason about in the source code is useful in the vast majority of cases. And for the 1% of cases where the programmer actually needs to know what the compiler produces, and / or full control over the control flow, the solution is simple: don't use `defer` and there, done, full control to the developer. So where exactly is the downside?

by yk 5y ago

eptcyka 5y ago

The feature wouldn't introduce much complexity to the abstract machine model IMO, not any more than what cleanup labels already do.

yk 5y ago
Cleanup labels are just a conditional jump, it's explicitly in the code. The defer feature would introduce implicit guarantees by the compiler.
mort96 5y ago
..And cleanup attributes aren't in C.

dgellow 5y ago

defer has nothing to do with C++.

dahfizz 5y ago
C++ has try finally, which is the same thing. Instead of bloating C, anyone needing defer can use a subset of C++ that fits their needs.
- eMSF 5y ago
  C++ has no finally blocks.
  - AnonC 5y ago
    > C++ has no finally blocks. Not in the standard, but there are compiler implementations (like Microsoft’s) that have added it.
    - jcelerier 5y ago
      I just did a gh code search (__finally lang:c++), a hundred-ish instances shows up in ~12 repos mainly related to MS / .Net: ‎ sleuthkit/scalpel‎ ‎‎ microsoft/service-fabric‎ ‎ ‎dotnet/runtime‎ ‎ ‎microsoft/Detours‎ ‎ ‎dotnet/wpf‎ ‎ ‎Chuyu-Team/VC-LTL‎ ‎ ‎apache/logging-log4net‎ ‎ ‎microsoft/Windows-classic-samples‎ ‎ ‎microsoft/winfile‎ ‎ ‎dotnet/llilc‎ ‎‎ microsoft/DirectXShaderCompiler‎ ‎ ‎dotnet/diagnostics‎ ‎‎ SoftEtherVPN/SoftEtherVPN‎ ‎ ‎microsoft/PTVS‎ ‎ ‎aybe/Windows-API-Code-Pack-1.1‎ I don't think that it's in any way meaningful, it's literally unused given that it's been there for likely 20+ years.
- kaba0 5y ago
  You mix that up with RAII.
- isomel 5y ago
  Maybe you're mixing up with SEH (Structured Exception Handling) which is a Microsoft extension to C that came even before C++
- dgellow 5y ago
  So we moved from “defer” to “using a different language, with different semantics, and use the non-standard finally”.

usrbinbash 5y ago

How does "defer" make it harder to reason about the code? Especially when the alternative is a bunch of resource-flag-tests and cleanup labels? There is a reason why it was introduced in Go.

yk 5y ago
Because the compiler has to introduce code implicitly. The control flow is usually very explicit in C, with this feature it is less explicit.
- pjmlp 5y ago
  Until a signal gets raised.
  - jstimpfle 5y ago
    The comment was about the generated code, not about arcane OS hacks that were introduced to add asynchronous notifications to otherwise blocking OS APIs.
    - pjmlp 5y ago
      It is part of ISO C standard library.
- usrbinbash 5y ago
  So its better to make the control flow explicitly complicated with a bunch of labels and resource-flags and doing so inconsistently (because everyone has a slightly different view on how to implement it), than having the compiler do it in a consistent way? Pragmatic point of view: In 99% of cases, the developer doesn't care what the compiler produces and doesn't have to. A mechanism providing a complex control flow in the compiler output but is incredibly easy to read and reason about in the source code is useful in the vast majority of cases. And for the 1% of cases where the programmer actually needs to know what the compiler produces, and / or full control over the control flow, the solution is simple: don't use `defer` and there, done, full control to the developer. So where exactly is the downside?