5 ms·

I would like to point out that if you write code like this (that is, creating a temporary object only to have it instantly deleted), your code smells. Backward

I would like to point out that if you write code like this (that is, creating a temporary object only to have it instantly deleted), your code smells. Backwards-compatibility notwithstanding, it would not be totally illogical for C++ to allow optimizing out construct-destruct chains even in the presence of side effects, in a similar manner to the existing copy elision behavior. After all, the object is unused, and the destructor should be merely undoing whatever the constructor did, so afterward it should be as if the object was never constructed. If you rely on the side effects of normal construction, that's not so different from relying on the side effects of copy construction, which you can't already do. Hence you shouldn't do the first either. So yes, it's a bug, and needs to be fixed, but regardless of that, you shouldn't write code like this in the first place. EDIT: See comment below, apparently the bug comes up in more cases than those I referred to here.

MereInterest 9y ago
I don't think it seems like a code smell at all. For example, I could be adding together multiple vectors, some of which are created as temporaries. auto total_offset = Vector{x_offset, y_offset} + global_offset; Granted, in this case, there are no resources being held by such a Vector class, but having immediately-destroyed temporary objects is not necessarily a code smell.
- wfunction 9y ago
  That's definitely not "immediately destroyed", there's operator+ being called between construction and destruction. I didn't realize this can trigger the bug though, so if it does, I should clarify I didn't mean to include it in my comment. I was only referring to cases where there is no intervening operation between construction and destruction.
  - SolarNet 9y ago
    It's a minimal testcase; minimal. I thought the blog post was pretty clear that it had nothing to do with how the object was used after (e.g. if it was immediately destructed or not) and even linked to a real world example that would disprove that. Hence why your holier than thou attitude about not writing smelly code is just asinine and not helpful. It plays into a mindset that people who write "good code" don't have to worry about 'esoteric' bug reports (e.g. like security advisories).
  - jmgao 9y ago
    There's probably far more reasonable cases of temporaries being immediately destructed than you'd expect. One that springs to mind is gtest. It defines a bunch of macros like ASSERT_TRUE that return a temporary object that has operator<< overloads to let you add additional information to the assertion failure. For example: ASSERT_NE(-1, open("/foo", O_RDONLY)) << "failed to open file: " << strerror(errno); It's perfectly legitimate to just go ASSERT_TRUE(1 != 2), though.
    - wfunction 9y ago
      Like I said: > That's definitely not "immediately destroyed", there's operator<< being called between construction and destruction.
      - yorwba 9y ago
        The point is that you have the option of using operator<<, but if you don't exercise that option, the temporary object is destroyed immediately.
ars 9y ago
> I would like to point out that if you write code like this (that is, creating a temporary object only to have it instantly deleted), your code smells. Not necessarily. What if all you want are the side effects of the object? In particular I/O. Either disk or network. Creating the object opens the connection, destroying it closes the connection. And you use the object in between to write data. Or, don't assign the new object to anything, and simply write the data you pass in to it, and close the stream. It's a perfectly reasonable use case.
- wfunction 9y ago
  > And you use the object in between to write data That's not what I was talking about. See the original comment and follow-ups.
  - ars 9y ago
    > That's not what I was talking about. You didn't read my next sentence. I was explaining that you could use the object in two ways. (If you only ever used it the second way then you would just make it static, so I was giving the first way as a reason why it would not be static.)
nuntius 9y ago
Instantly, as in next line of code? Yeah, probable human error (or auto-generated code). Without being used? Not surprising. It is surprisingly common to allocate a variable, pass it to a function, and have the call never actually use the variable. Unwind, and the variable is destructed without use. I've seen other nasty framework errors exposed by such (non-)usage patterns.

MereInterest 9y ago

I don't think it seems like a code smell at all. For example, I could be adding together multiple vectors, some of which are created as temporaries. auto total_offset = Vector{x_offset, y_offset} + global_offset; Granted, in this case, there are no resources being held by such a Vector class, but having immediately-destroyed temporary objects is not necessarily a code smell.

wfunction 9y ago
That's definitely not "immediately destroyed", there's operator+ being called between construction and destruction. I didn't realize this can trigger the bug though, so if it does, I should clarify I didn't mean to include it in my comment. I was only referring to cases where there is no intervening operation between construction and destruction.
- SolarNet 9y ago
  It's a minimal testcase; minimal. I thought the blog post was pretty clear that it had nothing to do with how the object was used after (e.g. if it was immediately destructed or not) and even linked to a real world example that would disprove that. Hence why your holier than thou attitude about not writing smelly code is just asinine and not helpful. It plays into a mindset that people who write "good code" don't have to worry about 'esoteric' bug reports (e.g. like security advisories).
- jmgao 9y ago
  There's probably far more reasonable cases of temporaries being immediately destructed than you'd expect. One that springs to mind is gtest. It defines a bunch of macros like ASSERT_TRUE that return a temporary object that has operator<< overloads to let you add additional information to the assertion failure. For example: ASSERT_NE(-1, open("/foo", O_RDONLY)) << "failed to open file: " << strerror(errno); It's perfectly legitimate to just go ASSERT_TRUE(1 != 2), though.
  - wfunction 9y ago
    Like I said: > That's definitely not "immediately destroyed", there's operator<< being called between construction and destruction.
    - yorwba 9y ago
      The point is that you have the option of using operator<<, but if you don't exercise that option, the temporary object is destroyed immediately.

ars 9y ago

> I would like to point out that if you write code like this (that is, creating a temporary object only to have it instantly deleted), your code smells. Not necessarily. What if all you want are the side effects of the object? In particular I/O. Either disk or network. Creating the object opens the connection, destroying it closes the connection. And you use the object in between to write data. Or, don't assign the new object to anything, and simply write the data you pass in to it, and close the stream. It's a perfectly reasonable use case.

wfunction 9y ago
> And you use the object in between to write data That's not what I was talking about. See the original comment and follow-ups.
- ars 9y ago
  > That's not what I was talking about. You didn't read my next sentence. I was explaining that you could use the object in two ways. (If you only ever used it the second way then you would just make it static, so I was giving the first way as a reason why it would not be static.)

nuntius 9y ago

Instantly, as in next line of code? Yeah, probable human error (or auto-generated code). Without being used? Not surprising. It is surprisingly common to allocate a variable, pass it to a function, and have the call never actually use the variable. Unwind, and the variable is destructed without use. I've seen other nasty framework errors exposed by such (non-)usage patterns.