4 ms·

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

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 10y 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 10y 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 10y 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 10y ago
    Like I said: > That's definitely not "immediately destroyed", there's operator<< being called between construction and destruction.
    - yorwba 10y 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.

wfunction 10y 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 10y 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 10y 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 10y ago
  Like I said: > That's definitely not "immediately destroyed", there's operator<< being called between construction and destruction.
  - yorwba 10y 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.