[typeof] native implementation for msvc 8.0

AMDG The following hack works with msvc 8.0 It appears that using another specialization of msvc_extract_type tricks the compiler's filter. #elif BOOST_WORKAROUND(BOOST_MSVC,==1400) struct msvc_extract_type_default_param {}; template<typename ID, typename T = msvc_extract_type_default_param> struct msvc_extract_type; template<typename ID> struct msvc_extract_type<ID, msvc_extract_type_default_param> { template<bool> struct id2type_impl; typedef id2type_impl<true> id2type; }; template<typename ID, typename T> struct msvc_extract_type : msvc_extract_type<ID, msvc_extract_type_default_param> { template<> struct id2type_impl<true> //VC8.0 specific bugfeature { typedef T type; }; template<bool> struct id2type_impl; typedef id2type_impl<true> id2type; }; template<typename T, typename ID> struct msvc_register_type : msvc_extract_type<ID, T> { }; # else ... In Christ, Steven Watanabe

2006/12/23, Steven Watanabe <steven@providere-consulting.com>:
AMDG
The following hack works with msvc 8.0 It appears that using another specialization of msvc_extract_type tricks the compiler's filter.
Wow! Great job! This passed all our tests, so I added it to HEAD. I wonder if other compilers (e.g. Borland) can be tricked in the same way... Regards Peder
#elif BOOST_WORKAROUND(BOOST_MSVC,==1400) struct msvc_extract_type_default_param {};
template<typename ID, typename T = msvc_extract_type_default_param> struct msvc_extract_type;
template<typename ID> struct msvc_extract_type<ID, msvc_extract_type_default_param> { template<bool> struct id2type_impl;
typedef id2type_impl<true> id2type; };
template<typename ID, typename T> struct msvc_extract_type : msvc_extract_type<ID, msvc_extract_type_default_param> { template<> struct id2type_impl<true> //VC8.0 specific bugfeature { typedef T type; }; template<bool> struct id2type_impl;
typedef id2type_impl<true> id2type; };
template<typename T, typename ID> struct msvc_register_type : msvc_extract_type<ID, T> { }; # else ...
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2006/12/24, Arkadiy Vertleyb <vertleyb@hotmail.com>:
"Peder Holt" <peder.holt@gmail.com> wrote
Wow! Great job! This passed all our tests, so I added it to HEAD.
Cool!
Peder, should we also make it the default mode for 8.0?
Already done. I haven't updated the explicit-failures-markup.xml yet. Will do. Btw. This is some christmas present to the community :) Regards, Peder
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away.
I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this. Regards, Arkadiy

2006/12/25, Arkadiy Vertleyb <vertleyb@hotmail.com>:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away.
I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
That may take some time... The last regression tests on HEAD for VC8.0 was run Mon, 4 Dec 2006 23:51:21 +0000 Seems like all efforts are on testing the release branch... But I agree, this is a relatively low risk, high gain change. If it breaks regressions on the release branch, we can always revert it. I guess it is up to Thomas... Regards, Peder
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Arkadiy Vertleyb wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away.
I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
IANTRM (I am not the release manager), but I would STRONGLY discourage taking any changes into 1.34 that are not critical bug fixes. IMO, we need to be much more hard-core about feature freezes that we have been to date. This will be a wonderful feature -- for 1.35. -- Eric Niebler Boost Consulting www.boost-consulting.com

Eric Niebler wrote:
Arkadiy Vertleyb wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away. I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
IANTRM (I am not the release manager), but I would STRONGLY discourage taking any changes into 1.34 that are not critical bug fixes. IMO, we need to be much more hard-core about feature freezes that we have been to date.
I agree with Eric. The problem is that it is hard to define which we should allow and which we should not. I think going strict is the right way to go now and in the future.
This will be a wonderful feature -- for 1.35.
Certainly. I think it is also possible to release incremental updates after 1.34. I hope Beman's new release procedure (in the making) allows such incremental releases. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman wrote:
Eric Niebler wrote:
IANTRM (I am not the release manager), but I would STRONGLY discourage taking any changes into 1.34 that are not critical bug fixes. IMO, we need to be much more hard-core about feature freezes that we have been to date.
I agree with Eric. The problem is that it is hard to define which we should allow and which we should not. I think going strict is the right way to go now and in the future.
I also agree with Eric. The delay in getting 1.34 out the door is a serious problem, approach an emergency, IMO.
This will be a wonderful feature -- for 1.35.
Certainly. I think it is also possible to release incremental updates after 1.34. I hope Beman's new release procedure (in the making) allows such incremental releases.
I'm planning to start discussions about new release procedures the moment 1.34 ships. --Beman

Arkadiy Vertleyb wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away.
I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
In short this is a no-go, for reasons already mentioned. As a side-note I might miss release related questions when asked in threads like this. Thomas -- Thomas Witt witt@acm.org

Thomas Witt wrote:
Arkadiy Vertleyb wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away. I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
In short this is a no-go, for reasons already mentioned.
At any rate, this is definitely a wonderful Christmas present to the Boost community. Thank you very much Arkadiy, Peder and especially Steven! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

"Thomas Witt" <witt@acm.org> wrote
Arkadiy Vertleyb wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
[ typeof on VC8 ] Perhaps adding it to 1.34 could be considered. I know how this is against all the rules but 1.34 is still weeks/months away.
I think after the regressions pass for HEAD on all the compilers (just to be on the safe side), adding to 1.34 would be painless. Of course, this is up to the release manager to allow this.
In short this is a no-go, for reasons already mentioned.
OK. Maybe we should make the "patch" available in the file vault (and maybe even mention about it in the docs/release notes). Regards, Arkadiy

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Arkadiy Vertleyb Sent: 28 December 2006 14:53 To: boost@lists.boost.org Subject: Re: [boost] [typeof] native implementation for msvc 8.0
"Thomas Witt" <witt@acm.org> wrote
In short this is a no-go, for reasons already mentioned.
Maybe we should make the "patch" available in the file vault (and maybe even mention about it in the docs/release notes).
I think this is significant enough to merit both of these - and to trigger an immediate release of 1.34.1 including just this addition. Of course, we also need to completely alter our release process as Beman says. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Steven Watanabe <steven@providere-consulting.com> writes:
AMDG
The following hack works with msvc 8.0 It appears that using another specialization of msvc_extract_type tricks the compiler's filter.
Excuse me if I squeal like a giddy schoolgirl. OMG this is so cool! -- Dave Abrahams Boost Consulting www.boost-consulting.com

Steven Watanabe wrote:
AMDG
The following hack works with msvc 8.0 It appears that using another specialization of msvc_extract_type tricks the compiler's filter.
This is unbelievable! Steven, you rock! Also with you in Christ, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (10)
-
Arkadiy Vertleyb
-
Beman Dawes
-
David Abrahams
-
Eric Niebler
-
Joel de Guzman
-
Paul A Bristow
-
Pavel Vozenilek
-
Peder Holt
-
Steven Watanabe
-
Thomas Witt