output minimal .di files?

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 16 17:33:33 PST 2012

On Tue, Jan 17, 2012 at 12:17:18AM +0100, Timon Gehr wrote:
> On 01/16/2012 09:40 PM, H. S. Teoh wrote:
> >On Mon, Jan 16, 2012 at 09:32:57PM +0100, Alex Rønne Petersen wrote:
> >[...]
> >>I... don't think the error messages from expanding raw object code
> >>would be very pleasant to read, if you used a template incorrectly...
> >[...]
> >
> >It doesn't have to be *executable* object code; the compiler may store
> >extra info (perhaps as debugging data?) so that it can generate nicer
> >error messages.
> >
> >But like I said, this assumes the compiler is allowed to store arbitrary
> >data inside object files, which may not be the case on some platforms.
> >
> >
> >T
> >
> How would your proposal help hiding implementation details of
> templates anyway? All information still needs to be stored. Anyone
> could write a object file -> source file compiler for template
> implementations.

It depends on what you understand by "hiding implementation details".

I see it from the point of view of encapsulation taken to its logical
conclusion: users of the library only need to know the API of the
library and nothing else. When they read the interface file, it should
only contain the API and no implementation at all. In this sense,
implementation details are completely hidden -- that's what
encapsulation is all about.

Of course, the *compiler* (and/or linker) obviously needs to know the
full implementation details, otherwise it couldn't possibly produce the
final executable. So this information has to come from somewhere, object
files, compiler internal representation files, what-have-you. I don't
think it's possible, even in theory, to prevent reverse-engineering of
these sources of compiler information. Given enough determination,
*anything* can be reverse engineered.

And neither is prevention of reverse engineering the point.  The point
is that these are sources of *compiler* information, rather than
information for library users. In that sense it's useful to separate
information meant for the compiler, and information meant for users of
the library.


All problems are easy in retrospect.

More information about the Digitalmars-d-learn mailing list