[cfe-dev] libc++ internals visibility rational

[Reid Kleckner via cfe-dev]

I think this instance is just a bug.

As it was explained to me, libc++ attempts to make it possible to
statically link together two libraries that use different versions of
libc++ headers. These two libraries may reference inline template functions
from libc++ with different definitions, but as long as all of the
out-of-line symbols remain the same and implement the same functionality
and use the same struct layouts, things are supposed to "work".

With that in mind, any inline function in libc++ that isn't always_inline
or internal_linkage is probably a bug.

On Fri, Mar 31, 2017 at 10:46 PM, Mehdi Amini via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I’m wondering about libc++ visibility for the internals of the library.
> For example why do we define:
>
> _LIBCPP_INLINE_VISIBILITY
>     void __construct_at_end(size_type __n, const_reference __x);
>
> with inline/hidden visibility, but not this one:
>
> template <class _ForwardIterator>
> typename enable_if  <__is_forward_iterator<_ForwardIterator>::value,
> void>::type
> __construct_at_end(_ForwardIterator __first, _ForwardIterator __last,
> size_type __n);
>
>
> Thanks,
>
> —
> Mehdi
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170403/5942a49c/attachment.html>