New implementation of remove_xxx for vintage compilers
Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0: remove_pointer remove_reference remove_bounds The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support? #define BOOST_MAX_TYPEOF_SIZE 20 #include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex> #include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp> template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {}; BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long)) BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename)) int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value)); typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value)); return 0; } -- Peder Holt
Now that typeof has been checked into the CVS tree, what are the chances that we can get implementations of remove_pointer, remove_bounds, remove_reference, etc. for VC6 and VC7? See the attached message for a link to a typeof-based implementation. I would like to this this happen. It would fix problems in Boost.Range and Boost.Foreach for those compilers. -- Eric Niebler Boost Consulting www.boost-consulting.com Peder Holt wrote:
Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0:
remove_pointer remove_reference remove_bounds
The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip
The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support?
#define BOOST_MAX_TYPEOF_SIZE 20
#include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex>
#include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp>
template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {};
BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long))
BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename))
int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value));
typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value));
return 0; }
-- Peder Holt
Eric Niebler writes:
Now that typeof has been checked into the CVS tree, what are the chances that we can get implementations of remove_pointer, remove_bounds, remove_reference, etc. for VC6 and VC7? See the attached message for a link to a typeof-based implementation.
I would like to this this happen. It would fix problems in Boost.Range and Boost.Foreach for those compilers.
I'd like to see a comparison of compilation times between the old and the new implementation and the latter being stress tested on Boost.Python tests before it officially replaces the current code. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Eric Niebler writes:
Now that typeof has been checked into the CVS tree, what are the chances that we can get implementations of remove_pointer, remove_bounds, remove_reference, etc. for VC6 and VC7? See the attached message for a link to a typeof-based implementation.
I would like to this this happen. It would fix problems in Boost.Range and Boost.Foreach for those compilers.
I'd like to see a comparison of compilation times between the old and the new implementation and the latter being stress tested on Boost.Python tests before it officially replaces the current code.
I'm not sure what you mean. The "current code" for remove_pointer, et al. for VC6 and VC7 is broken -- it does nothing. You want to see a performance comparison between code that doesn't work and code that does. Why? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler writes:
Aleksey Gurtovoy wrote:
I'd like to see a comparison of compilation times between the old and the new implementation and the latter being stress tested on Boost.Python tests before it officially replaces the current code.
I'm not sure what you mean. The "current code" for remove_pointer, et al. for VC6 and VC7 is broken -- it does nothing.
It does, see http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broke....
You want to see a performance comparison between code that doesn't work and code that does. Why?
Because we have code that depends on Type Traits working reliably on MSVC 6.5 -- and taking a reasonable amount of time to compile. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
Eric Niebler writes:
Aleksey Gurtovoy wrote:
I'd like to see a comparison of compilation times between the old and the new implementation and the latter being stress tested on Boost.Python tests before it officially replaces the current code.
I'm not sure what you mean. The "current code" for remove_pointer, et al. for VC6 and VC7 is broken -- it does nothing.
It does, see
http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broke n_compiler_workarounds_.
You want to see a performance comparison between code that doesn't work and code that does. Why?
Because we have code that depends on Type Traits working reliably on MSVC 6.5 -- and taking a reasonable amount of time to compile.
If this is related to only VC6 and VC7.0, then a typeof-using implementation would compile fast (and not require registration) since for these compilers the only possible option is to use the Igor' Chesnokov's MSVC-specific trick (not emulation). However to stress-test it would be a good idea anyway. Regards, Arkadiy
Aleksey Gurtovoy wrote:
Eric Niebler writes:
I'm not sure what you mean. The "current code" for remove_pointer, et al. for VC6 and VC7 is broken -- it does nothing.
It does, see http://www.boost.org/doc/html/boost_typetraits/category.html#transform.broke....
You want to see a performance comparison between code that doesn't work and code that does. Why?
Because we have code that depends on Type Traits working reliably on MSVC 6.5 -- and taking a reasonable amount of time to compile.
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out. http://tinyurl.com/8fs7w IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way. It's a pretty easy test. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types. Here, though, we have more information. In stead of using an integral number to 'register' a type, we can use the input type: template<typename InputType> struct msvc_extract_type { struct id2type; }; template<typename RegisteredType, typename InputType> struct msvc_register_type : msvc_typeof_base<InputType> { struct msvc_typeof_base<InputType>::id2type // This uses nice VC6-VC7 bugfeature { typedef RegisteredType type; }; }; Later: template<typename U> struct remove_pointer { template<typename T> msvc_register_type<T,remove_pointer<T*> > remove_ptr_fn(T* (*)()) static U test_function(); enum {register_type=sizeof(remove_ptr_fn(test_function))}; typedef typename msvc_extract_type<remove_pointer<U> >::id2type::type type; }; I'll try to get a version up and going with this implementation very soon. Regards, Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/1/05, Eric Niebler <eric@boost-consulting.com> wrote:
John Maddock wrote:
Eric, can you and Peder co-operate on getting an improved version up and running, and tested with python as requested?
Certainly.
In lack of a working file vault, I have uploaded the new version to the yahoo files area. http://groups.yahoo.com/group/boost/files/remove_xxx.zip I have compiled all the remove_xxx.cpp tests: remove_all_extents_test.cpp remove_bounds_test.cpp remove_const_test.cpp remove_cv_test.cpp remove_extent_test.cpp remove_pointer_test.cpp remove_reference_test.cpp remove_volatile_test.cpp All compiles and run without warning. I do not use the specializations registered by BOOST_TT_BROKEN_COMPILER_SPEC, but this can be added without much problem. Compilation of the tests were relatively fast, but I had to increase the internal heap limit to 800 (Zm800) in order to compile the tests. Tested on VC6 sp5 Regards, Peder
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Eric Niebler wrote:
John Maddock wrote:
Eric, can you and Peder co-operate on getting an improved version up and running, and tested with python as requested?
Certainly.
I haven't forgotten about this. :-) I have been playing with Peder's remove_xxx implementation for vc6 and vc7.0 and the results look really good so far. All the type_traits remove_* tests pass on these compilers with the patch. Also, python builds successfully, and approx 20% faster with the change. (The number seems large to me, I should rerun the tests to be sure.) The python tests also all pass. This is after disabling BOOST_TT_BROKEN_COMPILER_SPEC and using Peder's remove_* implementations. I hope to run the full set of Boost's regression tests with the changes and compare with the results from HEAD. But that will have to wait until I get back from OOPSLA. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Eric Niebler wrote:
John Maddock wrote:
Eric, can you and Peder co-operate on getting an improved version up and running, and tested with python as requested?
Certainly.
I haven't forgotten about this. :-) I have been playing with Peder's remove_xxx implementation for vc6 and vc7.0 and the results look really good so far. All the type_traits remove_* tests pass on these compilers with the patch. Also, python builds successfully, and approx 20% faster with the change. (The number seems large to me, I should rerun the tests to be sure.) The python tests also all pass. This is after disabling BOOST_TT_BROKEN_COMPILER_SPEC and using Peder's remove_* implementations.
I hope to run the full set of Boost's regression tests with the changes and compare with the results from HEAD. But that will have to wait until I get back from OOPSLA.
I've done some more testing, and things continue to look good for the remove_xxx traits for vc6.5/7.0. I'd like to commit these improved traits soon. John, should I submit a patch, or just commit? Also, we don't seem to have any test coverage for vc6.5/7.0 against HEAD right now. Should I hold off until after 1.33.1 is done? -- Eric Niebler Boost Consulting www.boost-consulting.com
I've done some more testing, and things continue to look good for the remove_xxx traits for vc6.5/7.0. I'd like to commit these improved traits soon. John, should I submit a patch, or just commit?
Also, we don't seem to have any test coverage for vc6.5/7.0 against HEAD right now. Should I hold off until after 1.33.1 is done?
Once your happy with them go agead and commit the changes. However I think we probably should hold off until we get VC6/7 testing back on HEAD - it's not uncommon for changes to type_traits to pass all the type traits tests, only for something seemingly harmless to fail only when it's instantiated deep inside some very-specific instantiation tree :-( We should only be a few days away from a 1.33.1 release now anyway....? John.
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....?
Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5. Doug
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....?
Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
What is the status on this now? It would be nice if this made it in the 1.34 release... Regards Peder
Peder Holt wrote:
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....? Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug
What is the status on this now? It would be nice if this made it in the 1.34 release...
I tested it an was all set for a check-in, but now we have nobody running tests on vc6/7.0. I can't check it in without regression tests, and now we're in feature freeze, so I guess this one doesn't make the cut. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler <eric@boost-consulting.com> writes:
Peder Holt wrote:
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....? Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug
What is the status on this now? It would be nice if this made it in the 1.34 release...
I tested it an was all set for a check-in, but now we have nobody running tests on vc6/7.0. I can't check it in without regression tests, and now we're in feature freeze, so I guess this one doesn't make the cut.
I'm prepared to start running vc6/vc7 tests, if that's what it takes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 2/11/06, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Peder Holt wrote:
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....? Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug
What is the status on this now? It would be nice if this made it in the 1.34 release...
I tested it an was all set for a check-in, but now we have nobody running tests on vc6/7.0. I can't check it in without regression tests, and now we're in feature freeze, so I guess this one doesn't make the cut.
I'm prepared to start running vc6/vc7 tests, if that's what it takes.
Sorry for nagging about this, but I see that the regression tests for VC6.5 and VC7.0 are up. I know we're in feature freeze, but from what I understand much of the point of setting up the VC6.5 and VC7.0 regression tests again was to have a version of BOOST with the remove_xxx hack in it. What should we do about it? Regards, Peder
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
On 2/11/06, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Peder Holt wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote:
We should only be a few days away from a 1.33.1 release now anyway....? Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug What is the status on this now? It would be nice if this made it in
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote: the 1.34 release... I tested it an was all set for a check-in, but now we have nobody running tests on vc6/7.0. I can't check it in without regression tests, and now we're in feature freeze, so I guess this one doesn't make the cut. I'm prepared to start running vc6/vc7 tests, if that's what it takes.
Sorry for nagging about this, but I see that the regression tests for VC6.5 and VC7.0 are up. I know we're in feature freeze, but from what I understand much of the point of setting up the VC6.5 and VC7.0 regression tests again was to have a version of BOOST with the remove_xxx hack in it. What should we do about it?
I am ok with putting this in, despite feature freeze. Thomas Release Manager -- Thomas Witt witt@acm.org
On 3/24/06, Thomas Witt <witt@acm.org> wrote:
Peder Holt wrote:
On 2/11/06, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Peder Holt wrote:
On Nov 27, 2005, at 5:39 AM, John Maddock wrote: > We should only be a few days away from a 1.33.1 release now > anyway....? Prerelease tarballs of 1.33.1 should be available by midweek, and the full release will be on December 5.
Doug What is the status on this now? It would be nice if this made it in
On 11/28/05, Douglas Gregor <doug.gregor@gmail.com> wrote: the 1.34 release... I tested it an was all set for a check-in, but now we have nobody running tests on vc6/7.0. I can't check it in without regression tests, and now we're in feature freeze, so I guess this one doesn't make the cut. I'm prepared to start running vc6/vc7 tests, if that's what it takes.
Sorry for nagging about this, but I see that the regression tests for VC6.5 and VC7.0 are up. I know we're in feature freeze, but from what I understand much of the point of setting up the VC6.5 and VC7.0 regression tests again was to have a version of BOOST with the remove_xxx hack in it. What should we do about it?
I am ok with putting this in, despite feature freeze.
Thanks. I'll commit them to HEAD first, and if no new regressions pop up (and nobody protests) I'll merge them to the release branch during the coming week. Regards, Peder
Thomas
Release Manager
-- Thomas Witt witt@acm.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
Thanks. I'll commit them to HEAD first, and if no new regressions pop up (and nobody protests) I'll merge them to the release branch during the coming week.
Please send me a private mail once you are done. Thanks Thomas -- Thomas Witt witt@acm.org
Peder Holt <peder.holt@gmail.com> writes:
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types.
I hope that's false, but in any case, you've completely missed the point. There's a bugfeature in vc <= 7.1 that allows typeof to be implemented without any such limitation. No numerical representation is ever generated. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peder Holt <peder.holt@gmail.com> writes:
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type
"David Abrahams" <dave@boost-consulting.com> wrote traits
templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types.
I hope that's false, but in any case, you've completely missed the point. There's a bugfeature in vc <= 7.1 that allows typeof to be implemented without any such limitation. No numerical representation is ever generated.
I think Peder is right. IIRC, when Igor Chesnokov invented the trick, it needed __if_exist compiler extension on VC7. Peder got rid of it using compile-time variables (discussed on this list about a year ago). I think these compile-time variables are used to "register" types on the fly, at the moment typeof gets invoked. And they are the ones that introduce this limitation... I am not sure if the same limitation applies to VC6. I am also not completely sure whether it applies to both VC70 and VC71 or to VC71 only... Regards, Arkadiy
On 9/1/05, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
Peder Holt <peder.holt@gmail.com> writes:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote: traits
templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types.
I hope that's false, but in any case, you've completely missed the point. There's a bugfeature in vc <= 7.1 that allows typeof to be implemented without any such limitation. No numerical representation is ever generated.
I think Peder is right. IIRC, when Igor Chesnokov invented the trick, it needed __if_exist compiler extension on VC7. Peder got rid of it using compile-time variables (discussed on this list about a year ago). I think these compile-time variables are used to "register" types on the fly, at the moment typeof gets invoked. And they are the ones that introduce this limitation...
That's right. the typeof trick requires an unique identifier to be 'registered' for every new type invoked. In the typeof library, we use an integral constant. This is because the type is registered inside a function, and the only thing we can extract compile-time from a function is an integral constant using sizeof. It would perhaps be possible to use a more elaborate scheme, where two distinct compile-time constants are combined to increase the limit, but we have to take into account that this limit applies on a per-compilation-unit basis, and a compilation unit containing ~1000 typeof invocations of 1000 different types would probably exhaust the compiler anyway (at least in emulation modus)
I am not sure if the same limitation applies to VC6. I am also not completely sure whether it applies to both VC70 and VC71 or to VC71 only...
Currently the limitation applies to all three compilers, but the limit of 1000 is arbitrary. I read through an email I got from Igor on the subject, and he wrote: "... Also, limit of __if_exists/__if_not_exists counter is greater than 1000, but when it exceeds 2500+ compiler generates "internal structure overflow"." Regards, Peder
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams <dave@boost-consulting.com> writes:
Peder Holt <peder.holt@gmail.com> writes:
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types.
I hope that's false, but in any case, you've completely missed the point. There's a bugfeature in vc <= 7.1 that allows typeof to be implemented without any such limitation. No numerical representation is ever generated.
Whoops; I read too fast, sorry. You obviously know about the bugfeature. So why are you saying there's a numerical representation and a limit on # of types? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
David Abrahams <dave@boost-consulting.com> writes:
Peder Holt <peder.holt@gmail.com> writes:
On 9/1/05, David Abrahams <dave@boost-consulting.com> wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
It's a pretty easy test.
I don't think using the typeof library directly is the best idea. When using typeof, you represent each type by a number, limiting you to ~1000 types.
I hope that's false, but in any case, you've completely missed the point. There's a bugfeature in vc <= 7.1 that allows typeof to be implemented without any such limitation. No numerical representation is ever generated.
Whoops; I read too fast, sorry. You obviously know about the bugfeature.
...I would think so. Igor' Chesnokov's trick only applies to VC6.5 and VC7.1. I implemented the trick used for VC7.0 :) So why are you saying there's a numerical representation
and a limit on # of types?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
When using typeof, you represent each type by a number, limiting you to ~1000 types.
Is that true, about the limit? If so, I find that somewhat disturbing. It's possible to represent arbitrary-precision integers at compile-time; IMO we should be doing that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams writes:
Eric Niebler <eric@boost-consulting.com> writes:
Ah. But the fact remains that remove_pointer et al. are indeed broken on VC6 and VC7, and the regression tests bear this out.
IMO, the best path is to preserve the meaning of BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION for compilers without PTS. That is, it still defines full specializations of the type traits templates. But the typeof implementation should be what the primary template uses for compilers without PTS. That way, everything that is working now, keeps working with no change in performance.
I think it would better to do some actual speed testing there. After all, using the typeof hack *could* turn out to be much faster and use fewer resources than doing it the other way.
My thoughts exactly. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (8)
-
Aleksey Gurtovoy -
Arkadiy Vertleyb -
David Abrahams -
Douglas Gregor -
Eric Niebler -
John Maddock -
Peder Holt -
Thomas Witt