RE: [Boost-Users] A strange question-)
Sam Gentile wrote:
I'm sorry, no I still don't understand. Could you please say more?
Well, it would help me if you've said what exact points in my answer you are having troubles with :). Aleksey
-----Original Message----- From: Aleksey Gurtovoy [mailto:alexy@meta-comm.com] Sent: Wednesday, November 13, 2002 3:19 AM To: 'Boost-Users@yahoogroups.com' Subject: RE: [Boost-Users] A strange question-)
Sam Gentile wrote:
I went there and indeed it can't get any simpler - at least in theory-) Read the document C:\Boost\boost_1_29_0\libs\type_traits\c++_type_traits.htm and its quite simple:
template <typename T> struct is_void { static const bool value = false; };
template <> struct is_void<void> { static const bool value = true; };
That's exactly what I want to show. So I go to the header files and instead:
//* is a type T void - is_void<T>
BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_void,T,false)
BOOST_TT_AUX_BOOL_TRAIT_SPEC1(is_void,void,true)
Huh? So I look in bool_trait_def.hpp:
#define BOOST_TT_AUX_BOOL_TRAIT_DEF1(trait,T,C) \
template< typename T > struct trait \
: mpl::bool_c< C > \
{ \
BOOST_TT_AUX_BOOL_TRAIT_VALUE_DECL(C) \
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,trait,(T)) \
}; \
Well, the original code doesn't have all these excessive newlines ;), but yes, basically that's how it's implemented.
Argh! Why is it done like this? This makes it much more complicated and unreadable than it has to be. Why are macros being used everywhere?
Practical engineering matters. If you consider that the fact that there are ~60 trait templates in the library and every time when a new version of a compiler comes out, or when somebody starts porting the library to a new platform, there is a chance that you need to change half of those definitions, from, for instance,
template <typename T> struct is_void : mpl::bool_c<false> { };
to
template <typename T> struct is_void { BOOST_STATIC_CONSTANT(bool, value = false); typedef mpl::bool_c<value> type; };
it might all make sense, after all :). Something along the lines of both of the above scenarios has actually happened, a couple of times. It's not the whole picture yet, but IMO it's enough of the motivation already, so I won't go too deep into details :).
Hope this answers your question, Aleksey
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service.
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor ---------------------~--> 4 DVDs Free +s&p Join Now http://us.click.yahoo.com/pt6YBB/NXiEAA/ASSHAA/EbFolB/TM -------------------------------------------------------------- -------~->
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to
<rant> How positively delightful to wait 24 hours and get a non-response like this. This is like pulling blood out of a stone. At this point, I'll just forget it and use something else. I do understand that Boost users tend to be extremely advanced C++ users. For the record, I have been programming in C++ for well over 10 years and still get confused at some of the things you do. I am questioning and not understanding your approach at all. Why? Well, lets look at Stroustrup, 3rd edition page 160 "Macros are important in C, but have far fewer uses in C++. The first rule about macros is: Don't use them if you don't have to. Almost every macro demonstrates a flaw in the program, or the programmer." Then "avoid macros." Now, I'm sure I'm missing your good reason but there you go. To me, macros are an ugly legacy from C and render C++ code unreadable and maintainable. So, how detailed does my question have to be? I don't understand the whole approach and why it was taken. Is that clear enough? </rant> Sam Gentile .NET Consultant ManagedCode@nospam.attbi.com http://www.samgentile.com http://radio.weblogs.com/0105852/ -----Original Message----- From: Aleksey Gurtovoy [mailto:alexy@meta-comm.com] Sent: Wednesday, November 13, 2002 8:55 PM To: 'Boost-Users@yahoogroups.com' Subject: RE: [Boost-Users] A strange question-) Sam Gentile wrote:
I'm sorry, no I still don't understand. Could you please say more?
Well, it would help me if you've said what exact points in my answer you are having troubles with :). Aleksey
-----Original Message----- From: Aleksey Gurtovoy [mailto:alexy@meta-comm.com] Sent: Wednesday, November 13, 2002 3:19 AM To: 'Boost-Users@yahoogroups.com' Subject: RE: [Boost-Users] A strange question-)
Sam Gentile wrote:
I went there and indeed it can't get any simpler - at least in theory-) Read the document C:\Boost\boost_1_29_0\libs\type_traits\c++_type_traits.htm and its quite simple:
template <typename T> struct is_void { static const bool value = false; };
template <> struct is_void<void> { static const bool value = true; };
That's exactly what I want to show. So I go to the header files and instead:
//* is a type T void - is_void<T>
BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_void,T,false)
BOOST_TT_AUX_BOOL_TRAIT_SPEC1(is_void,void,true)
Huh? So I look in bool_trait_def.hpp:
#define BOOST_TT_AUX_BOOL_TRAIT_DEF1(trait,T,C) \
template< typename T > struct trait \
: mpl::bool_c< C > \
{ \
BOOST_TT_AUX_BOOL_TRAIT_VALUE_DECL(C) \
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,trait,(T)) \
}; \
Well, the original code doesn't have all these excessive newlines ;), but yes, basically that's how it's implemented.
Argh! Why is it done like this? This makes it much more complicated and unreadable than it has to be. Why are macros being used everywhere?
Practical engineering matters. If you consider that the fact that there are ~60 trait templates in the library and every time when a new version of a compiler comes out, or when somebody starts porting the library to a new platform, there is a chance that you need to change half of those definitions, from, for instance,
template <typename T> struct is_void : mpl::bool_c<false> { };
to
template <typename T> struct is_void { BOOST_STATIC_CONSTANT(bool, value = false); typedef mpl::bool_c<value> type; };
it might all make sense, after all :). Something along the lines of both of the above scenarios has actually happened, a couple of times. It's not the whole picture yet, but IMO it's enough of the motivation already, so I won't go too deep into details :).
Hope this answers your question, Aleksey
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service.
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor ---------------------~--> 4 DVDs Free +s&p Join Now http://us.click.yahoo.com/pt6YBB/NXiEAA/ASSHAA/EbFolB/TM -------------------------------------------------------------- -------~->
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. [Non-text portions of this message have been removed]
<rant>
How positively delightful to wait 24 hours and get a non-response like this. This is like pulling blood out of a stone. At this point, I'll
Sorry for your frustrations, but imagine the frustration of the library author after yet another bizarre compiler error on perfectly standard C++. Anyway, I think the answer was in the previous mail: Portability. In an ideal world most of this sort of macro hackery wouldn't exist. Unfortunately, boost exists in the real world...
just forget it and use something else. I do understand that Boost users tend to be extremely advanced C++ users. For the record, I have been programming in C++ for well over 10 years and still get confused at some of the things you do. I am questioning and not understanding your approach at all. Why? Well, lets look at Stroustrup, 3rd edition page 160 "Macros are important in C, but have far fewer uses in C++. The first rule about macros is: Don't use them if you don't have to. Almost every macro demonstrates a flaw in the program, or the programmer." Then "avoid macros." Now, I'm sure I'm missing your good reason but there you go. To me, macros are an ugly legacy from C and render C++ code unreadable and maintainable. So, how detailed does my question have to be? I don't understand the whole approach and why it was taken. Is that clear enough?
This viewpoint is just fine if you are creating a library for one platform and compiler. The reality of the current world is that many supposedly standard features of C++ or parts of the standard library are not correct on many of the most common compilers. As a result, if you write a library 'to the standard' it might not get used much since it won't compile or work correctly for most people. In addition, many boost libraries push compilers to the limits and thus for some boost libraries the situation is even more severe. The result is that many boost libraries use various macro techniques to create portable code. Looking ahead a few years most of this will hopefully disappear. HTH, Jeff
Well at least you gave somewhat of an answer. I still want to understand how those particular macros give that portability. Sam Gentile .NET Consultant ManagedCode@nospam.attbi.com http://www.samgentile.com http://radio.weblogs.com/0105852/ -----Original Message----- From: Jeff Garland [mailto:jeff@crystalclearsoftware.com] Sent: Thursday, November 14, 2002 11:13 AM To: Boost-Users@yahoogroups.com Subject: RE: [Boost-Users] A strange question-)
<rant>
How positively delightful to wait 24 hours and get a non-response like this. This is like pulling blood out of a stone. At this point, I'll
Sorry for your frustrations, but imagine the frustration of the library author after yet another bizarre compiler error on perfectly standard C++. Anyway, I think the answer was in the previous mail: Portability. In an ideal world most of this sort of macro hackery wouldn't exist. Unfortunately, boost exists in the real world...
just forget it and use something else. I do understand that Boost users tend to be extremely advanced C++ users. For the record, I have been programming in C++ for well over 10 years and still get confused at some of the things you do. I am questioning and not understanding your approach at all. Why? Well, lets look at Stroustrup, 3rd edition page 160 "Macros are important in C, but have far fewer uses in C++. The first rule about macros is: Don't use them if you don't have to. Almost every macro demonstrates a flaw in the program, or the programmer." Then "avoid macros." Now, I'm sure I'm missing your good reason but there you go. To me, macros are an ugly legacy from C and render C++ code unreadable and maintainable. So, how detailed does my question have to be? I don't understand the whole approach and why it was taken. Is that clear enough?
This viewpoint is just fine if you are creating a library for one platform and compiler. The reality of the current world is that many supposedly standard features of C++ or parts of the standard library are not correct on many of the most common compilers. As a result, if you write a library 'to the standard' it might not get used much since it won't compile or work correctly for most people. In addition, many boost libraries push compilers to the limits and thus for some boost libraries the situation is even more severe. The result is that many boost libraries use various macro techniques to create portable code. Looking ahead a few years most of this will hopefully disappear. HTH, Jeff Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thursday 14 November 2002 11:29 am, Sam Gentile wrote:
Well at least you gave somewhat of an answer. I still want to understand how those particular macros give that portability.
The type traits classes are no longer "normal" traits or metafunctions. They support argument binding via MPL's lambda facility, so that one can write, e.g., apply<is_base_and_derived<_, remove_pointer<_> > >::value Supporting the argument binding feature on all compilers requires a lot of hackery, the nature of which changes depending on the brokenness of the compiler. More importantly, some of these compilers require changes that are intrusive into metafunctions that support binding. This intrusiveness is encapsulated in the macros you found in the type traits headers. MPL has been accepted into Boost, but has not yet been in any release. Doug
participants (4)
-
Aleksey Gurtovoy -
Douglas Gregor -
Jeff Garland -
Sam Gentile