[libcxx-commits] [PATCH] D103960: [libc++] Towards a simpler extern template story in libc++

Nikolas Klauser via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Jun 9 01:03:08 PDT 2022

philnik added a comment.

In D103960#3568852 <https://reviews.llvm.org/D103960#3568852>, @ldionne wrote:

> In D103960#3567171 <https://reviews.llvm.org/D103960#3567171>, @philnik wrote:
>> I really like this. I've got just one question: Why are the `extern` declarations for string different than for every other `extern template` class declaration?
> Do you mean why do we use macros for them? It's just that there's a really long list of methods to declare, so using macros avoids repeating them. However, TBH it's not clear to me that it's actually better, since this sort of duplication isn't super harmful anyways. I think I'd be OK with changing that and repeating the list of instantiated methods in a separate patch.

I mean why aren't we using `extern template class _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS basic_string<char, char_traits<char>, allocator<char>>` etc.? It's quite surprising IMO that `string` is the one class where we don't do that. Just to try it out I removed the explicit list and replaced it with the normal `extern template` stuff.  It turns out that `__init_copy_ctor_external`, `__erase_external_with_move`, `__assign_external` and `__assign_short` aren't marked as `_LIBCPP_HIDE_FROM_ABI` but are also not exported from the dylib. Other than `__assign_short` I think these are intended to go into the dylib. Wheter they are or aren't supposed to go into the dylib doesn't really matter right now. My point is that the explicit list causes inconsistencies and doesn't seem to have any actual uses. It's of course possible that I'm missing something.'that makes the explicit lists super useful.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list