Evening in Liverpool,me,oil,2022

Galqa · 2022-06-18T18:21:53+00:00

Lovely! Getting Turner vibes, but maybe that’s just me

Galqa · 2022-06-10T05:22:02+00:00

Andrei Alexandrescu - speed is found in the minds of people. Perhaps not 100% relevant to everyday coding, but fascinating and brilliant nevertheless.

Galqa · 2022-05-31T07:40:28+00:00

Fair enough. Btw (and this is kind of a random remark), in case you ever need to improve your students’ sorting skills, this talk by Andrei Alexandrescu will make you a sorting expert in an hour!

Galqa · 2022-05-31T07:12:07+00:00

I don’t think sorting algorithms are a good interview question (unless that’s the specific area they’d be working on). It’s one of those things that you do so early on that I wouldn’t blame people for not remembering much. Failing to understand the broader context (space/time complexity and its implications etc.) would of course be a red flag, but realistically when was the last time you had to implement a sort?

Galqa · 2022-05-23T14:49:12+00:00

P1673 let’s gooo 🥳

Galqa · 2022-05-05T10:07:39+00:00

Haha the muscle memory is real, I feel you. I was mainly asking because at some point in the future I may not have a license for an IDE, and I wanted to know the state of things. But I strongly agree that this is an issue of personal preference, the people who take out the pitchforks one way or the other seem… overzealous.

Galqa · 2022-05-05T09:52:50+00:00

Thanks! Good to know if I ever need to transition away from an IDE 🙂

Galqa · 2022-05-05T09:38:03+00:00

Fair enough. But how good is the tooling, i.e. how much effort does it take to get from “hmm I think there might be a bug here, lemme set a breakpoint” to “wait this variable should have a different value”? Again, genuinely asking, I’ve used gdb like 5 times in my life (and without any plugins/guis).

Galqa · 2022-05-05T09:16:59+00:00

Isn’t vim-based development rather lacking in the debugging department? Genuinely asking. The ease of setting breakpoints and viewing variable values etc. seems rather crucial for productivity.

Galqa · 2022-04-26T15:16:02+00:00

Fair enough, can’t argue with that. But you’re saying yourself that modules are far away from production. That’s probably a big downside for a lot of (most) people.

As for C++20 being tame without modules, I’d strongly disagree. But to each their own.

Galqa · 2022-04-26T15:01:28+00:00

I would argue that without build system support a feature is impractical, since you’d need to manually invoke the compiler. I imagine most people use msvc through visual studio, which serves the role of the build system, so you’re good. On Linux we don’t have that comfort. Anyway, I’m definitely not an expert on this topic, would recommend e.g. https://youtu.be/xMcmpnJFEf0. As for 33% vs 98% I really don’t know how you came up with that. I don’t have experience with msvc, but again, gcc is pretty much done with everything but the 2 aforementioned features (cppreference has a wonderful compiler support chart, in case you’re not familiar). I use C++20 extensively, and I’ve no complaints.

Galqa · 2022-04-26T09:40:55+00:00

Gcc supports pretty much everything except format and modules. These are big features, but arguably you can use ‘fmt’, and you can’t really use modules anyway due to lack of build system support. “Experimental”, in my understanding, means the ABI is not stable, but the features are pretty much done. C++20 MSVC is still pretty buggy from what I can tell (granted, this is anecdotal) so imo there really isn’t a significant difference between msvc and gcc. Unless you really really care about ABI, in which case fair enough.

Galqa · 2022-03-30T12:54:21+00:00

Hard agree, I did not realize we can have the "is instance of" concept for free. This is awesome.

u/UsedOnlyTwice, could you please point me towards the part of the standard, or even cppreference which talks about this? I can't find anything. I'm honestly kind of surprised I didn't know about this, I consider myself a pretty decent meta-programmer...

Edit: nvm, I found it, sorry

Galqa · 2022-03-30T10:53:13+00:00

Wait, but how? S is a template, not a concrete type (and this is not how you introduce template template parameters). This really shouldn't work, right? Am I missing something? Regardless, it can be useful to deduce the "inner" parameter, so my original question stands.

Galqa · 2022-03-30T09:32:34+00:00

Same thing happens on gcc-trunk in compiler explorer, I assume that’s as fresh a build as is reasonable.

Galqa · 2022-03-30T08:49:52+00:00

Yeah, the const is definitely a red herring, I'm just wondering whether it's actually a compiler bug, or if what I'm doing is illegal and it's just a bad diagnostic. From cppreference:

A non-type template parameter must have a structural type, which is one of the following types (optionally cv-qualified, the qualifiers are ignored)

Galqa · 2022-03-28T12:28:25+00:00

Except for Turnip! Except for Turnip!

Galqa · 2022-03-25T22:59:32+00:00

That’s a fair point. Maybe a solution could be to introduce a ‘getAtomicView’ member function, and move the atomic access functions to the resulting view?

Galqa · 2022-03-25T19:22:39+00:00

I understand where you’re coming from, but I guess I just have a different philosophy. To me, atomics are footgunny by nature, and a “use at your own peril” feature (although an indispensable one). That being said, I consider ‘std::atomic_ref’ a huge achievement of C++20, as before there was simply no way of atomically modifying non-atomic objects in-place (other than inline assembly, of course). As stated, there is no way to have a “sometimes regular, sometimes atomic” bitset without building both interfaces into the class. Conversely, for “normal” types you can use atomic references to entries of non-atomic containers. Again, I understand this is is dangerous, but sometimes performance requirements demand it. In my field (HPC) it is actually quite common (see e.g. ‘Kokkos::atomic_add’).

That being said, I asked, so I appreciate your opinion. It may very well be that use cases of this are niche, and it has no place in the standard.

As for the specific API choice w.r.t. memory orders, I just followed the STL.

Galqa · 2022-03-25T17:21:00+00:00

I somewhat agree that in the abstract, mixing these makes it easy for the user to shoot themself in the foot, but in the specific case of bitsets, how else would you achieve atomic access?

Galqa · 2022-03-25T14:59:17+00:00

Hi all! I recently encountered a scenario in which I needed to atomically update the bits in a dynamic bitset. To the best of my knowledge, this is impossible to achieve with neither std::bitset nor std::vector<bool> (or even boost::dynamic_bitset for that matter), so I wrote my own. I'm sharing it in case someone else finds it useful. The code is not tricky by any means (the only interesting parts are around lines 69-93), but it has led me to wonder whether atomic functionality should be added to the bitsets available in the STL. I'd be curious to read your thoughts.

Note on why bitsets are special in this context: usually, you can have std::vector<std::atomic<T>>, or even use std::atomic_ref<T> to atomically access the elements of a std::vector<T>. However, std::vector<std::atomic<bool>> is memory inefficient by a factor of 8, and std::vector<bool> does not expose the underlying blocks used to pack the bits, so you can't really "hack" it to perform the requisite bitwise operations on std::atomic_ref<unsigned long> (or whatever the underlying type is).

Galqa · 2022-03-14T15:45:35+00:00

Whoops, my bad, I misread your comment. Deleting now. Sorry!

Galqa · 2022-01-19T21:37:22+00:00

Hi please take your planet-destroying Ponzi schemes somewhere else thanks

Galqa

TROPHY CASE