Passing C++ STL Strings vs. String Views at the Windows C API Boundary -- Giovanni Dicanio
A common question that is often asked is whether C++ STL string objects (like ) or string views (e.g. std::wstring_view) should be passed as string parameters at Windows C-interface API boundaries. The following articles tries to shed some light on this subject, answering that question:std::string/wstring
Passing C++ STL Strings vs. String Views as Input Parameters at the Windows C API Boundary
by Giovanni Dicanio
From the article:
Passing STL std::[w]string objects at Win32 API boundaries is common for C++ code that calls into Win32 C-interface APIs. When is it safe to pass *string views* instead?
(...) the code will work fine. In fact, the wstring::c_str() method is guaranteed to return a null-terminated C-style string pointer.
On the other hand, if you pass a string view like std::wstring_view in that context, you’ll likely get some subtle bugs! Try experimenting with the above API and something like “Connie is learning C++” and string views!

Exploring how different languages solve the same problem often reveals interesting contrasts, especially when it comes to implementing powerful features like reflection. While C++26 aims to introduce introspection and code generation via P2996 and P3294, Rust’s approach using its derive macros offers a mature solution for code generation, even without introspection, highlighting different philosophies in language design and their practical applications.
In C++20, the standard library introduced new synchronization primitives: std::latch and std::barrier. These are the utilities designed to coordinate between concurrent threads.
When you transition from older C++ standards like C++11 or C++14 to the latest C++17 and C++20 it can be a tough journey. It's essential for writing clean and easy-to-maintain code, but many developers find the process challenging.
When designing a circular doubly-linked list, the initial challenge is determining how to manage the construction of new nodes in relation to existing ones. While constructors seem like a natural fit for placing nodes before or after a given node, overloading them can lead to ambiguity and poor design choices. Instead, using distinct tag types or factory methods provides clearer intent, ensuring flexibility while respecting the constraints of guaranteed copy elision for node addresses.
Previously, I tried to answer the question:
C++ On Sea took place in Folkestone again in February this year. Sandor Dargo shares an overview of his favourite talks and some emergent ideas.