Re: Role of profile/hashtable.h?!?

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> If I remember well, we had to clone part of hashtable.h in order to
> instrument decisions such as when to rehash.  These decisions are
> based on private data such as _M_num_elements.  Other private data
> member values may be collected by instrumentation code.  In the case
> of hashtable-based containers, profile instrumentation only cares
> about hashtable details (distribution, rehashing), so instead of
> instrumenting hash_map and hash_set, we decided to instrument only
> hashtable.  Thus you only see hashtable.h and not hash_map or
> hash_set.  Is there a better way to do this, which ideally would
> eliminate or reduce greatly the amount of cloning?
>   
Bah, if you ask me, I would just *not* instrument those legacy
containers, which do not have an particular advantage compared to the
tr1 and std unordered containers. Actually, have been moved already to
the backward subdirectory and people still requiring those facilities
certainly can't assume the availability of profile-mode, which is brand
new. For comparison, we do *not* deliver debug-mode hash_* containers.
What about just removing that code and concentrating on the rest?
> I will be revisiting the include/profile/ code early this coming week
> and port a few needed fixes from the profile-stdlib branch and local
> patches.  In case you notice anything else questionable within
> include/profile, this is a very good time to bring it up.
>   
Ok thanks. I'm about to commit some changes which allows to cleanly
regtest profile-mode. Some C++0x bits were missing and some tests were
failing because we were forcing debug-mode in the testcases (which is
not compatible with profile-mode)

If I spot something else I will tell you, thanks for the good work!

Paolo.