C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Specify the mangled name

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Thu, 6 Feb 2025 11:04:44 +0000
I've never written a compiler before -- I've tinkered a bit editing
parts of g++ and the linker -- but anyway I imagine it works something
like as follows:

I imagine that the compiler maintains a list of all the types (and
unspecialised templateable types) that have been declared so far in a
translation unit. Let's call this container "gTranUnitTypes".
When the compiler encounters something that might be a type, e.g.
"std::vector<int>", it looks through gTranUnitTypes to see if it's
already been declared. If it doesn't find it, you get a compiler
error.

Well, what if a compiler were to be edited as follows:

If it fails to find the type in gTranUnitTypes, it then looks for it
in another built-in container called "gStdLibraryFwdDeclarations". The
latter container contains a forward declaration of every class type in
the C++ Standard library, approximately a thousand of them.
gStdLibraryFwdDeclarations is a sorted map where the key is the hash
of the type's name, so you can do a binary search through it.
gStdLibraryFwdDeclarations would take up way less than a megabyte in
memory.

This would mean that we could write a translation unit as follows:

    [ beginning of translation unit ]
    std::vector<int> my_global_vec;
    [ end of translation unit ]

and it would compile just fine because the compiler can find a forward
declaration of "std::vector" inside gStdLibraryFwdDeclarations.

So of course the next question is: ? ? ? ? ? How Will This Affect
Compile Times ? ? ? ? ?

Well it will only affect compile times for translation units that fail
to find the type in gTranUnitTypes -- that is to say: It will only
affect compile times for translation units that are going to fail to
compile anyway. And you can speed up compile times for other
translation units by getting rid of "#include <vector>".

Received on 2025-02-06 11:04:57