Re: [boost] Re: Re: Re: is_class
From: Daniel Frey [EMAIL PROTECTED] On Sat, 15 Feb 2003 19:01:08 +0100, Peter Dimov wrote: Daniel Frey wrote: typedef test::remove_pointer int A::* ::type t1; typedef test::remove_pointer int A::* const ::type t2; typedef test::remove_pointer int A::* volatile ::type t3; typedef test::remove_pointer int A::* const volatile ::type t4; typedef test::add_const int( int ) ::type t5; typedef test::add_volatile int( int ) ::type t6; typedef test::add_cv int( int ) ::type t7; Why do you expect these to work? Because add_const int returns int. I was under the impression that a) type-traits should compile if possible and b) that in the case of add_const the input type is returned unmodified if it cannot exist as a const version. I wasn't sure what you expected from add_const int (int) ; you might have wanted int (int) const as a result. Anyway, add_const(T) returns T const, whatever that means. References shrug off cv-qualifiers. Function types generate errors. They'll start shrugging off cv-qualifiers once compilers implement CWG#295. I don't see why you expect remove_pointer(T) to work when T is not a pointer. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
Peter Dimov [EMAIL PROTECTED] writes: I don't see why you expect remove_pointer(T) to work when T is not a pointer. I think that's a reasonable expectation, if by work you mean return the original type without modification. That's what it does for int arguments, for example. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
From: David Abrahams [EMAIL PROTECTED] Peter Dimov [EMAIL PROTECTED] writes: I don't see why you expect remove_pointer(T) to work when T is not a pointer. I think that's a reasonable expectation, if by work you mean return the original type without modification. That's what it does for int arguments, for example. I would argue that remove_pointer should cause a compile-time error when applied to a non-pointer. *p doesn't just conveniently return p when applied to a non-pointer. Either way though, it should be consistent, i.e. if it works for int, it should work for everything. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
Peter Dimov wrote: From: Daniel Frey [EMAIL PROTECTED] On Sat, 15 Feb 2003 19:01:08 +0100, Peter Dimov wrote: Daniel Frey wrote: typedef test::remove_pointer int A::* ::type t1; typedef test::remove_pointer int A::* const ::type t2; typedef test::remove_pointer int A::* volatile ::type t3; typedef test::remove_pointer int A::* const volatile ::type t4; typedef test::add_const int( int ) ::type t5; typedef test::add_volatile int( int ) ::type t6; typedef test::add_cv int( int ) ::type t7; Why do you expect these to work? Because add_const int returns int. I was under the impression that a) type-traits should compile if possible and b) that in the case of add_const the input type is returned unmodified if it cannot exist as a const version. I wasn't sure what you expected from add_const int (int) ; you might have wanted int (int) const as a result. I think we should consider to define what should not work and what should not. If we want add_const to reject types that cannot be made const, we should also consider to make references not compile. The user can check for references as he can check for functions. Either way would be fine for me, but the current mixture is IMHO not good. If we reject several cases, I think it might also be worth to consider a BOOST_STATIC_ASSERT to help the user to understand what he made wrong. I don't see why you expect remove_pointer(T) to work when T is not a pointer. Well, is_pointer doesn't detect member pointers, but for the case of a member variable pointer, removing the pointer would IMHO make sense. Or otherwise I would like to have a remove_member_variable_pointer-trait. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
Daniel Frey wrote: I think we should consider to define what should not work and what should not. If we want add_const to reject types that cannot be made const, we should also consider to make references not compile. The definition of what should work in this case is simple: add_constT::type is equivalent to T const. T const is equivalent to T when T is a reference type, see 8.3.2/1. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] Peter Dimov [EMAIL PROTECTED] writes: I don't see why you expect remove_pointer(T) to work when T is not a pointer. I think that's a reasonable expectation, if by work you mean return the original type without modification. That's what it does for int arguments, for example. I would argue that remove_pointer should cause a compile-time error when applied to a non-pointer. *p doesn't just conveniently return p when applied to a non-pointer. Either way though, it should be consistent, i.e. if it works for int, it should work for everything. I think silent non-modification is a more-useful behavior; it saves on if_is_pointerT, remove_pointerT, identityT which is sometimes what you want. I feel the same, especially looking at remove_const, remove_volatile and remove_cv. Of course we could decide to treat those three different from the rest, but this is IMHO neither needed nor useful. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
Peter Dimov wrote: Daniel Frey wrote: I think we should consider to define what should not work and what should not. If we want add_const to reject types that cannot be made const, we should also consider to make references not compile. The definition of what should work in this case is simple: add_constT::type is equivalent to T const. T const is equivalent to T when T is a reference type, see 8.3.2/1. Ah, I missed that, thanks. I think the documentation should repeat this and not rely on the user to know the standard's exact wording :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
John Maddock wrote: The basic point was (IMHO) never answered. I tried to clean up the implementation by providing a closed implementation of is_class for more compilers. This should decrease the coupling of all the different parts. I think that this is a better design than the current one. The example I gave which I thought might show the local problem was wrong. My fault, granted. But does it speak against cleaning up the code? No, it's just that the version you posted only seemed to work with gcc - so it makes for a more tangled is_class implementation. It also works for the Intel (EDG-based) compilers (v6 and v7), as Intel kindly allows free personal home use. I never intended to write a GCC-only implementation. Bad luck it doesn't work for Win32-compilers :( is_member_function_pointer is not a secondary type category Which I have already said is a bug, but we need time to do a fix justice. Can't it be just moved to the primary-section or am I missing something here? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: is_class
Daniel Frey [EMAIL PROTECTED] writes: On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: I won't try to fix any of these anymore. I neither understand the documentation nor the implementation of boost's type-traits. I tried to make the code better but AFAICS there is no interest in improvment. Does anyone understand what improvement you're trying to make? I have the impression that the type-traits can and should be improved. I don't have a complete solution for everything at once and I prefer evolution over revolution. Thus I tried to start by suggesting a new is_class implementation. I was disappointed to see only bashing on details instead of a discussion of the big picture. The basic point was (IMHO) never answered. I tried to clean up the implementation by providing a closed implementation of is_class for more compilers. This should decrease the coupling of all the different parts. I think that this is a better design than the current one. The example I gave which I thought might show the local problem was wrong. My fault, granted. But does it speak against cleaning up the code? No, it does not, but someone has to have the time and energy to do the job, and do it right. By that I mean not just providing a patch that reduces dependencies on a few compilers, but that one that actually works and doesn't break anything. If I understand this conversation correctly, that was not done. John invested a lot of time to understand and test submissions and reply to commentary already. I have certainly had my share of complaints about the type_traits documentation, especially with respect to being able to know what the results will be on broken compilers. Having done it myself, I also know how hard it is to make actual working improvements in the type_traits implementation. I guess what I'm saying is, it's only a better design if it works. It isn't fair to say that there's no interest in improvement before an actual possible improvement is demonstrated. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: is_class
Daniel Frey wrote: I won't try to fix any of these anymore. I neither understand the documentation nor the implementation of boost's type-traits. I tried to make the code better but AFAICS there is no interest in improvment. Does anyone understand what improvement you're trying to make? I have the impression that the type-traits can and should be improved. I don't have a complete solution for everything at once and I prefer evolution over revolution. Thus I tried to start by suggesting a new is_class implementation. I was disappointed to see only bashing on details instead of a discussion of the big picture. What is a big picture here? Looking at your original posting, it's all seems to be about the details. Anyway, I would understand your frustration if you've proposed a drop-in replacement for the current 'is_class' implementation that passes all the current tests and is better, in at least one way, than what we have now - and it was ignored. But that's not what happened, is it? If you start the discussion by posting an incomplete and large enough amount of code be ignored by most of the skimming readers, and leave it to the library maintainers to figure out what they can take out of it, if anything, there is a huge possibility that it will progress in the way it did in this case. I don't think there is anything wrong with it. If you want a different kind of discussion, try a different approach. E.g. post a drop-in replacement for 'is_class', motivate why it is better, and I am sure John will happily accept it. The basic point was (IMHO) never answered. That is ...? I tried to clean up the implementation by providing a closed implementation of is_class for more compilers. This should decrease the coupling of all the different parts. I think that this is a better design than the current one. The example I gave which I thought might show the local problem was wrong. My fault, granted. But does it speak against cleaning up the code? No, it doesn't. But, in general, you cannot expect the maintainers to follow through the course of your experiments, however interesting those are. They might sometimes, when they have resources, but if you want the concrete results, try to post the concrete (and, if it's possible, complete) proposals. As far as I learned right now, boost is not meant to provide a clean implementation, instead, it provides a good documentation and an implementation that just works. That's just not true. When possible, we do strike for a clean implementation. It's the sorry state of current compilers that often forces one to sacrifice the internal beauty for usefulness in the real world. But even the documentation confused me several times. is_scalar doesn't mention enum, is_member_function_pointer is not a secondary type category, Patches are always welcome! the mixture of utility functions and a framework and primary type categories are implemented using secondary type categories. Even if it works, it is IMHO still bad code. If you have a vision of how to improve it, the best way to change the status quo is to post a proof in the form of working code. HTH, Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
