On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley
<wiley.andre...@gmail.com> wrote:
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer
<schvei...@yahoo.com>wrote:
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
That's exactly what storing the interface in the object file does. You
don't need the source because the object file contains the compiler's
interpretation of the source, and any inferred properties it has
discovered.
Putting inferred purity into an object file sounds like a bad idea. It's
not hard to imagine this scenario:
-function foo in libSomething is inferred as pure (but not declared pure
by
the author)
-exeSomethingElse is compiled to use libSomething, and the compiler takes
advantage of purity optimizations when calling foo
-libSomething is recompiled and foo is no longer pure, and
exeSomethingElse
silently breaks
no, it just doesn't link.
Purity inference is fine for templates (because recompiling the library
won't change the generated template code in an executable that depends on
it), but in all other cases, the API needs to be exactly what the author
declared it to be, or strange things will happen.
I agree that's the case with the current object/linker model. Something
that puts inferred properties into the object file needs a new model, one
which does not blindly link code that wasn't compiled from the same
sources.
-Steve
