Design your data to be thread safe
Some tricks for writing shell scripts
This article was published as a guest post on fluentcpp.com. Function poisoning is an interesting option to prevent the usage of a function in a codebase, but it is not always available. In some environments, your code is immune to poison. The pragma is also compiler-specific, as for now it only works with gcc and clang. That’s why I would like to present alternative approaches: deprecate and delete.
This article was published as a guest post on fluent cpp. What does it mean to poison a function? The gcc compiler has an interesting pragma that I’ve rediscovered after four years since I’ve noticed it the first time: #pragma GCC poison. It works as follow: If there is an identifier that you want to prohibit in your source code, you can "poison" it, in order to get a compile error if that identifier appears in your codebase.
Using regex for validation might cause more harm than good.
The introduction to this article series can be found here, whereas here you can find all posts. In the last article I mentioned how there are many algorithms for solving ODE’s, but showed only the implementation for explicit and implicit Euler. The reason behind my decision was that those algorithms, and many others as well, are part of a larger family of algorithm: The Runge-Kutta methods. Again, Wikipedia does a great job by describing how to put up such a system.