C++

Recently, I started a small C++ project using AI. The most frustrating moment isn’t when it can’t write the code, but when it spits out a seemingly decent directory structure in three minutes and casually throws in a few third-party libraries, making the demo actually runnable. That’s the problem. You haven’t even figured out what the newly introduced library supports, how the compilation link works, or where its boundaries are, so rework is basically inevitable later on.

I’m increasingly feeling that what AI programming fears most is not the model being dumb, but starting too greedily. Especially with languages like C++, which don’t have much scaffolding to fall back on; if you miss one step upfront, later you have to account for several steps regarding compilation, linking, library versions, and directory structure.

Previously, when I debugged C++ in VS Code, the configuration basically stopped at launch.json, maybe with an extra line for GDB. Fill in the program, fill in the gdb, set the breakpoints. And then what? Then every time before debugging, I had to manually run cmake --build in the terminal. What was even more annoying was that after setting breakpoints on custom prices, contracts, or order types, the VS Code debug window often only showed a bunch of internal fields. The data was correct, but it wasn’t human-readable. The ridiculous part is that some tutorials I saw before stopped around launch.json. It wasn’t until recently, when I had an AI set up a new project for me, that it conveniently added preLaunchTask and gdb_printers.py, that I realized: debugging C++ in VS Code isn’t just about starting GDB. You can automatically trigger CMake compilation before debugging, and after hitting a breakpoint, you can even let GDB load a Python script to format business types into something readable for us. Honestly, this isn’t some black magic. But it perfectly filled two annoying gaps in daily C++ debugging: pre-launch build and variable display after a breakpoint.

When I recently wrote the algorithm service, as soon as I implemented modules like twap and vwap, this old problem popped up again.

If we rely on class names to enforce semantics in C++, the naming convention quickly becomes out of control. Things like TwapOrderManager, VwapOrderManager, and AlgoOrderManager sound like, “I know my structure isn’t contained, but I’ll at least add a prefix.” Frankly speaking, organizing by folders and then adding a layer of namespace isn’t about code snobbery; it’s filling the gap that C++ has because it lacks Java’s native package system.

This article analyzes the bizarre phenomenon in C++ development where unordered_map::find returns an object with mismatched fields after a hit. The root cause lies in defining a static lambda within the function and using reference capture to capture local variables, leading to a dangling reference after the first call, triggering undefined behavior (UB) and polluting cache data in subsequent calls. It is recommended to address this issue by explicitly passing parameters instead of implicit capture, managing lifecycles properly, and utilizing Sanitizer tools.

Optimizing performance for a hot function involves the bulk of the time spent within internal loops. AI suggested using enumerate and ranges, so I consulted some related documentation.

The main content of the article was generated by AI, and I tested the code and added some supplementary explanations. Online Compiler – testing C++ code inevitably involves our old friend.

On gcc13, traditional for loops were slightly faster than std::views::enumerate, which is negligible in practice.

The existing communication protocol within the group uses steady_clock as a timestamp to calculate the latency for each individual node. In a specific scenario, a message packet’s built-in timestamp was used, and this timestamp originated from another machine – resulting in an anomalous latency calculation.

As a side note: Gemini2.5 Pro shows promise of completely surpassing GPT-4.

C++ service crashed. The service depends on a static library for compilation. The static library made modifications, adding members to the header file and re-publishing the binary static library file. The service relies on the new binary library file, compiles and runs normally, but then crashes. The crash point appears fine, similar to the crashes caused by compiler upgrades – undefined behavior, an untrustworthy stack trace. Updating the service’s dependent header files allows it to mutate correctly, and running also works normally. A detailed explanation is needed, involving computer science knowledge, I suspect it’s related to memory layout, with examples for a thorough explanation.

In actual C++ development, bitwise operations are a common technique, especially when dealing with system states, flags, or control bits. Bitwise operations can provide very efficient solutions. This article will illustrate how to use bitwise operations to retrieve and set specific flags through an example.

Bitwise Operations Fundamentals

In computers, data is stored in binary bits (0 and 1). Bitwise operations are operations performed on these binary bits. C++ provides several commonly used bitwise operators: