On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer <schvei...@yahoo.com>wrote:
> 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. > Then all you've done is to make attributes the author can't control part of the API, which will force library users to recompile their code more often for non-obvious reasons. Avoiding that is one of the points of shared libraries. I think we're actually talking about different contexts. I'm speaking in the context of shared libraries, where I think the API needs to be exactly what the author requests and nothing more. With object files, static libraries, and static linking, I agree that this sort of thing could work and wouldn't cause the same problems because it's impossible to swap the library code without recompiling/relinking the entire program.
