An informal comparison of the three major implementations of std::string

by Raymond Chen

In the original version of this article, I got the sense of the “small/large” bit backward in the clang implementation. This in turn led to redoing the code generation and new code golfing results.

We’ll compare these versions based on the complexity of some commonly-used operations.

C++ Safety with Herb Sutter

by Jordi Mon Companys in Software Engineering Daily

It's really, really important as native languages C and C++, not to have our heads in the sand and say, "Oh, well, we've been hearing this for years. All is well." No, it's not. We have work to do. But it's also important not to go to the other extreme, and think that, "Oh, if we just magically wave a wand and make all the world's software, suddenly convert overnight to memory-safe languages", which would be great if it can be done. It's not technically feasible. ut even if we could do that, we're not going to make most of the attacks go away.

Exceptionally Bad: The Misuse of Exceptions in C++ & How to Do Better

by Peter Muldoon

Exceptions were originally heralded as a new modern way to handle errors. However the C++ community is split as to whether exceptions are useful or should be banned outright. It has not helped the pro-exception lobby that in their enthusiasm to embrace exceptions, a lot of code has been written that puts exceptions in a bad light.

In this talk, We will present the original intent/history of exceptions and a brief overview of how exception mechanics work and how they circumvent the usual stack return mechanism to set the stage. we will then examine the philosophy of using exceptions and then the many cases of exception misuse including resource management, retries, hierarchies, data passing and control flow to name but a few.

For each case, we will then suggest better ways to handle each specific situation. In many cases, exceptions are often dropped in favor of some other more appropriate paradigm.
Finally, we will introduce situations that can truly benefit from exceptions and what a model exception class might look like.

Adding State to the Update Notification Pattern, Part 7

by Raymond Chen

If we don’t have a UI thread, then we open a race condition.

class EditControl
{
    ⟦ ... existing class members ... ⟧

    std::atomic<unsigned> m_latestId;
};

winrt::fire_and_forget
EditControl::TextChanged(std::string text)
{
    auto lifetime = get_strong();

    auto id = m_latestId.fetch_add(1, std::memory_order_relaxed);

    co_await winrt::resume_background();

    if (!IsLatestId(id))) co_return;

    std::vector<std::string> matches;
    for (auto&& candidate : FindCandidates(text)) {
        if (candidate.Verify()) {
            matches.push_back(candidate.Text());
        }
        if (!IsLatestId(id))) co_return;
    }

    // co_await winrt::resume_foreground(Dispatcher());

    if (!IsLatestId(id))) co_return;

    SetAutocomplete(matches);
}

Lightning Talk: You Should Use AddressSanitizer

by Brody Holden 

This talk aims to get you, yes you, to use Address Sanitizer. ASan will detect various memory errors and is worth your time.

Understand Internals of std::expected

by Bartlomiej Filipek

In short, std::expected should contain two data members: the actual expected value and the unexpected error object. So, in theory, we could use a simple structure:

template <class _Ty, class _Err> 
struct expected {  
     /*... lots of code ... */  
     _Ty _Value;  
     _Err _Unexpected; 
}; 

However, there are better solutions than this. Here are some obvious issues for our “struct” approach.

• The size of the object is the sum of the Value type and the Error type (plus padding if needed).
• Two data members are “active” and initialized, which might not be possible - for example, what if the Value type has no default constructor? The Standard requires that std::expected" holds either a value of type Tor an error of typeE` within its storage.
• We’d have to guarantee that _Ty cannot be a reference type or an array type; it must be a Destructible Type.
• Similarly for the _Err type we have to guarantee that it’s also Destructible, and must be a valid template argument for std::unexpected (so not an array, non-object type, nor cv-qualified type).
• Plus, we’d have to write a lot of code that creates an API for the type

C++ programmer's guide to undefined behavior: part 1 of 11

by Dmitry Sviridkin

Many modern programming languages, especially newer ones, forbid implicit type conversions. So, in Rust, Haskell, or Kotlin, we can't just use float and int in the same arithmetic expression without explicitly stating in the code to convert one to the other. Python isn't as strict but still keeps strings, characters, and numbers from mixing. C++ doesn't forbid implicit conversion, which leads to a lot of erroneous code. Moreover, such code can contain both defined (but unexpected) and undefined behavior.

Delivering Safe C++

by Bjarne Stroustrup

Type safety was one of the key initial C++ design ideals. We have evolved C++ to the point where we can write C++ with no violations of the type system, no resource leaks, no memory corruption, no garbage collector, no limitation of expressiveness or performance degradation compared to well-written modern C++.

We face three major challenges: To define what “safe” means in the context of various C++ uses, to guarantee such safety where guarantees are needed, and to get developers to write such verified safe code.

I outline an approach based on safety profiles to address these challenges, describe an approach to eliminate dangling pointers, and suggest how to eliminate all dangling pointers and all range errors. My aim for key applications is verified type-and-resource-safe C++. An emphasis is on minimizing costly run-time checks through the use of abstractions. I see the current emphasis on safety as an opportunity to complete one aspect of C++’s fundamental aims in real-world code.

Speaking about C++

Organized by Jens Weller

This event will focus on the process of creating technical talks for the C++ community. Various speakers will share their views on how to submit, prepare and give talks to the C++ community in the form of lightning talks and a panel.

Qt and Trivial Relocation (Part 1)

by Giuseppe D'Angelo

The container classes introduced in Qt 4 (Tulip, for the aficionados) had an interesting optimization: the ability to turn certain operations on the contained objects into byte-level manipulations.

Example: vector reallocation

Consider the reallocation of a QVector<T>: when the vector is full and we want to insert a new value (of type T), the vector has to allocate a bigger block of memory.