[sword-devel] Pointer Management

[Troy A. Griffitts]

Yes, exactly.  SWModule is stateful: e.g., you can turn options on and 
off, set properties, and position it to a verse and it retains that 
information, e.g, mod->setKey("Jn.3.16"); cout << mod->renderText(); // 
renders Jn.3.16

So, if I am using one SWModule instance for reading and display and 
another for searching (in another thread), the search loop which 
traverses the entire module will be doing something like for ((*mod) = 
TOP; !mod->popError(); (*mod)++) { ... }

While that search is looping across the entire module and if my user 
interface allows the user to do something like "Display Matthew Chapter 
3" in another window while he is waiting for the search, then the render 
code and and the search loop code with fight for state when the display 
code does something like mod->setKey("Matt.1.1"); outputWindow += 
mod->renderText();

So I usually keep one SWMgr instance per thread.

Yes, any call to SWMgr::getModule will return a pointer to an SWModule 
which SWMgr has allocated and SWMgr will free this pointer when the 
SWMgr instance goes out of scope.

Troy



On 4/11/25 11:56 AM, Greg Hellings wrote:
> OK, so if I have code like this:
>
> SWModule *mod1 = mgr->getModule("KJV");
> SWModule *mod2 = mgr->getModule("KJV");
>
> Those two pointers are to an object owned by the SWMgr object and I 
> should simply let the variable go out of scope when I'm done with it? 
> I should not be calling any delete or free on the module itself, 
> correct? If I have need to manipulate the module separately, then I 
> should instantiate a different SWMgr object and fetch a pointer from 
> it? I presume that's the reason you have separate ones for search and 
> retrieval?
>
> --Greg
>
> On Sat, Apr 5, 2025 at 10:51 AM Troy A. Griffitts 
> <scribe at crosswire.org> wrote:
>
>     Hi Greg,
>
>     Typically in SWORD, the object/factory that created the object is
>     responsible for deleting the object unless a call was made to
>     something
>     like 'clone' or 'create'.  So, SWMgr will delete all the SWModule
>     objects it allowcates when the SWMgr object is deleted. If you have
>     multiple threads in your application, we recommend each thread
>     have its
>     own SWMgr object because the same SWModule object instances are
>     returned
>     each time a getModule() call is made to the same instance of SWMgr.
>
>     I usually have 3 SWMgr objects I interact with in my apps: one I
>     create
>     for display, one I create for searching, and one I get from
>     InstallMgr.
>
>     The exceptions, as mentioned above, are usually noted in the
>     comments, e.g.,
>
>     https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swmodule.h#L486
>     https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swkey.h#L134
>
>     Hope this helps,
>
>     Troy
>
>
>     On 3/25/25 7:42 AM, Greg Hellings wrote:
>     > I have a question about pointer lifetime and management when
>     > interacting with libsword: who owns the lifetime and delete
>     management
>     > of pointers coming out of the SWMgr and SWModule calls? For
>     instance:
>     > if I create an SWMgr object and fetch a SWModule* from its get
>     module
>     > methods, who owns deletion of that? Should I preserve the
>     pointer and
>     > have SWMgr delete it when it gets deleted? Or does the caller
>     need to
>     > own deletion of it? Is that instance of the SWModule shared with
>     > everyone else who calls the getter methods, or is it unique per
>     > invocation of the getter?
>     >
>     > A similar question regarding getting keys from a module
>     instance. Does
>     > that key live with the module's cleanup, or does the caller now
>     have
>     > responsibility for the instance?
>     >
>     > --Greg
>     >
>     > _______________________________________________
>     > sword-devel mailing list: sword-devel at crosswire.org
>     > http://crosswire.org/mailman/listinfo/sword-devel
>     > Instructions to unsubscribe/change your settings at above page
>     _______________________________________________
>     sword-devel mailing list: sword-devel at crosswire.org
>     http://crosswire.org/mailman/listinfo/sword-devel
>     Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list:sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20250417/b6cb5724/attachment.htm>