guess the language!
unnecessary bound checks,
runtime type information,
overuse of abstractions,
global state in libraries,
repeated half-assed reference counting,
repeated half-assed implementations of common data structures/algorithms,
tons of fragile platform specific code.
Alternatively you can avoid changing the iterator concept by changing the algorithms, leaning onto the elementwise logical negation operator ~.
For this to make sense you have to introduce a new type: an array of bools with an associated reduction operation - conjunction or disjunction, that would represent the equality comparison in each dimension and contextually convert to a boolean, by performing the reduction. The == operator will return such an array with conjunciton, since that's what makes more sense for the tuple in general. Now the logical ! in order to also remain sensible will need to negate the elements of the array AND change the conjunction to a disjunciton, adhering to De Morgan's law. The elementwise ~ however has no such obligations of logical consistency (it's wavy, it's chaotic, it's insaneee) and can happily just negate the elements leaving the reduction operation untouched. This coincidentally is both exactly what we need for loop conditions and exactly what we always had when working with integer types as bit vectors (so hopefully it shouldn't be that alien of a syntax). What I'm getting at is that the range based for loop and algorithms should use ~(first == last) instead of (first != last) as a loop condition. Unfortunately the (fisrt == last) for early returns and such, will turn into ~(first != last) with this approach... that's double negation... disgusting... and I forgot the #cpp in OP -_-
stumbled upon another type of multi-dimensional iterator that you just can't have in STL in it's current form :
Goal: Iterate over multiple containers in tandem.
Solution: Iterator tuple wrapper that applies all relevant operations to it's elements.
Problem: the range based for loop, the algorithms library, and the whole concept of iterators relies on equality comparison. The loops increment the first(begin) iterator while it's not equal to last(end) iterator, some algorithms exit early if first == last, etc. In this case we want the iteration to stop when one of the ranges is exhausted, therefore the inequality of the tuple must be implemented as a conjunction of element-wise inequality comparisons, that is the tuples will be unequal only if all their corresponding elements are all individually unequal. The tragedy is that this makes absolutely no sense in any other context and is a bonkers way to implement inequality for a tuple (or any other vector/collection type), since any two tuples that have only one element in common will be considered equal. Alas this is what you have to do to satisfy the standard library. The only solution to this would be to change the iterator concept to use a different function (maybe called std::reaches(first, last)), that will just default to equality comparison unless specialized for a given type. The use of equality comparison is already conceptually dubious for ranges that use sentinel end iterators (like input streams, lazy generators, or when you want to do less than because some overflow is allowed and expected), but when you try to up the dimensions even in the trivial cases it just completely breaks apart.
string? what does that even mean? why is it not called a char_array or something? and then null terminated string? You mean random_access_char_stream? Who came up with this nonsense? and everyone is gobbling it up!
xfce: you can setup as many panels as you want!
also xfce: https://forums.linuxmint.com/viewtopic.php?t=296092
unity game: *installed in games folder*
Games folder: *exists*
unity game: *can't find data files in Games folder, won't start*
me: *removes Games folder*
unity game: *starts*
how do you even manage to do that? Are you capitalizing every path component? Are you case insensitive searching for em? spectacular...
Roti Prata is really nice. If you ever visit Singapore, don't miss it. If course the true answer to the question that that the best place can be found in the North 😂
If anyone has a good example of a similar channel in their own country that I can watch, please share a link.
how do you even make a puzzle game...
ok, cool thread, but the dongle works on Linux trisquel 4.15.0-142-generic just fine without any such workarounds and doesn't work on anything past 5.4 with or without these such workarounds...
wow these bozos were quick to cash in on MY IDEA
who would by that though, are PS4 dpads made of adamantium or something?
joke's on me, spend the whole day to find this troll of a bug
nevermind random crashes, constant misconfigurations and irreconcilable video driver issues, just sitting there for 60 seconds has gotta be the most infuriating bug ever... go ahead and figure out why nothing is working when everything is right... low priority, cause wait a minute... it still works
this actually worked, feels and plays better than any dpad I ever tried, and that's for any type of game, other than maybe some hypothetical no tolerance rhythm game where you'd need to develop muscle memory for quick and precise diagonals. The shape and the position of the buttons is really important, but them being a one piece is just defective design.
manjaro I have: drm + kernel can't figure out how to 2 monitors or who's fault it is
trisquel I want: "not an absolutely ancient gpu? nope!"
guix I want: failed to install itself with a cryptic lisp stack trace and borked my grub
xubuntu LTS I get - just works
my granma is on xubuntu and I'm on xubuntu cause xubuntu just works
here is how you do it properly
you mount the buttons sideways, press them by pushing a lever around and get proper feedback when changing directions, especially from axial to diagonal. I'm pretty sure I had a tiny knob version of this on a flight stick, much smaller than most dpads.
Laying them flat is cheaper? Sure, but then stop gluing them together and pretending you made a stick.
each logical component of a library should have:
smol brain: one file to represent it
big brain: one interface file and one implementation file to represent it
huge brain: one interface file, one type generic implementation file and one type specific implementation file to represent it
galaxy brain: one interface file, one type generic implementation file, one type specific inline implementation file, and one compilation unit file to rule them all, find them all, bring them all and in the darkness bind them all.