6 ms·

Why would you implement your own atomics? It seems very similar to std::atomic, except you need to do a bunch of platform specific hacks to get it to work. The

by slaymaker1907 3y ago

Why would you implement your own atomics? It seems very similar to std::atomic, except you need to do a bunch of platform specific hacks to get it to work. The only possible reason I could think of why you would do this is if you aren't using at least C++11. If you aren't using C++11, then you probably shouldn't be using threads in the first place.

qwery 3y ago
I can't speak for the author, but using `std::atomic` would presumably break one of the project's listed principles: > No C++ Standard Library / Exceptions / RTTI
- reactordev 3y ago
  Which is like making cookies without butter. It can be done, but why would you want to? The standard library exists for this reason. To provide these abstractions. And I laugh at the idea that C++ could ever be exception free.
  - qwery 3y ago
    > why would you want to? It seems like you know C++ pretty well, so I think you could probably come up with some reasons if you gave it a try. The obvious thing that comes to my mind is because you can't rely on an undesirable, unknown, or potentially nonexistent implementation of the STL for your target platform. As for cookies: who am I to dictate what/how someone should bake?
  - 112233 3y ago
    As a person working in a large exception-free C++ environment, I'm all ears.
    - pjmlp 3y ago
      I assume you're making use of no-throw placement new and not touching any standard library type, whose error conditions as available only via exceptions as per ISO C++. Otherwise good luck porting that exception free code across multiple OSes and C++ compilers, not only the big three.
      - rockwotj 3y ago
        Presumably they just use -fno-exceptions, and not everyone has to have portable code. I appreciate the concept but pragmatically there are plenty of C++ server side projects that only use Clang and GCC
        pjmlp 3y ago
        Yeah, and then come into twitter complaining when the code fails spectacularly after a compiler upgrade.
        reactordev 3y ago
        “-fno-exceptions“ Here-in lies the problem. This only says “no std::exception” “no throw” but nothing is stopping you from writing your own template for error handling. An exception is by definition a “unexpected condition” and we all have to handle exceptions in some form or fashion. Whether that’s with error codes, macro checks, or the like. That’s my point. Exception free code doesn’t exist. Safety guarantees are compile time at best. If this weren’t true, things like memory manipulation wouldn’t be possible. But it is. CheatEngine exists. Funnest thing is to read a var, set a var, and then check if the set var equals the set value or if it equals the old value. You just detected a memory pin cheat.
        diath 3y ago
        I think you're terribly misguided here; when people discuss "no exceptions" here, they do not mean "any error handling that is not the typical/expected flow", they mean "getting rid of built-in exception system that comes with the heavy price of stack unwinding and the related mechanisms", not that they do not want to handle errors.
  - jandrewrogers 3y ago
    I am always baffled by the assertion that C++ cannot be exception-free. The vast majority of C++ code bases I have worked on, at companies large and small, have been exception-free. It is completely ordinary to have no exceptions, and is largely the de facto reality for a lot of C++ development. In some vanilla app code exceptions are fine, but they introduce nasty edge cases in the kinds of systems code architectures C++ is mostly used for these days. Additionally, they don’t solve an urgent problem in practice that would strongly incentive someone to use them, so it the price of admission is rather steep for minimal benefit.
    - reactordev 3y ago
      You can’t guarantee the underlying memory so you can’t guarantee your app won’t blow up. You can handle errors, or expects, or however you want to call “exceptions” without the stdlib but you still have error states, you still have deterministic code branches, you may not have RTTI and non-deterministic std::exception but you still have the concept of an exception. The alternative is to segfault.
      - jandrewrogers 3y ago
        You are correct that there is code that solves a similar class of problems as exceptions. This code exists because it is can gracefully handle cases that exceptions handle poorly, in addition to the cases exceptions handle well. The literal C++ exceptions are an inferior tool. It is trivial to “guarantee” the underlying memory and is idiomatic for a lot of software that cares about performance or reliability. That is code anyone can write if they care. There isn’t much that can go wrong with memory allocation if you are not allocating memory from the system. No one is requiring C++ developers to poorly duct tape a bunch of rubbish STL together and call it an app. That simply isn’t something you see much in the hardcore systems domains where C++ is the tool of choice. Somehow, mission-critical software is routinely written in C++ without exceptions and it works just fine. Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them. And no, the alternative is not a segfault. C++ is designed to work just fine without exceptions. The language allows you to bring your own error/exception handling models with minimal overhead, same way you can import alternative ownership/safety models.
  - pagghiu 3y ago
    You can definitively use C++ in exception free way. I've been working on multiple Exception free codebases for work. One large open source project that is using Exception free C++ is SerenityOS for example https://github.com/SerenityOS/serenity https://github.com/SerenityOS/serenity The best way to write proper exception free C++ is not to use the C++ Standard Library.
    - reactordev 3y ago
      No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing. Whatever you want to call it, ErrorOr, OptionalWithError, Exception, you have branching code paths that deal with null/undefined conditions vs your known happy path. Exceptions / Error Handling / it’s all the same class of crap. Only in C++ land do developers delusion themselves into thinking their way isn’t this way. That exception free means just simply not doing try/catch. jandrewrogers made a good argument below about memory safety and allocations in regards to mission-critical code but even in that scenario, underlying memory can be manipulated by MITM or other conditions that could cause corruption or segfaults in allocator pages.
      - pagghiu 3y ago
        > No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing. I think that handling errors with ErrorOr<T,E> or similar techniques (I use something similar too) is very different from exception handling. My main problems with exception handling are: 1. It's not zero-overhead (brings in RTTI often) 2. You can't know if a function throws something by looking at its signature 3. You don't know what types exceptions a function can throw 4. It doesn't force users to handle errors that can happen, leading tomore "happy path" style code Something like ErrorOr or similar with [[nodiscard]] ticks all the above 4 points.
        reactordev 3y ago
        If the argument is purely don’t use std::exception if you don’t want the overhead, use MyExceptionTemplate because it doesn’t introduce overhead then sure, I’m for that. If the argument is don’t use it because it’s non-deterministic, use MyErrorWrapperMagic, fine. But in the software engineering sense you are still exception handling, only deterministically - which I like. Everyone is getting hung up on semantics of std::exception instead of exceptions. Exceptions are a part of everyday coding. Why we call things exception-free when we really mean “goto-free”. I’m not a fan of goto jumps in my code. ErrorOr is a better design for things to be deterministic. The point I was trying to make is that exceptions are errors and error handling and exception handling (while implemented differently) are essentially the same thing. In C++ std::exception is “exceptions” and everything else is “pretty error”. It doesn’t matter how the house is decorated. Exceptions = Errors = Oopsies = NotIntendedState
- pagghiu 3y ago
  Exactly! This is all in an effort to bring down compile times, avoiding including anything from the standard because you can never know if including <atomic> is bringing 10K lines of code in your header. I will probably provide an optional USE_STANDARD_HEADERS flag someday to allow including a few standard things, including atomics, to avoid doing things wrong on compilerS that are not tested enough (as I clearly can't test every compiler).
jbandela1 3y ago
Also, std::atomic is one of those special types. It is deeply integrated into the C++11 memory model. The compiler has to know about the semantics of the type to make sure it doesn’t reorder operations around it.
- deleted 3y ago
  [deleted]

qwery 3y ago

I can't speak for the author, but using `std::atomic` would presumably break one of the project's listed principles: > No C++ Standard Library / Exceptions / RTTI

reactordev 3y ago
Which is like making cookies without butter. It can be done, but why would you want to? The standard library exists for this reason. To provide these abstractions. And I laugh at the idea that C++ could ever be exception free.
- qwery 3y ago
  > why would you want to? It seems like you know C++ pretty well, so I think you could probably come up with some reasons if you gave it a try. The obvious thing that comes to my mind is because you can't rely on an undesirable, unknown, or potentially nonexistent implementation of the STL for your target platform. As for cookies: who am I to dictate what/how someone should bake?
- 112233 3y ago
  As a person working in a large exception-free C++ environment, I'm all ears.
  - pjmlp 3y ago
    I assume you're making use of no-throw placement new and not touching any standard library type, whose error conditions as available only via exceptions as per ISO C++. Otherwise good luck porting that exception free code across multiple OSes and C++ compilers, not only the big three.
    - rockwotj 3y ago
      Presumably they just use -fno-exceptions, and not everyone has to have portable code. I appreciate the concept but pragmatically there are plenty of C++ server side projects that only use Clang and GCC
      - pjmlp 3y ago
        Yeah, and then come into twitter complaining when the code fails spectacularly after a compiler upgrade.
      - reactordev 3y ago
        “-fno-exceptions“ Here-in lies the problem. This only says “no std::exception” “no throw” but nothing is stopping you from writing your own template for error handling. An exception is by definition a “unexpected condition” and we all have to handle exceptions in some form or fashion. Whether that’s with error codes, macro checks, or the like. That’s my point. Exception free code doesn’t exist. Safety guarantees are compile time at best. If this weren’t true, things like memory manipulation wouldn’t be possible. But it is. CheatEngine exists. Funnest thing is to read a var, set a var, and then check if the set var equals the set value or if it equals the old value. You just detected a memory pin cheat.
        diath 3y ago
        I think you're terribly misguided here; when people discuss "no exceptions" here, they do not mean "any error handling that is not the typical/expected flow", they mean "getting rid of built-in exception system that comes with the heavy price of stack unwinding and the related mechanisms", not that they do not want to handle errors.
- jandrewrogers 3y ago
  I am always baffled by the assertion that C++ cannot be exception-free. The vast majority of C++ code bases I have worked on, at companies large and small, have been exception-free. It is completely ordinary to have no exceptions, and is largely the de facto reality for a lot of C++ development. In some vanilla app code exceptions are fine, but they introduce nasty edge cases in the kinds of systems code architectures C++ is mostly used for these days. Additionally, they don’t solve an urgent problem in practice that would strongly incentive someone to use them, so it the price of admission is rather steep for minimal benefit.
  - reactordev 3y ago
    You can’t guarantee the underlying memory so you can’t guarantee your app won’t blow up. You can handle errors, or expects, or however you want to call “exceptions” without the stdlib but you still have error states, you still have deterministic code branches, you may not have RTTI and non-deterministic std::exception but you still have the concept of an exception. The alternative is to segfault.
    - jandrewrogers 3y ago
      You are correct that there is code that solves a similar class of problems as exceptions. This code exists because it is can gracefully handle cases that exceptions handle poorly, in addition to the cases exceptions handle well. The literal C++ exceptions are an inferior tool. It is trivial to “guarantee” the underlying memory and is idiomatic for a lot of software that cares about performance or reliability. That is code anyone can write if they care. There isn’t much that can go wrong with memory allocation if you are not allocating memory from the system. No one is requiring C++ developers to poorly duct tape a bunch of rubbish STL together and call it an app. That simply isn’t something you see much in the hardcore systems domains where C++ is the tool of choice. Somehow, mission-critical software is routinely written in C++ without exceptions and it works just fine. Error states are a normal part of all code, no exceptions required since obviously many languages don’t have them. And no, the alternative is not a segfault. C++ is designed to work just fine without exceptions. The language allows you to bring your own error/exception handling models with minimal overhead, same way you can import alternative ownership/safety models.
- pagghiu 3y ago
  You can definitively use C++ in exception free way. I've been working on multiple Exception free codebases for work. One large open source project that is using Exception free C++ is SerenityOS for example https://github.com/SerenityOS/serenity https://github.com/SerenityOS/serenity The best way to write proper exception free C++ is not to use the C++ Standard Library.
  - reactordev 3y ago
    No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing. Whatever you want to call it, ErrorOr, OptionalWithError, Exception, you have branching code paths that deal with null/undefined conditions vs your known happy path. Exceptions / Error Handling / it’s all the same class of crap. Only in C++ land do developers delusion themselves into thinking their way isn’t this way. That exception free means just simply not doing try/catch. jandrewrogers made a good argument below about memory safety and allocations in regards to mission-critical code but even in that scenario, underlying memory can be manipulated by MITM or other conditions that could cause corruption or segfaults in allocator pages.
    - pagghiu 3y ago
      > No, instead of using std::exception, serenity has ErrorOr template. C’mon, that’s basically the same thing. I think that handling errors with ErrorOr<T,E> or similar techniques (I use something similar too) is very different from exception handling. My main problems with exception handling are: 1. It's not zero-overhead (brings in RTTI often) 2. You can't know if a function throws something by looking at its signature 3. You don't know what types exceptions a function can throw 4. It doesn't force users to handle errors that can happen, leading tomore "happy path" style code Something like ErrorOr or similar with [[nodiscard]] ticks all the above 4 points.
      - reactordev 3y ago
        If the argument is purely don’t use std::exception if you don’t want the overhead, use MyExceptionTemplate because it doesn’t introduce overhead then sure, I’m for that. If the argument is don’t use it because it’s non-deterministic, use MyErrorWrapperMagic, fine. But in the software engineering sense you are still exception handling, only deterministically - which I like. Everyone is getting hung up on semantics of std::exception instead of exceptions. Exceptions are a part of everyday coding. Why we call things exception-free when we really mean “goto-free”. I’m not a fan of goto jumps in my code. ErrorOr is a better design for things to be deterministic. The point I was trying to make is that exceptions are errors and error handling and exception handling (while implemented differently) are essentially the same thing. In C++ std::exception is “exceptions” and everything else is “pretty error”. It doesn’t matter how the house is decorated. Exceptions = Errors = Oopsies = NotIntendedState
pagghiu 3y ago
Exactly! This is all in an effort to bring down compile times, avoiding including anything from the standard because you can never know if including <atomic> is bringing 10K lines of code in your header. I will probably provide an optional USE_STANDARD_HEADERS flag someday to allow including a few standard things, including atomics, to avoid doing things wrong on compilerS that are not tested enough (as I clearly can't test every compiler).

jbandela1 3y ago

Also, std::atomic is one of those special types. It is deeply integrated into the C++11 memory model. The compiler has to know about the semantics of the type to make sure it doesn’t reorder operations around it.

deleted 3y ago
[deleted]