A blog about C++ programming, more or less.
In C++, there exists many ways to end a program. You probably have heard most of them, but do you know how they are different from each other. It is important to be familiar with those termination mechanisms and their differences so that you can choose the right one at the right situation to make your programs better.
Oversubscribing physical resources on a VMs host is a common practice among administrators, who try to maximize the utilization of that host machine. Light oversubscription has only minor impact on the performance of applications running inside VMs, but if they push oversubscription too far, then the applications’ performance will suffer along with the host. As one of the applications’ engineer, it is important for you to understand what oversubscription is and when a performance issue is indeed caused by oversubscription.
Stack backtraces play a crucial role in programming, particularly in debugging and troubleshooting scenarios. Backtraces are essential tools for diagnosing a wide range of issues. Utilizing backtrace effectively when debugging is a core programming skill every developer should master. In this post, we’d like to discuss this skill in detail.
Logging is an important and integral part of software development. However, just like everything else, logging has its own downside as well. One of the typical issues with logging is actually having too many log entries. In today’s post, we are going to talk about the common ways to limit logging into a sensible rate.
In a programming language, such as C++, an assertion is a statement at a specific point in a program to help you to confirm that the statement it makes about your program is indeed true. Judicious use of assertions in a program may bring many benefits, especially, experience has shown that writing assertions while programming is one of the quickest and most effective ways to detect and correct bugs.[1] Thus, having assertions at the right places of a program is one of the most commonly used preemptive techniques for debugging.
Compiler warnings are messages produced by a compiler who is trying to warn you about potential issues in your code. Although, warnings don’t interrupt the compilation process, they should not just be ignored, as warnings may provide valuable insight and advice to keep your programs away from certain bugs. Paying attention to compiler warnings and keeping a low number of warnings is a commonly used preemptive technique to prevent bugs in the earlier phase of software development life circle. As it is said, it is much easier and cheaper to fix bugs in earlier stages than later ones.
Continue with my preview post, in today’s article, I am going to explore more about user-defined input stream buffers. For reasons you will see shortly, the input stream buffers are slightly more involved than the output ones. However, our existing knowledge with the output stream buffers will definitely help us understanding the input ones. So, if you haven’t, I strongly recommend you check out my output stream buffer post first.
You are probably already familiar with using iostream to perform I/O operations in C++. However, are you familiar with the backbone of the stream, which is the stream buffers. streambuf class is definitely a sophisticated class in the C++ standard library, if not the most sophisticated one. As it said, the complexity of the interfaces reflects tradition, the need for I/O performance, and the variety of human expectations.[2:§38.4] Nevertheless, a solid understanding of the stream buffer’s operations is required for implementing your own stream buffers. In today’s post, I am going to slice the streambuf into bite-size pieces and show you how to implement a user-defined output stream buffer.
You are probably already familiar with accessing files in C++ using fstream, but do you know there are at least two other common ways to access files? In this post, I am going to present all three ways of doing file I/O in C++. The goal is to create a concise reference which summarizes and compares all those methods, so that people can choose between them quickly and easily, if needed.
Recently, I have run into an issue with a python test script which is run by CTest. The test runs normally by itself, but it never terminates until its timeout is reached if launched by CTest. In this post, I’m going to show you how to reproduce this issue first, then how I tackled this problem, and, of course, the solution at the end.
You probably already known that, in C++, every temporary object has a lifetime, which begins when it is created and ends when it is destroyed automatically. However, do you know you can extend temporary objects’ lifetime with a reference? In this post, we are going to discuss the lifetime of temporary objects, how to extend their lifetime with a reference, and also the exceptions when that extension cannot be applied.
Recently, I run into an issue with OpenLDAP client library’s ldap_set_option() function, when I was trying to turn on the library’s internal debug logging. Due to its poor documentation, I have to dig deeply into its source code to find out the right way of setting the debug level of OpenLDAP library. In this post, I’d like to share what I have found, so that other people, who have similar issues, may save some of their time.
Are you tired of typing password when running LDAP commands with -W, but feel nervous about using plain text password with -w? Are you looking for a way to run LDAP commands that is both passwordless and secure? Then this post is for you.
The ldapwhoami command can tell you how the LDAP server sees you after authentication.[1] I found it is pretty helpful for understanding LDAP authentication mechanisms. In this post, I am going to present an introduction to ldapwhoami and discuss briefly about LDAP authentication mechanisms.
The second-system effect is a well-known buzz word in the world of software engineering. As many years after it was first described by Frederick Brooks in his classic The Mythical Man-Month, people are still talking about it. As you can see from my previous posts, the definition of the second-system effect is rather stricter than people think. Then one question raises naturally. Is it even practical to identify this effect from real world software projects? Even further, is it a real thing?
The second-system effect is a well-known buzz word in the world of software engineering. As many years after it was first described by Frederick Brooks in his classic The Mythical Man-Month, people are still talking about it. Unfortunately, the terminology, chose by Dr. Brooks, is kind of misleading. When people do talk about it, do they really refer to the same thing?
The second-system effect is a well-known buzz word in the world of software engineering. As many years after it was first described by Frederick Brooks in his classic The Mythical Man-Month, people are still talking about it. However, Dr. Brooks didn’t actually give a rigorous definition about it, which certainly caused some confusions. What does it really mean? Is it really as simple as the terminology suggested?