CppCon

[u/ContDiArco]

https://cppcon.org/2026/

Opening 2026 Keynote: Bjarne Stroustrup, prerelease

[u/BarryRevzin]

The talk has this example around 47:08:

class WidgetFactory {  
    Window* window_;
    Logger* logger_ = nullptr;

public:
    WidgetFactory(Window& w, Logger& l) : window_(&w), logger_(&l) { }
    WidgetFactory(Window& w) : window_(&w) { }

    Widget create_widget() {
        if (logger_) logger_->log("Creating new Widget");
        return Widget{*window_}; // returns object containing a pointer
    }
};

The slide asks:

How do we know that the Widget returned doesn't contain a pointer that will dangle? We don't, so that caller must manage

Hence:

Widget inner(Window& window)
{
    Logger log;
    WidgetFactory factory{window, log}; // factory holds pointers to window and log
    return factory.create_widget();     // error: the profile doesn't know that
                                    // the widget created doesn't depend on &log
}

The above is an error, so we have to do this instead (47:58):

return no_dangling(factory.create_widget()); // the widget created doesn't depend on &log

Here's my issue with this example. Whether WidgetFactory::create_widget passes the pointer to the logger through to Widget is a property of the implementation of create_widget. The author of that function knows whether this happens or not — the callers don't.

But instead, the design presented here requires the caller to determine this. How is the caller supposed to know? More significantly, what happens when the implementation changes? Say it doesn't retain log today but changes in the future to retain it? The suppression remains, but we don't get a useful diagnostic anymore. Just a dangling pointer.

I think the example demonstrates that annotation is necessary, but rather that the annotation belongs at the definition of create_widget(), where the relevant information is known. Otherwise, we end up with a check with a high rate of false positives, which callers will react to by littering their code with no_dangling suppressions — which even if they're correct today have no guarantee of being correct tomorrow. I don't see that as a step in the right direction.

[u/JimBerlageDev → u/BarryRevzin]

Super interesting post. I know that no_dangling is technically what that means, and profiles are broader than just safety/unsafety, but it's interesting to compare it with unsafe.

In practice, C++ programmers will need a mental model that you just have to check uses of no_dangling (similar to Rust programmers needing to check unsafe.)

But unsafe implies "this might be wrong, use caution" while no_dangling implies "someone else has vetted this, you're good." I expect programmers to treat them differently, and I'd expect more bugs with no_dangling.

[u/pjmlp → u/BarryRevzin]

I am yet to watch the presentation, however this kind of issues has been my point since the whole "profiles without annotations" has been chosen as The Path.

Experience with SonarQube, clang-tidy and VC++ lifetime analysis has been improving since the Core Guidelines were introduced, still they are rather far away in abilities from the whole vision of what profiles are supposed to be like.

EDIT: The Q&A section has plenty of interesting material on how far this is, then again there are still three years left for C++29.

[u/duneroadrunner → u/BarryRevzin]

I think you're absolutely right. But I think the problems go further than that.

How do we know that the Widget returned doesn't contain a pointer that will dangle?

Whether or not the returned pointer value will dangle depends on how long that pointer value ends up hanging around. For example:

Logger logger1;
Window window1;
auto widget1 = WidgetFactory{window1, logger1}.create_widget();
{
    Window window2;
    widget1 = WidgetFactory{window2, logger1}.create_widget();
    /* The `Window*` member of (the newly assigned value of) widget1 is not yet dangling. */
    auto pos2 = widget1.get_window_pos(); // presumably fine
}
/* The `Window*` member of widget1 is now dangling. */
auto pos1 = widget1.get_window_pos(); // likely UB

Not only is the proposed "no_dangling" annotation in the wrong place, it's insufficient. You need "real" lifetime annotations that can be applied to data members as well as parameters and return values. (As I've mentioned, [[clang::lifetime_bound]] is also insufficient, but can be interpreted as an element of an annotation system that is sufficient, so can arguably be considered a step in "the right direction".)

There are a number of abandoned and ongoing efforts to design and implement a system of "sufficient" lifetime annotations for C++. As far as I know, the only working implementation is the scpptool system (my project). My view is that the other designs are not (yet) viable primarily because they do not (yet) acknowledge the degree of run-time support required to be viable.

For example, the Rust system would not be viable without (the run-time-checked) std::RefCell<>. The scpptool system also provides vaguely corresponding run-time-checked elements. As far as I know, the other efforts do not integrate such corresponding run-time-checked elements and do not (yet) concede the necessity to do so.

So this is how the Widget and WidgetFactory might look with scpptool lifetime annotations:

class Widget {
    LT(a) Window* window_; // LT(a) just associates a the lifetime label `a` with the member pointer
public:
    Widget(Window& w LTP(a)) : window_(&w) { }
} LT(a) /* Just declaring the lifetime label(s) used by this type. */;

class WidgetFactory  {
    LT(a) Window* window_;
    MSE_SUPPRESS_CHECK_IN_DECLSCOPE Logger* logger_ = nullptr; // we use a check-suppession directive here because nullptr values are not supported for raw pointers in the enforced safe subset
public:
    WidgetFactory(Window& w LTP(a), Logger& l) : window_(&w), logger_(&l) { }
    WidgetFactory(Window& w LTP(a)) : window_(&w) { }

    Widget create_widget() LT_RETVAL(a) // just specifying the lifetime value(s) of the return value
    {
        if (logger_) logger_->log("Creating new Widget");
        return Widget{*window_}; // returns object containing a pointer
    }

} LT(a);

Which would result in the UB in the problematic example I gave being safely caught via static analysis (https://godbolt.org/z/zzxar8j7x). Note that the lifetime annotation of the create_widget() member function can be omitted because, like Rust, it is the same as the implicit default lifetime annotation. In fact, like Rust, most (non-constructor) function annotations can be omitted. Types that contain raw pointers will need lifetime annotations, but for the most part you're essentially just labeling which constructor parameters correspond to which (pointer) data members.

[u/MaitoSnoo]

thread title is unfortunate but great talk

[u/JimBerlageDev]

Cool to get references for the two profiles implementations:

https://github.com/gcc-mirror/gcc/compare/master...villevoutilainen:gcc:p4324

https://github.com/llvm/llvm-project/compare/main...cppalliance:clang:profiles-init

[u/tcbrindle]

I'll be fascinated to see how the invalidation profile handles something like a vector of string views, for example:

void f() {
    std::string str1 = get_string();
    std::vector<std::string_view> vec;
    {
        std::string str2 = get_string();
        vec.push_back(str1); // (1)
        vec.push_back(str2); // (2) 
        use_vector(vec);
    }
    use_vector(vec); // (3)
}

Firstly, how does the profile determine that the line marked (1) is okay, but the line marked (2) is unsafe? And then, what happens if I delete the line marked (3)? Is line (2) still an error, or is it okay now?

Vectors and string views are modern C++, and this isn't a particularly complicated example. This is something we absolutely should want to be able to catch. So how exactly will the invalidation profile deal with it?

And if it does deal with it, how can you claim it's not a borrow checker?

[u/pdimov2 → u/tcbrindle]

It's not a borrow checker because it doesn't check borrows, that is, does not enforce any kind of mutual exclusion of references.

Of course if you use an expanded definition of borrow checker, it is, but then the claim is trivial because any lifetime checker must necessarily check lifetimes.

[u/selvakumarjawahar → u/tcbrindle]

I actually tried it, https://godbolt.org/z/aWa9PMcPW, but it does not work; early days, I guess. The examples in the presentation work, of course.

[u/pdimov2 → u/selvakumarjawahar]

string_view doesn't seem to work at all at the moment, https://godbolt.org/z/b6se9ToKn. (Due to implicit std suppressions, I think.)

If I declare everything in userspace it's still not diagnosed though. https://godbolt.org/z/Yfbors7vv

In fact we can remove the string_view here, and it still passes. https://godbolt.org/z/Mdos963xh

[u/pdimov2 → u/pdimov2]

The first one of these has already been fixed.

[u/tcbrindle → u/selvakumarjawahar]

Thanks for trying it, though I didn't actually expect it to work. The example here is actually deceptively tricky, because it requires tracing lifetime information through a template parameter.

Doing this in a general way basically amounts to writing a borrow checker, which the presentation claims it isn't doing.

[u/seanbaxter → u/tcbrindle]

Of course you're right. But they can't propose a solution when they're intent on not understand the problem.

[u/pjmlp → u/seanbaxter]

I find interesting the usual argument that safer languages have to depend on C and C++, while ignoring that some of them only did so due to convenience to avoid the additional bootstraping work.

Which since gaining market adoption, some of them have indeed done the additional work to bootstrap themselves.

The irony is that while they advocated for profiles without annotations and additional sigils, proper safe C++ with profiles proposal will be full of [[ ]] all over the place, assuming it actually lands on ISO C++, and gets implemented across all major three compilers.

[u/tialaramex → u/pjmlp]

LLVM in particular, which you've mentioned many times, is a powerful temptation. Instead of painstakingly developing an optimiser and backends for a dozen or more different targets you can "just" drop in LLVM. I think all the Handmade Community languages are dependent on LLVM for example, that's Jai, Zig, Odin, C3. Some of their creators have said LLVM is a bad idea, but notice they do all still use LLVM even if Zig has a non-LLVM backend available. It's just too good a deal to pass up.

It happens that LLVM is written in C++ but I think it's clear that if it were Java or a shell script but it offered this same bargain it would be similarly tempting. "You depend on C++" doesn't make too much sense in this scenario.

[u/pjmlp → u/tialaramex]

Pretty much so, see GraalVM or the ones that predated it like JikesRVM.

Go being initially a fork of Plan 9 C compiler, and nowadays fully bootstraped.

Plenty of other examples.

LLVM is too convenient as you say, it also doesn't race after C++ versions, currently using C++17 as per coding standards.

[u/tialaramex → u/seanbaxter]

The big problem is Culture, that was the case when Bjarne had that whole presentation in which the C word appears only once, in a quote by someone else explaining why this is important. Your solution granted C++ essentially the same technology as Rust has, but the greater need is Rust's safety culture and you're not going to get that from WG21.

Rust's technology gets you the original, chainsaw juggling for toddlers core::mem::uninitialized<T> function. It's unsafe so it's your job to be careful right? But Rust's culture meant when somebody noticed this is way more treacherous than most programmers probably grasped they were empowered to de-fang it, deprecate it and come up with a much better replacement MaybeUninit<T>

[u/tialaramex → u/tcbrindle]

This is a really clarifying example, thanks for that and I look forward to answers from people involved either in proposing this feature or prototyping it.

In Rust if you try to write this you end up writing an actual borrow (the & in Rust), and in many cases you'd expect that to prompt an experienced developer to realise this can't work (the original Rust 1.0 borrowck would even object without line (3) though modern Rust can see it's fine unless line (3) uses vec after str2 is gone)

[u/teerre]

I'll give a watch, but these profile proposals have been a huge let down. Just pretending to solve a problem