• 0 Posts
  • 11 Comments
Joined 3 years ago
cake
Cake day: July 5th, 2023

help-circle

  • I presume that the code was tested for various cases where there was at least one previous password on record, but everyone forgot about new users with no previous passwords. However I’m having trouble imagining what the code could actually be doing.

    I can only imagine a dynamically typed language, and a “checkedPasswords” variable being declared but uninitialized, then a loop incrementing that variable for each non-similar password pulled from the records, and finally a check to see if checkedPasswords equals the number of stored previous passwords.

    The execution environment could type and initialize the variable by default after the first increment, but in the case of the user having no previous passwords on record that wouldn’t happen, and the final equivalency check would be comparing an integer to some internal “NaN” state, thus failing.




  • I know it’s a really picky take, but I resent the implication that I should want to keep my personal files mixed in at the same level of the file hierarchy as all my applications’ random settings, cached data, and temporary garbage. Documents, Music, Videos, Projects, .config, .cache, SelfishAppName, OtherSelfishAppName…

    It bothered me when Microsoft started doing it in Win95, and it still bothers me in Linux. Especially when software acts surprised (or occasionally indignant) that I don’t keep all my files in those directories. I have lost small bits of my own work over the years by forgetting to back up things that recalcitrant software refused to store anywhere else.

    But I am amused that this is the same name that I use at the top of my own storage hierarchy for self-made things.



  • Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject

    There’s a book about 101 ways to cut potatoes. Perhaps that could be a real mike-drop bit of evidence that we shouldn’t be cooking potatoes.

    Here’s a 249-page book “just” about atomics and locks in Rust. Does a book this large about only one aspect of Rust prove that it’s a terrible language? No, because as with the C++ book, if we look at the summary of contents we can see that it actually covers a great deal more, simply with a focus on those topics.

    Luckily we don’t have to be compete masters of every aspect of a language in order to use it.

    Honestly, I think that modern C++ is a very piecemeal language with no clear direction, and it has many issues because of that. But the title and page count of a single book is not a convincing argument of anything.


  • I’m all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don’t know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn’t seem funny to me.

    1. Crazy initialization
      That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I’ve never seen used in the wild.

    At this point I had hope that this was meant to be amusing.

    1. Printing to the console
      C++ has had a version of C’s printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.

    They still could be going for a comedy roast, I guess.

    1. Getting a random number
      Much like the printf statement for number 2 above, C++ had its own version of C’s rand function from the start. I’ve never even heard of the stuff that’s being shown in this part of the video.

    OK that was virtually the same fake point as the previous one, and still no punchlines in sight.

    1. Having to type “static_cast” every time you recast a variable
      Nope, you don’t. You’re free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they’re often called “C-style casts”. There are even implicit casts, where you literally don’t add anything, and just cross your fingers that the compiler does what you think it should do. It’s like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there’s a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it’s not just a random bit of busywork added for no reason.



  • the cross platform is a pain.

    It doesn’t have to be with libraries like SDL. Years ago I got stuck fighting all-in-one game engines that didn’t fit my design choices, precisely because I thought it would be worth it for platform independence. Then I found out about SDL, which was what I actually wanted.

    If someone thinks that not using a pre-rolled engine with a full editing suite included is a waste of time, I can respect that. But there are options if you’d rather make your own but still don’t want to have to learn the ins and outs of multiple hardware architectures and operating systems.