CC: Kaz Kylheku <kaz@xxxxxxxxxxxxxxxxx>, Dima Sorkin
<dima.sorkin@xxxxxxxxx>, eljay@xxxxxxxxx
Hi everybody,
Thank you all very much for your responses.
I'm sure I need some time to consume the information you referenced for me.
Just to make myself clear, I'd like to provide some sample sources, to
show what I meant:
(no ordering of files is implied)
File nm1/A.xcpp:
/struct A {
nm2::B * b;
};
/
File nm2/B.xcpp:
/struct B {
B(int param = nm1::def_param)
{ }
nm1::A a;
};
/
File nm1/misc.global.xcpp:
/const int def_param = 5;
/
Every source file contains standard C++ code, but with no includes.
Let compiler itself find files with needed sources and extract interface
parts from them. Mapping namespaces to src directories could work (type
definition/declaration should be in similary named or ".global" source
file in a corresponding directory). It keeps every declaration a one
with its definition. Source files are parsed here without any context.
It doesn't seem to be very complicated to me. In building C++ compiler
from scratch, IMHO this aspect wouldn't require much resources. E.g., as
I understand, standard C++ compiler already does parse class definition
as whole first, skipping method bodies for later compilation.
I don't see problems with binary files here. A single source file could
be treated as compilation unit and provide single object file, or many
files could be compiled together, grouped by any reasonable criteria
(first gives finer incremental compilation, later probably is better for
optimization). I don't know about "make" utility though. To make it
faster, compiler may want to keep extracted interfaces in some
intermediate binary files beside to sources. It would require new file
format probably, but on the other hand, it would almost immediately
facilitate a runtime reflection for those, who need it.
I'm sorry for making it so long without saying anything new.
Thanks again for your answers and opinions,
Peter
Kaz Kylheku wrote:
On December 5, 2006 Dima Sorkin wrote:
On 12/4/06, Peter Rybin wrote:
To let me completely forget about header files and
ordering of my declarations.
Hi.
I think this will break the ability of compiling C++ modules
separately,
as compiler will have to see the whole code ahead.
You might want to look at how some other languages handle this, like
Modula 2/3, Ada ...
Instead of seeing the whole code, the compiler sees some fraction of the
code which is designated as the interface.
In C++, we fraction off that part into a separate file and use text
inclusion. In these other languages, there is a more disciplined
approach whereby a module expresses a dependency on the other one, and
the compiler extracts the interface fraction of the module.
The nice thing is that because the data is structured in this way, you
can optimize it cleanly. For instance, the compiler can take the
interface fraction of a module, and compile it into a binary form. Then
when that module is used during the compilation of hundreds of other
modules, no lexical analysis or parsing has to take place. The compiler
loads (or refers to an already loaded) binary structure.
Similar things have been done for languages based on text inclusion,
like the ``precompiled headers'' in Microsoft's compiler. Without the
underlying structure which delimits the interfaces as objects, it
doesn't work particularly well. You get problems with broken
dependencies so that precompiled headers are not refreshed, etc.
