TR1 Fixes In VC9 SP1

TR1 Fixes In VC9 SP1 | Easycoded

TR1 Fixes In VC9 SP1 | Easycoded — Mon, 11 Aug 2008 22:53:58 GMT

PingBack from http://www.easycoded.com/tr1-fixes-in-vc9-sp1

re: TR1 Fixes In VC9 SP1

Adam C Merz — Mon, 11 Aug 2008 23:00:38 GMT

Out of curiousity, was any performance testing of tr1::regex done comparing to boost::xpressive rather than boost::regex? Given the introduction of boost::xpressive, boost::regex strikes me as a legacy library, only useful for a mostly-TR1-compatible API.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Tue, 12 Aug 2008 00:29:28 GMT

Remember that <regex> is part of the C++0x Standard Library, so I'd hardly call it "legacy".

I wasn't familiar with Boost.Xpressive, although from glancing at its documentation it appears to be extremely powerful. I'll look at it for future performance comparisons, thanks.

STL/CLR fixed?

someone — Tue, 12 Aug 2008 01:05:34 GMT

STL/CLR is embarrassingly slow compared to BCL. Has this been addressed?

re: TR1 Fixes In VC9 SP1

int19h — Tue, 12 Aug 2008 08:21:20 GMT

All good stuff. I wish the trait framework used to mark classes for swap optimization was public and documented, though, so we could use it for our own (unportable, obviously - though nothing an #ifdef can't alleviate - but sometimes performance is more important).

re: TR1 Fixes In VC9 SP1

hito — Tue, 12 Aug 2008 10:17:12 GMT

SP1's unordered_set is horribly slow compare to boost::unordered_set or even std::set.

and worse, it's destructer is unbelievably slow.

but if i called clear() before destructer is called, it is not so slow.

re: TR1 Fixes In VC9 SP1

MR — Tue, 12 Aug 2008 16:39:06 GMT

Does anyone have a sense of how TR1 regex compares to the exiting ATL regex implementation (CAtlRegExp)? From a performance and or functional perspective?

Visual Studio Links #64

Visual Studio Hacks — Tue, 12 Aug 2008 17:10:51 GMT

My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. Yesterday, Visual Studio 2008 SP1 and .Net 3.5 SP1 were released. Below is a list of links related to those releases: Greg Duncan

re: TR1 Fixes In VC9 SP1

Richard Webb — Tue, 12 Aug 2008 19:01:58 GMT

Hi,

I've run the Boost regression tests with SP1 final and a lot of the TR1 failures i was seeing before have been fixed, but there are still a couple left.

For example, there is a problem with a missing result_type definition in Bind (http://tinyurl.com/5myz9f). You previously mentioned (http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-feature-pack-released.aspx#8405685) that this was a known bug, so did it not get fixed in SP1?

Thanks,

Richard Webb

re: TR1 Fixes In VC9 SP1

Adam C Merz — Tue, 12 Aug 2008 19:40:46 GMT

Re: boost::regex -- by "legacy" I mean, if you're using Boost, then presumably you want something better than what's in the standard; because <regex> is standard in C++0x/TR1, I'd call boost::regex legacy since it doesn't offer much beyond what the standard already has. boost::xpressive, on the other hand, does have quite an advantage over <regex> in terms of design and performance, especially in regards to static expressions.

re: TR1 Fixes In VC9 SP1

jmm — Tue, 12 Aug 2008 20:20:55 GMT

Your post lists the 16 fixes for TR1, but what about the 60 fixes for MFC? Is there a post or article somewhere about these?

re: TR1 Fixes In VC9 SP1

jmm — Tue, 12 Aug 2008 20:49:55 GMT

I went to the official page for Microsoft Visual Studio 2008 Service Pack 1 (exe), which is: http://www.microsoft.com/downloads/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

At the bottom, within section [Related Resources], I clicked on:

2. Fixes included in this Service Packs (KB945140)

This gave me [Visual Studio 2008 Service Pack 1 Beta release notes and a list of fixed issues], which was published April 29, 2008.

Hopefully the actual fix list is posted sometime. Info on the MFC fixes would be great too.

re: TR1 Fixes In VC9 SP1

Pat Brenner — Wed, 13 Aug 2008 02:25:55 GMT

Hi all,

I've just posted a summary of the bugs that we fixed in MFC for VS2008 SP1. See it here: http://blogs.msdn.com/vcblog/archive/2008/08/12/bugs-fixed-in-mfc-in-visual-studio-2008-sp1.aspx

Pat Brenner

Visual C++ Libraries Development

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Wed, 13 Aug 2008 02:54:22 GMT

[int19h]

> I wish the trait framework used to mark classes for swap optimization

> was public and documented, though, so we could use it for our own

> (unportable, obviously - though nothing an #ifdef can't alleviate - but

> sometimes performance is more important).

This is probably as documented as it'll get. See below for my utterly unsupported example.

[hito]

> SP1's unordered_set is horribly slow compare to boost::unordered_set or even std::set.

> and worse, it's destructer is unbelievably slow.

> but if i called clear() before destructer is called, it is not so slow.

Please file bugs with specific test cases through Microsoft Connect. We've identified one major performance problem in tr1::unordered_set; erase() doesn't achieve its required complexity.

(I thought Boost 1.35.0 hadn't implemented the unordered containers yet; see http://www.boost.org/doc/libs/1_35_0/doc/html/boost_tr1.html .)

[MR]

> Does anyone have a sense of how TR1 regex compares to the exiting ATL regex implementation (CAtlRegExp)?

> From a performance and or functional perspective?

CAtlRegExp, along with the rest of ATL Server, was removed from VC9.

Hopefully, TR1 Regex outperforms CAtlRegExp, but we haven't done any performance comparisons there. From a usability perspective, TR1 Regex wins hands down.

[Richard Webb]

> I've run the Boost regression tests with SP1 final and a lot of the TR1

> failures i was seeing before have been fixed, but there are still a couple left.

> For example, there is a problem with a missing result_type definition in Bind

> (http://tinyurl.com/5myz9f). You previously mentioned

> (http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-feature-pack-released.aspx#8405685)

> that this was a known bug, so did it not get fixed in SP1?

Correct; this was postponed to VC10.

And here's that example for int19h:

C:\Temp>type meow.cpp

#include <iostream>

#include <ostream>

#include <vector>

using namespace std;

namespace feline {

struct kitty {

kitty() { cout << "default ctor" << endl; }

kitty(const kitty&) { cout << "copy ctor" << endl; }

kitty& operator=(const kitty&) { cout << "assign" << endl; return *this; }

~kitty() { cout << "dtor" << endl; }

void swap(kitty&) { cout << "swap" << endl; }

};

void swap(kitty& a, kitty& b) { a.swap(b); }

}

// Specific to VC9 SP1 and above.

// This machinery was broken for classes outside namespace std in VC9 RTM and below.

// This machinery will not be present in VC10 and above.

#if defined(_MSC_VER) && _MSC_VER == 1500 && _MSC_FULL_VER >= 150030729

#include <xutility>

namespace std {

template <> class _Move_operation_category<feline::kitty> {

public:

typedef _Swap_move_tag _Move_cat;

};

}

#endif

int main() {

vector<feline::kitty> v;

cout << "*** Constructing cat." << endl;

feline::kitty cat;

cout << "*** Pushing back cat #1." << endl;

v.push_back(cat);

cout << "*** Pushing back cat #2." << endl;

v.push_back(cat);

cout << "*** Destroying cat and v." << endl;

}

C:\Temp>cl /EHsc /nologo /W4 meow.cpp

meow.cpp

C:\Temp>meow

*** Constructing cat.

default ctor

*** Pushing back cat #1.

copy ctor

default ctor

dtor

default ctor

dtor

*** Pushing back cat #2.

copy ctor

default ctor

copy ctor

swap

dtor

default ctor

dtor

*** Destroying cat and v.

dtor

Note that the Swaptimization requires a default ctor.

re: TR1 Fixes In VC9 SP1

int19h — Wed, 13 Aug 2008 12:49:53 GMT

Thank you.

Hopefully, VC10 will see C++0x finalized and implemented, with its move constructors and all, so we won't need this hack by that time.

re: TR1 Fixes In VC9 SP1

Richard Webb — Wed, 13 Aug 2008 20:16:02 GMT

>>>>>>>>>>>>>>>

(I thought Boost 1.35.0 hadn't implemented the unordered containers yet; see http://www.boost.org/doc/libs/1_35_0/doc/html/boost_tr1.html .)

>>>>>>>>>>>>>>>

It didn't - they're new in 1.36, due any day now.

See http://beta.boost.org/users/news/version_1_36_0

re: TR1 Fixes In VC9 SP1

KluYa — Thu, 14 Aug 2008 09:08:45 GMT

I see a lot of things are being remanded to VC10. Is there any timeframe on when VC10 will hit? Late 2009, early 2010?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Thu, 14 Aug 2008 23:41:02 GMT

[KluYa]

> I see a lot of things are being remanded to VC10.

I'd say "some", not "a lot", except wrt <functional> and especially bind(). Only one bugfix was deliberately kept out of VC9 SP1 (this was the fairly extensive fix for the <memory> _InterlockedFoo problem, which was too risky for a service pack).

> Is there any timeframe on when VC10 will hit?

We're not talking about that yet.

Stephan T. Lavavej, Visual C++ Libraries Developer

re: TR1 Fixes In VC9 SP1

mikeb — Fri, 15 Aug 2008 23:39:13 GMT

You said: "So, within a class that defines a member swap(), calling unqualified swap() doesn't activate ADL, nor does it even find std::swap() - it finds the member swap()"

Does that mean the Scott Meyers' Item 25 in Effective C++ 3rd Ed. should be amended so that:

- in a class that has a member swap(), instead of having a "using std::swap" declaration and directly calling an unqualified swap()

it should:

- call a wrapper non-member template function that has a "using std::swap" declaration and calls an unqualified swap() - ie., our own implementation of std::_Swap_adl() that's not in the std namespace and doesn't start with an '_'?

It sounds like to be safe we should always call this non-member wrapper template function instead of calling swap(T&, T&) directly.

Jeez - this name lookup stuff is so convoluted, I'm not even sure if this question makes any sense.

VC9 SP1: problems with tr1::function?

grokbrsm — Sat, 16 Aug 2008 00:25:05 GMT

The following code breaks with an access violation when executing line

(*i)(tmp);

after an update to VC9 SP1. It works fine with RTM and even SP1 beta. Verified on two different machines, one (win XP x64) that had the beta, the other that didn't (win XP 32 bits).

---------------------

#include <iostream>

#include <vector>

#include <functional>

struct my_class

{

void f() { std::cout << "my_class::f()" << std::endl; }

};

void g(my_class x)

{

std::cout << "g(my_class)" << std::endl;

}

struct h

{

void operator()(my_class) const {

std::cout << "h::operator()(my_class)" << std::endl;

}

};

int main()

{

typedef std::tr1::function<void(my_class)> F;

std::vector<F> ops;

ops.push_back(&my_class::f);

ops.push_back(&g);

ops.push_back(h());

my_class tmp;

for (std::vector<F>::iterator i = ops.begin(); i != ops.end(); i++)

{

(*i)(tmp);

}

-------------------------

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Sat, 16 Aug 2008 00:38:45 GMT

> It sounds like to be safe we should always call this non-member wrapper template function instead of calling swap(T&, T&) directly.

According to my understanding, yes.

(Also according to my understanding, accidentally getting member swap is not particularly dangerous, as member swap will be one-arg while free swap is two-arg. It's accidentally getting general swap that's dangerous, as it'll compile but run slowly.)

I believe that Boost has their own swap wrapper for precisely this purpose.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Sat, 16 Aug 2008 01:23:48 GMT

[grokbrsm]

> VC9 SP1: problems with tr1::function?

A bazillion thanks for the bug report!

I've confirmed this. The underlying problem is that when we implemented the Small Functor Optimization, tr1::function::swap() wasn't updated accordingly. This was broken in the Feature Pack, and no one noticed. But now that the Swaptimization works for vector<function<FT> >, that's broken too. Profoundly awful, as vector-of-function is so powerful.

I'll file a bug and get this fixed in VC10.

re: TR1 Fixes In VC9 SP1

grokbrsm — Sat, 16 Aug 2008 09:09:18 GMT

Well the SP1 problems with std::vector of tr1::function render tr1 almost useless as far as I am concerned, which is a shame since the integration of tr1 containers in the debugger is something I would not want to lose (therefore I would not like to use boost instead of the MSVC impl)... Is it possible to fix or work around the problem through a small modification of tr1 headers? If I understand correctly, all the tr1::function is implemented in headers.

re: TR1 Fixes In VC9 SP1

grokbrsm — Sat, 16 Aug 2008 19:08:27 GMT

Well, I found a fix for the std::vector of tr1::function issue. in xxfunction, replace

void _Swap(_Myt& _Right)

{

(...)

}

void _Swap(_Myt& _Right)

{ // swap contents with contents of _Right

bool _right_is_local = (void *)_Right._Impl == (void *)&_Right._Space;

bool _this_is_local = (void *)_Impl == (void *)&_Space;

if (_right_is_local || _this_is_local)

{

_STD swap(_Space, _Right._Space);

}

_Ptrt *_Timpl = _Right._Impl;

_Right._Impl = _this_is_local?((_Ptrt *)&_Right._Space):_Impl;

_Impl = _right_is_local?((_Ptrt *)&_Space):_Timpl;

}

I'd be glad to know if this really works as expected in every situation.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Mon, 18 Aug 2008 22:11:40 GMT

grokbrsm:

> I'd be glad to know if this really works as expected in every situation.

It doesn't. (A functor can own an object which has a pointer back to the functor.)

We strongly advise against header-hacking, as it has the potential to make your Visual Studio installation unpatchable.

There are a few things that you can do:

1. Use boost::function. It's not like tr1::function has a useful visualizer anyways. (I wrote all of the TR1 visualizers, and they are as detailed as possible; unfortunately, the visualizer machinery can't see through a pointer-to-base, which is what powers tr1::function, so it's visualized with either "empty" or "full".)

2. Write a wrapper:

C:\Temp>type meow.cpp

#include <functional>

#include <iostream>

#include <ostream>

#include <vector>

template <typename FT> struct fxn {

fxn() : m_f() { }

fxn(int) : m_f() { }

template <typename F> fxn(F f) : m_f(f) { }

fxn(const fxn& other) : m_f(other.m_f) { }

fxn& operator=(int) {

m_f = 0;

return *this;

}

template <typename F> fxn& operator=(F f) {

m_f = f;

return *this;

}

fxn& operator=(const fxn& other) {

m_f = other.m_f;

return *this;

}

std::tr1::function<FT> m_f;

};

int add(int x, int y) {

return x + y;

}

int mult(int x, int y, int z) {

return x * y * z;

}

int main() {

using namespace std;

using namespace std::tr1;

using namespace std::tr1::placeholders;

vector<fxn<int (int, int)> > v;

v.push_back(add);

v.push_back(bind(mult, _1, _2, 10));

v.push_back(minus<int>());

for (vector<fxn<int (int, int)> >::const_iterator i = v.begin(); i != v.end(); ++i) {

cout << i->m_f(3, 4) << endl;

}

C:\Temp>cl /EHsc /nologo /W4 meow.cpp

meow.cpp

C:\Temp>meow

120

-1

(This wrapper attempts to look like tr1::function for the purposes of construction and assignment, but otherwise requires you to use m_f.)

3. Request a hotfix.

re: TR1 Fixes In VC9 SP1

grokbrsm — Mon, 18 Aug 2008 23:33:00 GMT

> It doesn't. (A functor can own an object which has a pointer back to the functor.)

Could you give a hint at when this can occur? If I understand correctly, in that case that pointer should be updated to point to the correct functor object, and obviously this does not happen with the code I posted.

The wrapper trick works because it prevents the "swaptimization"?

Thanks a lot for your detailed and insightful answers.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Tue, 19 Aug 2008 00:43:13 GMT

> Could you give a hint at when this can occur?

That's just a pathological example that I thought up.

> If I understand correctly, in that case that

> pointer should be updated to point to the correct

> functor object, and obviously this does not happen

> with the code I posted.

The problem is that your code is performing a bitwise copy of the stored functor, which can mangle non-PODs. To be truly correct, function::swap() must copy construct and destroy the stored functor. I now have a fix that does exactly this.

> The wrapper trick works because it prevents

> the "swaptimization"?

Bingo.

re: TR1 Fixes In VC9 SP1

Michael Marcin — Tue, 19 Aug 2008 02:22:06 GMT

I have some legacy code that uses boost::shared_ptr in std containers.

Will I have to convert that to std::tr1::shared_ptr to get the vector realloc with no reference count manipulation or does it rely purely on adl and thus should work as is by choosing the boost::swap overload for shared_ptr?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Tue, 19 Aug 2008 03:07:23 GMT

You'll either have to use tr1::shared_ptr, or partially specialize std::_Move_operation_category to annotate boost::shared_ptr as fast-swappable. There's no way to automatically detect fast-swappable types; they have to be annotated as such.

(If you partially specialize std::_Move_operation_category, you'll want to do so as early as possible. 14.7.3/7: "When writing a specialization, be careful about its location; or to make it compile will be such a trial as to kindle its self-immolation." If I were doing that, I'd forward-declare boost::shared_ptr and partially specialize std::_Move_operation_category at the top of my PCH, before anything else has a chance to instantiate vector<boost::shared_ptr<T> >.)

re: TR1 Fixes In VC9 SP1

Pierre B. — Tue, 19 Aug 2008 23:01:02 GMT

Wow! Very interesting. It's also very depressing that the chance of getting user-written template to work properly is very low. The amount of work-around needed to avoid all the gotchas of overloading, specialization, name lookup, makes it unlikely mere mortal can get it right.

re: TR1 Fixes In VC9 SP1

mikeb — Tue, 19 Aug 2008 23:21:01 GMT

"will be such a trial as to kindle its self-immolation."

Haha - I thought for sure that you were paraphrasing the standard for effect. But I see that "self-immolation" even made it into the index twice - once for "self-immolation", and again for "immolation, self"!

re: TR1 Fixes In VC9 SP1

Kris — Tue, 19 Aug 2008 23:54:29 GMT

Great post. Last time I talked with you was in the nuwen IRC probably 5 years ago when you were about to leave to work on Outlook at MS. VC++ Library Developer? Nice.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Wed, 20 Aug 2008 00:16:49 GMT

Pierre B.:

Actually, it's easy for users to use templates (including the Standard Library), and it's not terribly difficult to write templates with a moderate level of genericity.

What's difficult is implementing the Standard Library - the trick here was picking up user-defined swaps, which is an extreme level of customizability.

Note that the rules for getting your user-defined swaps to be picked up are easy: merely package them in the same namespace as your classes, which is the usual level of ADL cleanliness that you should be striving for (see Item 58 of C++ Coding Standards by Sutter and Alexandrescu for the full story).

mikeb:

Did you notice that it's a limerick? (I noticed the rhyming pattern when I first saw it, but didn't realize it was a limerick until someone else pointed it out to me.)

Kris:

Yup, I was an Outlook Search Dev in my former life, which I mentioned here: http://blogs.msdn.com/vcblog/archive/2007/02/26/stl-destructor-of-bugs.aspx

re: TR1 Fixes In VC9 SP1

int19h — Wed, 20 Aug 2008 13:13:11 GMT

> VC++ Library Developer? Nice.

Well, with the name like that (or rather, initials), it's probably just his karma. I can't help but smile (in a good way) every time I see stl@microsoft.com - that's one 'leet email address! ;)

re: TR1 Fixes In VC9 SP1

Michael Marcin — Wed, 20 Aug 2008 21:09:09 GMT

How can I detect that I'm building on VC9 with SP1 installed using the preprocessor?

I remember reading http://tinyurl.com/ys99kr which said that _MSC_BUILD would be used in the future to allow us to detect service pack versions but during this old blogging _MSC_BUILD for 2008 was 1 and it still is 1 for me with SP1 installed. I don't have a computer without SP1 installed to check against however.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Wed, 20 Aug 2008 23:11:47 GMT

Michael Marcin:

_MSC_BUILD can be used to precisely identify the compiler version number, but it does not directly correspond to service pack level (i.e. it is NOT 0 for RTM, 1 for SP1, etc.).

To summarize JonCaves' explanation:

VC9 RTM's compiler version number was 15.00.21022.08. This is major.minor.build.minor-build. The major.minor version of 15.00 simply means "VC9". The build version of 21022 corresponds to the daily build that was selected to become RTM. (This was 10/22/2007's build.) The minor-build version of 08 means that this build was "respun" 8 times to fix last-minute bugs. (Every daily build begins with a minor-build version of 00. During development, we typically generate new daily builds instead of respinning a specific build, so the minor-build version remains at 00 and is actually elided from cl's output. But for betas and official releases, we respin specific builds to gold-plate the bits, and typically the minor-build version is greater than 00.)

_MSC_FULL_VER corresponds to major.minor.build, while _MSC_BUILD corresponds to minor-build (yes, the names are somewhat confusing - hence the blog post).

VC8, which lacked _MSC_BUILD, had an RTM version number of 14.00.50727.42 and an SP1 version number of 14.00.50727.762. Therefore, their _MSC_FULL_VER values were identical, and they were indistinguishable without resorting to trickery.

We added _MSC_BUILD to prevent a recurrence of this.

Now, to explain what you saw:

VC9 Beta 2's version number was 15.00.20706.01.

VC9 RTM's version number was 15.00.21022.08.

VC9 SP1's version number is 15.00.30729.01.

By coincidence, we respun Beta 2 and SP1 exactly once. That's why their minor-build numbers are identical.

But unlike VC8, we increased SP1's build number (30729 indicates 7/29/2008's build). This is probably due to a change in our build process. So, _MSC_BUILD isn't actually needed to distinguish them.

Here's the fully correct way to identify VC9 SP1 or above:

C:\Temp>type meow.cpp

#include <iostream>

#include <ostream>

using namespace std;

int main() {

cout << "_MSC_FULL_VER: " << _MSC_FULL_VER << endl;

cout << "_MSC_BUILD: " << _MSC_BUILD << endl;

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150021022 || _MSC_FULL_VER == 150021022 && _MSC_BUILD >= 8)

cout << "This is VC9 RTM or above." << endl;

#endif

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150030729 || _MSC_FULL_VER == 150030729 && _MSC_BUILD >= 1)

cout << "This is VC9 SP1 or above." << endl;

#endif

}

C:\Temp>cl /EHsc /nologo /W4 meow.cpp

meow.cpp

With VC9 RTM:

C:\Temp>meow

_MSC_FULL_VER: 150021022

_MSC_BUILD: 8

This is VC9 RTM or above.

With VC9 SP1:

C:\Temp>meow

_MSC_FULL_VER: 150030729

_MSC_BUILD: 1

This is VC9 RTM or above.

This is VC9 SP1 or above.

The cout << "_MSC_BUILD: " << _MSC_BUILD << endl; line won't compile for VC8, but the #if tests will work correctly (without triggering warnings).

re: TR1 Fixes In VC9 SP1

Michael Marcin — Thu, 21 Aug 2008 00:26:11 GMT

Thank you for that detailed explanation.

re: TR1 Fixes In VC9 SP1

Niels Dekker — Fri, 22 Aug 2008 00:23:55 GMT

Thanks for your information, Stephan!

You wrote:

> I believe that Boost has their own swap wrapper for precisely this purpose.

FYI, Boost's swap utility isn't yet officially released, but it's available at https://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp

How to tweak Swaptimization in a generic way?

Niels Dekker — Sat, 23 Aug 2008 13:56:35 GMT

Would it be okay to tweak this "Swaptimization" by defining the macro _DEFAULT_MOVE_OPERATION_CATEGORY in a different way than <xutility> does? It looks to me that in general, the penalty of copying, when swapping is preferable, is much higher than the penalty of swapping, when copying is preferable. So would it be okay to change the default, by adding the following command line argument to the compiler? /D "_DEFAULT_MOVE_OPERATION_CATEGORY=_Swap_move_tag"

STL wrote: "There's no way to automatically detect fast-swappable types"

A type that has its own swap overload is usually fast-swappable. David Abrahams has actually just posted a has_swap_overload<T> metafunction at http://lists.boost.org/Archives/boost/2008/08/141334.php

Ideally, Swaptimization should be applied to type T by default, if-and-only-if T has its own swap overload. Right? Could a metafunction like has_swap_overload<T> be used to tweak Swaptimization in a more generic way?

TR1 for Windows Mobile projects

Alex — Mon, 25 Aug 2008 13:46:32 GMT

Windows Mobile projects in VC9 configured to use "ce\include" folder with different version of STL and without TR1 additions available in regular "include" folder.

Does this mean that TR1 one is not supported on Windows Mobile projects in VC9?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Mon, 25 Aug 2008 21:18:01 GMT

[Niels Dekker]

> Would it be okay to tweak this "Swaptimization" by defining the macro _DEFAULT_MOVE_OPERATION_CATEGORY in a different way than <xutility> does?

No. That would break some code, and slow down some other code.

The Swaptimization requires a default constructor, but the STL does not. Activating the Swaptimization for all types would therefore break containers of types without default constructors.

Furthermore, swapping is slower than copying for PODs. Slowing down vector<unsigned char> is bad news indeed.

_DEFAULT_MOVE_OPERATION_CATEGORY shouldn't be a macro in the first place; it is not a point of customization.

> Ideally, Swaptimization should be applied to type T by default, if-and-only-if T has its own swap overload. Right?

According to my understanding, there is no way to detect explicit specializations of std::swap (as opposed to overloads in another namespace).

> Could a metafunction like has_swap_overload<T> be used to tweak Swaptimization in a more generic way?

This question is (happily) moot due to rvalue references.

[Alex]

> Windows Mobile projects in VC9 configured to use "ce\include" folder with different version of STL and without TR1 additions available in regular "include" folder.

> Does this mean that TR1 one is not supported on Windows Mobile projects in VC9?

CE's STL is maintained by an entirely different team, like the X360.

re: TR1 Fixes In VC9 SP1

Alex — Wed, 27 Aug 2008 12:43:56 GMT

> CE's STL is maintained by an entirely different team, like the X360.

Why? Compiler front end is the same. What's the problem?

re: TR1 Fixes In VC9 SP1

Niels Dekker — Wed, 27 Aug 2008 23:49:24 GMT

STL wrote: "The Swaptimization requires a default constructor, but the STL does not"

Thanks for reminding me! :-) Does VC 9 provide a way to estimate whether a type is default-constructible?

"Furthermore, swapping is slower than copying for PODs. Slowing down vector<unsigned char> is bad news indeed."

Okay. But now I may have found a bug in \VC\include\array. It has a _Move_operation_category<tr1::array<_Ty,_Size>> specialization, having "typedef _Swap_move_tag _Move_cat". Which activates Swaptimization for an array of PODs, right? I think that tr1::array<_Ty,_Size> should only be "swaptimized" whenever _Ty itself is "swaptimized". So _Move_operation_category<tr1::array<_Ty,_Size>> should have:

typedef typename _Move_operation_category<_Ty>::_Move_cat _Move_cat;

Don't you think?

"_DEFAULT_MOVE_OPERATION_CATEGORY shouldn't be a macro in the first place; it is not a point of customization."

Unfortunately. Anyway, in "STL-implementation independent code", it does at least provide a simple way to check if the STL supports Swaptimization, by doing #ifdef _DEFAULT_MOVE_OPERATION_CATEGORY. (Right?) Which could be helpful to activate Swaptimization within Boost, as we're discussing at "[boost] Enabling fast swap optimization for Boost types VC9 SP1.", http://thread.gmane.org/gmane.comp.lib.boost.devel/178944

Thanks again!

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Thu, 28 Aug 2008 01:23:11 GMT

[Niels Dekker]

> Does VC 9 provide a way to estimate whether a type is default-constructible?

TR1 doesn't contain such a type trait. (has_trivial_constructor and has_nothrow_constructor have been renamed to has_trivial_default_constructor and has_nothrow_default_constructor in C++0x, but there is no has_default_constructor.)

I don't know whether has_default_constructor can be implemented in plain C++.

> I think that tr1::array<_Ty,_Size> should only be "swaptimized" whenever _Ty itself is "swaptimized".

Correct. This was my oversight. That makes three instances of Swaptimization-related borkage so far (sigh). But at least vector<shared_ptr<T> > is fast!

> Anyway, in "STL-implementation independent code", it does at least provide

> a simple way to check if the STL supports Swaptimization, by doing #ifdef

> _DEFAULT_MOVE_OPERATION_CATEGORY. (Right?)

Incorrect. This macro existed in VC9 RTM (and VC8, IIRC), but the Swaptimization was fixed to work for types other than those directly within namespace std only in VC9 SP1.

> Which could be helpful to activate Swaptimization within Boost

As I posted above, here's how to do it:

// Specific to VC9 SP1 and above.

// This machinery was broken for classes outside namespace std in VC9 RTM and below.

// This machinery will not be present in VC10 and above.

#if defined(_MSC_VER) && _MSC_VER == 1500 && _MSC_FULL_VER >= 150030729

#include <xutility>

namespace std {

template <> class _Move_operation_category<feline::kitty> {

public:

typedef _Swap_move_tag _Move_cat;

};

}

#endif

re: TR1 Fixes In VC9 SP1

SvenC — Thu, 28 Aug 2008 09:28:29 GMT

Stephan, I was pretty sure that you are really good at what you do. And with your last statement you proved it again: you are so good that you have no problems to openly tell when you do not know something (the has_default_constructor question). I like that and feel that STL is in good hands for VC++! Thanks, SvenC

re: TR1 Fixes In VC9 SP1

Niels Dekker — Thu, 28 Aug 2008 22:37:08 GMT

>> I think that tr1::array<_Ty,_Size> should only be "swaptimized" whenever _Ty itself is "swaptimized".

> Correct. This was my oversight.

Would it be helpful if I'd submit the tr1::array<_Ty,_Size> Swaptimization issue to Microsoft Connect?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Thu, 28 Aug 2008 23:14:01 GMT

SvenC: The more one works with C++, the more reluctant one becomes about saying "X can't be done in C++". :-)

Niels Dekker: Not especially, as this machinery is being ripped out in VC10. I'll see if we can hotfix function::swap() and the pair/tuple/array annotations simultaneously.

re: TR1 Fixes In VC9 SP1

Niels Dekker — Fri, 29 Aug 2008 00:21:24 GMT

> I'll see if we can hotfix function::swap() and the pair/tuple/array annotations simultaneously.

It's not entirely clear to me what's wrong about the pair/tuple annotations... Do you mean that MSVC's std::pair and tr1::tuple now accidentally require all of their template arguments to be DefaultConstructible, if only one of them is activated for Swaptimization?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Fri, 29 Aug 2008 02:54:02 GMT

Yes, which breaks conformant code, which is bad. The annotation is correct from a performance perspective, but we forgot that the Swaptimization has the additional requirement of a default constructor.

re: TR1 Fixes In VC9 SP1

Niels Dekker — Fri, 05 Sep 2008 00:02:02 GMT

Can you please give an indication of when this "swap hotfix" would be available? At my work (www.lkeb.nl), it is planned to apply SP1 later this month. (We're using VC9.) Would you recommend waiting for the hotfix before applying SP1? Please also provide a way to distinguish between a hotfixed and a non-hotfixed installation, by means of a macro or version number.

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Tue, 09 Sep 2008 01:43:12 GMT

[Niels Dekker]

> Can you please give an indication of when

> this "swap hotfix" would be available?

Not yet. I can't even promise that we'll ship a hotfix (although I certainly want to).

> At my work (www.lkeb.nl), it is planned to apply

> SP1 later this month. (We're using VC9.) Would you

> recommend waiting for the hotfix before applying

> SP1?

If you're using VC9 RTM, then you can upgrade to VC9 SP1. (The only known regression there is vector<pair<no-default-ctor, something-fast-swappable> >.)

If you're using VC9 Feature Pack Refresh, then you can upgrade to VC9 SP1 if you're not yet using vector<function<FT> >. If you are, then you'll be hit by this bug, and you'll either need to use a workaround or hold off on upgrading to VC9 SP1.

> Please also provide a way to distinguish between a

> hotfixed and a non-hotfixed installation, by means

> of a macro or version number.

_MSC_FULL_VER and _MSC_BUILD completely identify the compiler version. I believe that the compiler version would be incremented for such a hotfix, but I'm not sure. If we simultaneously hotfix the function::swap(), pair/tuple, and array issues, then the hotfix will certainly be identifiable by looking at how pair, tuple, or array is annotated.

re: TR1 Fixes In VC9 SP1

CMWoods — Thu, 18 Sep 2008 21:44:32 GMT

Any update on whether the team has decided whether or not a hotfix (or better) to address these various issues will be made?

re: TR1 Fixes In VC9 SP1

Stephan T. Lavavej [MSFT] — Sat, 20 Sep 2008 03:20:35 GMT

No promises, but Magic 8-Ball says: Signs point to yes.

I merged (function) and wrote (pair, tuple, array, random) the fixes last night, in my pajamas, in about 5 minutes. The other steps of the hotfix process will take longer.

We write VCBlog posts when hotfixes are publicly available, like we did for the Intellisense hotfix, so stay tuned.

VC9 SP1 Hotfix For The vector> Crash

Visual C++ Team Blog — Wed, 17 Dec 2008 20:05:33 GMT

Back in August, I blogged about the TR1 fixes in VC9 SP1 . An observant reader, grokbrsm, commented that