Re: Removing space waste for g++ static inlined objects

["Ronald F. Guilmette" <rfg at monkeys dot com>]

In message <u98zmxt01v.fsf@casey.cambridge.redhat.com>, you wrote:

>>>>>> "Ronald" == Ronald F Guilmette <rfg@monkeys.com> writes:
>
>> Included below is a revised and simpler one that seems to work quite
>> well.  It still doesn't live up to all of my best hopes with regard
>> to link-time ``global'' (inter-compilation-unit) name conflicts/pollution,
>> but I'm not sure that all of the problems in this regard can be solved
>> without totally reinventing what we know as ``linking'' anyway.  In
>> other words, it looks to me like the definition of the language (C++)
>> causes some basically insoluable problems, and that we just have to
>> muddle along as best as we can... at least until some brave soul steps
>> forward who wants to totally re-implement the linker from scratch.
>
>What problems are you referring to?  As you suspected and I confirmed, the
>ODR guarantees that a class always refers to the same class throughout the
>program.

No.  The One Definition Rule only guarantees that if the programmer causes
there to be more than one definition... of a class, or a function... within
the entire linked program, then it is HIS PROBLEM, and the compilation
system is, in that case, free to screw him... under the auspices of the
standard, of course.  (``Screwing him'' in this context just means that
the compilation system is allowed... by the standard... to produce the
proverbial ``undefined behavior'', which, as we all know, could mean
that the compiler stands up and starts whistling dixie, or that it whips
out a .45 and shoots the programmer right between the eyes for being such
a dummy as to accidentally violate the ODR.)

In my personal opinion, this was just bad engineering, and a bad choice
on the part of the C++ standardization comittee.  Humans are too frail,
and the programs we work on are too big.  On a 100 man project, how can
I be sure... when I start to code up a class `foo'... that somewhere else
on the project some other bloke isn't also coding up his own (conflicting
and different) version of `foo'?  I can't.  And when such a scenario
transpires, then the whole linked program may malfunction in deeply
mysterious ways.  WEhen that happens, we will investigate, of course, and
in the end, we will lay blame on the programmers for their violations of
the ODR, but what good does THAT do anybody?

It would have been a _lot_ better if the C++ standard had said that the
programmer must not violate the ODR _and_ that the compilation system
must tell him (warn him) when/if he does.

But that's not what it says, of course, so no actual C++ implementation
even try to do that.

I know what Stroustrup would say to all this... ``Use namespaces.  That
will solve the problem.''

Yeabut I live out here in the Real World where there are already unpteen
zillion lines of code written WITHOUT any use of namespaces.  It is a
little late now to re-engineer all of that.

>> Anyway, for now, this patch makes the wasted space for static-duration
>> extern-inline-function-nested objects go away.  It has been tested on
>> a big application and seems to work.
>
>Thanks, but it'll need some more work to go into CVS; first, of course,
>you'll need to update it to the current source tree (which has no function
>called build_static_name).  Also, rather than just call comdat_linkage, it
>should use the code currently wrapped in 'if (!flag_weak)', so that
>primitive object formats work somewhat.

OK.  I will do these things.

>Finally, we need to support
>calculating the discriminator properly for non-types.

Whatever you just said, it is Greek to me.

Can you elucidate (please)?