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
<scr...@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@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
