C++

In the history of C++ development projects, we utilized a custom protocol for communication, which employed a two-dimensional array pattern. When processing large volumes of data, the protocol required iterating through the arrays and performing serialization operations to generate logs. Due to its low efficiency, this resulted in noticeable lag or stuttering within the system under heavy load, as reported by the business departments.

Problem Identification

When troubleshooting the issue, we first performed a performance analysis of the system and discovered that CPU utilization increased significantly when processing large amounts of data, and system response times became longer. By analyzing the system logs, we identified numerous serialization operations, which were inefficient when handling two-dimensional arrays, leading to a decline in system performance.

In C++, lambda expressions are a convenient way to create anonymous functions that can capture external variables and use them within their bodies. This makes lambdas a flexible programming tool. However, the lifetime of parameters in a lambda expression is an aspect that requires careful attention, especially when capturing and passing parameters.

1. Lambda Expression Parameter Lifetime

The lifetime of parameters in a lambda expression is typically the same as that of other C++ functions. Parameters exist while the function is being called, and their lifetime ends when the function call terminates. However, due to the possibility of lambdas capturing external variables, the parameter’s lifetime is also affected by how it’s captured.

In the same business code scenario, the program compiled and ran normally in a CentOS 7 environment. However, when switching to CentOS 8 and using an updated version of GCC for compilation, the program crashed. It’s worth noting that the issue only occurs in Release mode, while Debug mode does not exhibit any problems. This is the first time we’ve encountered a situation like this; after three days of investigation, we finally identified the root cause.

This article aims to reveal the potential for program crashes when `std::map` containers are incorrectly used in C++ programming. Specifically, attempting to access a non-existent key using bracket operator automatically adds an empty element. We will delve into this misunderstanding and demonstrate its potential risks through example code.

Storing simple values poses no problem; however, if you store pointers, issues arise. Because a pointer is an address, and if it's not initialized, the address is undefined, leading to program crashes.

Text

In the C++ standard library, std::map is an associative container that stores elements in ascending order of keys (key) and provides efficient keyword lookup functionality. However, novice developers sometimes fall into trouble because they misunderstand the behavior of the square bracket operator [] in std::map. In fact, when using [] to access a non-existent key, std::map inserts a new key-value pair, and the default constructor will be used to initialize the value type corresponding to that key.

Designed a行情 SDK, implementing different callback function implementations, and performed an extensive test. Recently I’ve been looking into C++ function programming, where functions have become first-class citizens, flowing within the program internally – what’s the difference in performance?

Previous article link: Compiler, Callback Functions, Performance Testing leimao大佬 also did similar tests, so I borrowed their code.

While reviewing the code, std::this_thread::yield() suddenly popped into my view, a syntax sugar from C11 that I’d used quite a bit, but hadn’t noticed before.

Starting from my academic years, I’ve been working with C++ for over ten years. So, why do I need to learn other programming languages?

Work experience: Lacking experience in elegant module design, C++ syntax is freeform. Learning other languages helps me guide the development of more elegant designs.

I often use them when writing some tools. The design principles for low-level libraries and business modules are also becoming clearer.

A custom allocator can improve performance, increase memory utilization efficiency, and address the issue of frequent, small memory allocations.

Antecedent

Recently, I’ve been working on the development of network data packets, requiring frequent allocation and release of small blocks of memory. Initially, I considered using a memory pool, reviewing several existing ones and discovering this: https://github.com/cacay/MemoryPool When looking at the interface, I was quite puzzled by how the memory pool’s implementation was a bit strange. The MemoryPool implementation logic involves allocating fixed-size memory blocks. Having reviewed Boost’s memory pool interface, it provides a template that is instantiated when used. Fortunately, this library already had an article describing it, mentioning the concept of an ‘allocator’.