This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Precompiled headers and General Parsing of Header File


>>>>> Kevin Atkinson <kevina@clark.net> writes:

> Jason Merrill wrote:

>> >>>>> Kevin Atkinson <kevina@clark.net> writes:

>> > Also have you considered the idea of not fully parsing the header files
>> > with template information in it ot help speed up compiling of code that
>> > uses the STL.
>> 
>> > By not fully parsing the header file I mean skipping over the
>> > class/functions definitions.  For example:

>> Actually, g++ used to work this way.  I changed that in '96 so that
>> templates would actually work properly; trying to feed stuff back to the
>> parser is very tricky with a non-reentrant parser, and the semantics are
>> wrong anyway.  The standard specifies that names which do not depend on a
>> template argument are bound at the point of the template definition.

> Hu! You really lost me here.  Could you elaborate.

  void f (int);

  template <class T>
  void g (T)
  {
    f (1.0);
  }

  void f (double);

  main ()
  {
    g (24);
  }

Here, the call to f in g is bound immediately to f(int), since 1.0 does not
depend on T, even though at g's point of instantiation there is a better
match.  g++ actually doesn't get this right yet, but it's why we have to
parse templates immediately.

> I understand that not parsing template definitions also means not catching
> syntax errors until they are instantiated, however to me that is a minor
> drawback which can easily be fixed with a command line option...

That way lies madness.  There will only be one implementation of templates
in the compiler.

> Templates are a beautiful thing, however in reality they are very
> difficult to both implement correctly and efficiently.

Yep.

> Truefully I find the compile time for code that uses the STL ridiculously
> slow and there seams to me that they has got to be a way to speed things
> up by a factor of 1/2 or more...

Try profiling the compiler to see where it's spending all of its time.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]