This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: [v3] ext/type_traits.h


Martin Sebor <sebor@roguewave.com> writes:

| Howard Hinnant wrote:
| > On Sep 28, 2006, at 4:45 PM, Martin Sebor wrote:
| >
| >> Peter Dimov wrote:
| >>
| >>> Martin Sebor wrote:
| >>>
| >>>> The standalone add_unsigned critters would be okay too. They
| >>>> would be in line with all the other little traits classes. I
| >>>> don't see a big advantage of one approach over the other.
| >>>
| >>> The standalone to_unsigned can be used as a metafunction.
| >>
| >>
| >> Ah, neat. I hadn't thought of that. And the limits one couldn't
| >> because...? It doesn't have the right name?
| > Iiuc, yes.  Here's a trivial trait that takes a metafunction as a
| > template template parameter (F):
| 
| Cool. Thanks for the demo!
| 
| [...]
| > One might imagine some similar test or trait where supplying
| > add_unsigned would work, because it has a nested "type", and
| > numeric_limits would fail.
| 
| Hmm, looks like we need a "metafunction adapter" for legacy
| interfaces:
| 
|    template <class T>
|    struct make_type { typedef T type; };
| 
| That way make_type<numeric_limits<T>::unsigned_type>::type could
| be used as a metafunction too ;-)

Both are reasonable.  I do hope we have something less verbose or
"cleaver" though. 

-- Gaby


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