On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as minimal and
stupid variation of
module where symbols are identified by mangling (not plain
meta data as (would
be) in module) and no source for templates is emitted.
+1
I'll bite. How is this superior to D's system? I have never
used TP.
*Semantic info on interdependency of symbols in a source file
is destroyed right
before the linker and thus each .obj file is included as a
whole or not at all.
Thus all C run-times I've seen _sidestep_ this by writing each
function in its
own file(!). Even this alone should have been a clear
indication.
This is done using COMDATs in C++ and D today.
Honest question - If D already has all the semantic info in
COMDAT sections, why do we still require additional auxiliary
files? Surely, a single binary library (lib/so) should be enough
to encapsulate a library without the need to re-parse the source
files or additional header files?
You yourself seem to agree that a single zip file is superior to
what we currently have and as an aside the entire Java community
agrees with use - Java Jar/War/etc formats are all renamed zip
archives.
Regarding the obfuscation and portability issues - the zip file
can contain whatever we want. This means it should be possible to
tailor the contents to support different use-cases:
* provide fat-libraries as in OSX - internally store multiple
binaries for different architectures, those binary objects are
very hard to decompile back to source code thus answering the
obfuscation need.
* provide a byte-code solution to support the portability case.
e.g Java byte-code or Google's pNaCL solution that relies on LLVM
bit-code.
Also, there are different work-flows that can be implemented -
Java uses JIT to gain efficiency vs. .NET that supports
install-time AOT compilation. It basically stores the native
executable in a special cache.
