This is the mail archive of the gcc-patches@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: Merge C++ conversion into trunk (4/6 - hash table rewrite)


On 8/15/12, Richard Guenther <rguenther@suse.de> wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
> > This implements a new C++ hash table.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
>
> Now as we see the result I'd have prefered a more C++-way instead
> of making the conversion simple ...
>
> Like
>
> template <typename Element>
> class hash_table
> {
> ...
> };
>
> template <typename Element>
> class pointer_hash
> {
>   hashval_t hash ();
>   int equal (const Element *);
>   ~Element ();
>   Element e;
> };
>
> and
>
> /* Hash table with all same_succ entries.  */
>
> static hash_table <pointer_hash <struct same_succ_def> > same_succ_htab;
>
> The existing way is simply too ugly ... so, why did you not invent
> a "nice" C++ way?  (please consider reverting the hashtable patch)

We are trying to balance several factors.  Sometimes we're going
to pick multiple steps rather than a single step.  In some cases,
as here, the intent was to make the client code changes minimal and
unsurprising while still getting the type safety and efficiency.
Other times, it may be a minor technical issue.  In particular,
I prefer to avoid steps that might cause very poor matching of
lines in the diff.  Others may choose differently.  Together we
will learn where the tradeoffs lie.

More in a later response.

-- 
Lawrence Crowl


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