<div dir="ltr">& repeating for the benefit of cfe-dev, here's the list of known cases of conditional ownership (I'm sure there are others that don't fit the exact naming convention I grep'd for):<br><br><div>In Clang, simply grepping for "Owns" comes up with the following boolean members:</div><div><br></div><div>CodeGenAction::OwnsVMContext</div><div>ASTReader::OwnsDeserializationListener</div><div>Diagnostic::OwnsDiagClient</div><div>Preprocessor::OwnsHeaderSearch</div><div>TokenLexer::OwnsTokens</div><div>Action::OwnsInputs (this ones trickier - it's a boolean that indicates whether all the elements of a vector<T*> are owned or unowned)</div><div>ASTUnit::OwnsRemappedFileBuffers</div><div>VerifyDiagnosticConsumer::OwnsPrimaryClient</div><div>TextDiagnosticPrinter::OwnsOutputStream</div><div>FixItRewriter::OwnsClient</div><div>Tooling::OwnsAction</div><div><br></div><div>Some in LLVM:</div><div><br></div><div>circular_raw_ostream::OwnsStream</div><div>Arg::OwnsValues (another tricky one with a bool flag and a vector of raw pointers, if I recall correctly)</div><div><br></div><div><br></div><div>And a couple that I changed {T*, bool} to {T*, unique_ptr<T>}:</div><div><br></div><div>LogDiagnosticPrinter::StreamOwner</div><div>ASTUnit::ComputedPreamble::Owner</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 1:00 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">[+cfe-dev]<br><br>This conversation has already been happening on llvm-dev so there's no good way for me to capture the entire existing discussion (so I'm jumping you in part-way) & the subject line could be more descriptive, but I wanted to add Clang developers since many of the interesting cases of conditional ownership I've seen were in Clang.<br><br>I know some of you are also on llvm-dev but not active readers, so it might be worth using this as a jumping off point to go & find the full llvm-dev thread, read that and, when replying, add cfe-dev.<br><br>If anyone not on llvm-dev wants some more context there's the email archive here ( <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/thread.html#77136" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/thread.html#77136</a> ) and/or I'm happy to provide more context/summary myself.<div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 9:44 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Oct 2, 2014 at 2:43 AM, Anton Yartsev <span dir="ltr"><<a href="mailto:anton.yartsev@gmail.com" target="_blank">anton.yartsev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Thanks for the feedback!<br>
    </div><span>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Oct 1, 2014 at 3:36 PM, David
            Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <span dir="ltr"><<a href="mailto:anton.yartsev@gmail.com" target="_blank">anton.yartsev@gmail.com</a>></span>
                wrote:<br>
                <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
                  <div text="#000000" bgcolor="#FFFFFF">
                    <div>Ping!<span><br>
                      </span><br>
                      Suggested is a wrapper over a raw pointer that is
                      intended for freeing wrapped memory at the end of
                      wrappers lifetime if ownership of a raw pointer
                      was not taken away during the lifetime of the
                      wrapper. <br>
                      The main difference from unique_ptr is an ability
                      to access the wrapped pointer after the ownership
                      is transferred.<br>
                      To make the ownership clearer the wrapper is
                      designed for local-scope usage only.<br>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                </div>
              </span>
              <div>I'm still concerned this isn't the right direction,
                and that we instead want a more formal "maybe owning
                pointer". The specific use case you've designed for
                here, in my experience, doesn't seem to come up often
                enough to justify a custom ADT - but the more general
                tool of sometimes-owning smart pointer seems common
                enough (& problematic enough) to warrant a generic
                data structure (and such a structure would also be
                appliable to the TGParser use case where this came up).<br>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote></span>
    David, could you, please, clarify the concept of the "maybe owning
    pointer"?</div></blockquote><div><br></div></span><div>See my reply to Chandler with a list of classes that hold {T*, bool} members where the bool indicates whether the T* needs to be deleted or not. My original goal here was to provide an API to make those more robust (more precisely: to remove the need to call "release()" and allow us to stay in a clear(er) owning domain).</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div><br>
                I'd love to hear some more opinions, but maybe we're not
                going to get them... </div>
            </blockquote>
          </div>
          <br>
          I strongly agree that the example here isn't compelling.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">I think it is a very fundamental design
          problem when there is a need for a pointer value after it has
          been deallocated...</div>
      </div>
    </blockquote></span>
    Not deallocated but stored to the long-living storage. I agree, the
    problem is in design, the suggested wrapper is an intermediate
    solution, it was just designed to replace the existing ugly fixes.<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">I even question whether we need a
          "maybe owning" smart pointer, or whether this is just an
          indication that the underlying data structure is *wrong*. The
          idea of "maybe" and "owning" going to gether, in any sense,
          seems flat out broken to me from a design perspective, and so
          I'm not enthused about providing abstractions that make it
          easier to build systems with unclear ownership semantics.</div>
      </div>
    </blockquote>
    <br>
    </span><span><font color="#888888"><pre cols="72">-- 
Anton</pre>
  </font></span></div>

</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>