This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example

"David Abrahams" <> writes:

> Speculating, of course: I doubt it would have much impact because users
> typically know better than to use RTTI and EH in their inner loops; every
> good C++ book I've seen warns that these features are not always fast.

I'm guessing also, but I see more and more users of dynamic_cast
around me, after they get told that it is safer than static_cast; I
agree with them that users should use dynamic_cast if they can't
easily guarantee that static_cast will be always correct.

So expect more usage of RTTI in the future.

> I totally agree. In that case you'll have to accept my shared linking
> semantics, I think. In today's model, depending on the order in which it is
> loaded w.r.t. other "programs", a "program" may or may not share with its
> libraries.

I can't see all consequences, so I cannot really bless that approach
right now. Implementing that approach will tell what new problems it

> > In this specific case, any Python extension would be a "program"
> > (though free-standing, since it has a different entry point).
> So, what happens when multiple "programs" link to the same shared library?

Each object in the shared library should still exist only once. That
means that some objects can change their state "spontaneously", from
the view of a "program", but apart from that, ODR and everything is

> > You probably cannot convince compiler vendors to follow
> > what you consider a reasonable semantics unless you specify what that
> > semantics is, and contribute code or money to change their
> > implementations.
> There's one other way: the pressure of standards. However, that takes a
> long time, and seldom works without a reference implementation...

I think it should never work without a reference implementation:
standardization should codify existing practice, instead of setting
new grounds. That is OT here, of course.

> I think you misunderstand me. What you wrote doesn't contradict item 4:
> since the graph is bidirectional, if A is reachable from B then B is
> reachable from A. I don't care /which/ definition is chosen - they're
> required to be the same anyway - I only care that they're shared.

I see. If that is what Solaris does, it sounds reasonable indeed. If
Solaris does something else, I'd like to see that approach confronted
with your specification.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]