* Re: Question: possible feature for C++
@ 2006-12-05 23:46 Peter Rybin
0 siblings, 0 replies; 6+ messages in thread
From: Peter Rybin @ 2006-12-05 23:46 UTC (permalink / raw)
Cc: gcc-help
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Question: possible feature for C++
@ 2006-12-04 18:01 Kaz Kylheku
0 siblings, 0 replies; 6+ messages in thread
From: Kaz Kylheku @ 2006-12-04 18:01 UTC (permalink / raw)
To: Dima Sorkin, gcc-help; +Cc: Peter Rybin
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: possible feature for C++
2006-12-04 15:44 ` John Love-Jensen
@ 2006-12-04 15:48 ` John Love-Jensen
0 siblings, 0 replies; 6+ messages in thread
From: John Love-Jensen @ 2006-12-04 15:48 UTC (permalink / raw)
To: Peter Rybin, MSX to GCC
Hit [SEND] by accident...
"Fortunately, ..."
Fortunately, there are a couple committee member "heavy-hitters" championing
the module proposal.
Sincerely,
--Eljay
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: possible feature for C++
2006-12-04 14:32 Peter Rybin
2006-12-04 14:55 ` Dima Sorkin
@ 2006-12-04 15:44 ` John Love-Jensen
2006-12-04 15:48 ` John Love-Jensen
1 sibling, 1 reply; 6+ messages in thread
From: John Love-Jensen @ 2006-12-04 15:44 UTC (permalink / raw)
To: Peter Rybin, MSX to GCC
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question: possible feature for C++
2006-12-04 14:32 Peter Rybin
@ 2006-12-04 14:55 ` Dima Sorkin
2006-12-04 15:44 ` John Love-Jensen
1 sibling, 0 replies; 6+ messages in thread
From: Dima Sorkin @ 2006-12-04 14:55 UTC (permalink / raw)
To: gcc-help; +Cc: Peter Rybin
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Question: possible feature for C++
@ 2006-12-04 14:32 Peter Rybin
2006-12-04 14:55 ` Dima Sorkin
2006-12-04 15:44 ` John Love-Jensen
0 siblings, 2 replies; 6+ messages in thread
From: Peter Rybin @ 2006-12-04 14:32 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-12-05 23:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-05 23:46 Question: possible feature for C++ Peter Rybin
-- strict thread matches above, loose matches on Subject: below --
2006-12-04 18:01 Kaz Kylheku
2006-12-04 14:32 Peter Rybin
2006-12-04 14:55 ` Dima Sorkin
2006-12-04 15:44 ` John Love-Jensen
2006-12-04 15:48 ` John Love-Jensen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).