Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   For example, if you create your own class or struct which has a few
> > member variables, and then you instantiate a vector of that type, it will
> > be quite space-optimal: Every element in the vector will only consume as
> > much memory as the size of the object. There is no ancillary data needed.

> C# does that.  Of course, it's generating bytecodes not machine code.

  Can you compile a C# program into a stand-alone executable that does not
require a JIT compiler environment? (Well, I suppose that if the JIT
compiler is linked into the executable, it could perhaps work.)

  But thinking about it, why is the final compilation into machine code
delayed until the program is run? Why cannot it be done at compile time?

> >   On the other hand, it's not technically impossible, and it has been done,

> I had read that the guys who did it said basically it's impossible to do 
> right according to the standard, but you can get close. Not being an expert 
> on the esoteric details of C++ compiler implementation, I might have been 
> misunderstanding their conclusions.

  AFAIK they added export templates to the standard because they confirmed
that it can be done. They didn't predict, however, how hard it would be,
nor that major compiler writers would just skip doing it because of that.

> But sure, it can be done, but I'm not 
> sure what the benefit would be per se?  Why does anyone care? Is it just to 
> hide (in a commercial sense) the source code for the template library?

  Well, if you can avoid having to put tens of thousands of lines of code
in header files (just because the compiler forces you to), making compilation
slower and possibly bloating your program, that's always a plus. Often it's
beneficial when the compiler can inline templates, but there becomes a limit
where it actually becomes a hindrance when you have to put your entire
library in a header file. However, that's not the main problem.

  Support for export templates would allow the templated code to have
types, functions and data that are local to the compilation unit (and
possibly shared among all the different template type instantiations)
where the templated code is implemented. This might sound like a small
thing, but it's actually a huge defect in templated code when the compiler
doesn't support export templates.

  Just consider this simple example (in a source file):

//------------------------------------------
namespace
{
    int counter = 0;
}

export template<typename T>
void foo()
{
    ++counter;
    ...
}
//------------------------------------------

  What's so special about this? It's special in that all instantiations
of foo() will modify the *same* 'counter' (rather than there having one
'counter' per template type).

  The above is simply *not possible* with current C++ compilers (except
Comeau, which is the only one that supports export templates).

  (Ok, it's not completely impossible. You could make 'counter' global,
in which case the non-export foo() instantiations could modify it. However,
this obviously reduces modularity significantly, and grants unwanted
access for outside code to the variable.)

  Even if you don't really need data that is shared among all the template
instantiations, just the ability to have most of your types, functions and
data local to the compilation unit where the templates using them are,
would increase modularity significantly. It can also reduce executable bloat
(because types and data that are common to all template instantiations do
not need to be duplicated for each one.)

  AFAIK people working in the standardization committee are trying to come
up with a different solution to this problem which would be much easier for
compilers to implement.

-- 
                                                          - Warp

Post a reply to this message