This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] libstdc++/21244
Paolo Carlini <pcarlini@suse.de> writes:
| Hi Gaby
|
| >Avoiding any use of unamed enumeration is too drastic a cure for this
| >specific issue in the library. For example, the following is
| >perfectly fine
| >
| > template<class>
| > struct is_integer { enum { value = 0 }; };
| >
| > template<class>
| > struct is_floatiing_point { enum { value = 0 }; };
| >
| > template<class T>
| > struct is_arithemtic {
| > enum {
| > value = is_integer<T>::value || is_floatiing_point<T>::value
| > };
| > };
| >
| >
| I agree about your "hyper-panic mode" remark. Actually I was exactly
| considering in my mind the last situation. In our current
| cpp_type_traits we have this specific code, exploiting your nice traitor:
|
| template<class _Sp, class _Tp>
| struct __traitor
| {
| enum { __value = _Sp::__value || _Tp::__value };
| typedef typename __truth_type<__value>::__type __type;
| };
|
| template<typename _Tp>
| struct __is_arithmetic
| : public __traitor<__is_integer<_Tp>, __is_floating<_Tp> >
| { };
|
| Is this 100% safe
What is used is the result of the conversion of an integer
value to bool, and the template argument processor does not get to see
the type of "__value".
| even if the user (contra any good C++ programming book
| advice) overloads operator|| like, in c++/19404, operator/?!?
Or, I see what you mean. Even is you make the enumeration named,
you still run the risk of having unspeakble quantum process peaks
overload and render the whole incomprehensible. What is need is this
template<class _Sp, class _Tp>
struct __traitor
{
enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };
typedef typename __truth_type<__value>::__type __type;
};
Note the bool(...) -- please don't put static_cast, the conversion is
safe. And maybe put a comment at the start of the files, or in the
docs (somewhere).
-- Gaby