<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 5, 2018 at 7:43 PM, Li, Zeyang <span dir="ltr"><<a href="mailto:a.banknote@gmail.com" target="_blank">a.banknote@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">@Eric,<div><br></div><div>Could you elaborate a bit what it means to move the SFINAE into the template parameter list? Does it mean the enable_if conversion check could be moved to the template parameter list and remove the default __nat parameter?</div></div></blockquote><div><br></div><div>Yep, you got it. That's what it entails.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> Does that have any performance implication? </div></div></blockquote><div><br></div><div>You'll be passing one less parameter, so yes, there will be less codegen. Though I'm not necessarily doing it for that reason.</div><div><br></div><div>I personally find using default function arguments for SFINAE to be a worse solution than default template parameters. Users are able</div><div>to accidentally pass "{}" to the function parameter, which should really be ill-formed. I also find the default template parameter</div><div>SFINAE easier to read.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I'm really interested to know as I'm writing my own version of shared_ptr without atomics. </div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Zeyang</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 7:27 AM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That sounds right to me.<br>
<span class="m_3565306929256476950HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span><div class="m_3565306929256476950HOEnZb"><div class="m_3565306929256476950h5"><br>
On Jun 5, 2018, at 4:07 PM, Erik Pilkington <<a href="mailto:erik.pilkington@gmail.com" target="_blank">erik.pilkington@gmail.com</a>> wrote:<br>
> <br>
> Looks like the initial purpose was to implement a poor man's explicit operator bool that returned a pointer to member, but it was removed in r151088.<br>
> <br>
> <br>
> On 2018-06-05 3:57 PM, Eric Fiselier via cfe-dev wrote:<br>
>> I'm not sure what the purpose is. I agree it doesn't seem to have any effect, and the git blame comes back to the initial commit for libc++.<br>
>> Changing the layout of `__nat` now would be an ABI break; so that's out of the question. But I have some upcoming patches that are going<br>
>> to remove most usages of it.<br>
>> <br>
>> @Howard, do you recall what the purpose of this was? Something to do with initializing empty structs maybe?<br>
>> <br>
>> /Eric<br>
>> <br>
>> On Tue, Jun 5, 2018 at 2:11 AM, Li, Zeyang via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> I was looking through clang's c++ standard library, and found this class in the shared_ptr class.<br>
>> <br>
>> class shared_ptr<br>
>> ...<br>
>> private:<br>
>>         struct __nat {int __for_bool_;};<br>
>> ...<br>
>> };<br>
>> <br>
>> and I understand that this class is used to detect whether type conversion is possible at compile time, but its member __for_bool_ is never used anywhere in the class or the weak_ptr counterpart. So my question is, what is the point of __for_bool_, why not simply use an empty class for the same purpose?<br>
>> <br>
>> I'm sure the standard library authors definitely knows better than me. Please help.<br>
>> <br>
>> Thanks,<br>
>> Zeyang<br>
>> <br>
>> <br>
>> ______________________________<wbr>_________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
>> <br>
>> <br>
>> <br>
>> <br>
>> ______________________________<wbr>_________________<br>
>> cfe-dev mailing list<br>
>> <br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
> <br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>