On Tuesday, 18 December 2012 at 11:43:18 UTC, foobar wrote:
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.
In Windows 8 RT, .NET binaries are actually compiled to native
code when uploaded to the Windows App Store.
