[GiNaC-devel] tinfo
Jens Vollinga
vollinga at physik.uni-wuppertal.de
Tue Nov 22 16:25:15 CET 2005
Hi,
Christian Bauer wrote:
> How about:
>
> typedef const void * tinfo_t;
> struct tinfo_static_t {};
>
> class SOMECLASS {
> public:
> static const tinfo_static_t tinfo_static;
>
> SOMECLASS() : tinfo_key(&tinfo_static) {}
> SOMECLASS(tinfo_t ti) : tinfo_key(ti) {}
>
> tinfo_t tinfo() const { return tinfo_key; }
>
> protected:
> tinfo_t tinfo_key;
> };
>
> const tinfo_static_t SOMECLASS::tinfo_static = {};
>
> template<class T>
> inline bool is_exactly_a(const SOMECLASS & obj)
> {
> return obj.tinfo() == &T::tinfo_static;
> }
>
> This looks promising. No explicit specializations of is_exactly_a<> are
> needed any more.
Why don't you want to use char* as a static source of address? Is it
just a matter of taste? (If the class name is moved out of
registered_class_options there is no duplication.) Or is something more
involved I don't see?
Is it guaranteed that no smart optimizer will merge all static
tinfo_static_t into one (there are all the same, aren't they?) with the
effect that all tinfo_keys will be the same?
The char* version again (I just wrote it from memory. I hope I didn't
make some silly mistakes):
typedef const char* tinfo_t;
class SOMECLASS {
public:
static tinfo_t tinfo_name;
SOMECLASS() : tinfo_key(tinfo_name) {}
SOMECLASS(tinfo_t ti) : tinfo_key(ti) {}
tinfo_t tinfo() const { return tinfo_key; }
protected:
tinfo_t tinfo_key;
};
const tinfo_t SOMECLASS::tinfo_name = "SOMECLASS";
template<class T>
inline bool is_exactly_a(const SOMECLASS & obj)
{
return obj.tinfo() == T::tinfo_name;
}
BTW, maybe some disadvantage of both of the new ways: in order to avoid
as much as possible hash clashes, which are costly, the seed for the
hash calculation should be unique. With the new tinfos the bit pattern
for them in most cases has just changing least significant bits. With a
seed setup like tinfo^serial (serial a small number) for symbols as an
example, one is likely to get more hash clashes, I guess. So the seed
setup has to be changed for some classes as well, I think.
Regards,
Jens
More information about the GiNaC-devel
mailing list