[cfe-dev] http://llvm.org/bugs/show_bug.cgi?id=11462

[Eli Friedman]

On Fri, Dec 2, 2011 at 1:04 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote:
> FWIW, I think a better solution for the library issue would be for
> clang to provide an attribute saying "ignore the rule in
> [intro.object]p6, and allow this member to have 0 size." Doing this
> would allow possibly-empty types to be used directly as members,
> rather than obfuscating the code by forcing them into base classes or
> tuples. Perhaps spell the attribute [[may_be_empty]] or
> [[may_have_same_address_as_other_members]].

If we did that, the user could observe two final objects with the same
address... which shouldn't be possible, I think.

-Eli

> As c++std-lib-31670 indicates, there are non-final classes that can't
> be derived from:
>
>  struct B // cannot be a base class
>  {
>      virtual ~B() final {}
>  };
>
> So __is_final is probably not the right trait even for use cases
> beyond the empty-base-class optimization.
>
> On Fri, Dec 2, 2011 at 12:00 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>> I would like to draw clang developer's attention to:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=11462
>>
>> This is a feature request for a new intrinsic __is_final(T).
>>
>> This intrinsic has become necessary due to the recent C++ language addition "final".  The problem is that many libraries (such as libc++) will derive from types they know nothing about except that the type is a class and is eligible for the empty base optimization.
>>
>> libc++ uses this technique in no less than 5 places to optimize away space for allocators, deleters, predicates, etc.  It makes all containers smaller, and is what enables sizeof(unique_ptr) == sizeof(void*).  I.e. it is a critically important optimization.
>>
>> Now that our customers can write:
>>
>> class final A {};
>>
>> we find ourselves in the position that libc++ will attempt to derive from A in a surprising number of places (because it is empty), only to result in a compile time error because A is also final.  Thus libc++ needs a way to check classes for final.
>>
>> Ganesh has proposed a patch to clang to implement __is_final, complete with a __has_feature check.  libc++ really needs this so that our clients can write:
>>
>>   std::tuple<A> t;
>>
>> Comments?  Questions?
>>
>> Thanks,
>> Howard
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev