Compilation strategy

[Jonathan M Davis]

On Sunday, December 16, 2012 22:58:26 Walter Bright wrote:
> On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
> > If the entire .d file is there in binary form, then I don't see why it
> > wouldn't work. .di files fail because they strip out the implementation.
> > If a binary format were used,
> 
> It's all about what is in the file, not whether it is text or binary.

The concept of .di files and their ilk is fundamentally broken precisely 
because they're trying to strip what's in the file. That's what causes the 
problems.

> > then we should be able to get away with keeping the
> > implementation there, because then it's obfuscated rather than for sitting
> > there for all to see, which is why corporations and the like insist on
> > distributing only headers. Even with an object file, the best that you get
> > is obfuscation, because it can always be reverse engineered, so it seems
> > to me that what needs to be avoided is providing text. As long as we use
> > text, we're forced to cut out the implementation and end up crippling any
> > code that uses that module, since it can't inline it or use it in CTFE.
> > In binary format, it's obfuscated, so the entire implementation can be
> > there, allowing inlining and CTFE to work.
> 
> This method of obfuscation simply will not hide things from someone with
> even modest technical ability, because *all* the source information is
> *necessarily* there in the file.
> 
> Object files are resistant to reverse engineering because most of the
> information is gone.

True, but they can stll be reverse engineered, and if the problem is that 
companies don't want 3rd parties looking at their code, then a binary format 
has obfuscated it and possibly solved that problem. Object files do make it 
harder, but they can still be reverse engineered, so it really becomes a 
question of what it takes to satisfy the folks who think that not giving the 
whole information in a .d or .cpp file somehow protects their code (since it 
doesn't really). And if a binary format can do that (as it seems to in Java 
land), then that seems like a far better solution, because then we can leave 
all of the information in there that inlining and CTFE need in order to do 
their jobs. With .di files, we'll never get that.

- Jonathan M Davis