Changes to VS 2012 config
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012. The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features. If you see any problems, please let me know. -- Marshall
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know.
This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a little buggy). -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Wed, Nov 28, 2012 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know.
This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a little buggy).
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER. I'll see if I can find out more about their plans, too. --Beman
On Wed, Nov 28, 2012 at 9:59 PM, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Nov 28, 2012 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know.
This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a little buggy).
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
I'll see if I can find out more about their plans, too.
http://blogs.msdn.com/b/vcblog/archive/2012/11/26/visual-studio-2012-update-... A non-preview release is available too. It includes XP targetting, but not the latest features from the CTP release. But why wait until a compiler is actually released? -- Olaf
On 11/28/2012 12:59 PM, Beman Dawes wrote:
On Wed, Nov 28, 2012 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know. This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a little buggy). Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
I'll see if I can find out more about their plans, too.
My understanding is that they are releasing out-of-band releases for the compiler that are actual releases, not "just" CTPs. Herb Sutter's talk at the build conference in October very much suggested that there will be regular compiler and runtime library upgrades without having to wait for the next VS upgrade.
On 11/28/2012 5:16 PM, Timo H. Geusch wrote:
On 11/28/2012 12:59 PM, Beman Dawes wrote:
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
I'll see if I can find out more about their plans, too.
My understanding is that they are releasing out-of-band releases for the compiler that are actual releases, not "just" CTPs. Herb Sutter's talk at the build conference in October very much suggested that there will be regular compiler and runtime library upgrades without having to wait for the next VS upgrade.
Herb has been pretty clear about this. The CTP releases are what we'll get until the next major VS release, and the CTP releases are not intended for production use. I see this as mostly Microsoft trying to limit its liability. For Boost's purposes, I'd like to see us treat the CTP releases as full-fledged toolsets. I don't expect the CTPs will get bugfixes. We'll just get another CTP. But that's just a guess; don't quote me. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Herb has been pretty clear about this. The CTP releases are what we'll get until the next major VS release, and the CTP releases are not intended for production use. I see this as mostly Microsoft trying to limit its liability. For Boost's purposes, I'd like to see us treat the CTP releases as full-fledged toolsets. I don't expect the CTPs will get bugfixes. We'll just get another CTP. But that's just a guess; don't quote me. Haven't seen Herb's videos, but from the blog posts I've seen, that's not how it works. The CTPs are just that: community technical previews. In other words,
On 29.11.2012 03:25, Eric Niebler wrote: pre-betas. Eventually (like Update 1 just did) they will become out-of-band releases. The VS2012 IDE will remain the same, but either the toolset is updated or you get a new selectable platform toolset. Update 1 added a new toolset. Update 2 (or whatever they'll call the variadics update) might not, if the compiled part of the runtime remains the same (or if MS simply doesn't care to give their users the choice). So we should treat the Updates as releases for Boost, but the CTPs are just betas. We can support them in the trunk, but if the final release of that Update has changes, don't expect Boost to support the CTP variant. Sebastian
As a user, support for the XP targeting toolset in VS 2012 Update 1 would be extremely useful. Kind regards, Eoin On Thu, Nov 29, 2012 at 8:59 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 29.11.2012 03:25, Eric Niebler wrote:
Herb has been pretty clear about this. The CTP releases are what we'll get until the next major VS release, and the CTP releases are not intended for production use. I see this as mostly Microsoft trying to limit its liability. For Boost's purposes, I'd like to see us treat the CTP releases as full-fledged toolsets. I don't expect the CTPs will get bugfixes. We'll just get another CTP. But that's just a guess; don't quote me.
Haven't seen Herb's videos, but from the blog posts I've seen, that's not how it works. The CTPs are just that: community technical previews. In other words, pre-betas. Eventually (like Update 1 just did) they will become out-of-band releases. The VS2012 IDE will remain the same, but either the toolset is updated or you get a new selectable platform toolset. Update 1 added a new toolset. Update 2 (or whatever they'll call the variadics update) might not, if the compiled part of the runtime remains the same (or if MS simply doesn't care to give their users the choice). So we should treat the Updates as releases for Boost, but the CTPs are just betas. We can support them in the trunk, but if the final release of that Update has changes, don't expect Boost to support the CTP variant.
Sebastian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11/29/2012 12:59 AM, Sebastian Redl wrote:
On 29.11.2012 03:25, Eric Niebler wrote:
Herb has been pretty clear about this. The CTP releases are what we'll get until the next major VS release, and the CTP releases are not intended for production use. I see this as mostly Microsoft trying to limit its liability. For Boost's purposes, I'd like to see us treat the CTP releases as full-fledged toolsets. I don't expect the CTPs will get bugfixes. We'll just get another CTP. But that's just a guess; don't quote me.
Haven't seen Herb's videos, but from the blog posts I've seen, that's not how it works.
Link?
The CTPs are just that: community technical previews. In other words, pre-betas. Eventually (like Update 1 just did) they will become out-of-band releases. The VS2012 IDE will remain the same, but either the toolset is updated or you get a new selectable platform toolset. Update 1 added a new toolset. Update 2 (or whatever they'll call the variadics update) might not, if the compiled part of the runtime remains the same (or if MS simply doesn't care to give their users the choice). So we should treat the Updates as releases for Boost, but the CTPs are just betas. We can support them in the trunk, but if the final release of that Update has changes, don't expect Boost to support the CTP variant.
I'll be seeing Herb tomorrow. I'll ask him in person. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 11/29/2012 10:49 AM, Eric Niebler wrote:
On 11/29/2012 12:59 AM, Sebastian Redl wrote:
The CTPs are just that: community technical previews. In other words, pre-betas. Eventually (like Update 1 just did) they will become out-of-band releases. The VS2012 IDE will remain the same, but either the toolset is updated or you get a new selectable platform toolset. Update 1 added a new toolset. Update 2 (or whatever they'll call the variadics update) might not, if the compiled part of the runtime remains the same (or if MS simply doesn't care to give their users the choice). So we should treat the Updates as releases for Boost, but the CTPs are just betas. We can support them in the trunk, but if the final release of that Update has changes, don't expect Boost to support the CTP variant.
I'll be seeing Herb tomorrow. I'll ask him in person.
So here's the scoop from Herb. There are two separate things: the rolling releases (like the just-released Update 1 which added XP support to VS'12), and the CTP releases (like the one that just that added variadic templates to the compiler). The former are officially supported, go-live products; the latter are not. There is, and should be, *no expectation* that the features delivered in the CTP releases will ever make it into the officially supported updates. On other words, we should operate under the assumption that there will be no improvements in C++11 compliance of any officially supported Microsoft compiler until the next major release of Visual Studio. I worded that very carefully. I believe it is 100% accurate. I will be directing Herb's attention to this thread so that he can comment if I got anything wrong. What that means for Boost is up for us to decide. But given the above, I think it would be wise for us to add support for the CTP releases to Boost.Config using _MSC_FULL_VER so that we don't have to wait until VS.Next to start taking advantage of variadic templates (for example). -- Eric Niebler BoostPro Computing http://www.boostpro.com
On December 1, 2012 9:34:41 AM Eric Niebler <eric@boostpro.com> wrote:
So here's the scoop from Herb. There are two separate things: the rolling releases (like the just-released Update 1 which added XP support to VS'12), and the CTP releases (like the one that just that added variadic templates to the compiler). The former are officially supported, go-live products; the latter are not. There is, and should be, *no expectation* that the features delivered in the CTP releases will ever make it into the officially supported updates.
On other words, we should operate under the assumption that there will be no improvements in C++11 compliance of any officially supported Microsoft compiler until the next major release of Visual Studio.
I worded that very carefully. I believe it is 100% accurate. I will be directing Herb's attention to this thread so that he can comment if I got anything wrong.
What that means for Boost is up for us to decide. But given the above, I think it would be wise for us to add support for the CTP releases to Boost.Config using _MSC_FULL_VER so that we don't have to wait until VS.Next to start taking advantage of variadic templates (for example).
I disagree. If CTP is not an indication of a feature support in the official compiler, why should we support it? Adding workarounds for CTP bugs is probably reasonable but not new features. OTOH the rolloing releases give new features the official status, and we can be sure they won't disappear.
01.12.2012 11:20, Andrey Semashev пишет:
I disagree. If CTP is not an indication of a feature support in the official compiler, why should we support it? Because this will allow us to test the implementation of the new compiler features as early as possible. For example, if the decltype support had been tested by Boost before the MSVC2012 release it would have been found buggy earlier and we wouldn't have had to add the decltype-related workaround for the VC11 to the Boost.
Earlier test -> earlier bugreport -> earlier bugfix -> no workaround.
Adding workarounds for CTP bugs is probably reasonable but not new features. OTOH the rolloing releases give new features the official status, and we can be sure they won't disappear. CTP is a preview. The community (i.e., we) should test it and tell MS about any bugs found and especially about bugs in the new features. But I don't think that we should make workarounds or support the previews in any other way.
-- Best regards, Sergey Cheban
On December 1, 2012 3:59:04 PM Sergey Cheban <s.cheban@drweb.com> wrote:
01.12.2012 11:20, Andrey Semashev пишет:
I disagree. If CTP is not an indication of a feature support in the official compiler, why should we support it? Because this will allow us to test the implementation of the new compiler features as early as possible. For example, if the decltype support had been tested by Boost before the MSVC2012 release it would have been found buggy earlier and we wouldn't have had to add the decltype-related workaround for the VC11 to the Boost.
Earlier test -> earlier bugreport -> earlier bugfix -> no workaround.
Adding workarounds for CTP bugs is probably reasonable but not new features. OTOH the rolloing releases give new features the official status, and we can be sure they won't disappear. CTP is a preview. The community (i.e., we) should test it and tell MS about any bugs found and especially about bugs in the new features. But I don't think that we should make workarounds or support the previews in any other way.
While I welcome C++11 adoption, I don't see Boost as a testbed for MSVC or any other particular implementation. Yes, in many ways Boost is on the bleeding edge of the language so it's tempting to test against it. But Boost is just a library and it has users. And actually MS is able to build and test Boost with their compiler themselves, be that an internal build or CTP or an official release. Boost is developed by volunteers and adding another platform to the list of supported platforms increases the burden. The most obvious increase is testing on the new platform and updating configuration. Less obvious are workarounds for bugs and incomplete features in the libraries. Decltype is a good example of this: it is supported but it's "not quite there" yet, which results in more and more config macros to test for in the libraries. I'm not demanding a compllete support for every feature in every official compiler release, that's hardly possible. But supporting CTPs or betas or whatever increases the granularity of such "not quite there" things which in turn makes supporting code harder. However, I don't mind if someone volunteers to test Boost on CTP and report problems back to MS. This won't make CTP the supported platform and Boost development won't be affected. I just think it's MS's job to do the testing as long as they sell MSVC as a product.
01.12.2012 16:56, Andrey Semashev пишет:
CTP is a preview. The community (i.e., we) should test it and tell MS about any bugs found and especially about bugs in the new features. But I don't think that we should make workarounds or support the previews in any other way.
While I welcome C++11 adoption, I don't see Boost as a testbed for MSVC or any other particular implementation. Yes, in many ways Boost is on the bleeding edge of the language so it's tempting to test against it. But Boost is just a library and it has users. And actually MS is able to build and test Boost with their compiler themselves, be that an internal build or CTP or an official release. I think it's a good idea for MS to test their compiler with boost regression tests with workarounds turned off. Unfortunately, they are not always able to do it by themselves. For example, implementing decltype-based result_of has required some work from the boost::phoenix developers.
Boost is developed by volunteers and adding another platform to the list of supported platforms increases the burden. I agree that CTPs should not be supported. But it would be good to "view" them and do our part of work as soon as possible.
However, I don't mind if someone volunteers to test Boost on CTP and report problems back to MS. This won't make CTP the supported platform and Boost development won't be affected. I just think it's MS's job to do the testing as long as they sell MSVC as a product. I think it is useless to use the CTPs for those who are not planning to report the bugs to the MS. So, only those who are playing these games will be affected by the CTP-related changes in the Boost.
-- Best regards, Sergey Cheban
On 1 December 2012 05:34, Eric Niebler <eric@boostpro.com> wrote:
On other words, we should operate under the assumption that there will be no improvements in C++11 compliance of any officially supported Microsoft compiler until the next major release of Visual Studio.
[snip]
What that means for Boost is up for us to decide. But given the above, I think it would be wise for us to add support for the CTP releases to Boost.Config using _MSC_FULL_VER so that we don't have to wait until VS.Next to start taking advantage of variadic templates (for example).
Maybe we should make support of CTP features optional, i.e. we only use the feature if the user sets a macro. That way, the default build won't break if a feature is removed.
On Sat, Dec 1, 2012 at 6:34 AM, Eric Niebler <eric@boostpro.com> wrote:
So here's the scoop from Herb. There are two separate things: the rolling releases (like the just-released Update 1 which added XP support to VS'12), and the CTP releases (like the one that just that added variadic templates to the compiler). The former are officially supported, go-live products; the latter are not. There is, and should be, *no expectation* that the features delivered in the CTP releases will ever make it into the officially supported updates.
We also shouldn't expect those features not to be part of a supported update. XP support was also released as CTP (preview) before it was released as Update 1.
On other words, we should operate under the assumption that there will be no improvements in C++11 compliance of any officially supported Microsoft compiler until the next major release of Visual Studio.
That'd be very, very disappointing. -- Olaf
(Follow-up from Herb posted below.) On 11/30/2012 9:34 PM, Eric Niebler wrote:
So here's the scoop from Herb. There are two separate things: the rolling releases (like the just-released Update 1 which added XP support to VS'12), and the CTP releases (like the one that just that added variadic templates to the compiler). The former are officially supported, go-live products; the latter are not. There is, and should be, *no expectation* that the features delivered in the CTP releases will ever make it into the officially supported updates.
On other words, we should operate under the assumption that there will be no improvements in C++11 compliance of any officially supported Microsoft compiler until the next major release of Visual Studio.
I worded that very carefully. I believe it is 100% accurate. I will be directing Herb's attention to this thread so that he can comment if I got anything wrong.
What that means for Boost is up for us to decide. But given the above, I think it would be wise for us to add support for the CTP releases to Boost.Config using _MSC_FULL_VER so that we don't have to wait until VS.Next to start taking advantage of variadic templates (for example).
And as promised, here is the follow-up from Herb: Herb Sutter wrote:
I think you said it right, the only things I wanted to add were that:
- I'm not recommending either for or against Boost making the CTP a target of interest for Boost. My $0.02 would be you probably wouldn't want to expend that effort since it's just a CTP.
- As I said in my Feb talk, these are "out-of-band (OOB)" CTPs to give people a look at our C++11 progress. Our goal is to try to "go dark" less on customers, and to enable earlier feedback (too often we had an all-too-short time between beta and release to respond to feedback, and this will help).
- The CTP is a separate stream from the new VS Update releases. It's yet TBD whether these will roll into a future VS Update, but since that hasn't been announced you shouldn't count it. DO however count on CTP features being in the next VC++ compiler release -- including betas, and recall our betas sometimes come with a go-live license, as VC++ 2012 beta did this year for example.
- Don't assume "next release of VC++" means the historical "wait two years for the feature to appear in a product." As generally announced, Visual Studio is moving to faster update cycles, which means you should NOT expect to wait the historically-usual two years for these features to appear in a product release. (Though note that we haven't announced any release dates yet for VC++ vNext.)
- As I said in my November talk, we promised to share more conformance news in first half of 2013.
Whether to support the CTP releases in Boost.Config is still an open question. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Dec 4, 2012 at 6:15 AM, Eric Niebler <eric@boostpro.com> wrote:
[SNIPPED]
Whether to support the CTP releases in Boost.Config is still an open question.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At the very least I think that adding toolset support for it in Boost.Build would be hugely beneficial to users (though I'm not sure how that would work... msvc-ctp perhaps?). It would enable people who use Boost.Build as the build system for their project(s) to easily test their code under the CTP.* Whether to add support for the CTP in Boost.Config is a different issue however. * I'm aware that you can still do it if you run the Developer Command Prompt then set up the PATH and INCLUDE environmental variables yourself, but having automatic support in Boost.Build would be nice.
On Tue, Dec 04, 2012 at 06:50:59AM +1100, Joshua Boyce wrote:
On Tue, Dec 4, 2012 at 6:15 AM, Eric Niebler <eric@boostpro.com> wrote:
[SNIPPED]
Whether to support the CTP releases in Boost.Config is still an open question.
At the very least I think that adding toolset support for it in Boost.Build would be hugely beneficial to users (though I'm not sure how that would work... msvc-ctp perhaps?). It would enable people who use Boost.Build as the build system for their project(s) to easily test their code under the CTP.* Whether to add support for the CTP in Boost.Config is a different issue however.
* I'm aware that you can still do it if you run the Developer Command Prompt then set up the PATH and INCLUDE environmental variables yourself, but having automatic support in Boost.Build would be nice.
In particular, having autolinking and tagging working as intended would be very nice, no matter if it's a CTP or OOB update. I'm currently blocked from moving to the v110_xp toolset from v100 due to the lack of support in it in Boost.Build. Have we've agreed yet in the thread that the non-CTP updates _shall_ be implemented eventually? -- Lars Viklund | zao@acc.umu.se
On Dec 3, 2012, at 11:56 AM, Lars Viklund <zao@acc.umu.se> wrote:
On Tue, Dec 04, 2012 at 06:50:59AM +1100, Joshua Boyce wrote:
On Tue, Dec 4, 2012 at 6:15 AM, Eric Niebler <eric@boostpro.com> wrote:
[SNIPPED]
Whether to support the CTP releases in Boost.Config is still an open question.
At the very least I think that adding toolset support for it in Boost.Build would be hugely beneficial to users (though I'm not sure how that would work... msvc-ctp perhaps?). It would enable people who use Boost.Build as the build system for their project(s) to easily test their code under the CTP.* Whether to add support for the CTP in Boost.Config is a different issue however.
* I'm aware that you can still do it if you run the Developer Command Prompt then set up the PATH and INCLUDE environmental variables yourself, but having automatic support in Boost.Build would be nice.
In particular, having autolinking and tagging working as intended would be very nice, no matter if it's a CTP or OOB update.
I'm currently blocked from moving to the v110_xp toolset from v100 due to the lack of support in it in Boost.Build. Have we've agreed yet in the thread that the non-CTP updates _shall_ be implemented eventually?
I'm actually working on those. I _believe_ that I've got the library specific bits correct - but would appreciate a second (or third) set of eyes on them. [ They were checked into the trunk in r81613 ] The second half is to match up the compiler capabilities. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 03.12.2012, at 20:15, Eric Niebler wrote:
Whether to support the CTP releases in Boost.Config is still an open question.
Thank you for the detailed response from Herb. My opinion is that we shouldn't support them. The features in the CTPs appear to be rather buggy still (when STL did a talk showing off the new features he stumbled upon one bug himself, and a commenter pointed out another), so the options would be either to mark features as enabled that don't work very well yet (bad idea), or add additional config macros to indicate that the compiler sort-of supports the features (worse idea). If we decide to support the CTPs, I think we should only mark features as supported where some testing has shown that they are largely bug-free. Sebastian
On 29/11/12 13:25, Eric Niebler wrote:
On 11/28/2012 5:16 PM, Timo H. Geusch wrote:
On 11/28/2012 12:59 PM, Beman Dawes wrote:
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
I'll see if I can find out more about their plans, too.
My understanding is that they are releasing out-of-band releases for the compiler that are actual releases, not "just" CTPs. Herb Sutter's talk at the build conference in October very much suggested that there will be regular compiler and runtime library upgrades without having to wait for the next VS upgrade.
Herb has been pretty clear about this. The CTP releases are what we'll get until the next major VS release, and the CTP releases are not intended for production use. I see this as mostly Microsoft trying to limit its liability. For Boost's purposes, I'd like to see us treat the CTP releases as full-fledged toolsets.
I don't expect the CTPs will get bugfixes. We'll just get another CTP. But that's just a guess; don't quote me.
Does this mean we'll have to have workarounds for every single CTP?
Does this mean we'll have to have workarounds for every single CTP? I think that it's reasonable to support CTPs in the boost/config.hpp and enable (and test!) the C++11 features immediately after they apperar in
On 29.11.2012 14:45, Jookia wrote: the compiler. This would help MS to improve the compiler. I don't think that it is a good idea to implement any workarounds for the bugs in the compiler betas. The workarounds hide the bugs, and the purpose of the beta releases is to find the bugs before the actual release. -- Sergey Cheban
On Wed, Nov 28, 2012 at 3:59 PM, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Nov 28, 2012 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know.
This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a little buggy).
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
... Many messages later...
Summary: there was a lot of unhappiness with the proposal to treat the CTP features as enabled since these features are not yet supported and are known to have a relatively high number of bugs. OTOH, some folks do want to use the shinny new C++ CTP features, if only to test. Someone (sorry, I can't find the message) suggested that we do report the features as present, but only when _MSC_FULL_VER is greater or equal the CTP full version number && defined(BOOST_ENABLE_MSVC_2012_NOV_CTP). That will allow those of us who do want the feature macros to be useable to do so, without getting in other folks way. If there aren't strong objections, I'd like go ahead with that proposal. The actual name of the macro is subject to change, of course, if someone has a better name. IIRC, the feature macros involved are: BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS BOOST_NO_CXX11_HDR_INITIALIZER_LIST BOOST_NO_CXX11_RAW_LITERALS BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX BOOST_NO_CXX11_VARIADIC_TEMPLATES Comments? --Beman
So, to enable CTP support, one would simply build with BOOST_ENABLE_MSVC_2012_NOV_CTP defined, yes? Charles Wilson Senior Software Development Engineer Dell | Enterprise Solutions Group
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Monday, January 14, 2013 2:59 PM To: boost@lists.boost.org Subject: Re: [boost] Changes to VS 2012 config
On Wed, Nov 28, 2012 at 1:36 PM, Eric Niebler <eric@boostpro.com> wrote:
On 11/28/2012 8:44 AM, Marshall Clow wrote:
Just so people know - I'm updating the Visual Studio configuration to more accurately reflect the capabilities of VS 2012.
The first step was in http://svn.boost.org/trac/boost/changeset/81613 ; the next step will be to update the compiler features.
If you see any problems, please let me know.
This is great Marshall. Thanks for doing this. Will there be any effort made to support the rolling CTP releases of the MS compiler? The latest CTP has variadic templates, for instance (although they're a
On Wed, Nov 28, 2012 at 3:59 PM, Beman Dawes <bdawes@acm.org> wrote: little buggy).
Historically we didn't add config support until a compiler was actually released. But if Microsoft is going to be adding features just via rolling CTP releases, with no formal release for several years, I'd like to see us add the CTP features based on _MSC_FULL_VER. Note that the CTP released didn't bump _MSC_VER.
... Many messages later...
Summary: there was a lot of unhappiness with the proposal to treat the CTP features as enabled since these features are not yet supported and are known to have a relatively high number of bugs. OTOH, some folks do want to use the shinny new C++ CTP features, if only to test.
Someone (sorry, I can't find the message) suggested that we do report the features as present, but only when _MSC_FULL_VER is greater or equal the CTP full version number && defined(BOOST_ENABLE_MSVC_2012_NOV_CTP). That will allow those of us who do want the feature macros to be useable to do so, without getting in other folks way.
If there aren't strong objections, I'd like go ahead with that proposal. The actual name of the macro is subject to change, of course, if someone has a better name.
IIRC, the feature macros involved are:
BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS BOOST_NO_CXX11_HDR_INITIALIZER_LIST BOOST_NO_CXX11_RAW_LITERALS BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX BOOST_NO_CXX11_VARIADIC_TEMPLATES
Comments?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jan 14, 2013 at 5:17 PM, Beman Dawes <bdawes@acm.org> wrote:
On Mon, Jan 14, 2013 at 4:05 PM, <Charles_J_Wilson@dell.com> wrote:
So, to enable CTP support, one would simply build with BOOST_ENABLE_MSVC_2012_NOV_CTP defined, yes?
Correct. The compiler also has to have the CTP _MSC_FULL_VER or later value
Committed to trunk. The macro name ended up being BOOST_MSVC_ENABLE_2012_NOV_CTP. Here is the commit message: Add BOOST_MSVC_ENABLE_2012_NOV_CTP macro to allow users to explicitly enable use of VC++ November 2012 Community Technology Preview. C++11 features supplied by this CTP are not enabled by default since they represent unsupported alpha-level code that should not be used for production work. --Beman
participants (14)
-
Andrey Semashev -
Beman Dawes -
Charles_J_Wilson＠Dell.com -
Daniel James -
Eoin O'Callaghan -
Eric Niebler -
Jookia -
Joshua Boyce -
Lars Viklund -
Marshall Clow -
Olaf van der Spek -
Sebastian Redl -
Sergey Cheban -
Timo H. Geusch