Re: Any hopes for export ?
Timothy Madden wrote:
Walter Bright wrote:
Timothy Madden wrote:
The main reasons I hear now against export are that it is not actively
demanded (users always have the old inclusion model), that it is costly
to implement, and that it has not been implemented.
Export also fails to deliver on its promises of:
1. faster compilation
2. effective obfuscation of template definition source code
Export promises template declarations in header files, and definitions
in source files.
Right, but there has to be a point to that.
If the compiler can get some form of speed benefit with that, which is
likely, that would be great.
I should say here that pre-parsed templates might compile faster than
plain source code templates included everywhere. Pre-parsed templates,
although not fully compiled like object code, are still half-compiled
and that will help with speed.
It doesn't work out that way in practice, though, for various reasons -
precompiled headers are a far simpler feature and deliver actual speedups.
Speed is not improved radically as some expected because the template
still gets compiled at potentially any translation unit where it is
instantiated; symbols used in the template that are dependent on
template arguments have to be looked for at that point too. That is
flexible behavior and a good thing, but then again not every template
uses dependent names, so you still get a speed benefit. And if they do
use them, you get no slower than the speed you get including the
definition. How is export wrong ?
For one thing, it requires that the compiler maintain some sort of global
database of precompiled templates. Managing that database is a time sink,
comes with its own set of problems.
About source code obfuscation, other languages too compile to
bytecode, that can gives back the source, and they do just fine and
have a lot of support and many libraries. So if export can get that
for templates, and compiles to a pre-parsed tree, much like the
bytecode, I would say it still helps. Again, how is it wrong ?
Because it is a failure at source obfuscation. There are many programs that
convert bytecode back into reasonable source code, thereby rendering
any attempts to obfuscate the source. Furthermore, precompiled templates
necessity contain more information than Java bytecodes, so the decompiler
an even better job at reconstructing the source.
Basically, if you need source obfuscation, use PIMPL. Exported templates
going to get you there.
Besides, even proprietary libraries usually ship with the source code
(but without the license for its use) for debugging and documentation,
so source obfuscation is not much of an issue, and whatever export can
get of it, shall be good enough.
It's fine if obfuscation isn't desirable, but then what are exported
And of all the complexity that export is accused of, introducing a
whole-program compilation feature, such as template instantiation (as
someone else said in this thread), makes possible more language
features, not just export.
Whole program compilation would render exported templates irrelevant, so
there seems to be no place for them.
Is there some estimate about when the new language shall be out ? Will
there be other meetings, or votes until then ?
I don't know, I'm not on the Committee.
Yeah, I can see it is not obvious to everybody that export is useful;
I've written a complete C++ compiler, and spend some time studying the
My conclusion is that exported templates simply have no net benefit, even if
their implementation cost were zero.
people have long gotten used to the inclusion model as the only model
Not at all. I worked on D, which has a symbolic import system. "Exported
templates" comes for free with such, and without the complexity. C++
templates attempted to graft a subset of symbolic import onto the inclusion
model, and it just does not work.
A company that is interested in this would certainly help, however I
guess this is not too likely. Sometimes I find that the commercial
model of developing-for-profit looks much like the greedy algorithm
used for computing the minimum coins for a change (given a set of
possible coin values) on a snacks machine. Greedy is known to give an
optimal solution for practical and most cases, but not for all of them
:(. Just like a company could benefit from export, but still because
of the greedy-like approach of go-for-profit always has only a loose
interest for it.
Look at it another way. It would take me 3 man-years to implement it. Am I
greedy to want some sort of return for investing 3 years of my life? I don't
any return on investment for exported templates, not for me and not for my
customers. I've got too much to do that has big demand for it, like the 64
code generator I'm up to my eyeballs in at the moment.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]