From: Francis Glassborow on
Timothy Madden wrote:
> Walter Bright wrote:
> [...]
>> Don't get me wrong, I'm not criticizing you for being enthusiastic about
>> this
>> feature and thinking it will work. Often times, fundamental advancements
>> are
>> made by people who reject the conventional wisdom and find a way. The
>> source
>> code is available for many C++ compilers, including g++ and Digital Mars
>> C++.
>> Feel free to organize some like-minded developers and try out your ideas.
>
> How would I do that when the committee is on to removing export ? :(
>
> Thank you,
> Timothy Madden
>

An IS is supposed to standardise existing practice. WG21 has on several
occasions ignored this (and with a lot of justification) However when 12
years after introducing a creative invention to resolve an impasse in
the committee it is not available to most users and we have absolutely
no reason to expect it ever to be. (however you look at it, that was the
primary motivation for the introduction of export, WG21 and J16 were
very close to meltdown at the meeting prior to its introduction -- I was
there and as a Head of Delegation I think I know all the details)

If after 12 years something is essentially just ink on paper and the
only people to have done anything about it (implement it) support its
removal WG21 would not be doing its job if it were to leave it in.
AFAICS no NB commented on its removal in the comments to the recent
ballot on the FCD so it is time, IMNSHO, to face reality, C++0x will be
a step closer to standardising existing paractice because export will
not be in it.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Timothy Madden wrote:
> Walter Bright wrote:
>> Timothy Madden wrote:
>>> Walter Bright wrote:
>>>> For one thing, it requires that the compiler maintain some sort of
>>>> global database of precompiled templates. Managing that database is a
>>>> time sink,
>>>> and comes with its own set of problems.
>>> I have heard this idea before, but how is this required ?
>>
>> If the compiler is compiling foo.cpp, and it contains an exported
>> template declaration, the compiler has no clue from the source code
>> where it might find that template definition.
>>
>> Therefore, there must be some sort of global database the compiler can
>> consult and update.
>
> The idea is the template definition is only needed at template
> instantiation time. I will compile foo.cpp /without/ the template
> definitions, and instead include the symbol table as it was at the end
> of the unit, in the generated object file.
>
> At the template instantiation phase (translation phase 8, a new step
> between compiling and linking) the compiler has all the object files,
> finds the pre-parsed template definition in one of them, and then
> completes the compilation of foo.cpp using the stored symbol table to
> compile the needed templates.
>
> There is no such global database involved, except maybe for some
> optimizations if you will.

The global database is, in this scenario, the collection of object files
containing the stored symbol tables and template definitions you present to
whatever program implements step 8.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Timothy Madden wrote:
> Walter Bright wrote:
> [...]
>> Don't get me wrong, I'm not criticizing you for being enthusiastic about this
>> feature and thinking it will work. Often times, fundamental advancements are
>> made by people who reject the conventional wisdom and find a way. The source
>> code is available for many C++ compilers, including g++ and Digital Mars C++.
>> Feel free to organize some like-minded developers and try out your ideas.
>
> How would I do that when the committee is on to removing export ? :(

The Committee doesn't dictate anything to you. You are free to start with those
compiler sources and implement whatever you wish. If your project winds up
proving that exported templates are a great idea, then I would expect that to
carry a lot of weight with the Committee in considering adopting it.

I am not on the Committee and do not speak for it, but given the history of
export, I expect that the members will not give the time of day to someone
simply arguing for export. A practical implementation demonstrating it's a good
idea would be the only thing that'll get an audience. Keep in mind that the only
existing implementation failed to prove it's a good idea.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andre Kaufmann on
Louis Lavery wrote:
>
> [...]
> I rarely use #defines (apart from the include guards in my .hpp and
> ..cpp files), and when I do it's a #define in a header and the #ifdef
> or #ifndef in the .cpp or .hpp. So it's not a problem for me. That

It's a problem for the compiler and sometimes for the developer too.

> [...]
> I like header files. As others have said, they separate the interface


The header file system introduces IMHO more complexity than needed.
(pimpl for separation, include guards -> multiple inclusion,
"thousand" includes in a header and implementation file ...)

Separation of interface and implementation can be done (optionally) in a
single file.

The main advantage of modules would be, that C++ could get rid of some
bad design decisions, inherited from C.

> [...]
> Louis.

Andre

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Timothy Madden on
Walter Bright wrote:
> Timothy Madden wrote:
[...]
>> The idea is the template definition is only needed at template
>> instantiation time. I will compile foo.cpp /without/ the template
>> definitions, and instead include the symbol table as it was at the end
>> of the unit, in the generated object file.
>>
>> At the template instantiation phase (translation phase 8, a new step
>> between compiling and linking) the compiler has all the object files,
>> finds the pre-parsed template definition in one of them, and then
>> completes the compilation of foo.cpp using the stored symbol table to
>> compile the needed templates.
>>
>> There is no such global database involved, except maybe for some
>> optimizations if you will.
>
> The global database is, in this scenario, the collection of object files
> containing the stored symbol tables and template definitions you present to
> whatever program implements step 8.

That would be the compiler (or a compiler tool or compiler-provided
tool), because template instantiation means actual template compilation
from pre-parsed source.

Anyway, if the object files are that database, then I see no locking
problem there, even if source files are compiled separately or in
parallel. Final template instantiation works on all object files at
once, like linking, except that you can also perform instantiation on a
subset of them if you want. For example if most of the templates are
written by you and you use only a few templates written by other
programmers in the project than you can instantiate templates using only
your object files to test your changes or compilation results. When the
program is ready, for example you are ready to commit changes to source
code control, the entire project will be compiled and templates still to
be instantiated are also found.

If you want instantiation on two subsets of object files at the same
time you get to the locking problem ... :)

Thank you,
Timothy Madden

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]