<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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</p>
    <p>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)++) { ... }</p>
    <p>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();</p>
    <p>So I usually keep one SWMgr instance per thread.</p>
    <p>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.</p>
    <p>Troy</p>
    <p><br>
    </p>
    <p> <br>
    </p>
    <div class="moz-cite-prefix">On 4/11/25 11:56 AM, Greg Hellings
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHxvOV+NQm1veYkaOC=s_arRR3TQMaCXvhc4RU5R4eLVqtkv3A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">OK, so if I have code like this:</div>
        <div dir="ltr"><br>
        </div>
        <div>SWModule *mod1 = mgr->getModule("KJV");</div>
        <div>SWModule *mod2 = mgr->getModule("KJV");</div>
        <div><br>
        </div>
        <div>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?</div>
        <div><br>
        </div>
        <div>--Greg</div>
        <br>
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr" class="gmail_attr">On Sat, Apr 5, 2025 at
            10:51 AM Troy A. Griffitts <<a
              href="mailto:scribe@crosswire.org" moz-do-not-send="true"
              class="moz-txt-link-freetext">scribe@crosswire.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
            Greg,<br>
            <br>
            Typically in SWORD, the object/factory that created the
            object is <br>
            responsible for deleting the object unless a call was made
            to something <br>
            like 'clone' or 'create'.  So, SWMgr will delete all the
            SWModule <br>
            objects it allowcates when the SWMgr object is deleted. If
            you have <br>
            multiple threads in your application, we recommend each
            thread have its <br>
            own SWMgr object because the same SWModule object instances
            are returned <br>
            each time a getModule() call is made to the same instance of
            SWMgr.<br>
            <br>
            I usually have 3 SWMgr objects I interact with in my apps:
            one I create <br>
            for display, one I create for searching, and one I get from
            InstallMgr.<br>
            <br>
            The exceptions, as mentioned above, are usually noted in the
            comments, e.g.,<br>
            <br>
            <a
href="https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swmodule.h#L486"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swmodule.h#L486</a><br>
            <a
href="https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swkey.h#L134"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">https://github.com/bibletime/crosswire-sword-mirror/blob/trunk/include/swkey.h#L134</a><br>
            <br>
            Hope this helps,<br>
            <br>
            Troy<br>
            <br>
            <br>
            On 3/25/25 7:42 AM, Greg Hellings wrote:<br>
            > I have a question about pointer lifetime and management
            when <br>
            > interacting with libsword: who owns the lifetime and
            delete management <br>
            > of pointers coming out of the SWMgr and SWModule calls?
            For instance: <br>
            > if I create an SWMgr object and fetch a SWModule* from
            its get module <br>
            > methods, who owns deletion of that? Should I preserve
            the pointer and <br>
            > have SWMgr delete it when it gets deleted? Or does the
            caller need to <br>
            > own deletion of it? Is that instance of the SWModule
            shared with <br>
            > everyone else who calls the getter methods, or is it
            unique per <br>
            > invocation of the getter?<br>
            ><br>
            > A similar question regarding getting keys from a module
            instance. Does <br>
            > that key live with the module's cleanup, or does the
            caller now have <br>
            > responsibility for the instance?<br>
            ><br>
            > --Greg<br>
            ><br>
            > _______________________________________________<br>
            > sword-devel mailing list: <a
              href="mailto:sword-devel@crosswire.org" target="_blank"
              moz-do-not-send="true" class="moz-txt-link-freetext">sword-devel@crosswire.org</a><br>
            > <a
              href="http://crosswire.org/mailman/listinfo/sword-devel"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
            > Instructions to unsubscribe/change your settings at
            above page<br>
            _______________________________________________<br>
            sword-devel mailing list: <a
              href="mailto:sword-devel@crosswire.org" target="_blank"
              moz-do-not-send="true" class="moz-txt-link-freetext">sword-devel@crosswire.org</a><br>
            <a href="http://crosswire.org/mailman/listinfo/sword-devel"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
            Instructions to unsubscribe/change your settings at above
            page<br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
    </blockquote>
  </body>
</html>