Memory management and FdoPtr

[Snehal Joshi]

Hi All,

 

I just started using FDO libraries, and have a question regarding memory management in FDO. I am confused about when to use FdoPtr and FDO_SAFE_ADDREF/FDO_SAFE_RELEASE.

 

Based on the information in the Developer's Guide, my understanding is that FdoPtr will take care of incrementing the reference count/release the object (provided the class implementes FdoIDisposable) - however, it'll call Release() as soon as the FdoPtr goes out of scope. So, within a function I write, if I wrap the return values of one of the FDO create/get methods in an FdoPtr, and return that FdoPtr as a function return value, it's a bad idea. Is that a valid assumption?

 

Thanks,

Snehal

 

 

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Gavin Cramer]

Hi, Snehal.  In your use case is probably the most common for intermediate code that retrieves and also returns ref-counted FDO types.  The only special action to take is in the return statement, when it is necessary to increase the ref-count to preserve your method’s “share” of object ownership on behalf of its caller.

 

FdoPtr<SomeFdoType> ret;

ret = CallSomeMethod();

return FDO_SAFE_ADDREF(ret.p);

 

Best wishes,

Gavin

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Snehal Joshi
Sent: Friday, May 11, 2012 12:03 PM
To: FDO Users Mail List
Subject: [fdo-users] Memory management and FdoPtr

 

Hi All,

 

I just started using FDO libraries, and have a question regarding memory management in FDO. I am confused about when to use FdoPtr and FDO_SAFE_ADDREF/FDO_SAFE_RELEASE.

 

Based on the information in the Developer's Guide, my understanding is that FdoPtr will take care of incrementing the reference count/release the object (provided the class implementes FdoIDisposable) - however, it'll call Release() as soon as the FdoPtr goes out of scope. So, within a function I write, if I wrap the return values of one of the FDO create/get methods in an FdoPtr, and return that FdoPtr as a function return value, it's a bad idea. Is that a valid assumption?

 

Thanks,

Snehal

 

 

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Snehal Joshi]

Thanks Gavin. I'm assuming that the caller of this method could then just use FdoPtr while getting the return value, or call FDO_SAFE_RELEASE to take care of releasing its share of object ownership. Is that correct?

Many thanks,
Snehal

On Fri, May 11, 2012 at 11:11 AM, Gavin Cramer <[hidden email]> wrote:

Hi, Snehal.  In your use case is probably the most common for intermediate code that retrieves and also returns ref-counted FDO types.  The only special action to take is in the return statement, when it is necessary to increase the ref-count to preserve your method’s “share” of object ownership on behalf of its caller.

 

FdoPtr<SomeFdoType> ret;

ret = CallSomeMethod();

return FDO_SAFE_ADDREF(ret.p);

 

Best wishes,

Gavin

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Snehal Joshi
Sent: Friday, May 11, 2012 12:03 PM
To: FDO Users Mail List
Subject: [fdo-users] Memory management and FdoPtr

 

Hi All,

 

I just started using FDO libraries, and have a question regarding memory management in FDO. I am confused about when to use FdoPtr and FDO_SAFE_ADDREF/FDO_SAFE_RELEASE.

 

Based on the information in the Developer's Guide, my understanding is that FdoPtr will take care of incrementing the reference count/release the object (provided the class implementes FdoIDisposable) - however, it'll call Release() as soon as the FdoPtr goes out of scope. So, within a function I write, if I wrap the return values of one of the FDO create/get methods in an FdoPtr, and return that FdoPtr as a function return value, it's a bad idea. Is that a valid assumption?

 

Thanks,

Snehal

 

 

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users

[Jackie Ng]

That is correct. The onus is always on the method caller to release via FDO_SAFE_RELEASE or automatically via FdoPtr

- Jackie

[Gavin Cramer]

If the caller is using FdoPtr, it can just let that pointer fall out of scope (or reassign it if it's in a loop).

FDO_SAFE_RELEASE is for callers that use a plain pointer, not a smart pointer.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jackie Ng
Sent: Saturday, May 12, 2012 2:50 PM
To: [hidden email]
Subject: [fdo-users] Re: Memory management and FdoPtr

That is correct. The onus is always on the method caller to release via
FDO_SAFE_RELEASE or automatically via FdoPtr

- Jackie

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Memory-management-and-FdoPtr-tp4968699p4973896.html
Sent from the FDO Users mailing list archive at Nabble.com.
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users