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]
Other format: [Raw text]

Re: Fwd: Pseudo-templates


Patrick Moran <patrick.a.moran@gmail.com> writes:

> ÂÂÂ We are two students in a Compiler Design course who have been
> assigned to work on a gcc beginners project. We have chosen the
> project on making pseudo-templated containers, and we had some
> questions about the semantics you want from them. The gcc page
> specifically mentioned splay trees and hash tables, so we will ask
> about those.
>
> ÂÂÂ The goal of the project was stated to be the elimination of
> abstraction penalties. The hash table and splay tree both store
> entries by pointer (except that splay tree can cast ints to the
> pointer and back out). Would you prefer a generic container that held
> items by value? We could do this, but it would break code that expects
> aliases to be preserved.
>
> ÂÂÂÂ We are currently working under the assumption that it is
> acceptable for all of our function-like macros to take the type of the
> stored elements. Do you agree? Is it okay for lookup function macros
> to take the type they are looking up? If we can take the type, we can
> make the semantics of returning pointers much more elegant.

Thanks for your interest.

I personally have been slowing working on the gcc-in-cxx branch which
will support writing gcc in C++.  I think that if that approach is
accepted, then pseudo-template code will become much less
interesting--we can just use C++ template code instead.  So from my
perspective this may be a less interesting project today.

That said, there is an existing example of a pseudo-template container,
in gcc/vec.h.  Any new pseudo-template should be similar to that one.

New hash table code should store objects by value, as you suggest.  I
don't think there would be much gain to having another way to write a
hash table which stores pointers.  You are correct that this could be
only used in certain cases.

It would be worth first identifying places where performance critical
code avoids the general code.  One example might be the identifier hash
table in libcpp/symtab.c.  Why do we use a special purpose hash table
there rather than using htab_t?

Ian


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