[type_index] C++03 implementation in boost?
After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11. It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values? I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code. Agustín K-ballo Bergé.- http://fusionfenix.com
Agustín K-ballo Bergé wrote:
After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11.
It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values?
I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code.
Agustín K-ballo Bergé.- http://fusionfenix.com
It sounds like this might be similar to the "extended_type_info" used in the serialization library for many years. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 02/07/2012 01:11 a.m., Robert Ramey wrote:
Agustín K-ballo Bergé wrote:
After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11.
It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values?
I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code.
Agustín K-ballo Bergé.- http://fusionfenix.com
It sounds like this might be similar to the "extended_type_info" used in the serialization library for many years.
Robert Ramey
It's considerably simpler than `extended_type_info`. It's just a wrapper around a `std::type_info const*` that is usable as a key in associative sequences (both ordered and unordered). Nothing more, nothing less. Agustín K-ballo Bergé.- http://fusionfenix.com
2012/7/2 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
It's considerably simpler than `extended_type_info`. It's just a wrapper around a `std::type_info const*` that is usable as a key in associative sequences (both ordered and unordered). Nothing more, nothing less.
See TpeIndex library: http://apolukhin.github.com/type_index/index.html https://github.com/apolukhin/type_index It has the functionality of c++11 std::type_index (has all the comparators, hash functions and ostream operators), but can also work with disabled RTTI, store const-volatile-reference modifiers(if required) and has a full set of workarounds for broken compilers. I`ll request a formal review in a week or two. Any advices, for improvement are welcomed! -- Best regards, Antony Polukhin
On 02/07/2012 02:17 a.m., Antony Polukhin wrote:
2012/7/2 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
It's considerably simpler than `extended_type_info`. It's just a wrapper around a `std::type_info const*` that is usable as a key in associative sequences (both ordered and unordered). Nothing more, nothing less.
See TpeIndex library: http://apolukhin.github.com/type_index/index.html https://github.com/apolukhin/type_index
It has the functionality of c++11 std::type_index (has all the comparators, hash functions and ostream operators), but can also work with disabled RTTI, store const-volatile-reference modifiers(if required) and has a full set of workarounds for broken compilers.
Looks like an interesting library, but has a much wider scope than that of `std::type_index`
I`ll request a formal review in a week or two. Any advices, for improvement are welcomed!
The documentation needs some work. There are a considerable number of typos, most notable 'retruns' -> 'returns'. Hashing the type names could be suboptimal compared to a native implementation of `type_info::hash_code`. The compiler knows the entire set of values, so it *should* be able to provide a perfect hash function. You should use the native implementation in those cases where its available. I'm no expert in locales, but I believe your implementation of `before` may be susceptible to global locale changes. I'm not particularly keen on `name` and `name_demangled` returning different string types. Would it make sense to have `name_demangled` cache the result, and return a `char const*` instead? Agustín K-ballo Bergé.- http://fusionfenix.com
2012/7/3 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
The documentation needs some work. There are a considerable number of typos, most notable 'retruns' -> 'returns'.
Could not find it. In what file is it?
Hashing the type names could be suboptimal compared to a native implementation of `type_info::hash_code`. The compiler knows the entire set of values, so it *should* be able to provide a perfect hash function. You should use the native implementation in those cases where its available.
You are right. I looked through the headers of GCC and found that it has optimized version of hash_code(). Fixed hash_code() in type_index.
I'm no expert in locales, but I believe your implementation of `before` may be susceptible to global locale changes.
Looks fine for me.
I'm not particularly keen on `name` and `name_demangled` returning different string types. Would it make sense to have `name_demangled` cache the result, and return a `char const*` instead?
Caching the result will increase size of type_index object, and that would lead to slower copying/assigning/constructing of type_indexes. Demangled names are usually used in non performance critical sections (in error reporting; outputting user readable data to stream) and usually only once. So I think that not using caching is a little bit better than using it. Thanks for your advices! -- Best regards, Antony Polukhin
On 03/07/2012 01:59 p.m., Antony Polukhin wrote:
2012/7/3 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
The documentation needs some work. There are a considerable number of typos, most notable 'retruns' -> 'returns'.
Could not find it. In what file is it?
Several places in both code and documentation. I will try and provide you a patch for those.
I'm no expert in locales, but I believe your implementation of `before` may be susceptible to global locale changes.
Looks fine for me.
Yes, please disregard. I have just confirmed that `strcmp` is locale independent.
I'm not particularly keen on `name` and `name_demangled` returning different string types. Would it make sense to have `name_demangled` cache the result, and return a `char const*` instead?
Caching the result will increase size of type_index object, and that would lead to slower copying/assigning/constructing of type_indexes. Demangled names are usually used in non performance critical sections (in error reporting; outputting user readable data to stream) and usually only once. So I think that not using caching is a little bit better than using it.
Caching will certainly increase the size of type_index, but you don't necessarily need to actually copy them. Anyway, this is just a bit of nitpicking on my side. Agustín K-ballo Bergé.- http://fusionfenix.com
participants (3)
-
Agustín K-ballo Bergé -
Antony Polukhin -
Robert Ramey