RE: Question: possible feature for C++

RE: Question: possible feature for C++

[Kaz Kylheku]

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.

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

Re: Question: possible feature for C++

[John Love-Jensen]

Hit [SEND] by accident...

"Fortunately, ..."

Fortunately, there are a couple committee member "heavy-hitters" championing
the module proposal.

Sincerely,
--Eljay

Re: Question: possible feature for C++

[John Love-Jensen]

Hi Peter,

> I'm thinking about some "improvement" for C++. Basically, that's about
> coming back to C++ from Java. Can C++ compiler find sources for
> referenced classes/types itself, like Java compiler does, i.e. without
> notion for includes?

The "module" proposal is being worked on for the next C++ standard, or
perhaps the one after.

One of the effects of the module proposal would be NOT to obsolesce the
preprocessor, but it would be a compelling alternative to using #include
preprocessor directives.

At the current moment, as I understand the situation, module proposal has
been cut from C++0x (2008-or-so of the ISO 14882), and pushed back to a TR
or perhaps the next update of the standard (2018-or-so).  Fortunately,

Google URLs on C++ Modules...
http://www.google.com/search?rls=en&q=modules+site:www.open-std.org/jtc1/sc2
2/wg21/&ie=UTF-8&oe=UTF-8

Keep in mind that ISO standards are supposed to be stable for a 10 year
commitment at a stretch.  That's both bad (squelches compiler innovation),
and good (stops the moving target for compiler vendors).

> I'm looking for some discussion about this. Could you please point me
> some place, where such themes could be discussed? I believe I'm hardly a
> first one to think about it.

The place where the ongoing evolution and development of C++ itself is
happening is the C++ Standards Committee (JTC1, SC22, WG21).
http://www.open-std.org/jtc1/sc22/wg21/

Also, there is a lot of C++ work going on in Boost, which likely a good
portion thereof will be incorporated into future C++ standards.
http://www.boost.org/index.htm

HTH,
--Eljay

Re: Question: possible feature for C++

[Dima Sorkin]

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.

I hope I understood you right.

Regards,
Dima.

Question: possible feature for C++

[Peter Rybin]

Hi noble GCC developers!

Sorry for using a general purposes mailing list.

I'm thinking about some "improvement" for C++. Basically, that's about 
coming back to C++ from Java. Can C++ compiler find sources for 
referenced classes/types itself, like Java compiler does, i.e. without 
notion for includes? It seems, that in our days it's not such a big task 
for compiler. To let me completely forget about header files and 
ordering of my declarations. And to the greatest joy of IDEs. Is it 
possible to implement this as experimental extension? Does anyone have 
ideas, how difficult it's going to be to develop this on top of gcc?

I'm looking for some discussion about this. Could you please point me 
some place, where such themes could be discussed? I believe I'm hardly a 
first one to think about it.

Thank you very much,

Peter