Somewhat of a week and lots of internets later, here's another "Interesting links" post already. At first I was kind of worried since there seemed to appear no interesting links at the end of last week, but yesterday and today it took off again. I want to make one special mention this week: the Wait but why blog. Why? Well, if you're somehow finding my blog worthy of your time, Wait but why will definitely not disappoint.
And now without further ado, the interestings links of past week.
[Article] How To Criticize Computer Scientists, or Avoiding Ineffective Deprecation And Making Insults More Pointed
As a (wannabe) computer scientist this was fun to read. Altough I'm not very sure about how useful it will actually be in practice, it gets the two types of computer scientists kind of right. It would probably get you a pretty good mileage if the computer scientist you're trying to take down hasn't read this article, and if the computer scientist is kind of senior (I don't think anybody told me about Hartmanis in the past 1.5 years). But please, as a sign of thanks, don't use it against me if the day ever comes.
[Article] The World's Dumbest Smart Pointer
This is an interesting concept which has been discussed in one of the more recent C++ Standard meetings. I think this is a very useful addition since it enables a developer to give another subtle message about the pointer and the intention of it. It also encompasses a use case which is not covered by your standard smart pointers (std::unique_ptr and std::shared_ptr): what if you want to keep managing the pointers lifetime, but also want to distribute it across your program? std::shared_ptr is an option, but the reference counting it implicitly does is unneeded. You could pass a raw pointer, but that doesn't give any indication about the intention of the pointer at all! Enter std::observable_ptr.
I'm not sure where but I read somewhere that smart pointers are also being added to give developers a sort of vocabulary to talk about pointers. For example, if you have a certain class which distributes raw pointers often, you'll have to describe the different kinds of pointers in the documentation. It would be something vaguely similar to this: "This one can be distributed across your program, but be sure to free it when all is done. This one needs to be explicitly owned and freed, you can't just copy it all over the place! This one can be observed by your program, but our manager singleton will take care of its lifetime." With the smart pointers you can just indicate this by choosing the correct type: std::unique_ptr, std::shared_ptr, and now also (hopefully soon) std::observer_ptr. Oh yeah, and the second document also lists a few alternative names for std::observer_ptr, be sure to check them out.
[Blog] OpenGEX - The 3D Format of Indie Game Developers?
When I was a (tiny) bit younger and did more 3D experiments than I do now, it annoyed me that 3D formats always were so... Vague. Sure, I didn't understand just about anything back then ("Why does nobody tell me how to just simply compile Spaceship.h! I hate compilers!") but 3D file formats always were a hassle. That's why OpenGEX sounds pretty good to me: it's just a json file, and it's maintained by the community (this can also be viewed as a downside, but let's not go into that right now). Also, the article itself does a pretty good job giving an overview on the current state of 3D object file formats, and explaining what's going wrong.
[Blog] How to use inotify-tools to trigger scripts on filesystem events
This is just a neat trick. I keep reading in various linux tool tutorials "People with some *nix skills can probably write an autoupdate script with inotify to run this everytime a file is updated". Sadly the people who write that stuff never post an actual script that does this. With this blogpost I now finally know!
[Blog] Container Algorithms
The syntax discussed in this blogpost is just so damn elegant! I couldn't resist, I think everyone should see it. It would be pretty awesome if we could iterate over a list like this and mutate things on the fly.
|
// Update gui by distributing events, updating animations, and rendering them
guiElements |= gui::handleEvents | gui::updateAnimation | gui::render;
// Update enemy components, sort in rendering order, and render them
enemies |= ecs::updateAI | ecs::updatePosition | ecs::updateAnimation | cont::sort | ecs::render;
// Update player objects, handle weapon physics, and finally sort and render them
players |= gui::handleEvents | ecs::updatePosition | ecs::updateWeapons | cont::sort | ecs::render;
|
I don't know, but it just looks really neat and ordered. I guess losing the for-loop noise it cool. Also, I think the meeting where his ranges were discussed is same c++ meeting where std::observer_ptr was a subject. Not sure though. So yeah. Read his post :D
[Articles] Guru of the Week
A series of articles which are an amazing read if you want to learn about the more fine-grained concepts of C++ and the philosophy behind it. The format is also really interesting (and in my opinion, effective): first a few (test like) questions are asked. You can choose to ponder them for a few minutes, or you can go on ahead and find out immediately that you were wrong. From my experience it seems that the updated GotW's (the ones on the site from Herb Stutter) are more clear and relevant, but both links are equally interesting.
[Post/Blog] Game Development on Twitch: Lessons Learned
Livestreaming gamedev has been on the rise lately, and with it came a lot of inexperienced streamers. This reddit post contains some great discussion in the comments, as well as a copy of and a link to the actual blog post giving the tips. For anyone thinking about livestreaming development, even if you don't expect many viewers, this is a mandatory blog post.
[Post/Blog] Why programmers work at night
A brief but interesting blog post about why programmers like to work at night. To me the most interesting point is about the huge mental investment: before you can get any (useful) work done, you first need to load all the structures and variables of the project into your mind. Having to help someone with something completely different or a meeting of some sort can cause you to have to reload everything again, which obviously take a lot of time. That's why I like the idea of IT companies scheduling as much meetings as possible in the morning, so at least the programmers can spend the noon loading and mutating that enormous set of variables and structures.
Comments
Comments powered by Disqus