Safe to pass dereferenced anonymous shared_ptr? - Boost-users - lists.preview.boost.org

newer
Boost API System or Library Calls...

Safe to pass dereferenced anonymous shared_ptr?

older
[Containter] Compilation errors...

Chris Stankevitz

5 Nov 2013 5 Nov '13

11:12 p.m.

Q1: Is the below code dangerous? A1: Only if the anonymous shared_ptr is deleted before function f returns. Q2: Is the anonymous shared_ptr deleted before function f returns? A2: ? Thank you, Chris === #include <iostream> #include void f(const int& i) { std::cout << "i = " << i << std::endl; } int main() { f(*boost::make_shared<int>(42)); return 0; }

Reply

Sign in to reply online Use email software

Show replies by date

Krzysztof Czainski

5 Nov 5 Nov

11:30 p.m.

2013/11/6 Chris Stankevitz

Q1: Is the below code dangerous? A1: Only if the anonymous shared_ptr is deleted before function f returns.

Q2: Is the anonymous shared_ptr deleted before function f returns? A2: ?

Thank you,

Chris

===

#include <iostream> #include

void f(const int& i) { std::cout << "i = " << i << std::endl; }

int main() { f(*boost::make_shared<int>(42));

return 0; }

I don't think this particular use is dangerous, but does it make sense? I can't imagine why would you ever want to do that. In your (simplified I presume) example you don't share anything, you don't even need a pointer at all. In your real example you probably have some class with a user-defined constructor instead of int, but can't you do: f( int(42) ); HTH, Kris

Reply

Sign in to reply online Use email software

Chris Stankevitz

6 Nov 6 Nov

3:56 a.m.

On Tue, Nov 5, 2013 at 3:30 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:

In your (simplified I presume) example you don't share anything, you don't even need a pointer at all. In your real example you probably have some class with a user-defined constructor instead of int, but can't you do:

Kris, Scott, Edward, Thank you for your replies regarding the safe use of the anonymous shared_ptrs. === Kris: FYI my more complex use-case looks like this: class TCImage { public: // Default constructs a black image TCImage(unsigned Width, unsigned Height); }; boost::shared_ptr<const std::string> GetJpegBytes(const TCImage& Image); GetJpegBytes generates JPEG bytes for an image and returns them as a shared_ptr. The shared_ptr is helpful because these JPEG bytes are passed around throughout my system. My question arose when I had the following atypical special-case (simplified but you get the idea): void WriteJpegBytes(const std::string& JpegBytes); void WriteBlackImage(); === I considered three options: 1. Pass a dereferenced anonymous boost::shared_ptr void WriteBlackImage() { WriteJpegBytes(*TCJpegEncoder::GetBytes(TCImage(640, 480))); } 2. Pass a dereferenced named boost::shared_ptr void WriteBlackImage() { boost::shared_ptr<const std::string> pBytes = TCJpegEncoder::GetBytes(TCImage(640, 480)); WriteJpegBytes(*pBytes); } 3. Change my interface: boost::shared_ptr<const std::string> GetJpegBytesAsSharedPointer(const TCImage& Image); std::string GetJpegBytesAsString(const TCImage& Image); I opted for approach (1) but wanted it clear it first with you guys. ===== Thank you again, Chris

Reply

Sign in to reply online Use email software

Scott Mueller

4:55 a.m.

I have just one comment. I would recommend returning a unique_ptr instead of a shared_ptr, as you can then use the object as a unique_ptr, be move it into a shared_ptr, or adopt it by other means elsewhere in your data structures. Returning a shared_ptr locks you into keeping the data as a shared_ptr. Best Regards, M. Scott Mueller

On Nov 5, 2013, at 7:56 PM, "Chris Stankevitz" wrote:

Kris, Scott, Edward,

Thank you for your replies regarding the safe use of the anonymous shared_ptrs.

===

Kris: FYI my more complex use-case looks like this:

class TCImage { public:

// Default constructs a black image TCImage(unsigned Width, unsigned Height); };

boost::shared_ptr<const std::string> GetJpegBytes(const TCImage& Image);

GetJpegBytes generates JPEG bytes for an image and returns them as a shared_ptr. The shared_ptr is helpful because these JPEG bytes are passed around throughout my system.

Reply

Sign in to reply online Use email software

Krzysztof Czainski

10:48 a.m.

2013/11/6 Scott Mueller

I have just one comment. I would recommend returning a unique_ptr instead of a shared_ptr, as you can then use the object as a unique_ptr, be move it into a shared_ptr, or adopt it by other means elsewhere in your data structures. Returning a shared_ptr locks you into keeping the data as a shared_ptr.

Best Regards,

M. Scott Mueller

If you're in C++11, why would you use a pointer at all and not return a string? It's movable. If you're not in C++11, then consider returning by value anyway. RVO will most likely avoid the copy anyway. That said, (I wish unique_ptr emulation was in boost) I get it why use shared_ptr even though you don't share anything... Regards, Kris

Reply

Sign in to reply online Use email software

Krzysztof Czainski

10:50 a.m.

2013/11/6 Krzysztof Czainski <1czajnik@gmail.com>

If you're not in C++11, then consider returning by value anyway. RVO will most likely avoid the copy anyway. That said, (I wish unique_ptr emulation was in boost) I get it why use shared_ptr even though you don't share anything...

Or maybe return a boost::container::vector<char> in C++98? It's movable, you know ;-) HTH, Kris

Reply

Sign in to reply online Use email software

Scott Mueller

12:57 a.m.

Hello, Q1: Is the below code dangerous? A1: Short answer: no. For the long answer, see the end of this email. Q2: Is the anonymous shared_ptr deleted before function f returns? A2: No, it is deleted afterward. -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Chris Stankevitz Sent: Tuesday, November 05, 2013 3:13 PM To: boost-users@lists.boost.org Subject: [Boost-users] Safe to pass dereferenced anonymous shared_ptr? ... #include <iostream> #include void f(const int& i) { std::cout << "i = " << i << std::endl; } int main() { f(*boost::make_shared<int>(42)); return 0; } -----/Original Message----- As far as I understand the standard, any temporaries that are created for an expression are destroyed after the result is obtained. With this in mind, the boost::shared_ptr<> will be destroyed after the invocation of f().

From 12.2.3 of ISO/IEC 14882:2011(E): When an implementation introduces a temporary object of a class that has a non-trivial constructor (12.1, 12.8), it shall ensure that a constructor is called for the temporary object. Similarly, the destructor shall be called for a temporary with a non-trivial destructor (12.4). Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing an exception. The value computations and side effects of destroying a temporary object are associated only with the full-expression, not with any specific subexpression.

Yep, I paid the 30 bucks. ;) Best regards, M. Scott Mueller

Reply

Sign in to reply online Use email software

Edward Diener

2:43 a.m.

On 11/5/2013 6:12 PM, Chris Stankevitz wrote:

Q1: Is the below code dangerous? A1: Only if the anonymous shared_ptr is deleted before function f returns.

Q2: Is the anonymous shared_ptr deleted before function f returns? A2: ?

Thank you,

Chris

===

#include <iostream> #include

void f(const int& i) { std::cout << "i = " << i << std::endl; }

int main() { f(*boost::make_shared<int>(42));

return 0; }

A2: No. But this is C++ and has nothing to do with shared_ptr.

Reply

Sign in to reply online Use email software

4126

Age (days ago)

4127

Last active (days ago)

Download

7 comments

4 participants

tags

participants (4)

Chris Stankevitz
Edward Diener
Krzysztof Czainski
Scott Mueller