• Content count

  • Joined

  • Last visited

Community Reputation

9823 Excellent

About formerly_known_as_samoth

  • Rank
    Advanced Member
  1. They're different from the ones that the WayBackMachine shows for December 17, 2016 (and certainly different from the ones I agreed to in 2008 or so). Be that as it may, little does it matter. I bid you farewell.
  2. The technical issues of which there are many, the inability to use the site at all without javascript and the immense reduction of the signal/noise ratio that came with this update are not the dominating problems which makes me consider leaving the community in all seriousness. The main issue with the site upgrade are the modified terms and conditions that you piggy-backed onto the update. Among these are several terms and conditions which, frankly, are barely acceptable if at all. In particular, I find paragraph 3, paragraph 5.1, and the last sentence of 11.1 objectionable.
  3. They're an attempt to keep activity up. An ill-advised attempt, in my opinon. You no longer get reputation for activity, only for upvotes. But you get "pixels" for activity. And, to "encourage" you, you're losing pixels for inactivity.
  4. That must be the funniest ever error message I've seen in my life. And maybe the longest (standard library template errors with 5,000 lines of "instantiated from", doesn't really count). But you can't say it doesn't tell you exactly what's wrong in the compiler's opinion or what you have to do. The compiler I used to get the above was GCC 7.1, I didn't bother trying clang... was too frustrating with a single compiler already.
  5. What is the difference between...?       struct foo     {             uint16_t a;             uint16_t b;             uint16_t c;             uint16_t not_used;     }; and     union foo     {         uint64_t dont_care;         struct         {                 uint16_t a;                 uint16_t b;                 uint16_t c;                 uint16_t not_used;         };     };     Well yes, 47 characters. But apart from that, what if you e.g. make a std::atomic<foo>? For a compare-exchange, the difference is around 200 instructions! And no, the union is not the one with more instructions. :) It is of course well-known that std::atomic doesn't guarantee that just about everything be atomic, in particular it gives no guarantees whatsoever except on atomic_flag. How could one guarantee every possible thing being atomic, anyway -- the hardware doesn't necessarily even support that. OK. Accepted. But you can somewhat expect that something that easily fits within the instruction set's capabilities (an integer, a struct of two integers, four smaller integers) is "just atomic" anyway. Well, that's not the case. But what's really stunning is not so much that the compiler fails to emit e.g. a single CMPXCHG8B when it could just do that in the first case. What truly does me is that if you give the compiler a "hint" by aliasing with an uint64_t as in the second case, then all of a sudden, as if by magic, it works... How did I find out? You don't want to know. :lol: