4 ms·

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

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
  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 5y ago
    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
    - jcelerier 4y ago
      > 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? I have a hard time understanding why "I could just be using a new variable" follows from "it won't have a useful value".
raydev 5y ago
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 5y ago
  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/ https://www.cplusplus.com/reference/string/string/string/ The semantics of c++ object initialization are such that a constructor will always be called.
- jcelerier 5y ago
  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 5y ago
  In C++, you can prevent that with compiler options.
deschutes 5y ago
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 https://godbolt.org/z/7jsxnMs8E also relevant: https://i.imgur.com/3wlxtI0.gifv https://i.imgur.com/3wlxtI0.gifv
- jcelerier 5y ago
  By object, I mean: https://eel.is/c++draft/intro.object 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 5y ago
    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-external-code https://clang.llvm.org/docs/MemorySanitizer.html#handling-ex... [2]: https://godbolt.org/z/Gsxsfn9GT https://godbolt.org/z/Gsxsfn9GT

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 5y ago

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 5y ago
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 5y ago
  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 5y ago
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 5y ago
  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
  - jcelerier 4y ago
    > 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? I have a hard time understanding why "I could just be using a new variable" follows from "it won't have a useful value".

raydev 5y ago

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 5y ago
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/ https://www.cplusplus.com/reference/string/string/string/ The semantics of c++ object initialization are such that a constructor will always be called.
jcelerier 5y ago
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 5y ago
In C++, you can prevent that with compiler options.

deschutes 5y ago

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 https://godbolt.org/z/7jsxnMs8E also relevant: https://i.imgur.com/3wlxtI0.gifv https://i.imgur.com/3wlxtI0.gifv

jcelerier 5y ago
By object, I mean: https://eel.is/c++draft/intro.object 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 5y ago
  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-external-code https://clang.llvm.org/docs/MemorySanitizer.html#handling-ex... [2]: https://godbolt.org/z/Gsxsfn9GT https://godbolt.org/z/Gsxsfn9GT