Re: namespaces and main()
From: poiuz24 (poiuz24_at_web.de)
Date: 07/26/04
- Next message: Phlip: "Re: New to the group - with question."
- Previous message: Victor Nazarov: "Sets relations"
- In reply to: tom_usenet: "Re: namespaces and main()"
- Next in thread: JKop: "Re: namespaces and main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 26 Jul 2004 03:17:32 -0700
> I for one would love something along the lines of:
> #import "otherclass.cpp"
> and
> #import <vector>
> etc.
> I'm sure that something like this could be made to work, it's just a
> matter of someone writing it and proving it.
yes, i'd love that too .. actually, i thought along very
similar lines: import "otherclass"
that is, not the preprocessor, but the compiler would handle
'import' and no specification of file extension, since object
file extensions may be platform specific (on a *nix system, above
would make the compiler read type information for OtherClass
from "otherclass.o")
> >it becomes clearer and clearer to me that the real legacy are the
> >object file formats used to communicate between compiler and linker
>
> Indeed. C++ was specifically designed so that it could be linked using
> a traditional linker. Templates slightly damaged that, and the best
> solution would be to bite the bullet and either go down the pre-linker
> route or use more intelligent linkers.
aeh, what is the "pre-linker route"? didn't heard of that one yet ..
> Sadly C++ was designed with multiple preprocessed translation units
> very firmly in mind. Changing it to use something more like "modules"
> is not going to be easy, but I think it would be worth the effort.
a module system that integrates with the build system .. absolutely!
i've spent some time trying to figure out what would be needed.
i came to the conclusion that one would need to bring the
object file format much closer to the compiler middle in a computer
science sense, that is closer to the Abstract Sytntax Tree.
a new object file format containing full static type information for
exported types would be needed. what does "full static type inf." mean?
e.g. for exported non-inline, non-template, non-member functions:
- the fully namespace qualified function name
- the function signature
so far so good. this could be done pretty ad-hoc. but what is
"full static type inf." for an exported template function e.g.
template<typename T> T fun (const T& x);
i would argue that full static type information in this case
included the function body. if so, that would require a new
object file format to be powerful enough to express function
bodies. that could be done at the Abstract Syntax Tree (AST)
level. in other words, a sufficiently powerful object file
format would be similar to a persistent file format for
C++ ASTs. when compiling a translation unit, the compiler would
produce an object file that contains native code + those parts
of the AST for the current translation unit, that describe exported
types. compiling another translation unit importing a module
would make the compiler not start with the empty AST for the
translation unit, but with an AST prefilled from the AST parts
embedded in and read from all imported modules.
in a sense, this is perhaps roughly similar to preparsed
headers but without the headers
i'm sure this is no new idea but must have been proposed
already. what's the catch? would such a module system "deliver"?
- Next message: Phlip: "Re: New to the group - with question."
- Previous message: Victor Nazarov: "Sets relations"
- In reply to: tom_usenet: "Re: namespaces and main()"
- Next in thread: JKop: "Re: namespaces and main()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
