Q&A on our TR1 implementation

???????????????????? ?????????????????? - ????????????????????

???????????????????? ?????????????????? - ???????????????????? — Wed, 09 Jan 2008 04:08:00 GMT

PingBack from http://blogs.gotdotnet.ru/personal/kichik/PermaLink,guid,4F4F8997-BB1C-41BD-9E39-F901F7F75C54.aspx

re: Q&A on our TR1 implementation

Neil — Wed, 09 Jan 2008 04:38:06 GMT

Great stuff! Thanks for the detailed rundown. Looking forward to using it!

re: Q&A on our TR1 implementation

Cory Nelson — Wed, 09 Jan 2008 06:58:36 GMT

Looks nice, but where do we submit TR1 bugs?

re: Q&A on our TR1 implementation

James — Wed, 09 Jan 2008 07:25:37 GMT

If TR1 is just a bunch of headers and maybe some link libraries, and if there are no compiler changes, then why would TR1 not run on VCExpress? With a little bit of manual work, I imagine that it would not be too difficult to get up and running. Is this merely a business decision, or is there actually a technical reason for this restriction?

Why you may ask?

I have access to the full version, but I honestly prefer to work in Express. Express removes so much of the unneeded bloat, is faster, and as a result more productive. Similar to the days of VC6.

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Wed, 09 Jan 2008 14:14:06 GMT

[Cory Nelson]

> Looks nice, but where do we submit TR1 bugs?

Microsoft Connect, or directly to me at stl@microsoft.com .

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Anon. — Wed, 09 Jan 2008 14:59:31 GMT

Stephan T. Lavavej,

Pretty cool initials you have there. Seems ideal for someone who loves the STL so much.

re: Q&A on our TR1 implementation

Jared — Wed, 09 Jan 2008 19:37:55 GMT

James,

Thats a really great idea: use VCExpress to avoid the bloated VS.

Stephan T. Lavavej,

Is there an official method for paying customers to use (leverage) VCExpress with MFC and TR1. I also find VS has become very bloated since VC6. Overall, I think the VC++ team is doing a good job, but much of Visual Studio does not appeal to me.

re: Q&A on our TR1 implementation

Pavel Minaev — Wed, 09 Jan 2008 22:01:20 GMT

Speaking of STL optimizations: is there any specific reason (aside from the "we haven't time to do that") why std::vector doesn't use __is_pod and friends to switch to a memset/memcpy-using implementation where possible? In my tests, this gives noticeable speed increase for small elements - it's more than 2x for chars, and 20% for shorts.

re: Q&A on our TR1 implementation

Kevin — Wed, 09 Jan 2008 22:30:45 GMT

Dinkumware has implemented nearly everything in sections 5.2 and 8. Since MS is licensing Dinkumware's implementation, is there a good reason VC9 TR1 does not include sections 5.2 and 8?

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Wed, 09 Jan 2008 22:35:07 GMT

[Anon.]

> Pretty cool initials you have there. Seems ideal for someone who loves the STL so much.

Yes (and my initials are so much more convenient to type)!

[Jared]

> Is there an official method for paying customers to use (leverage) VCExpress with MFC and TR1.

No, this is not supported.

[Pavel Minaev]

> Speaking of STL optimizations: is there any specific reason

> (aside from the "we haven't time to do that") why std::vector

> doesn't use __is_pod and friends to switch to a

> memset/memcpy-using implementation where possible?

I thought it did - vector<T>::push_back() eventually calls vector<T>::_Insert_n(), which (should) call _Umove() to move elements from the old memory block to the new memory block. (As I mentioned in http://blogs.msdn.com/vcblog/archive/2008/01/07/mfc-beta-now-available.aspx#7032589 , this is broken in the VC9 TR1 Beta.) That eventually calls _Uninit_move(), which - if T is something like char which isn't annotated with _Swap_move_tag - calls unchecked_uninitialized_copy() ("move defaults to copy if there is not a more effecient way"). That eventually calls _Uninit_copy(), of which there are two implementations. The first is for _Nonscalar_ptr_iterator_tag, and the second is for _Scalar_ptr_iterator_tag. The latter calls _CRT_SECURE_MEMMOVE().

Did you define __STDC_WANT_SECURE_LIB__ to 0 when doing your performance comparisons? If not, you might just be seeing the overhead of memmove_s() versus memmove().

Of course, now I wonder if memcpy() is actually faster, and whether we should be using _CRT_SECURE_MEMCPY().

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Wed, 09 Jan 2008 23:25:11 GMT

[Kevin]

> Dinkumware has implemented nearly everything in

> sections 5.2 and 8. Since MS is licensing

> Dinkumware's implementation, is there a good reason

> VC9 TR1 does not include sections 5.2 and 8?

Development time, testing time, and customer value.

Shipping C99 compat and special math functions would take more dev and test time (probably not an incredible amount of time, but definitely nonzero).

The special math functions are of extremely limited interest (and have not been picked up into C++0x), and the C99 compat, while useful, is of less interest than the Boost-derived components. (I'd like to have <cstdint>, but shared_ptr is about a bazillion times more vital.)

So, given limited resources, we chose the Boost-derived components and unordered containers. Does that sound reasonable?

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Pavel Minaev — Thu, 10 Jan 2008 10:05:15 GMT

> Of course, now I wonder if memcpy() is actually faster, and whether we should be using _CRT_SECURE_MEMCPY().

Not really, since memmove() in VC checks the ranges for overlap, and delegates to memcpy() if possible anyway. My tests show no noticeable difference for non-overlapping sequences between the two even for amount of data as small as 4K. Not a problem with memmove_s(), either - it also does a very quick check with no observable difference for moderately large vectors.

I was also thinking that the difference is because I used memset to zero-initialize my arrays, and vector uses std::fill (it could also use memset to default-initialize PODs, by the way), but again it doesn't seem to make any difference. So I don't know what to make of it. Here's the code I've used to test:

#include <algorithm>

#include <cstdio>

#include <cstring>

#include <vector>

#include <windows.h>

struct timer

{

const char* msg;

DWORD start;

timer(const char* msg)

: msg(msg), start(GetTickCount())

{

}

~timer()

{

DWORD end = GetTickCount();

std::fprintf(stderr, "%s: %u\n", msg, end - start);

}

};

int main()

{

typedef char elem_t;

static const int N = 100000, K = 10000;

//getchar();

{

timer t("vector");

for (int k = 0; k < K; ++k)

{

std::vector<elem_t> v(N);

v.push_back(0);

}

{

timer t("fill + memmove");

for (int k = 0; k < K; ++k)

{

elem_t* a1 = new elem_t[N];

std::fill(a1, a1 + N, 0);

elem_t* a2 = new elem_t[N * 2];

std::memmove(a2, a1, N * sizeof(elem_t));

delete[] a1;

a2[N] = 0;

delete[] a2;

}

{

timer t("fill + memcpy");

for (int k = 0; k < K; ++k)

{

elem_t* a1 = new elem_t[N];

std::fill(a1, a1 + N, 0);

elem_t* a2 = new elem_t[N * 2];

std::memcpy(a2, a1, N * sizeof(elem_t));

delete[] a1;

a2[N] = 0;

delete[] a2;

}

{

timer t("memset + memcpy");

for (int k = 0; k < K; ++k)

{

elem_t* a1 = new elem_t[N];

std::memset(a1, 0, N * sizeof(elem_t));

elem_t* a2 = new elem_t[N * 2];

std::memcpy(a2, a1, N * sizeof(elem_t));

delete[] a1;

a2[N] = 0;

delete[] a2;

}

This is compiled with:

> cl /EHsc /Ox /Zi /D_SECURE_SCL=0 /D__STDC_WANT_SECURE_LIB__=0

When run, it gives the following results:

vector: 1344

fill + memmove: 422

fill + memcpy: 422

memset + memcpy: 437

From what you say, I would expect vector to be as fast as fill+memmove (since that's pretty much what it does). Curiously, these numbers differ with varying K and N; in general, smaller N make the difference more pronounced, while larger N make it less noticeable. For example, for N=10000 & K=1000000 I get:

vector: 11391

fill + memmove: 2343

fill + memcpy: 2313

memset + memcpy: 2328

And for N=1000000 & K=1000, it's:

vector: 5000

fill + memmove: 4938

fill + memcpy: 4937

memset + memcpy: 4938

Which makes more sense. I'm more interested in cases with N<100000, since that's where it is going to be in most practical cases. From these numbers, it seems that the issue is not in the filling/copying code itself, but in some checks which remain there even with _SECURE_SCL disabled.

re: Q&A on our TR1 implementation

Pavel Minaev — Thu, 10 Jan 2008 10:08:31 GMT

> I'd like to have <cstdint>, but shared_ptr is about a bazillion times more vital.

<cstdint> is by far the most important of all TR1 compat headers, and also the simplest; why not have it and forgo the rest?

re: Q&A on our TR1 implementation

Phaeron — Thu, 10 Jan 2008 11:13:47 GMT

I'm disappointed at stdint/cstdint being missing, too. I hate typing unsigned __int64 in one-off programs and I've never seen a major project that didn't have to have its own typedefs for sized types. Lots of fun when they collide. Much of the stuff in TR1 section 8 I could do without, but stdint.h I want. I suppose not having the extra printf() size specifiers would be a bummer, though.

re: Q&A on our TR1 implementation

Pavel Minaev — Thu, 10 Jan 2008 12:43:42 GMT

Well, for most practical purposes, we've got a defacto standard by now:

sizeof(short)==2

sizeof(int)==4

sizeof(long long)==8

At least I'm not aware of any still-relevant compiler for which this doesn't hold (I know int was 2 bytes in 16-bit DOS days, but these are hardly relevant today).

Even so, int32_t is so much more preferrable...

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 11 Jan 2008 01:00:39 GMT

[Pavel Minaev]

Aha - it's good to know that memmove_s(), memmove(), and memcpy() are basically indistinguishable, and the same for fill() and memset().

Thanks for the test case - profiling indicates that the vector test spends 76% of its time in vector<T>::_Construct_n(). I'll file a bug.

> <cstdint> is by far the most important of all TR1 compat headers,

> and also the simplest; why not have it and forgo the rest?

The "which parts of TR1 should we ship" decision was made at the coarsest-grained level of Boost/C99/Math.

[Phaeron]

> I'm disappointed at stdint/cstdint being missing, too.

There's always boost/cstdint.hpp.

> I hate typing unsigned __int64 in one-off programs

VC accepts "unsigned long long".

> and I've never seen a major project that didn't have to have

> its own typedefs for sized types. Lots of fun when they collide.

Namespaces!

Also - I'd like to personally thank you, Phaeron, for writing those two posts about autoexp.dat visualizers. They really helped me when I was writing the TR1 visualizers (which, as you will see, are extensively commented - unlike the existing STL visualizers).

[Pavel Minaev]

> At least I'm not aware of any still-relevant compiler for which this doesn't hold

"ILP64" platforms make int, long, long long, and void * all 64 bits. I'm not sure which platforms actually implement ILP64.

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Phaeron — Fri, 11 Jan 2008 09:15:04 GMT

> There's always boost/cstdint.hpp.

I tend to compile lots of little test programs with cl.exe for which bringing in Boost is, um, a bit much.

> VC accepts "unsigned long long".

That's even longer!

> Also - I'd like to personally thank you, Phaeron, for writing those two posts about

> autoexp.dat visualizers. They really helped me when I was writing the TR1 visualizers

> (which, as you will see, are extensively commented - unlike the existing STL

> visualizers).

You're welcome. You can probably imagine my amusement, though, that a developer on the VC++ Libraries team used reverse-engineered docs from an external source for the VC++ debugger. Go bug the debugger team and ask them to write better docs! Then tell them to release them to us. :)

re: Q&A on our TR1 implementation

Pavel Minaev — Fri, 11 Jan 2008 18:51:13 GMT

> I've written visualizers for almost every TR1 type (I am secretly proud of how shared_ptr's visualizer switches between "1 strong ref" and "2 strong refs").

How about boost::function? ;)

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 11 Jan 2008 21:41:03 GMT

[Phaeron]

> I tend to compile lots of little test programs with cl.exe for which bringing in Boost is, um, a bit much.

At home, I drop Boost into VC\PlatformSDK\Include and VC\PlatformSDK\Lib, so I can use it without any /I switches. (I could also have used VC\include and VC\lib .) This is, of course, entirely unsupported - as a general rule you shouldn't perform brain surgery in Program Files - but it works entirely well.

>> VC accepts "unsigned long long".

> That's even longer!

The typedefs I use at home are uc_t, us_t, ul_t, and ull_t. :-)

> You're welcome. You can probably imagine my amusement, though,

> that a developer on the VC++ Libraries team used reverse-engineered

> docs from an external source for the VC++ debugger.

The sad thing is that - to my knowledge - your docs are the most complete ones in existence. We don't have *any* internal docs for the visualizer, beyond the comments in autoexp.dat.

[Pavel Minaev]

> How about boost::function? ;)

I visualize tr1::function too; however, pointers-to-bases are a "brick wall" to visualizers, so I can only preview them with "empty" or "full". Vaguely speaking, _Impl->_Callee._Object stores the functor, but there's no way to get that into the preview.

For the same reason, shared_ptr deleters are not visualizable. When this happens, I provide [actual members] so you can dig into the representation; the foo,! trick isn't widely known, and is less convenient anyways.

Yesterday, I checked in an enhanced regex visualizer. While basic_regex looks like it stores a plain string, it actually stores a finite state machine, which is completely un-visualizable. So, I added a data member named _Visualization to basic_regex that stores the string from which it was constructed, which we can use to preview the regex. By default, this is enabled in debug and disabled in ship (we'll fall back to a significantly less useful preview), although you can override this by defining _ENHANCED_REGEX_VISUALIZER (0 in debug would remove the overhead of storing the string; 1 in ship would make debugging easier). While basic_regex is much more heavyweight than a simple string, I didn't want to make ship any slower without people asking for it.

Hopefully, you will be pleasantly surprised by the number of TR1 types that I visualize, and the comprehensiveness of their visualizers. weak_ptrs can be previewed with "expired", regex_iterators and regex_token_iterators have useful previews and children, and even the return value of bind() will be visualized (this hasn't been checked in yet, pending a bind() fix, but STL functors like plus<T>() and the like will also get visualizers, since that makes bind() visualizers much prettier).

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Cory Nelson — Sat, 12 Jan 2008 00:54:58 GMT

I am also disappointed to not see stdint. Having to make typedefs in portable code gets old quick.

stdint and inttypes are both very simple, is there no way for them to be included?

re: Q&A on our TR1 implementation

memodude — Sat, 12 Jan 2008 04:06:03 GMT

Agreed. cstdint is necessary, not to mention ridiculously easy to implement. There's no excuse not to ship a standard header file which consists of nothing but a small set of extremely useful typedefs.

re: Q&A on our TR1 implementation

mochi — Sat, 12 Jan 2008 12:38:36 GMT

Since we are talking about Visualizers, does anyone else have this problem - on Vista w/ VC2005 SP1 (w/ vista update), no [Visualizer]s seem to work at all.

My [AutoExpands] work properly, but I cannot even get STL container of ints to visualize as you would expect (e.g. I get {_Myfirst=0x003d4ea0 _Mylast=0x003d4eb4 _Myend=0x003d4eb8 } instead of {[2](x,y)}.

re: Q&A on our TR1 implementation

mochi — Sat, 12 Jan 2008 12:49:05 GMT

Btw, this is on Visual Studio 2005 Standard, though I can't see why that would make a difference.

re: Q&A on our TR1 implementation

Pavel Minaev — Sat, 12 Jan 2008 13:09:07 GMT

> I visualize tr1::function too; however, pointers-to-bases are a "brick wall" to visualizers, so I can only preview them with "empty" or "full". Vaguely speaking, _Impl->_Callee._Object stores the functor, but there's no way to get that into the preview.

Not quite. You can get past a pointer-to-base with a cast if you know what's really there. And you can use the same trick you did for regex - storing a member identifying the actual type of the functor inside tr1::function for debug builds, at least for some commonly-used functor types (e.g. plain function pointers and bind expressions).

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Sun, 13 Jan 2008 02:00:01 GMT

[Cory Nelson]

> I am also disappointed to not see stdint.

I'd like to have cstdint in VC9 TR1 too, but remember the opportunity cost.

If we had an extra day, week, or month to work on TR1, I'd want us and Dinkumware to look at regex perf.

[mochi]

> on Vista w/ VC2005 SP1 (w/ vista update), no [Visualizer]s seem to work at all.

On my dev box (Server 2003 SP2 with VC8 SP1 Team Suite), visualizers work intermittently, which mystifies me. I had installed and uninstalled another edition of VC8 before, but hadn't done anything else unusual to that computer. (I'm 90% sure that my ordinary development work doesn't interact with the regular installation.) I really ought to nuke and pave that machine, but I'm waiting to get a quad-core.

[Pavel Minaev]

> Not quite. You can get past a pointer-to-base with a cast if you know what's really there.

> And you can use the same trick you did for regex - storing a member identifying the actual

> type of the functor inside tr1::function for debug builds, at least for some commonly-used

> functor types (e.g. plain function pointers and bind expressions).

Function pointers, okay - given a tr1::function<FT>, if it holds a function pointer, that's of type FT *. That's a good idea. But bind expressions, no - the type of a bind expression is highly variable, depending on more than its signature.

regex's representation was almost completely opaque (except for the flags with which it was constructed), so the enhanced regex visualizer is rather valuable. I could imagine it being hard to track down the string from which a regex was constructed (especially in the case of constructing a regex from input iterators), even though the usual case is to have a const regex constructed from a string literal. tr1::function's representation, on the other hand, is obnoxious to pick through the first time, but does contain all of the information you want. So the need for an enhanced visualizer is less (although it sure would be convenient).

I'll take a look at how simple it would be to add a "stores a function pointer" bool to tr1::function, although I suspect that it would require adding some overloads. Anything that could destabilize the implementation would be Bad. (regex's _Visualization didn't need any new overloads, so there was no danger of breaking something else. At worst, we'd forget to update the _Visualization when we should.)

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

Visual C++ 2008 Feature Pack 베타

bkchung's WebLog — Mon, 14 Jan 2008 08:47:56 GMT

Visual C++ Team Blog : MFC Beta Now Available Download details VC++ 2008 Libraries Feature Pack Beta

Visual C++ 2008 Feature Pack 베타

Noticias externas — Mon, 14 Jan 2008 09:40:38 GMT

Visual C++ Team Blog : MFC Beta Now Available Download details VC++ 2008 Libraries Feature Pack Beta

re: Q&A on our TR1 implementation

Dave — Mon, 14 Jan 2008 21:04:02 GMT

Can we use MFC/TR1 for native/win32 programming and not MFC?

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Mon, 14 Jan 2008 22:17:30 GMT

[Dave]

> Can we use MFC/TR1 for native/win32 programming and not MFC?

I don't understand your question, can you clarify it?

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

mikeb — Tue, 15 Jan 2008 00:10:36 GMT

Hey - everyone who says Microsoft needs to provide stdint.h. There's a public domain version available (from the MinGW toolset):

http://www.cs.colorado.edu/~main/cs1300/include/stdint.h

It required some tweaks for my use (to make the 64-bit stuff work with VC6 - I don't remember if changes were needed for any other MS compiler version). I know that MS should provide this with the compiler (and I sure have no idea why they don't), but until they decide to you can have your portability in this small area with little in the way of maintainability headaches since it's not interdependent on other bits of the library - it's just a bunch of typedefs and macros.

re: Q&A on our TR1 implementation

Dave — Tue, 15 Jan 2008 00:54:44 GMT

- I mean, Is TR1 an specific feature for MFC users? if not , why did you distribute it along with MFC update?

- after compiling with this new patch ,is distribution of updated CRT enough ?

No new libraries needed to distribute?

Thanks in advance

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Tue, 15 Jan 2008 02:14:34 GMT

[Dave]

> I mean, Is TR1 an specific feature for MFC users?

No. It has nothing whatsoever to do with MFC.

> if not , why did you distribute it along with MFC update?

Read the third Q&A above:

"Q: If I use TR1, will I gain a dependency on MFC? Or, if I use the MFC updates, will I gain a dependency on TR1?

A: No. The TR1 and MFC updates don't interact. They're just being distributed together for simplicity."

> after compiling with this new patch ,is distribution of updated CRT enough ?

Yes.

> No new libraries needed to distribute?

Correct. TR1 involves no additional DLLs.

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

scorpion007 — Tue, 15 Jan 2008 08:16:40 GMT

Is VC 2005 still going to get service packs and updates? The product lifecycle website says mainstream support ends 2011 and extended support ends 2016. I'm hoping you don't just forget about it.

After all, VC6 had 6 service packs.

re: Q&A on our TR1 implementation

Jared — Tue, 15 Jan 2008 18:56:31 GMT

Good question scorpion007!!

I'm also curious if VC 2005 will get more SPs. I too remember the relatively frequent SPs for VC6 and I miss getting semi-regular service packs. IMHO, VS has turned into a money-machine where developers need to buy new versions to get fixes that used to be in Service Packs.

Looking at it from a different angle. VS6 SPs were sort of a conversation (feedback loop) between VS producers and consumers: Each SP addressed either recent or longstanding significant issues. Continued support was something like iterative. Then (with VS 2002, 2003, and 2005) continued support appears to be more Waterfall: A customer gets one SP and that's it, so you'd better like it.

I prefer Iterative development and support.

re: Q&A on our TR1 implementation

Jesse W. Towner — Tue, 15 Jan 2008 21:43:29 GMT

A developer could implement stdint.h/cstdint and test cases for it in an afternoon or less, especially if you have the licensed Dinkumware implementation to work from.

It shouldn't interact with any of the other STL or TR1 code, there's no reason to refactor any of it to use cstdint. It's isolated from everything else. This is probably one of the easiest TR1 features to get right.

You would seriously be doing everyone a service by shipping it. Here's hoping you will reconsider. ^_^

千呼万唤始出来的 Visual C 2008 Feature Pack 介绍

Michael Lee — Wed, 16 Jan 2008 15:24:41 GMT

缘起：自VisualC 5.06.0以来一直遭人诟病的是什么？过于简单的界面控件！

作为一个以VisualC 作为开发工具的程序员，遇到最郁闷的事情是什么？开发一个具有漂...

千呼万唤始出来的 Visual C 2008 Feature Pack 介绍

Michael Lee — Wed, 16 Jan 2008 15:31:02 GMT

缘起：自VisualC 5.06.0以来一直遭人诟病的是什么？过于简单的界面控件！

作为一个以VisualC 作为开发工具的程序员，遇到最郁闷的事情是什么？开发一个具有漂...

re: Q&A on our TR1 implementation

ikk — Wed, 16 Jan 2008 16:23:53 GMT

<quote>

Hey - everyone who says Microsoft needs to provide stdint.h. There's a public domain version available (from the MinGW toolset):

http://www.cs.colorado.edu/~main/cs1300/include/stdint.h

It required some tweaks for my use

</quote>

It is exactly those tweaks that developers should not need to do. That's the point of stdint/inttypes: it should be provided by the implementation so that we can be sure that changes in the implementation are reflected in stdint.

BTW, boost also has stdint.

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Thu, 17 Jan 2008 00:16:44 GMT

Pavel Minaev - I am happy to report that the swap-optimization regression you found has just been fixed in mainline (and the comments have been updated to match the code). Thanks again for being so observant.

Also, a bug has been fixed where replacing "A" with "x" in "AAAAAA" was producing "xAxAxA" instead of the correct "xxxxxx". (I found this one myself, but someone also reported it through vcblog a day later!)

Keep those bug reports coming!

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

mikeb — Thu, 17 Jan 2008 05:08:44 GMT

<quote>

</quote>

True. but if you aren't going to get it from Microsoft (and that looks to be the case in the near future) and you want or need it, then it's an option. And, since it public domain there are absolutely no licensing issues (though Boost's license is pretty dang close to PD as well).

The boost version is C++ only (which may be fine for some people). Then again, the version I pointed to doe snot have a cstdint variant for C++, and it has some deficiencies properly defining pointer-sized values on 64-bit builds. Anyone who wants a correct version for Win64 should maybe get the latest from MinGW at:

http://www.mingw.org/download.shtml

As for changes I had to make in my case, I'm pretty sure I'll have no good luck getting a version of stdint.h from MS for VC6, even if they ever deliver one for VC 2008+.

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Thu, 17 Jan 2008 05:47:52 GMT

VC6 is no longer supported by Microsoft.

("Good riddance," I said, referring only to the compiler and libraries, which were hideously nonconformant.)

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Richard Webb — Thu, 17 Jan 2008 18:03:36 GMT

Hi,

I've tried running the Boost regression tests on VC9 with the feature pack, and they are showing up a number of apparent issues with the beta TR1.

For example, from type_traits:

-std::tr1::is_const<type[N]>::value always seems to be true

-std::tr1::remove_const<const type[N]::type always seems to be 'type const[N]'.

Using the Boost versions of type_traits, the results are false and 'type[N]'.

The Boost/VC9/TR1 test results are viewable at <http://beta.boost.org/development/tests/trunk/developer/tr1.html>, in the column "RW_WinXP_VC".

Does anyone have any comments on these in general, or should i just raise the possible issues on the connect site?

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 18 Jan 2008 05:42:45 GMT

[Richard Webb]

> I've tried running the Boost regression tests on

> VC9 with the feature pack, and they are showing up

> a number of apparent issues with the beta TR1.

Excellent; the more bugs that we can hammer out during the beta, the better.

> -std::tr1::is_const<type[N]>::value always seems to be true

> -std::tr1::remove_const<const type[N]::type always seems to be 'type const[N]'.

N2157 ( http://tinyurl.com/2r54lo ), voted into the WP, clarifies that is_const<int[3]>::value is false, and is_const<const int[3]>::value is true, so VC's wrong there.

It also clarifies that remove_const<const int[3]>::type is int[3], so VC's also wrong there.

I have filed a bug about this (internal number 171837).

> Does anyone have any comments on these in general,

> or should i just raise the possible issues on the

> connect site?

If you could investigate the other issues and file Connect bugs about them, that'd be great. Please provide self-contained repros.

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

re: vector performance

Ilijas Selimovic — Sat, 19 Jan 2008 00:56:48 GMT

[Pavel Minaev]

Hi,

I have had the same problems with the performance of std::vector. Maybe worse because my vectors had an average element count of 5. The result was my own vector implementation. Since I have analized the problem in detail, here are some explanations.

Look at the folowing code which is called from the consructor:

bool _Buy(size_type _Capacity)

{

// allocate array with _Capacity elements

_Myfirst = 0, _Mylast = 0, _Myend = 0;

if (_Capacity == 0)

return (false);

else if (max_size() < _Capacity)

_Xlen(); // result too long

else

{ // nonempty array, allocate storage

_Myfirst = this->_Alval.allocate(_Capacity);

_Mylast = _Myfirst;

_Myend = _Myfirst + _Capacity;

}

return (true);

}

First look at

_Myfirst = 0, _Mylast = 0, _Myend = 0;

Could be transormed to (on wintel platforms)

_Myfirst =_Mylast =_Myend;

Lets have a look at

if (max_size() < _Capacity)

Does anybody need that check? Me not, but even if, the result of max_size is typicaly known at compiletime but the compiler leaves a function call and some computations.

The really funny thing is, that allocate

makes the same checks again, before calling new. The rest of the vector implementation has similar "features".

The implementation of vector cannot be called

efficient for small element counts.

If you can do without generalized allocators, have a look at yasli::vector, an implementation of Alexandrescu.

re: Q&A on our TR1 implementation

Richard Webb — Sun, 20 Jan 2008 15:40:22 GMT

[Stephan]

I've opened a number of bugs @ Connect.

However:

There are a number of test failures for things where the WP (N2157+) is different from the TR1 draft (N1836). For example:

-the result of is_base_of<int, int>

-the behaviour of is_convertible<> with void types

So the expected results depend on which spec you're following. (see http://tinyurl.com/yw9zcb for a bit more info on the Boost tests in question).

Can you confirm whether these issues are considered bugs in the feature pack?

Thanks,

Richard Webb

Support du TR1 dans Visual Studio 2008

Noticias externas — Mon, 21 Jan 2008 00:37:45 GMT

Soma annonce sur son blog le support du TR1 dans Visual Studio 2008 . Vous pouvez télécharger la béta

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Mon, 21 Jan 2008 05:44:26 GMT

[Richard Webb]

> I've opened a number of bugs @ Connect.

Thanks!

> Can you confirm whether these issues are considered bugs in the feature pack?

I haven't yet looked at all of the bugs you opened. In general - where N2157 clarifies or corrects TR1, we'll want to follow N2157. Obviously, we'll ignore C++0x-specific changes in N2157 (e.g. is_rvalue_reference).

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

scorpion007 — Wed, 23 Jan 2008 03:05:32 GMT

@Jared, heh. Might be because the service packs take forever to install nowadays, MS doesn't want to bother with them ;)

VC 6 ones were a lot faster. But of course, as time moves on, things get bigger and [maybe?] better.

I've submitted some bugs myself, and hope the fix gets back ported to VC 2005.

re: Q&A on our TR1 implementation

好男人 — Wed, 23 Jan 2008 12:31:05 GMT

the regex doesn't work with subsystem:window application,when i did 2 undef about the max() and min(),it then worked.but still it was givin me memory leaks

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Wed, 23 Jan 2008 12:45:05 GMT

> the regex doesn't work with subsystem:window

> application,when i did 2 undef about the max() and

> min(),it then worked.

We have an open bug about this, thanks. In the meantime, you can define NOMINMAX before including <windows.h>, which will prevent it from defining the min and max macros that stomp over <regex>.

(In VC7.1, I think, <algorithm> was affected, but it has since been made immune. We'll simply extend this to TR1.)

> but still it was givin me memory leaks

Can you provide a self-contained test case that demonstrates this?

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

好男人 — Thu, 24 Jan 2008 06:56:57 GMT

this a mfc dialog application

i put:

#include "stdafx.h"

#include "regex_test_dlg.h"

#include "regex_test_dlgDlg.h"

#undef max

#undef min

#include <regex>

using namespace std::tr1;

at the beginning of the regex_test_dlgDlg.cpp file.

then i put this "regex r("aa");" into OnInitDialog(),after that,i start the debug version program.when it's done,i get this

Detected memory leaks!

Dumping objects ->

{486} normal block at 0x00ED1B20, 20 bytes long.

Data: <@4C > 40 34 43 00 15 00 00 00 00 00 00 00 00 00 00 00

{485} normal block at 0x00ED1AC8, 24 bytes long.

.................

do you get that?

re: Q&A on our TR1 implementation

Jared — Thu, 24 Jan 2008 20:03:12 GMT

好男人 has touched on something that I've wondered about for years.

Why can't the VC++ memory leak detection code be extended, so that the Origin (Filename + source code line and/or class name) is captured? You could then echo the Origin when you report each item in: "Dumping object ->".

I appreciate VC++ detecting memory leaks, but notification of the leak isn't worth nearly as much as also knowing what actually leaked (which enables devs to more quickly fix leaks). In the above post (by 好男人) it may be obvious what caused the memory leak. But, even in that case we are making an assumption and as a CS professor wisely told me: DON'T ASSUME! In large systems, it’s usually anything but obvious what leaked.

Am I missing something? Is there an easy way to reconcile the detected memory leak to the actual source code or class? (I'm sometimes kind of dense).

Thanks much.

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 25 Jan 2008 03:30:15 GMT

Confirmed! regex is leaking memory. I've identified the problem and I'll file a bug about it immediately.

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

scorpion007 — Fri, 25 Jan 2008 11:59:35 GMT

@Jared:

Usually the debug CRT does in fact tell you what leaked, and where. You can even double-click in the IDE and it will take you right to the cause, provided it was identified correctly.

I don't remember the specifics, but occasionally it doesn't show you the offending line.

Anyway, here's an example which *does* show you the offending code.

// compile with cl /D_DEBUG /MDd leak.cpp

#define _CRTDBG_MAP_ALLOC

#include <stdio.h>

#include <crtdbg.h>

int main()

{

malloc(40); // leak 1

malloc(10); // leak 2

_CrtDumpMemoryLeaks();

return 0;

}

0:000> g

Detected memory leaks!

Dumping objects ->

leak.cpp(11) : {62} normal block at 0x001A3FB8, 10 bytes long.

Data: < > CD CD CD CD CD CD CD CD CD CD

leak.cpp(10) : {61} normal block at 0x001A1188, 40 bytes long.

Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

Object dump complete.

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

And another with C++ code, requires some adjustment:

// compile with cl /D_DEBUG /MDd /EHsc leak2.cpp

#define _CRTDBG_MAP_ALLOC

#include <iostream>

#include <crtdbg.h>

#ifdef _DEBUG

#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)

#define new DEBUG_NEW

#endif

int main()

{

char *a = new char[10];

char *b = (char*)malloc(20);

_CrtDumpMemoryLeaks();

return 0;

}

0:000> g

Detected memory leaks!

Dumping objects ->

leak2.cpp(17) : {62} normal block at 0x002011D0, 20 bytes long.

Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD

leak2.cpp(16) : {61} normal block at 0x00201188, 10 bytes long.

Data: < > CD CD CD CD CD CD CD CD CD CD

Object dump complete.

re: Q&A on our TR1 implementation

ikk — Fri, 25 Jan 2008 20:20:45 GMT

Nice tricks with _CrtDumpMemoryLeaks(), i didn't know much about it.

It seems that the documentation is not that good, because i couldn't find _CRTDBG_MAP_ALLOC and DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__). But i admit that my search was not extensive.

If you use _CrtDumpMemoryLeaks() without those macros, would it work? It's a little sad that such features are not easily available from the IDE. Or are they?

re: Q&A on our TR1 implementation

scorpion007 — Sat, 26 Jan 2008 07:25:33 GMT

Sorry about the slightly off-topic posts guys.

@ikk, these links should be helpful:

http://msdn2.microsoft.com/en-us/library/k70yt3e2%28VS.80%29.aspx

http://msdn2.microsoft.com/en-us/library/zh712wwf(VS.80).aspx

http://msdn2.microsoft.com/en-us/library/974tc9t1%28VS.80%29.aspx

And all the related sub-topics, etc.

Also, I recommend John Robbins' excellent book, which also covers the Debug CRT very nicely:

http://www.amazon.com/Debugging-Applications-Microsoft-Windows-Pro-Developer/dp/0735615365

(Don't let the .NET in the title fool you, the majority of it is native)

re: Q&A on our TR1 implementation

scorpion007 — Sat, 26 Jan 2008 09:47:19 GMT

@ikk,

The spam catcher stops me from posting anything containing multiple URLs, so I'll just tell you that you can find more info on MSDN -- just look for the Debug CRT, etc.

Also, get John Robbin's book "Debugging Applications" which covers the Debug CRT and a lot more.

re: Q&A on our TR1 implementation

H Zhang — Mon, 28 Jan 2008 19:55:04 GMT

"A: Our implementation contains everything in TR1 except sections 5.2 and 8"

But the beta reference_wrapper doesn't seem to be assignable. Are we going to have reference_wrapper& operator=(const reference_wrapper<T>& x)?

Thanks.

re: Q&A on our TR1 implementation

H Zhang — Mon, 28 Jan 2008 23:10:05 GMT

Here is a piece of my test code:

struct A

{

int f() {std::cout<<" f called\n";return 8; }

};

A a;

int (A::*pAf)() = &A::f;

std::tr1::function< int (A)> mf1(pAf);

//std::tr1::function< int (A*)> mf2(pAf);

//mf2(&a);

mf1(a);

boost::function<int (A)> bf1(&A::f);

boost::function<int (A*)> bf2(&A::f);

bf1(a);

bf2(&a);

std::tr1::mem_fn(pAf)(a);

std::tr1::mem_fn(pAf)(&a);

std::tr1::bind(pAf, a)();

std::tr1::bind(pAf, &a)();

My question:

Why the line std::tr1::function< int (A*)> mf2(pAf);

won't work?

Note that boost::function<int (A*)> bf2(&A::f); as well as all other lines, works fine.

Is there a reason why it shouldn't be allowed?

I couldn't figure it out from n1836. And I didn't have time to dig through the source code yet.

Am I missing something?

Thanks.

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Tue, 29 Jan 2008 22:49:31 GMT

[H Zhang]

> But the beta reference_wrapper doesn't seem to be

> assignable.

It is:

C:\Temp>type ref.cpp

#include <functional>

#include <iostream>

#include <ostream>

using namespace std;

using namespace std::tr1;

int main() {

int x = 100, y = 200;

reference_wrapper<int> a(x), b(y);

a += 10;

b += 20;

cout << x << ", " << y << endl;

b = a;

cout << x << ", " << y << endl;

a += 1;

b += 2;

cout << x << ", " << y << endl;

}

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

ref.cpp

C:\Temp>ref

110, 220

113, 220

> Why the line std::tr1::function< int (A*)> mf2(pAf);

> won't work?

That's a bug. I'll file a bug in our internal database.

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

H Zhang — Wed, 30 Jan 2008 19:37:05 GMT

You are right about my first question ("the beta reference_wrapper...").

I didn't investigate deep enough.

I jumped to conclusion too fast when I saw this error:

1>c:\users\hzhang\documents\visual studio 2008\projects\test\test.cpp(35) : error C2582: 'operator =' function is unavailable in 'std::tr1::reference_wrapper<_Ty>'

Even though I cannot find a definition of 'operator =' in the source, I could assume that the trivial copy assignment operator bit-copies the internal pointer-to-type.

Thank you.

re: Q&A on our TR1 implementation

Kris G — Wed, 30 Jan 2008 22:34:39 GMT

This stuff is awesome, and really the only reason I want to upgrade to VC9 (a real, working, debuggable, shared_ptr class without having to install the giant mess that is boost)

re: Q&A on our TR1 implementation

H Zhang — Thu, 31 Jan 2008 03:29:32 GMT

Having said that, something still puzzles me:

void f(){cout<<"f"<<endl;}

void g(){cout<<"g"<<endl;}

typedef int*const cpi;

typedef void (*const cpf)();

int main()

{

int a = 100, b=120;

cpi cpia = &a;

cpi cpib = &b;

cpf cpf1 = & f;

cpf cpf2 = & g;

//cpia = cpib;//can't do this, we already know

//cpf1 = cpf2;//can't do this either, we all know

reference_wrapper<cpi> ra(cpia), rb(cpib);

reference_wrapper<cpf> rf(cpf1), rg(cpf2);

rf();

//rf = rg;//can we do this? the compiler won't

*ra += 1;

cout<<a<<" ";

ra= rb;//we can do this, the compiler does it

*ra += 2;

cout<<b<<endl;

return 0;

}

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 01 Feb 2008 01:14:36 GMT

Another bug, I'll file it.

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

Noise Reduction in VS2008 Profiler

Colin's Microsoft Developer Blog — Fri, 01 Feb 2008 06:01:34 GMT

ProfilerOne of the new features in Visual Studio Team System (VS2008) is called Noise Reduction. This

Noise Reduction in the VS2008 Profiler

Noticias externas — Fri, 01 Feb 2008 06:49:59 GMT

ProfilerOne of the new features in Visual Studio Team System (VS2008) is called Noise Reduction. This

re: Q&A on our TR1 implementation

Kim Gräsman — Thu, 07 Feb 2008 22:31:57 GMT

Hello,

I'm a little late to the game, but does the feature pack contain new redist MSIs for the CRT dlls?

Thanks,

- Kim

re: Q&A on our TR1 implementation

mjf — Tue, 12 Feb 2008 01:30:35 GMT

Can these libraries be used with Smart Device (Windows Mobile) projects?

flaw in hash_set and unordered_set performance

gulli — Thu, 21 Feb 2008 16:18:27 GMT

Hello,

during playing with the feature pack I found a performance characteristic that looks strange to me.

A simple A*-example-App needs to test whether it has seen an unsigned long long before - any set-style class can handle that:

std::set<unsigned long long> vals;

...

while(...)

{

unsigned long long val=...

if(vals.insert(val).second)

//not yet seen

else

//seen

...

}

Since stdext::hash_set and std::tr1::unordered_set (and mingw gcc 3.4.5 __gnu_cxx::hash_set) share this interface I made a perf comparison (for the mingw I had to implement the hash-function)

The results are strange (just used task manager to measure cpu-time):

using std::set mingw and vs 2008 keep pace:

vs: 36 sec

mingw: 35 sec

using __gnu_cxx::hash_set shows the expected drop in computing time: 28 sec

but the 2 VS2008 hash sets use a lot more computing time than before which renders them rather useless:

stdext::hash_set: 50 sec

std::tr1::unordered_set: 53 sec

is there a way to adress this?

thanks

gulli

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 22 Feb 2008 02:51:03 GMT

[Kim Gräsman]

> I'm a little late to the game, but does the feature

> pack contain new redist MSIs for the CRT dlls?

Yes; otherwise, end users would be unable to run TR1-powered applications. VCRedist has also been updated (although VC recommends against its use).

[mjf]

> Can these libraries be used with Smart Device

> (Windows Mobile) projects?

Anything that can use VC9's STL can use TR1.

[gulli]

> flaw in hash_set and unordered_set performance

I will investigate.

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

re: Q&A on our TR1 implementation

Stephan T. Lavavej [MSFT] — Fri, 22 Feb 2008 05:20:34 GMT

I have filed a bug about our hash_set/unordered_set performance. (I also found an infinite loop bug in <random> while I was at it.)

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

Channel 9: Stephan T. Lavavej: Digging into C++ Technical Report 1 (TR1)

Visual C++ Team Blog — Tue, 26 Feb 2008 00:33:16 GMT

Hello Recently we shipped a beta of our MFC/TR1 Feature Pack that, naturally enough, included a large

Channel 9: Stephan T. Lavavej: Digging into C++ Technical Report 1 (TR1)

Noticias externas — Tue, 26 Feb 2008 01:23:34 GMT

Hello Recently we shipped a beta of our MFC/TR1 Feature Pack that, naturally enough, included a large

vc9 Feature Pack tr1 的一些问题

WuErPing — Sat, 29 Mar 2008 04:58:58 GMT

vc9 Feature Pack tr1 的一些问题一、头文件包含的问题二、regex memory leak

Visual C++ 2008 Feature Pack Released!

Visual C++ Team Blog — Mon, 07 Apr 2008 15:49:00 GMT

The final release of the Visual C++ 2008 Feature Pack is now available for download. This release provides

Visual C++ 2008 Feature Pack

Johan Lindfors — Mon, 07 Apr 2008 20:41:12 GMT

Nu finns ett så kallat Feature Pack till Visual C++ 2008 att ladda he m för alla kunder med

Visual C++ 2008 Feature Pack Released

US ISV Developer Evangelism Team — Mon, 07 Apr 2008 21:05:25 GMT

The final release of the Visual C++ 2008 Feature Pack is now available for download. This release provides

Visual C++ 2008 Feature Pack Released

Ruud de Jonge — Tue, 08 Apr 2008 10:39:13 GMT

Hello all, The final release of the Visual C++ 2008 Feature Pack is now available for download. 

C++ Gets Some Love

Is This Thing On? — Fri, 11 Apr 2008 17:08:56 GMT

Good news from the C++ Team!!   ================== The final release of the Visual C++ 2008 Feature

Visual C++ 2008 Feature Pack Released

Andrew Coates ::: MSFT — Tue, 29 Apr 2008 11:05:48 GMT

During my Windows Development session at the Heroes Happen { 2008 } launch shows around the country,

TR1 Fixes In VC9 SP1

Visual C++ Team Blog — Mon, 11 Aug 2008 22:37:46 GMT

STL enjoys speaking in the third person and also enjoys bringing you this exclusive news: Visual Studio

简介Visual C 2008 Feature Pack

Henry Read — Sun, 18 Jan 2009 12:13:18 GMT

无数的VisualC 程序员为了那几个单调、简单VisualC 的控件苦恼着；而无数的VisualC 程序员又因为这个界面问题而大发其财。BCGLibrary、MagicSkin这些...