Formal Review: Typeof
The formal review of Arkadiy Vertleyb and Peder Holt's Typeof library begins today, May 20th 2005. The review period will continue until the 30th of May. The proposed Typeof library emulates the functionality of the non-standard 'typeof' operator, and incomplete implementations of decltype and the proposed 'auto' declarator , described in http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf. It is commonly acknowledged that this type of functionality is sorely needed and should be standardardised in the language. For compliant compilers the library requires some help in the form of registration macros but, because use of typeof is by its nature most likely in generic libraries, it is expected that this can often be done by the library author rather than the user. In some cases the compilers capabilities (by means of extensions and even compiler bugs) have been used to remove the need for registration. However, for portability and in order to test emulation mode on the compilers where it is available but not used by default (VC7.1, GCC etc), #define BOOST_TYPEOF_COMPLIANT [see note *1*]. Testing the emulation is useful, even on compilers that provide a better option, to get a rounded view of the library and its capabilities. I hope you will find time to write a review of the library, which is available at: http://boost-sandbox.sourceforge.net/vault/ , typeof.zip The system has been tested with the following compilers: MSVC 6.5/7.0/7.1/8.0; [see note *1* regarding VC7.0 and VC6.5] GCC 3.4.2 (The following is a quote from : http://www.boost.org/more/formal_review_process.htm ) Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Andy Little Typeof review manager notes: *1* MSVC6.5 and VC7.0 are not supported by the BOOST_TYPEOF_COMPLIANT macro
Here are some preliminary remarks:
What is your evaluation of the design?
Pretty nice. Why isn't BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP built into all of the registration macros, simply for ease-of-use? For experts, you could include BOOST_TYPEOF_REGISTER_ANOTHER_TEMPLATE // ;-) which doesn't increment the registration group.
What is your evaluation of the implementation?
Haven't looked yet. One thing that seems to be missing is consistency between the usage of native and non-native typeof. On most compilers with native support, apparently "typename" is illegal before the typeof operator because it's clearly a type name. However, on other compilers BOOST_TYPEOF(x) expands to: some_template< something >::type which of course requires a typename prefix in order to work. I suggest that on compilers like GCC, BOOST_TYPEOF(x) be defined something like: mpl::identity< __typeof__( x ) >::type so that everything can be uniform. I also know there are some bugs in the native GCC typeof that can cause it to ICE. These can be worked around by passing the result of the expression through another layer, something like template <class T> mpl::identity<T> make_identity(T&); template <class T> mpl::identity<T const> make_identity(T const&); #define TYPEOF(x) __typeof__(make_identity(x))::type I don't know if the authors are already doing this. If they _are_ managing to avoid known bugs in existing native typeof implementations, they should note it in the documentation, so people know the library is useful.
What is your evaluation of the documentation?
Still sorely lacking. For example, there are no examples that show how BOOST_TYPEOF_TPL, BOOST_AUTO_TPL, and BOOST_LVALUE_TYPEOF should be used, nor even any documentation of how many parameters they take. When trying to use the library I discovered the hard way that I had to close all namespaces before using any of the registration macros -- and, "obviously," fully qualify the names being registered. This should be noted in the documentation. The documentation should make it clear how BOOST_TYPEOF et. al are meant to be used in dependent contexts. There is absolutely no formal reference documentation. The documentation was generated by saving a MS-Word file to HTML. In general this produces bloated HTML files that often don't work as expected in browsers. Also, I found the documentation hard to grasp quickly. It's a little too informal and unstructured. These docs should be re-organized and divided into sections and subsections. Preferably there should be a rewrite in QuickBook.
What is your evaluation of the potential usefulness of the library?
Mega-useful.
Did you try to use the library?
Yes.
With what compiler?
vc7.1 vc8.0 gcc-3.3.3
Did you have any problems?
Noted above.
How much effort did you put into your evaluation? A glance? A quick reading?
Only a quick skimming of the documentation.
In-depth study? Are you knowledgeable about the problem domain?
Fairly.
And finally, every review should answer this question:
Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
On the condition that the documentation undergoes major improvement, an enthusiastic yes. Ideally I would like to see the authors work on improving the documentation immediately and have something to show before the end of the review period. Yes, that would be raising the bar a bit over what we've expected of people in the past, but we _need_ to do that, and this particular library is too important to allow it to slide in with substandard docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi David, Thanks for for what I consider overall a positive review.
What is your evaluation of the design?
Pretty nice. Why isn't BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP built into all of the registration macros, simply for ease-of-use?
The problem is that it is actually: #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() ^^^^^^ which IIUC makes it impossible to use this inside a macro. When I started I used MS-specific __COUNTER__ macro, which allowed it. However the only portable alternative seems to be the methods with preprocessor slots, suggested sometime ago by Paul Mensonides, and this involves #including the file. We can special-case it for Microsoft, but I don't know if it worth it...
What is your evaluation of the implementation?
Haven't looked yet. One thing that seems to be missing is consistency between the usage of native and non-native typeof. On most compilers with native support, apparently "typename" is illegal before the typeof operator because it's clearly a type name. However, on other compilers BOOST_TYPEOF(x) expands to:
some_template< something >::type
which of course requires a typename prefix in order to work.
That's what BOOST_TYPEOF_TPL and BOOST_AUTO_TPL are intended for. They are supposed to be expanded correctly for dependent contexts, whether emulation or native typeof is used. However...
I suggest that on compilers like GCC, BOOST_TYPEOF(x) be defined something like:
mpl::identity< __typeof__( x ) >::type
so that everything can be uniform.
At the first glance I like it much better than what we have now with BOOST_TYPEOF/AUTO_TPL. Maybe these two macros should be eliminated rather than better documented :-)
I also know there are some bugs in the native GCC typeof that can cause it to ICE. These can be worked around by passing the result of the expression through another layer, something like
template <class T> mpl::identity<T> make_identity(T&); template <class T> mpl::identity<T const> make_identity(T const&); #define TYPEOF(x) __typeof__(make_identity(x))::type
I don't know if the authors are already doing this. If they _are_ managing to avoid known bugs in existing native typeof implementations, they should note it in the documentation, so people know the library is useful.
No, we are currently not doing anything about native typeof bugs.
What is your evaluation of the documentation? [ A few paragraphs explaining why the documentation is a mess ]
OK, I agree with [almost] everything about the docs. We'll see what we can do during the review period.
Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
On the condition that the documentation undergoes major improvement, an enthusiastic yes.
Thanks again.
Ideally I would like to see the authors work on improving the documentation immediately and have something to show before the end of the review period.
I think it should be possible, of course closer to the end of the review period. Regards, Arkadiy
David Abrahams <dave@boost-consulting.com> writes:
Did you try to use the library?
Yes.
One further data point: so far nothing I've tried to do with the library has worked. It is of course possible that I've got a bug in my code, but I am getting internal compiler errors and other strange issues. It may be that this library needs more reinforcement against compiler bugs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
One further data point: so far nothing I've tried to do with the library has worked. It is of course possible that I've got a bug in my code, but I am getting internal compiler errors and other strange issues. It may be that this library needs more reinforcement against compiler bugs.
Can you ellaborate on this? Which compiler(s) are you referring to? Can you provide an example of what doesn't work? Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
One further data point: so far nothing I've tried to do with the library has worked. It is of course possible that I've got a bug in my code, but I am getting internal compiler errors and other strange issues. It may be that this library needs more reinforcement against compiler bugs.
Can you ellaborate on this? Which compiler(s) are you referring to? Can you provide an example of what doesn't work?
The three mentioned earlier: vc7.1, vc8, and gcc-3.3.3 I'd be happy to. Just grab http://www.luannocracy.com/arkadiy.tar.bz2 In there you should find a "standard" Boost tree "overlay." Go to libs/sequence/algorithm/test and compile copy.cpp. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
One further data point: so far nothing I've tried to do with the library has worked. It is of course possible that I've got a bug in my code, but I am getting internal compiler errors and other strange issues. It may be that this library needs more reinforcement against compiler bugs.
Can you ellaborate on this? Which compiler(s) are you referring to? Can you provide an example of what doesn't work?
The three mentioned earlier: vc7.1, vc8, and gcc-3.3.3
I'd be happy to. Just grab http://www.luannocracy.com/arkadiy.tar.bz2 In there you should find a "standard" Boost tree "overlay." Go to libs/sequence/algorithm/test and compile copy.cpp.
Just updated with a more recent version. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
David Abrahams <dave@boost-consulting.com> writes:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
One further data point: so far nothing I've tried to do with the library has worked. It is of course possible that I've got a bug in my code, but I am getting internal compiler errors and other strange issues. It may be that this library needs more reinforcement against compiler bugs.
Can you ellaborate on this? Which compiler(s) are you referring to? Can you provide an example of what doesn't work?
The three mentioned earlier: vc7.1, vc8, and gcc-3.3.3
I'd be happy to. Just grab http://www.luannocracy.com/arkadiy.tar.bz2 In there you should find a "standard" Boost tree "overlay." Go to libs/sequence/algorithm/test and compile copy.cpp.
Just updated with a more recent version.
Now I think I found the bug in my code and BOOST_TYPEOF is off the hook. Seems to be working fine so far! -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Now I think I found the bug in my code and BOOST_TYPEOF is off the hook. Seems to be working fine so far!
OK. Just a couple of things I noticed: 1) copy.hpp doesn't have INCREMENT_REGISTRATION_GROUP. This might result in a problem if you use emulation mode and this file is first to register a type or REGISTER_TYPE is on the same line number as in one of files included before; 2) the return type of the function call operator is: typename dispatch<copy_(typename add_const<Range1>::type&,Range2&)>::result ^^^^ Is it intended? I don't see a "result" typedef in the dispatch... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Now I think I found the bug in my code and BOOST_TYPEOF is off the hook. Seems to be working fine so far!
OK. Just a couple of things I noticed:
1) copy.hpp doesn't have INCREMENT_REGISTRATION_GROUP. This might result in a problem if you use emulation mode and this file is first to register a type or REGISTER_TYPE is on the same line number as in one of files included before;
Good catch.
2) the return type of the function call operator is:
typename dispatch<copy_(typename add_const<Range1>::type&,Range2&)>::result
^^^^ Is it intended? I don't see a "result" typedef in the dispatch...
yeah, that was a major culprit; I caught it myself a little while ago. Unfortunately there are still problems with vc-8: ..\..\..\..\boost/sequence/detail/typeof_add.hpp(15) : error C2893: Failed to specialize function template 'char (&boost::type_of::size(const T &))[boost::mpl::size<encode_type<boost::type_of::vector0<>,T>::type>::value]' With the following template arguments: 'T' ..\..\..\..\boost/sequence/detail/typeof_add.hpp(16) : see reference to class template instantiation 'boost::sequence::detail::typeof_add<T,U>' being compiled See the updated archive. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Unfortunately there are still problems with vc-8:
..\..\..\..\boost/sequence/detail/typeof_add.hpp(15) : error C2893: Failed to specialize function template 'char (&boost::type_of::size(const T &))[boost::mpl::size<encode_type<boost::type_of::vector0<>,T>::type>::value] ' With the following template arguments: 'T' ..\..\..\..\boost/sequence/detail/typeof_add.hpp(16) : see reference to class template instantiation 'boost::sequence::detail::typeof_add<T,U>' being compiled
See the updated archive.
I've run into this problem before. Looks like it's present only in vc8 beta. Seems to be "fixed" if make<T>() is replaced with T() -- of course then we have problems with non-default-constructible classes. *(T*)0 doesn't work either. Doesn't look like a Typeof problem, although Typeof may be responsible for driving the compiler crazy, after which it chokes. Seems to be a question to Microsoft... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message
"David Abrahams" <dave@boost-consulting.com> wrote
Unfortunately there are still problems with vc-8:
..\..\..\..\boost/sequence/detail/typeof_add.hpp(15) : error C2893: Failed to specialize function template 'char (&boost::type_of::size(const T
&))[boost::mpl::size<encode_type<boost::type_of::vector0<>,T>::type>::value]
'
With the following template arguments: 'T' ..\..\..\..\boost/sequence/detail/typeof_add.hpp(16) : see
reference to class template instantiation 'boost::sequence::detail::typeof_add<T,U>' being compiled
See the updated archive.
I've run into this problem before. Looks like it's present only in vc8 beta. Seems to be "fixed" if make<T>() is replaced with T() -- of course then we have problems with non-default-constructible classes. *(T*)0 doesn't work either.
Doesn't look like a Typeof problem, although Typeof may be responsible for driving the compiler crazy, after which it chokes.
Seems to be a question to Microsoft...
After looking at this more closely, I believe the problem can't always be "cured" in the way I suggested. Also it can be reproduced on both vc71 and vc8 beta. Here is the minimal example: // ---- #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp" template<class T> T make(); template<class T> struct et { typedef boost::mpl::vector1<int> type; }; template<class T> char(&sz(const T&))[ boost::mpl::size< typename et<T>::type >::value ]; template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> //boost::mpl::size_t<sizeof(sz(T() + U()))> -- doesn't help here > type; }; int main() { return 0; } // ---- This example compiles fine with GCC, but both MS compilers choke on it. OTOH, our ODR test uses BOOST_TYPEOF_TPL(T() + U()) in a few different contexts, and it works fine on both MS compilers. Do Microsoft people read this list, or should I post it elsewhere? Regards, Arkadiy
Arkadiy Vertleyb wrote:
Here is the minimal example:
// ---- #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp"
template<class T> T make();
template<class T> struct et { typedef boost::mpl::vector1<int> type; };
template<class T> char(&sz(const T&))[ boost::mpl::size< typename et<T>::type >::value ];
template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> //boost::mpl::size_t<sizeof(sz(T() + U()))> -- doesn't help here > type; };
int main() { return 0; } // ----
This example compiles fine with GCC, but both MS compilers choke on it.
I have experienced this problem before, and the fix is to calculate the return type of the sz() function as a separate step: #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp" template<class T> T make(); template<class T> struct et { typedef boost::mpl::vector1<int> type; }; template<class T> struct sizer { typedef char(&type)[ boost::mpl::size< typename et<T>::type >::value ]; }; template<class T> typename sizer<T>::type sz(const T&); template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> > type; }; This compiles with VC7.1 and with gcc. I don't have VC8 beta installed.
Do Microsoft people read this list, or should I post it elsewhere?
Report the bug at the product feedback center: http://lab.msdn.microsoft.com/productfeedback/ -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote
Arkadiy Vertleyb wrote:
Here is the minimal example:
// ---- #include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp"
template<class T> T make();
template<class T> struct et { typedef boost::mpl::vector1<int> type; };
template<class T> char(&sz(const T&))[ boost::mpl::size< typename et<T>::type >::value ];
template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> //boost::mpl::size_t<sizeof(sz(T() + U()))> -- doesn't help here > type; };
int main() { return 0; } // ----
This example compiles fine with GCC, but both MS compilers choke on it.
I have experienced this problem before, and the fix is to calculate the return type of the sz() function as a separate step:
#include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp"
template<class T> T make();
template<class T> struct et { typedef boost::mpl::vector1<int> type; };
template<class T> struct sizer { typedef char(&type)[ boost::mpl::size< typename et<T>::type >::value ]; };
template<class T> typename sizer<T>::type sz(const T&);
template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> > type; };
This compiles with VC7.1 and with gcc. I don't have VC8 beta installed.
Hi Eric, Your example does compile on VC8 beta -- thanks a lot. Now I'll try to aply it to typeof... As far as "Microsoft bug" is conserned, my testing wasn't accurate. After I #include "boost/mpl/size.hpp", which I use, VC7 is fine and VC8 is fine with T() + U(). It still can't handle make<T>() + make<U>(), though... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Your example does compile on VC8 beta -- thanks a lot. Now I'll try to aply it to typeof...
As far as "Microsoft bug" is conserned, my testing wasn't accurate. After I #include "boost/mpl/size.hpp", which I use, VC7 is fine and VC8 is fine with T() + U(). It still can't handle make<T>() + make<U>(), though...
Can you submit a small test case that uses make<>? This one is important and should get attention from the MS engineers. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
As far as "Microsoft bug" is conserned, my testing wasn't accurate. After I #include "boost/mpl/size.hpp", which I use, VC7 is fine and VC8 is fine with T() + U(). It still can't handle make<T>() + make<U>(), though...
Can you submit a small test case that uses make<>? This one is important and should get attention from the MS engineers.
I'll do once I figure out what's going on... Eric's suggestion moved me past the immediate problem, but now I am having another one, related to sizeof(...) not being recognized as a constant expression... A good news is that I probably know how to fix it by simplifying (removing some optimization), so that VC8 is able to handle this -- it works with my preliminary tests. The price will be decreased performance of BOOST_TYPEOF_TPL (but not BOOST_TYPEOF) in VC8 only, for simple types, but your example should be fixed once I do this. Until I find a better solution it probably makes sense to upload the patched version, so that we could move on with the review. I'll do it some time tomorrow if I don't find anything better until then. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Your example does compile on VC8 beta -- thanks a lot. Now I'll try to aply it to typeof...
I believe I have substantially simplified the implementation of typeof and fixed the vc8 compatibility problems. See the enclosed typeof_impl.hpp I am a little concerned about the implementation. When I saw the complexity of what the BOOST_TYPEOF macro expanded into, I was a bit shocked. Aside from what I addressed, the fact that the expression gets repeated 100 times was really surprising to me -- it seems to me that asking the compiler to evaluate the type of the expression over and over could get to be quite expensive. The simplification I've made results in the expression being repeated "only" 50 times. Is it possible to do better? Also, on a stylistic note, the paucity of whitespace in namespace boost{namespace type_of{ seems a bit draconian (yes, I'm exercising my vocabulary today ;->). -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
I believe I have substantially simplified the implementation of typeof and fixed the vc8 compatibility problems. See the enclosed typeof_impl.hpp
Right. That's exactly the simplification I meant in my previous post. Unfortunately it means at() is instantiated BOOST_TYPEOF_LIMIT_SIZE times, whereas with more complicated expression it is instantiated only n times, where n is the actual size of the encoded vector. I introduced this complexity about half a year ago, and it cut the time of my tests more than in half...
I am a little concerned about the implementation. When I saw the complexity of what the BOOST_TYPEOF macro expanded into, I was a bit shocked. Aside from what I addressed, the fact that the expression gets repeated 100 times was really surprising to me -- it seems to me that asking the compiler to evaluate the type of the expression over and over could get to be quite expensive.
But this is on average seems to be compensated by less times the template is instantiated.
The simplification I've made results in the expression being repeated "only" 50 times. Is it possible to do better?
I don't believe it's possible with conventional metaprogramming. The problem is that, in order to calculate the size of the vector at compile time, we have to pass the expression inside a metafunction, which doesn't seem possible. Therefore we have to do it at preprocessing time, which means BOOST_TYPEOF_LIMIT_SIZE times. This is the price of crossing boundaries.
Also, on a stylistic note, the paucity of whitespace in
namespace boost{namespace type_of{
seems a bit draconian (yes, I'm exercising my vocabulary today ;->).
Well, there are two whitespaces :-) Why? Does it make it unreadable? Regards, Arkadiy ---------------------------------------------------------------------------- ----
// Copyright (C) 2004 Arkadiy Vertleyb // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (http://www.boost.org/LICENSE_1_0.txt)
#ifndef BOOST_TYPEOF_TYPEOF_IMPL_HPP_INCLUDED #define BOOST_TYPEOF_TYPEOF_IMPL_HPP_INCLUDED
#include <boost/mpl/size_t.hpp> #include <boost/preprocessor/repetition/enum.hpp> #include <boost/typeof/encode_decode.hpp> #include <boost/mpl/int.hpp>
#ifdef BOOST_TYPEOF_USE_MPL_VECTOR # include <boost/mpl/vector.hpp> # include <boost/mpl/size.hpp> # include <boost/mpl/at.hpp> # include <boost/mpl/begin_end.hpp> # include <boost/mpl/push_back.hpp> # include <boost/typeof/limit_size.hpp> # define BOOST_TYPEOF_VECTOR(n) BOOST_PP_CAT(boost::mpl::vector, n) #else # include <boost/typeof/vector.hpp> # define BOOST_TYPEOF_VECTOR(n) BOOST_PP_CAT(boost::type_of::vector, n) #endif
namespace boost{namespace type_of{
template<int pos, class T> struct at_ { enum { size = mpl::size< typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type >::type::value };
enum { n = (pos < size) ? pos : 0 };
typedef char(&type)[ mpl::at_c< typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type , n >::type::value ]; };
template <int pos, class T> static typename at_<pos,T>::type at(const T&); }}
#define BOOST_TYPEOF_TYPEITEM(z, n, expr)\ boost::mpl::size_t<sizeof(boost::type_of::at<n>(expr))>
#define BOOST_TYPEOF(Expr) \ boost::type_of::decode_type< \ boost::mpl::begin< \ BOOST_TYPEOF_VECTOR(BOOST_TYPEOF_LIMIT_SIZE)< \ BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_TYPEITEM, Expr) \ > \ >::type \ >::type
#define BOOST_TYPEOF_TPL(Expr) \ typename boost::type_of::decode_type< \ typename boost::mpl::begin< \ BOOST_TYPEOF_VECTOR(BOOST_TYPEOF_LIMIT_SIZE)< \ BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_TYPEITEM, Expr) \ > \ >::type \ >::type
#endif//BOOST_TYPEOF_COMPLIANT_TYPEOF_IMPL_HPP_INCLUDED
---------------------------------------------------------------------------- ----
-- Dave Abrahams Boost Consulting www.boost-consulting.com
---------------------------------------------------------------------------- ----
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
I believe I have substantially simplified the implementation of typeof and fixed the vc8 compatibility problems. See the enclosed typeof_impl.hpp
Right. That's exactly the simplification I meant in my previous post. Unfortunately it means at() is instantiated BOOST_TYPEOF_LIMIT_SIZE times, whereas with more complicated expression it is instantiated only n times, where n is the actual size of the encoded vector. I introduced this complexity about half a year ago, and it cut the time of my tests more than in half...
Okay, how about the one enclosed here, then?
I am a little concerned about the implementation. When I saw the complexity of what the BOOST_TYPEOF macro expanded into, I was a bit shocked. Aside from what I addressed, the fact that the expression gets repeated 100 times was really surprising to me -- it seems to me that asking the compiler to evaluate the type of the expression over and over could get to be quite expensive.
But this is on average seems to be compensated by less times the template is instantiated.
Okay.
The simplification I've made results in the expression being repeated "only" 50 times. Is it possible to do better?
I don't believe it's possible with conventional metaprogramming. The problem is that, in order to calculate the size of the vector at compile time, we have to pass the expression inside a metafunction, which doesn't seem possible. Therefore we have to do it at preprocessing time, which means BOOST_TYPEOF_LIMIT_SIZE times. This is the price of crossing boundaries.
Also, on a stylistic note, the paucity of whitespace in
namespace boost{namespace type_of{
seems a bit draconian (yes, I'm exercising my vocabulary today ;->).
Well, there are two whitespaces :-)
Why? Does it make it unreadable?
Just less readable than it might be. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
I believe I have substantially simplified the implementation of typeof and fixed the vc8 compatibility problems. See the enclosed typeof_impl.hpp
Right. That's exactly the simplification I meant in my previous post. Unfortunately it means at() is instantiated BOOST_TYPEOF_LIMIT_SIZE times, whereas with more complicated expression it is instantiated only n times, where n is the actual size of the encoded vector. I introduced this complexity about half a year ago, and it cut the time of my tests more
"David Abrahams" <dave@boost-consulting.com> wrote than
in half...
Okay, how about the one enclosed here, then?
Now you have both size() and size_<> instantiated LIMIT_SIZE times ;-)
Also, on a stylistic note, the paucity of whitespace in
namespace boost{namespace type_of{
seems a bit draconian (yes, I'm exercising my vocabulary today ;->).
Well, there are two whitespaces :-)
Why? Does it make it unreadable?
Just less readable than it might be.
I don't have strong feelings about it -- I'll add some whitespaces... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
I believe I have substantially simplified the implementation of typeof and fixed the vc8 compatibility problems. See the enclosed typeof_impl.hpp
Right. That's exactly the simplification I meant in my previous post. Unfortunately it means at() is instantiated BOOST_TYPEOF_LIMIT_SIZE times, whereas with more complicated expression it is instantiated only n times, where n is the actual size of the encoded vector. I introduced this complexity about half a year ago, and it cut the time of my tests more than in half...
Okay, how about the one enclosed here, then?
Now you have both size() and size_<> instantiated LIMIT_SIZE times ;-)
According to Eric, you need something like size_<> to workaround vc++ bugs, though. Okay, let me try one more. I think this one gets close to the minimal number of instantiations required to work around VC++ bugs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Okay, how about the one enclosed here, then?
Now you have both size() and size_<> instantiated LIMIT_SIZE times ;-)
According to Eric, you need something like size_<> to workaround vc++ bugs, though.
Not if the expression is simplified. It's really multiple calls to sizeof what drives the compiler crazy.
Okay, let me try one more. I think this one gets close to the minimal number of instantiations required to work around VC++ bugs.
Still, select<> is instantiated LIMIT_SIZE times... The beauty of the ugly solution with the conditional operator is that it brings the algorithm complexity, in terms of template instantiations, to O(m), where m is the real size of the vector. True, we pay by doubling the amount of template lookups, and expression evaluations, but it looks like it pays. It's a pity that VC8 chokes on this in some contexts -- maybe we'll be able to get MS to fix it before the real thing comes out. Until then, I believe we should specialcase the VC8, and I think your first suggestion, with no separate size function will do the job fine. We could even limit this to dependent contexts, since I don't think this problem exists outside templates. However your other suggestion, that allows to remove _TPL, makes this impossible. Still, I love the idea of removing _TPL so much that I am willing to pay this price... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Okay, how about the one enclosed here, then?
Now you have both size() and size_<> instantiated LIMIT_SIZE times ;-)
According to Eric, you need something like size_<> to workaround vc++ bugs, though.
Not if the expression is simplified. It's really multiple calls to sizeof what drives the compiler crazy.
Okay, let me try one more. I think this one gets close to the minimal number of instantiations required to work around VC++ bugs.
Still, select<> is instantiated LIMIT_SIZE times...
Yes, but not LIMIT_SIZE * N, where N is the number of different types passed to BOOST_TYPEOF. So it's a one-time cost, which is better than what I posted earlier.
The beauty of the ugly solution with the conditional operator is that it brings the algorithm complexity, in terms of template instantiations, to O(m), where m is the real size of the vector. True, we pay by doubling the amount of template lookups, and expression evaluations, but it looks like it pays.
OK.
It's a pity that VC8 chokes on this in some contexts -- maybe we'll be able to get MS to fix it before the real thing comes out.
Yes, I have got one of their engineers working on it :)
Until then, I believe we should specialcase the VC8, and I think your first suggestion, with no separate size function will do the job fine.
I think my latest is better.
We could even limit this to dependent contexts, since I don't think this problem exists outside templates. However your other suggestion, that allows to remove _TPL, makes this impossible. Still, I love the idea of removing _TPL so much that I am willing to pay this price...
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Okay, how about the one enclosed here, then?
Now you have both size() and size_<> instantiated LIMIT_SIZE times ;-)
According to Eric, you need something like size_<> to workaround vc++ bugs, though.
Not if the expression is simplified. It's really multiple calls to sizeof what drives the compiler crazy.
Okay, let me try one more. I think this one gets close to the minimal number of instantiations required to work around VC++ bugs.
Still, select<> is instantiated LIMIT_SIZE times...
Yes, but not LIMIT_SIZE * N, where N is the number of different types passed to BOOST_TYPEOF. So it's a one-time cost, which is better than what I posted earlier.
Hmm, I'm no longer certain of that. It's at least LIMIT_SIZE * M, where M is the number of distinct result types of size(). -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Hmm, I'm no longer certain of that. It's at least LIMIT_SIZE * M, where M is the number of distinct result types of size().
OK, since we are not certain which one is better, I prefer the simplest one (the one you suggested first). Since, as you mentioned, somebody at Microsoft is looking at this (thanks a lot, BTW), it might not matter after all. For now this one would do, and, if we have to live with it in the long run, we can see what can be done to optimize it. I uploaded the new version, take it at usual place, http://boost-sandbox.sourceforge.net/vault/, typeof.zip -- the problem should be fixed, and I also added similar code to the tests. I havn't changed anything else -- I think other things, like removing _TPL, etc., can (and should) wait until after the review... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Hmm, I'm no longer certain of that. It's at least LIMIT_SIZE * M, where M is the number of distinct result types of size().
OK, since we are not certain which one is better, I prefer the simplest one (the one you suggested first).
Well, there are two ways to get an idea of which is better: 1. Decide if size() will return the same value for multiple different types. If so, it's likely the 2nd one is better. If not, it's likely the 1st one is. 2. Time it ;-)
Since, as you mentioned, somebody at Microsoft is looking at this (thanks a lot, BTW), it might not matter after all.
It's very close to the wire for them. There's no guarantee they'll make it, FWIW.
For now this one would do, and, if we have to live with it in the long run, we can see what can be done to optimize it.
I uploaded the new version, take it at usual place, http://boost-sandbox.sourceforge.net/vault/, typeof.zip -- the problem should be fixed, and I also added similar code to the tests.
Thanks. I should probably download it and try that one eventually, but I am currently attacking other problems in my code using my 2nd implementation.
I havn't changed anything else -- I think other things, like removing _TPL, etc., can (and should) wait until after the review...
Makes sense. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 09:15 2005-05-21, Eric Niebler wrote:
Arkadiy Vertleyb wrote:
Here is the minimal example:
[deleted]
I have experienced this problem before, and the fix is to calculate the return type of the sz() function as a separate step:
#include "boost/mpl/vector.hpp" #include "boost/mpl/size_t.hpp"
template<class T> T make();
template<class T> struct et { typedef boost::mpl::vector1<int> type; };
template<class T> struct sizer { typedef char(&type)[ boost::mpl::size< typename et<T>::type >::value ]; };
template<class T> typename sizer<T>::type sz(const T&);
template<class T, class U> struct add { typedef boost::mpl::vector1< boost::mpl::size_t<sizeof(sz(make<T>() + make<U>()))> > type; };
This compiles with VC7.1 and with gcc. I don't have VC8 beta installed.
compiles on my 8.0
Do Microsoft people read this list, or should I post it elsewhere?
Report the bug at the product feedback center:
http://lab.msdn.microsoft.com/productfeedback/
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Caleb Epstein" <caleb.epstein@gmail.com> wrote
First the wet noodle sadism, and now this. What happened to the real Dave?
:-)
Ok ... Having downloaded 3Mb in order to follow Dave Abraham's argument, I can sympathise with your sentiments. However as review manager I need to alert you to the fact that you are (at least) way off topic. Any chance of a review of the library to redeem youself? regards Andy Little
What is your evaluation of the design?
Not much to say about the (typeof-) client interface, as these are basically macro-ized keywords of a language extension (in case of 'auto' even language history). I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out. Making libraries work with Boost.Typeof implies collecting a lot of information about types and templates which could be useful in other places as well: For example it would be possible to collect the names as well (and require them to be fully qualified) to allow an efficient "compile time type info" facility to be built upon it. There might be more interesting ideas in this direction (and that's the primary reason for me to mention it here). In the registration interface there is no way to get rid of the one #include per file, so I would prefer a table passed as "named external argument" for the registration data: #define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER() This allows to hide the "registration group issue" from the user and enforces proper handling. Even better: it allows to completely get rid of it (well, in some sense) and use a "dense index space" instead, which in turn allows a more efficient encoding. A downside is, that it's no longer possible to invoke a registration from within another macro (which is ugly but maybe practical). It also would allow "vertical repetition constructs" to be used, which do improve diagnostics both for tracking down typos of the client and for the maintainer. However, I am not too sure about this part of the suggestion, because it is likely to cost some preprocessing time.
What is your evaluation of the implementation?
From what I have seen, the implementation seems well structured and even reads good (and it's really easy for things to look messy when there is a lot of preprocessor code around).
What is your evaluation of the documentation?
The documentation works for me and I'm not too ambitios about it because the usage is straightforward. The page title (<TITLE>Contents</TITLE>) could be a bit more expressive, I guess ;-).
What is your evaluation of the potential usefulness of the library?
Very useful, as the language currently lacks a way to transport a type from expression scope to class scope.
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Did you try to use the library? With what compiler? Did you have any problems?
I have looked into it once in a while throughout its evolution and recently started actually using it. I didn't have any problems with my primary compilers, which are among the officially supported ones and did some testing on my secondary computer (running linux) while writing this review: All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").
Are you knowledgeable about the problem domain?
A bit - I once implemented a minimalist typeof emulator (it's only capable of handling type template parameters and requires a class to be defined to "do the actual typeof thing", though).
Do you think the library should be accepted as a Boost library?
Yes, I do. Regards, Tobias
Here is a repost of my review because the subject of the original post wasn't conforming to the guidelines 8-) --- original message ---
What is your evaluation of the design?
Not much to say about the (typeof-) client interface, as these are basically macro-ized keywords of a language extension (in case of 'auto' even language history). I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out. Making libraries work with Boost.Typeof implies collecting a lot of information about types and templates which could be useful in other places as well: For example it would be possible to collect the names as well (and require them to be fully qualified) to allow an efficient "compile time type info" facility to be built upon it. There might be more interesting ideas in this direction (and that's the primary reason for me to mention it here). In the registration interface there is no way to get rid of the one #include per file, so I would prefer a table passed as "named external argument" for the registration data: #define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER() This allows to hide the "registration group issue" from the user and enforces proper handling. Even better: it allows to completely get rid of it (well, in some sense) and use a "dense index space" instead, which in turn allows a more efficient encoding. A downside is, that it's no longer possible to invoke a registration from within another macro (which is ugly but maybe practical). It also would allow "vertical repetition constructs" to be used, which do improve diagnostics both for tracking down typos of the client and for the maintainer. However, I am not too sure about this part of the suggestion, because it is likely to cost some preprocessing time.
What is your evaluation of the implementation?
From what I have seen, the implementation seems well structured and even reads good (and it's really easy for things to look messy when there is a lot of preprocessor code around).
What is your evaluation of the documentation?
The documentation works for me and I'm not too ambitios about it because the usage is straightforward. The page title (<TITLE>Contents</TITLE>) could be a bit more expressive, I guess ;-).
What is your evaluation of the potential usefulness of the library?
Very useful, as the language currently lacks a way to transport a type from expression scope to class scope.
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Did you try to use the library? With what compiler? Did you have any problems?
I have looked into it once in a while throughout its evolution and recently started actually using it. I didn't have any problems with my primary compilers, which are among the officially supported ones and did some testing on my secondary computer (running linux) while writing this review: All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").
Are you knowledgeable about the problem domain?
A bit - I once implemented a minimalist typeof emulator (it's only capable of handling type template parameters and requires a class to be defined to "do the actual typeof thing", though).
Do you think the library should be accepted as a Boost library?
Yes, I do. Regards, Tobias
Hi Tobias, Thanks for the review. "Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.
Making libraries work with Boost.Typeof implies collecting a lot of information about types and templates which could be useful in other places as well: For example it would be possible to collect the names as well (and require
to be fully qualified) to allow an efficient "compile time type info" facility to be built upon it. There might be more interesting ideas in this
I don't have strong feelings about our current spelling, but I am not sure if I am crasy about BOOST_TYPEOF_TEMPLATED either. When David suggested using mpl::identity<__typeof__(x)>::type to wrap native typeof, I thought we can get rid of the xxx_TPL macros altogether (which would be a preferable solution for me), but now I realize that "typename" is used twice in the macto expansion. Which means we may also need BOOST_LVALUE_TYPEOF_TPL (or analogous). I need to give this a little more thought, and I also like to hear what other people think about naming. them direction
(and that's the primary reason for me to mention it here).
In the registration interface there is no way to get rid of the one #include per file, so I would prefer a table passed as "named external argument" for
Agreed. Also I think Steve Dewhurst (who apparently did a lot of research in this area) once published an article about decomposing a type and bringing it back together... the
registration data:
#define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER()
Not sure I understand this... Can you ellaborate?
I didn't have any problems with my primary compilers, which are among the officially supported ones and did some testing on my secondary computer (running linux) while writing this review:
All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").
We did some work with Aleksandr Nasonov to port the library to Intel 8.0, and we came pretty close -- only the exotic case "template<class T, Tn>" didn't work, and we proved to ourselves that this was because of the compiler bug. So I think Intel will be among first compilers to extend our support. Regards, Arkadiy
Hi Arkadiy, Arkadiy Vertleyb wrote:
Hi Tobias,
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.
I don't have strong feelings about our current spelling, but I am not sure if I am crasy about BOOST_TYPEOF_TEMPLATED either. When David suggested
actually, I meant BOOST_TEMPLATED_TYPEOF and BOOST_TEMPLATED_LVALUE_TYPEOF, which read and speak better...
I need to give this a little more thought, and I also like to hear what other people think about naming.
...but don't claim these names to be perfect, of course.
[...] Agreed. Also I think Steve Dewhurst (who apparently did a lot of research in this area) once published an article about decomposing a type and bringing it back together...
Are you talking about the 'typeints'- or the 'typeof'-article ? Can you perhaps post a link ?
In the registration interface there is no way to get rid of the one #include per file, so I would prefer a table passed as "named external argument" for the registration data:
#define BOOST_TYPEOF_REGISTRATION <table> #include BOOST_TYPEOF_REGISTER()
Not sure I understand this... Can you ellaborate?
First of all I have to "fix a bug" in my previous post: it does not point to the definitions or at least to the documentation of Boost.Preprocessor to explain the terms "named external argument" and "vertical repetition": http://www.boost.org/libs/preprocessor/doc/terms/named_external.html http://boost-consulting.com/tmpbook/preprocessor.html#vertical-repetition I'm talking about making the client code for the registration look like this (e.g.): #define BOOST_TYPEOF_REGISTRATION \ ( typename(boost::lambda::greater_action) ) \ ( template(boost::lambda::functor,1) ) \ ( template(boost::lambda::lambda_functor_base,2) ) \ [...] #include BOOST_TYPEOF_REGISTER() This way you don't need a registration group to create unique indices for all registered templates/types. All you need to do is store the last index incremented by one as the first index for the next run (i.e. #inclusion) and the user isn't required to remember incrementing the registration group. Further I mentioned the possibility to trade some preprocessing performance for convenience and transparency, which may or may not be desirable.
We did some work with Aleksandr Nasonov to port the library to Intel 8.0, and we came pretty close -- only the exotic case "template<class T, Tn>" didn't work, and we proved to ourselves that this was because of the compiler bug. So I think Intel will be among first compilers to extend our support.
Good to hear it's a compiler bug. Btw. I had to do something like this once and got away with member templates: template<typename T> class X { template<T n> [...] (IIRC this works with Intel) and to be honest I didn't even know it is a valid possibilty to do it within a single template parameter list, until now (well, don't know for sure - I just believe you ;-) ).
Thanks for the review.
Thanks for the library ! Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
Agreed. Also I think Steve Dewhurst (who apparently did a lot of research in this area) once published an article about decomposing a type and bringing it back together...
Are you talking about the 'typeints'- or the 'typeof'-article ? Can you perhaps post a link ?
I'm talking about making the client code for the registration look like
Can't find it :-( I think he used type tags instead if integers, decomposed a type into a typelist of these tags with the help of partial template specialization, applied some transformation to the list, and then reassembled the new type. I don't remember if he mentioned any practical usage of this, though... this (e.g.):
#define BOOST_TYPEOF_REGISTRATION \ ( typename(boost::lambda::greater_action) ) \ ( template(boost::lambda::functor,1) ) \ ( template(boost::lambda::lambda_functor_base,2) ) \ [...] #include BOOST_TYPEOF_REGISTER()
Understood. Let me think about this...
We did some work with Aleksandr Nasonov to port the library to Intel 8.0, and we came pretty close -- only the exotic case "template<class T, Tn>" didn't work, and we proved to ourselves that this was because of the compiler bug. So I think Intel will be among first compilers to extend our support.
Good to hear it's a compiler bug. Btw. I had to do something like this once and got away with member templates:
template<typename T> class X { template<T n> [...]
(IIRC this works with Intel) and to be honest I didn't even know it is a valid possibilty to do it within a single template parameter list, until now (well, don't know for sure - I just believe you ;-) ).
Here is the final minimal example Alexander (sorry for misspelling his name the first time) came up with: //------ template<class T, T n> struct a {}; template<class V, class T> struct traits; template<class V, class T, T n> struct traits<V, a<T, n> > {}; struct X {}; int main() { traits<int, a<int,0> > good; traits<X , a<int,0> > bad; // error: incomplete type is not allowed. } //------ This was the only problem with Intel 8.0, but I think other versions have a few more (your experience demonstrated it). Regards, Arkadiy
Here is the final minimal example Alexander (sorry for misspelling his name the first time) came up with:
You were right the first time. In Russian passport my first name is written down as Alexandr. In a foreign passport it's Alexander. But you can call me Sasha, it's the same but more familiar :) -- Alexander
"Alexander Nasonov" <alnsn-boost@yandex.ru> wrote
You were right the first time. In Russian passport my first name is written down as Alexandr. In a foreign passport it's Alexander. But you can call me Sasha, it's the same but more familiar :)
OK, Sasha be it :-) I just used the direct Russian spelling the first time, then saw your signature, and decided to correct myself... Arkadiy
Tobias Schwinger wrote:
Further I mentioned the possibility to trade some preprocessing performance for convenience and transparency, which may or may not be desirable.
^^^^ Sorry for posting wrong stuff: Vertical repetition is even faster than horizontal one, as Paul Mensonidis has recently pointed out to me. Regards, Tobias
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:d6lvtt$oas$1@sea.gmane.org...
All tests failed with Intel 7.0 and Intel 8.1 ("no instance of function template boost::type_of::at matches the argument list * - in BOOST_TYPEOF_TPL").
We did some work with Aleksandr Nasonov to port the library to Intel 8.0, and we came pretty close -- only the exotic case "template<class T, Tn>" didn't work, and we proved to ourselves that this was because of the compiler bug. So I think Intel will be among first compilers to extend our support.
Be sure to report this to Intel. They have been very good about fixing bugs, so it is definitely worth the effort. --Beman
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Hi Tobias,
Thanks for the review.
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I don't like the '_TPL' suffix - I'ld prefer 'TEMPLATED' to be spelled out.
I don't have strong feelings about our current spelling, but I am not sure if I am crasy about BOOST_TYPEOF_TEMPLATED either. When David suggested using mpl::identity<__typeof__(x)>::type to wrap native typeof, I thought we can get rid of the xxx_TPL macros altogether (which would be a preferable solution for me), but now I realize that "typename" is used twice in the macto expansion. Which means we may also need BOOST_LVALUE_TYPEOF_TPL (or analogous).
Naw... anything of the form metafunction1< metafunction2< ... >::type >::type can be collapsed into metafunction3< ... >::type where template <class T> struct metafunction3 : metafunction1< typename metafunction2< T >::type > {}; So there should be no need for any _TPL suffixes.
I need to give this a little more thought, and I also like to hear what other people think about naming.
Well, even "TEMPLATED" is not very descriptive ;-)
We did some work with Aleksandr Nasonov to port the library to Intel 8.0, and we came pretty close -- only the exotic case "template<class T, Tn>" didn't work, and we proved to ourselves that this was because of the compiler bug. So I think Intel will be among first compilers to extend our support.
Did you submit a bug report to intel? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
Naw... anything of the form
metafunction1< metafunction2< ... >::type >::type
can be collapsed into
metafunction3< ... >::type
where
template <class T> struct metafunction3 : metafunction1< typename metafunction2< T >::type > {};
So there should be no need for any _TPL suffixes.
Please note however, that we do not strictly operate with metafunctions. The argument of TYPEOF can't be passed to a metafunction, which does change the rules. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Naw... anything of the form
metafunction1< metafunction2< ... >::type >::type
can be collapsed into
metafunction3< ... >::type
where
template <class T> struct metafunction3 : metafunction1< typename metafunction2< T >::type > {};
So there should be no need for any _TPL suffixes.
Please note however, that we do not strictly operate with metafunctions. The argument of TYPEOF can't be passed to a metafunction, which does change the rules.
I don't understand. You can't write template <class T> struct decode_type_begin : boost::type_of::decode_type< typename boost::mpl::begin<T>::type > {}; #define BOOST_TYPEOF(Expr) \ boost::type_of::decode_type_begin< \ BOOST_TYPEOF_VECTOR(BOOST_TYPEOF_LIMIT_SIZE)< \ BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_TYPEITEM, Expr) \ > \ >::type ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
I don't understand. You can't write
template <class T> struct decode_type_begin : boost::type_of::decode_type< typename boost::mpl::begin<T>::type > {};
#define BOOST_TYPEOF(Expr) \ boost::type_of::decode_type_begin< \ BOOST_TYPEOF_VECTOR(BOOST_TYPEOF_LIMIT_SIZE)< \ BOOST_PP_ENUM(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_TYPEITEM, Expr) \ > \ >::type
??
You are right. We can get rid of xxx_TPL, and this will be a major interface improvement. Thanks! Regards, Arkadiy
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
What is your evaluation of the design? What is your evaluation of the implementation?
I don't fully understand it so I can comment only few things. - Why decode_type_impl and encode_type_impl primary templates are declared in unnamed namespace? All specializations are also in (other) unnamed namespaces. Is it intentional? - It would be nice to put some functionality like get_unsigned<T> in correspondent libraries. This way, we could have better support for them. In this particular case, non-standard integral types could be supported as well. See also my note about documentation. - encode_integral casts integral type to size_t. Is there any guarantee that size_t is always big enough? - I don't understand why some big contants are hardcoded? For example, encode_size_t template checks if n >= 0x3fffffff. If it's magic, can you please comment it explicitly?
What is your evaluation of the documentation?
Not yet complete. - There's no references to online versions of Steve Dewhurst's articles. They can be found at http://www.semantics.org/localarchive.html - No information at all about how to compile in compliant mode. - Why only "well-known integral type" are registered implicitly? I think that all integral types supported by boost::is_integral should be supported by the library as well.
What is your evaluation of the potential usefulness of the library? Very useful
Did you try to use the library? With what compiler? Did you have any problems? I've tried gcc 3.2 in both native and compliant modes. It works fine. Free version of Intel 8.0 under linux compiles in native mode. Linux version of this compiler comes with gcc emulation mode and, AFAIK, __typeof__ is also emulated. Though, I don't know whether it differs from gcc __typeof__. Intel compiler fails to compile in compliant mode because of bug in the compiler. BTW, who is a best person to send a bug report to Intel? Me or the authors?
How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Somewhere between "A quick reading" and "In-depth study".
Are you knowledgeable about the problem domain?
I heard about typeof but I never read WG21 papers.
And finally, every review should answer this question:
Do you think the library should be accepted as a Boost library?
It should be accepted. -- Alexander Nasonov
Alexander Nasonov <alnsn-boost <at> yandex.ru> writes: Please, ignore my post above. It's a duplicate of http://lists.boost.org/boost/2005/05/27276.php -- Alexander Nasonov
participants (9)
-
Alexander Nasonov -
Andy Little -
Arkadiy Vertleyb -
Beman Dawes -
Caleb Epstein -
David Abrahams -
Eric Niebler -
Tobias Schwinger -
Victor A. Wagner Jr.