As mentioned in my previous blog post, I hope to examine a more interesting comparison for the different types of methods. Note that this comparison completely ignores the different use-cases for each type, it is therefor only relevant for ‘pure functions’, as in that case it doesn’t matter whether they belong to a class or whether they are static or not.
In comparison to Java, C++ does not force you to make all methods part of a class. Instead you can also have regular methods, which are often used for helper methods that only rely on their input parameters to generate an output. It is obvious that these methods don’t have to be part of a class as they do not require any state, they are what we call pure methods.
But you can also have regular methods and static methods outside of a class. Although this seems odd since isn’t static only saying that it does not require a class to be called, but since the method isn’t part of a class in the first place, what is the point of doing this?
In the previous blog post I wrote how you can have a simple ‘to string‘ method for a C++ object. My proposed solutions however, like in all languages, require you to have access to the code of that class and be able to alter it. There is however a way that allows you to ‘extend’ a class with some methods without needing actual access to the source code. In this blog post I will show you how you can implement output stream operator <<, and then discuss this approach more generally.
It won’t be long before you run into the situation where you want to print an object. And when you do so, you of course want to have a meaningful representation of your object and not just the memory address. In Java and Python you have ‘special’ methods that are meant to do this translation for you, being toString and __str__ and __repr__ respectively. But what about C++?
This is a blog post that has been on my ‘to-write’ list for a long time. The first inspiration came from how we did release management at my previous job (which was nearly non-existing) but due to some lack of content I put it on hold. After the switch to a different company I have some more things to compare and thus some actual content to discuss.
In this blog post I will look at a couple of ways on how releases can be managed. This includes everything from how to create an actual release, what steps are involved, to how to distribute it.
I always believed (and still do) that logging and debugging served a very different function. Where logging is provided to be able to check the status of a system, as some sort of feedback what is going on. Whereas debugging is aimed at fine-grained inspection of the system most likely because it is behaving wrongly and you are trying to find out why.
Nevertheless the approach of adding logging statements as a way of debugging is common, which is enough reason to discuss the different approaches and compare them with each other.
In the previous blog post I examined the ‘meaning’ (or context if you like) of an event. I come to the conclusion that simply keeping an event as a trigger to indicate something happened is, in my opinion, the best approach. But how does this relate to the information shown to the user? That is what I will investigate in this blog post.