4 ms·

C++ Object Lifetime

32 points by jandeboevrie 3y ago

zabzonk 3y ago
> As we said, references are not types, but what if we declare something like struct S{ int& ref;}; would that be an object type? yes it would be, because it "is not a function type, not a reference type, and not a void type" - it is a type named S. this article is not very good - the lifetime of a named object in C++ begins when the object is defined, and ends when the name goes out of scope. pretty simple. edit: and i should have added "and its constructor (if it has one) has completed"
- MathMonkeyMan 3y ago
  auto *p = new T; What is the lifetime of the object to which p points? The trouble with defining the reference-containing struct as a value type is that assignment to the struct assigns _through_ the reference rather than making it refer to something else. My impression of the article is that more precise and pedantic language is required to talk about these things.
  - drtgh 3y ago
    if one is using auto, then contemporary C++ is being used, and I think smart pointers are expected to be used, the article is mixing classical and contemporary features. So IMHO, the problem is such features consumption approach, if one is using raw pointers for any reason, all that area and subsequent should use classical structures, and use some kind of interfaces for to connect them to contemporary structures (suboptimal thought?), never mixing, case contrary to debug those things will be epic poetry (oh, the code uses auto, but is taking care of the pointers or no, damn, I have to read all the library for to know).
    - jebarker 3y ago
      > the article is mixing classical and contemporary features As a C++ novice that is practicing to improve this is the number one problem with finding tutorials. It's really hard for me to figure out which features are current best practice and which shouldn't be used together. I can obviously dig in to specific topics to read the history and pros/cons of features, but that's a very slow way to learn.
  - zabzonk 3y ago
    please note that my comment said: > the lifetime of a named object in this case "new T" does not create a named object. the lifetime of an unnamed object is determined explicitly by the programmer (i.e. "delete p" in this case), or implicitly if the object is being pointed to by something like a smart pointer, or is undefined (if you didn't assign the result of calling "new" to anything).
    - MathMonkeyMan 3y ago
      ah, point taken. Reference data members are still tricky, though.
      - zabzonk 3y ago
        reference data members are generaly A Bad Thing (your design is probably wrong) - the main purpose of references is to serve as function parameters and/or return types. if you need a reference-like member, use a pointer.
  - wiseowise 3y ago
    Until delete is called on it.
turtledragonfly 3y ago
How can you write an article like this and not say the magic word: RAII RAII is one of the great things about C++, precisely because it allows detailed control over object lifetimes (even in the face of exceptions, etc). However, I did learn something from this article: I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra code that is run after the real ctor"? But I wouldn't rely on subtleties like that, or rely on others to know about it. Just use simple RAII (:
- imron 3y ago
  > I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra code that is run after the real ctor"? This does not appear to be the case. The code in question is not calling the constructor that throws! It's still calling int main(){S s;} If you change it to: int main(){S s(42);} It will throw and not call the destructor (both latest clang and gcc). See for example https://godbolt.org/z/ohjchhGvz https://godbolt.org/z/ohjchhGvz
  - turtledragonfly 3y ago
    Ah, thanks for that follow-up. That is more in line with my mental model. So... seems like a bad example in the article (:
    - imron 3y ago
      > That is more in line with my mental model. Right, mine too. It wasn't until I saw your comment that I thought to go and verify how it worked.
  - delta_p_delta_x 3y ago
    To be precise, with proper exception handling, the former will throw, but the destructor will also be called as part of the stack-unwind.

32 points by jandeboevrie 3y ago

> As we said, references are not types, but what if we declare something like struct S{ int& ref;}; would that be an object type? yes it would be, because it "is not a function type, not a reference type, and not a void type" - it is a type named S. this article is not very good - the lifetime of a named object in C++ begins when the object is defined, and ends when the name goes out of scope. pretty simple. edit: and i should have added "and its constructor (if it has one) has completed"

MathMonkeyMan 3y ago
auto *p = new T; What is the lifetime of the object to which p points? The trouble with defining the reference-containing struct as a value type is that assignment to the struct assigns _through_ the reference rather than making it refer to something else. My impression of the article is that more precise and pedantic language is required to talk about these things.
- drtgh 3y ago
  if one is using auto, then contemporary C++ is being used, and I think smart pointers are expected to be used, the article is mixing classical and contemporary features. So IMHO, the problem is such features consumption approach, if one is using raw pointers for any reason, all that area and subsequent should use classical structures, and use some kind of interfaces for to connect them to contemporary structures (suboptimal thought?), never mixing, case contrary to debug those things will be epic poetry (oh, the code uses auto, but is taking care of the pointers or no, damn, I have to read all the library for to know).
  - jebarker 3y ago
    > the article is mixing classical and contemporary features As a C++ novice that is practicing to improve this is the number one problem with finding tutorials. It's really hard for me to figure out which features are current best practice and which shouldn't be used together. I can obviously dig in to specific topics to read the history and pros/cons of features, but that's a very slow way to learn.
- zabzonk 3y ago
  please note that my comment said: > the lifetime of a named object in this case "new T" does not create a named object. the lifetime of an unnamed object is determined explicitly by the programmer (i.e. "delete p" in this case), or implicitly if the object is being pointed to by something like a smart pointer, or is undefined (if you didn't assign the result of calling "new" to anything).
  - MathMonkeyMan 3y ago
    ah, point taken. Reference data members are still tricky, though.
    - zabzonk 3y ago
      reference data members are generaly A Bad Thing (your design is probably wrong) - the main purpose of references is to serve as function parameters and/or return types. if you need a reference-like member, use a pointer.
- wiseowise 3y ago
  Until delete is called on it.

turtledragonfly 3y ago

How can you write an article like this and not say the magic word: RAII RAII is one of the great things about C++, precisely because it allows detailed control over object lifetimes (even in the face of exceptions, etc). However, I did learn something from this article: I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra code that is run after the real ctor"? But I wouldn't rely on subtleties like that, or rely on others to know about it. Just use simple RAII (:

imron 3y ago
> I didn't realize that a delegating constructor counted as "fully initializing" the object. The main constructor is, I imagine, just treated as some "extra code that is run after the real ctor"? This does not appear to be the case. The code in question is not calling the constructor that throws! It's still calling int main(){S s;} If you change it to: int main(){S s(42);} It will throw and not call the destructor (both latest clang and gcc). See for example https://godbolt.org/z/ohjchhGvz https://godbolt.org/z/ohjchhGvz
- turtledragonfly 3y ago
  Ah, thanks for that follow-up. That is more in line with my mental model. So... seems like a bad example in the article (:
  - imron 3y ago
    > That is more in line with my mental model. Right, mine too. It wasn't until I saw your comment that I thought to go and verify how it worked.
- delta_p_delta_x 3y ago
  To be precise, with proper exception handling, the former will throw, but the destructor will also be called as part of the stack-unwind.