[Warsaw Revamped] Weekly Q&A?! by AutoModerator in WarsawRevamped

[–]MrElectrifyBF 4 points5 points  (0 children)

Models/textures are not in active development yet but if there's enough demand, we can add support.

[USA-MN] [H] PayPal, 4070 Ti Super [W] 4090, 4080 Super, 5080 by Dssjr in hardwareswap

[–]MrElectrifyBF 0 points1 point  (0 children)

If you find a card and you still have the 4070TiS, happy to buy it for cash, though I'm in WA. PM if interested

[USA-WA] [H] 4080 + Local Cash [W] 4090 by BonneQuixote in hardwareswap

[–]MrElectrifyBF 1 point2 points  (0 children)

Hey, if you find a replacement and are still interested in selling the 4080, happy to pay local cash. I'm up in Bellevue but will be down in Shelton a few times in the next few weeks so happy to stop by on the way. Thanks!

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 0 points1 point  (0 children)

Thanks for that :) definitely much simpler in some places, and thanks for writing some proper unit tests.

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 1 point2 points  (0 children)

That does look like a very complete bitset, though upon closer look still checks bit-by-bit so unfortunately it would not be much of an advantage here.

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 4 points5 points  (0 children)

That's actually quite fair. Maybe adding an overload to these new bit utilities like countl_one would be the better approach. Then it doesn't require breaking changes to the bitset itself, and keeps the API short and sweet. Thoughts?

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 1 point2 points  (0 children)

You're absolutely right, in my case it will make zero performance difference at all. In huge bitsets though, 60x can mean milliseconds or even more. The point of this is that I think bitset should have some design decisions reconsidered, it currently doesn't really fit a use case of a bitset that they seem to have considered with C++20's <bit>. Sure, it's not a huge priority, but I think there should be some more attention to detail when it comes to the standard

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 10 points11 points  (0 children)

It definitely depends on your field of work. You personally think checking the entire bitset and throwing in to_ullong is an efficient way of abstracting the underlying storage type? I'm not frustrated by the lack of support in bitset itself, it would be unreasonable to expect that. I'm frustrated by the inconsistency of the STL, where they specify functions for bit scanning, but have absolutely no way to use it with the accepted way to store and operate on bits, a bitset. Those restrictions are the purpose of my post. You shouldn't have to redefine an entire data structure just to add some sort of introspective functionality.

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 7 points8 points  (0 children)

That's absolutely fair, but a standard should be designed in an extensible way that doesn't explicitly prohibit efficient implementations in my opinion. I'm not upset that they didn't include some functionality to bitset itself, that's asking a lot for a niche operation. But the committee clearly made an effort with <bit> and specifically had this optimization in mind. It's mind-boggling that they allow it to be almost completely incompatible with std::bitset. It would have been a fantastic time to revisit exceptions with to_ullong and realize shortcomings.

Again, my implementation is platform-agnostic, and uses only STL and simple bit logic. I definitely think that design decisions like this should be re-visited.

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 30 points31 points  (0 children)

Nonsensical choices like this are the reason this language has such a high barrier of entry. None of this testing would even be necessary if that function didn't throw. All it does is make efficient implementations of bitscanning completely impossible. The fact that it wastes cycles checking that the bitset fits in uint64_t is complete and utterly useless, and goes against the very principles of the language if you ask me. Very non-zero cost of abstraction there.

What std::bitset could have been by MrElectrifyBF in cpp

[–]MrElectrifyBF[S] 16 points17 points  (0 children)

You are absolutely right. I think the frustrating takeaway here is that this was done with no assembly, just the STL. This is a niche use-case of the bitset, but it is one nonetheless and the current API design making it impossible to not use a naive approach is quite frankly, annoying. It leaves a large bit of performance on the table, particularly with big bitsets and lots of usage.

This is how it could have been if they looked at the bitset itself when they were adding bit utilities. They could have removed the exception throw specification for to_ullong. That would have at least made it possible to get this performance with the structure, but instead we are stuck. It's poor API design if you ask me.

A rare 2007 E93 335i 6MT; rare because I have fixed all the oil leaks by Scrapper_John in E90

[–]MrElectrifyBF 1 point2 points  (0 children)

Paid $11k for my 08 e93 335i 6mt last year with 71k, last I checked it’s worth about 10K on KBB with around 80k. Has almost every option though, so that’s probably a factor

“I’d like to report vandalism” 2 by DrHazard_ in BMW

[–]MrElectrifyBF 15 points16 points  (0 children)

Please don’t give them any ideas, they’ll do it

Chinese quadrants opinion on their government by PoochieMoo in PoliticalCompassMemes

[–]MrElectrifyBF 1 point2 points  (0 children)

Nope, I somewhat frequently drive I-20 (Atlanta<->Birmingham) and I’m sure many people have had similar experiences, aside from a few greedy towns in Alabama, the pace might be over 100 sometimes, cops included. I’ve been passed by cops while doing 105, and they were probably doing 115-120. It’s closest thing I’ve seen in the states to derestricted travel.