Hi Ulrich,
On 7 March 2014 19:46, Ulrich Hertlein wrote:
> Yes, that was my understanding too.
> I was just advocating this procedure since it's sort of most-common
> practice in OSG to
> return raw pointers and the question came up.
>
Returning raw pointers is for efficiency and flexibility.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Robert,
On 6/03/2014 12:48, Robert Osfield wrote:
> Hi Ulrich,
>
> If you get a C pointer from a ref_ptr<> you are explicitly moving outside the
> scope
> of automatic reference counting. It's only safe to get and use a C pointer
> from a
> r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6/03/2014 20:09, ttaw wrote:
> From: Ulrich Hertlein mailto:u.hertl...@sandbox.de>>
> try
> m_resource.release().
Thanks, whoever you are.
But that moves the ownership from the class to the caller and is not what I'm
after.
Plus it doesn't sol
From: Ulrich Hertlein
To: osg-users
Subject: [osg-users] osg::ref_ptr thread safety
Message-ID: <53179051.8020...@sandbox.de>
Content-Type: text/plain; charset=UTF-8
try m_resource.release().
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi guys,
during a recent discussion at the
Hi Ulrich,
If you get a C pointer from a ref_ptr<> you are explicitly moving outside
the scope of automatic reference counting. It's only safe to get and use a
C pointer from a ref_ptr<> if you know the object being referenced will not
get unreferenced during the lifetime of the C pointer. If yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi guys,
during a recent discussion at the office the question was raised whether or not
there's
anything architectural that's stopping the owner of a ref-counted resource to
return it
via a raw pointer and dereference (and hence delete it) before
6 matches
Mail list logo
