[libcxx-dev] Option to disable inline namespacing completely?

[Eric Fiselier via libcxx-dev]

On Wed, Nov 14, 2018 at 12:04 PM Eric Fiselier <eric at efcs.ca> wrote:

> The itanium specification provides special compressed mangled names for
> std::string when it's not in an inline namespace [1]
>
> Specifically, `Ss` vs `St3__112basic_string`
>

Correction... `Ss` vs
`NSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE`


>
> [1]
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-compression
>
> On Wed, Nov 14, 2018 at 10:03 AM Marshall Clow via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> On Sun, Nov 11, 2018 at 9:49 PM Kristina Brooks via libcxx-dev <
>> libcxx-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I was wondering, would it be possible to add an option to disable inline
>>> namespacing completely (as a CMake
>>> configuration flag) in libc++ for the sake of being able to use
>>> shorthand mangling and without having to resort to
>>> handling it on IA64 mangler level. This has many use cases for example
>>> distributions of anything that includes libc++ as
>>> one and only libc++ and does not allow non-vendor software to be
>>> installed. On an embedded system, assuming debug info
>>> is generated, and given how common some of the debug data takes a very
>>> significant amount of space given the complex
>>> definition of something like `std::__2::basic_string<...>` versus the
>>> short form (`std::string` having a shorthand
>>> mangling is a godsend since it's 95% shorter, not an accurate figure but
>>> basically definitely above 90%).
>>>
>>
>> I'm confused here.
>> Why are you comparing `std::string` to `std::__2::basic_string<......" ?
>>
>> `std::__2::string` is quite short.
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>
>> -- Marshall
>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181114/eac9d895/attachment.html>