Question: possible feature for C++

[Peter Rybin]

CC: Kaz Kylheku <kaz@zeugmasystems.com>, Dima Sorkin 
<dima.sorkin@gmail.com>, eljay@adobe.com

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.
>