[rnikander]

Swift gets weirder and more difficult, C++ gets better. Will the two lines intersect? Probably not, but I'm starting to wonder.

I wish C++ had a few more cosmetic and convenient things that I've gotten used to in Swift. 1. Properties with get/set/didSet blocks. 2. Non-nullable types, ie `T` and `T?`. There's probably no way to add those, even as a GCC-specific non-standard extension.

[gpderetta]

What do you mean non nullable types? In C++ only pointers can be nullable.

[darknavi]

Also with `std::optional` "nullable" pod values are a LOT nicer.

[rnikander]

Years ago I worked on some C++ and the code had a lot of pointers to objects. Maybe it was not well written C++.

In Swift (and Kotlin and others) the compiler can prove that you never get a null pointer error at runtime. If you want something that can be null, the type is `T?` (short for `Optional<T>`) instead of `T`. Then there are various syntactically convenient ways of unwrapping it and dealing with the null case. Eg `foo ?? bar` means give me `foo` if it's not null, otherwise `bar`. Or `foo?.x` means: get the property x of foo, if foo is not null.

I haven't used C++ much in recent years. If there's an equivalent, I'd love to know about it.

[jcelerier]

C++ objects are values.

E.g. in

    std::string str;

str is never null, and always a valid object, because it's a value, not a pointer like in most GC'ed or dynamic languages

[Tyr42]

Wait, but what if you have

std::string str1{"Apple"}; std::string str2 = std::move(str1);

Isn't str1 in an invalid (err, unspecified?) state and you shouldn't use it? It's not `null` sure, but it's not good to use.

[lenkite]

This issue is caught and flagged by clang-tidy. Though technically the standard says it is in valid but un-specified state. Because of short string optimisation, the move might be possibly a copy, so one should not rely on the contents being empty.

[deschutes]

Clang tidy covers only the most trivial use after move scenarios. It's useful coverage but isn't and never will be complete like the rust borrow checker.

[jcelerier]

No, you can absolutely use it (but you most likely want to clear() or assign an empty string to it before doing e.g. push_back as move does not necessarily clear the moved-from object - std::move(some_int) won't clear the int)

[Tyr42]

I mean, it won't have a useful value, so I need to re assign to it, at which point I could just be using a new variable right?

It might not be null, but I can't do much more with it than I can with null. I need to assign something new first

[deschutes]

It depends on what you mean by "object". For example, pod types share syntax with classes but are not always initialized.

What's better is that sanitizers don't detect this form of undefined behavior! (Clean on memory,address,undefined.)

https://godbolt.org/z/7jsxnMs8E

also relevant: https://i.imgur.com/3wlxtI0.gifv

[jcelerier]

By object, I mean: https://eel.is/c++draft/intro.object ; pod types, even uninitialised, are still objects.

Also, uninitialized by itself does not mean invalid though ? For your example, I wonder if it would make sense to flag it: printf could be implemented in assembly or Fortran for what we know (a few popular libc implementations are done in c++ for instance), and as such I don't know how much sense it would make for its internal usage of the pointed value to be checked against the c++ rules. I'd assume the outcome would be different with std::format or std::cout for instance

[deschutes]

My complaint is that it is too easy to create an object with uninitialized members by accident. On account of the syntax being identical. I guess its too late to add affordances there.

I suppose a definition of valid that prohibited uninitialized members would preclude lots of useful stuff like container and buffer types.

From the msan documentation [1], the flaw with my earlier example is that `printf` isn't instrumented.

And to address your other question, I don't know if msan can instrument a function implemented in assembly. It definitely can't deal with something it didn't compile as the instrumentation is added during compilation.

It seems that on godbolt the platform library also isn't instrumented because the equivalent iostream code is msan clean [2]. I suppose that makes sense as it's allowing you to pass arbitrary options to the compiler.

In summary, msan can detect these uninitialized reads but it requires quite a lot of fiddling.

[1]: https://clang.llvm.org/docs/MemorySanitizer.html#handling-ex... [2]: https://godbolt.org/z/Gsxsfn9GT

[raydev]

But that would compile and run, and you'd still get garbage if you tried to access str later, correct?

In Swift you are not allowed to declare a variable without assigning some value or nil to it before the current scope ends.

[benchaney]

I don't think that's true. The default constructor for std::string creates an empty string. See: https://www.cplusplus.com/reference/string/string/string/

The semantics of c++ object initialization are such that a constructor will always be called.

[jcelerier]

No, either you get the previous content of the string (if it was under the small-string optimization limit) or a new empty string, but never garbage.

[pjmlp]

In C++, you can prevent that with compiler options.

[pjmlp]

Well, in spite its warts, I know which ecosystem I would rather invest on.

[rnikander]

And I forgot: 3. keyword arguments to functions. :)

[stargrazer]

Not in the standard, but the language does support it: https://www.boost.org/doc/libs/1_79_0/libs/parameter/doc/htm...