On 4/26/12 9:35 AM, Diego Novillo wrote:
On Thu, Apr 26, 2012 at 06:43, Dodji Seketeli<do...@seketeli.org> wrote:
I guess it's also worth noting one limitation of PPHs that is, if I
believe the wiki:
In essence, the only headers that can be pre-parsed are those that
produce the same result when they are compiled in isolation or as
part of another translation unit. So, header files that are affected
by pre-processor symbols defined before inclusion are not going to
be considered (e.g., stddef.h).
[1]: http://gcc.gnu.org/wiki/pph#Scope_and_limitations
How hard would it be to drop that limitation?
It's an explicit non-goal, actually. If you relax this requirements,
you might as well re-parse the header file. The work needed to make
flexible PPH images will rob you of most/all the performance you were
looking for.
Expanding a bit on this point.
One of the goals of PPH is to act as a bridge towards C++ modules, which
is currently being discussed for inclusion in the next C++ standard.
While it is uncertain what modules will look like, we want to use this
experience to inform the committee on the different tradeoffs and issues
we found. We will publishing something shortly, and discussing it at
the Prague meeting.
I a future world with modules (if it comes to be), files acting as
modules will need to have exactly one meaning, regardless of where they
are imported from or what was imported before them (think Java/Go/Python
modules).
Diego.
