Re: A remark on -fsquangle

[Joe Buck <jbuck at synopsys dot com>]

> Undoubtedly, it's a brilliant idea, to compress huge mangled names. But
> the necessity to have the entire run-time system being compiled with an
> option, which is disabled per default, is a real handicap. When I
> develop some software package and make it publicly available, I can't in
> earnest require from the potential users that they have to reinstall
> their compiler prior to using my package.

This is why -fsquangle isn't the default.  However, we must break
binary compatibility for other reasons, to have a fully conforming
C++ library.  For this reason we were planning to make all the changes
that break compatibility as a group, so we break things only once.

> Must it inevitably lead to another, incompatible mangling scheme? I'd
> like to propose the following alternative: the maximal symbol length the
> system assembler and linker can cope with is known for each platform, or
> can be estimated experimentally. E.g. by Solaris it lies slightly above
> 1K. Or one can choose a defensive universal bound that would do on the
> most platforms.  At any rate, only the names that would exceed this
> boundary must be compressed.

If -fsquangle were the only new feature that would break compatibility
this might make sense.  But we will need to totally break things to move
the C++ library into the std namespace; we also have a new layout that
greatly reduces the memory requirement when empty classes are used or
derived from.

-fsquangle saves space even for common, relatively short names.  It will
compress almost any name where the same class appears twice or more.

For example,
	MyClass::MyClass(const MyClass&)

is
__7MyClassRC7MyClass

without squangling and
__7MyClassRCB0

with squangling.  It's there, it works, it greatly reduces the size of
symbol tables.  I can't see any reason to toss it.