New Features in C++/CX's <collection.h> for VS 2013 RTM

New Features in C++/CX's <collection.h> for VS 2013 RTM

Rate This
  • Comments 11


Hi, I’m Brandon Jacobs, an intern on the Visual C++ Libraries team. For part of my internship, I was tasked with adding new features to Stephan T. Lavavej’s <collection.h>. It was certainly an honor to be one of the few to contribute to <collection.h>. You can find these changes in VS 2013 RTM (these changes are not in 2013 Preview).



These are the changes I’ve made to <collection.h>:

1.            Added UnorderedMap and UnorderedMapView wrapper classes to <collection.h>.

2.            Added initializer_list constructors to Vector, VectorView, Map, MapView,  UnorderedMap, and UnorderedMapView.

3.            Added validation so that customers use valid WinRT types to instantiate the collections in <collection.h>.



UnorderedMap and UnorderedMapView:

This is the wrapper class for the std::unordered_map class. The functionality is the same as Map and MapView. The only difference is the underlying data structure, which is a hash table instead of a balanced binary tree. So, types must be hashable and must be able to show equality. Just like Map and MapView defaults to std::less,  UnorderedMap and UnorderedMapView defaults to std::hash and std::equal_to. Both the hash and equality predicates are template parameters, so you are allowed to change the actions of UnorderedMap and UnorderedMapView by providing your own predicates.


initializer_list constructors:

You can now construct any data structure using the C++11 initializer_list constructors.

An example:

namespace WFC = Windows::Foundation::Collections;

namespace PC = Platform::Collections;

WFC::IVector<int>^ v = ref new PC::Vector<int>{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };

WFC::IMap<int, int>^ m

= ref new PC::Map<int, int>{ { 1, 10 }, { 2, 20 }, { 3, 30 }, { 4, 40 } };

WFC::IMap<int, int>^ m2

= ref new PC::UnorderedMap<int, int>{ { 1, 10 }, { 2, 20 }, { 3, 30 }, { 4, 40 } };


Valid WinRT types only:

We now check whether the type you want to store in your given data structure is a valid WinRT type. Currently if you have:


You will get an odd compiler error. Now we check whether the types passed in are valid WinRT types. If this check fails, you will now get a much nicer compiler error that even includes the line in which you tried to create a collection with an invalid type.

Only the items that will appear in the Windows::Foundation::Collections interfaces need to be valid WinRT types. Predicates such as std::less, std::hash, etc. are not passed into the Windows::Foundation::Collections interfaces, so they are not affected by that restriction.

Valid WinRT types are:

  1. integers
  2. interface class ^
  3. public ref class^
  4. value struct
  5. public enum class


Thank you for taking the time and reading this post,

Brandon Jacobs

SDE Intern – Visual C++ Libraries

  • Did this article was cleared before by anyone or is intern permitted to post freely?

  • Does this suggest VS2013 RTM is now complete? How long till we can download? Thanks

  • Kleave:  We trust our colleagues, but we also have a fairly rigorous review process for both code reviews and blog article reviews (for all changes, made by everyone on the Visual C++ Libraries team).  Rest assured, several members of the Visual C++ Libraries team reviewed both the changes to <collection.h> and this blog article.  :-)

    Gary:  Visual Studio 2013 is not yet complete, so if you find bugs in the Visual Studio 2013 Preview please report them on Microsoft Connect!  But, as we get changes integrated into our release branches, we'll start discussing them here on the Visual C++ Team Blog.

  • Hey, Brandon,

    Why are you talking about WinRT in this article?  I know you're an intern, so I'm assuming you are fairly young, but before there was WinRT, there was this whole world of Windows applications called "desktop applications".  I know that your colleagues at Microsoft like to pretend that desktop applications either never existed or that there is no reason left for anybody to write or maintain one.  But I can assure you that is not the case.

    That said, it's just weird to bring up WinRT in this article.  It makes it seem like your changes to the STL only apply to WinRT.  Certainly, if I'm writing a non-Metro application, the types that I store in a collection do not have to be valid WinRT types, right?  I think the WinRT part of this post should have been done as a separate post and posted in a blog specifically about WinRT applications, where it could have been understood in a proper context.

    I have to add this:  We often joke when we find something from Microsoft that is poorly designed or just doesn't work that Microsoft shouldn't have let the interns work on it.  Now, come to find out, maybe that wasn't such a joke!



  • Okay, I think I've got this wrong.  This article *does* only apply to Metro apps, is that right?  If so, then the mistake was not making it clear from the top of the post that this content applies to Metro apps only.  Not everybody knows that when you say you changed <collection.h> that that is a Metro thing.  So, quite frankly, this entire post should not have appeared on the Visual C++ Team blog; it should have been posted on a Metro apps blog.

  • Okay, did the title change to now include "C++/CX"?  Or did I miss that the first time?  If you added it, thanks, that's helpful.

  • small_mountain_0705: collection.h is not part of the STL, it is a layer on top of the STL. In fact, they use different terminology - WinRT talks about "collections" while the STL talks about "containers". (The difference is subtle but significant: a container physically contains its elements and controls their lifetimes.) They also use different naming conventions: WFC::IVector and PC::Vector versus std::vector. And of course, <collection.h> has a file extension, while C++ Standard Library headers are extensionless.

    I apologize for any confusion. I reviewed Brandon's post and suggested linking to MSDN's <collection.h> documentation upon the first mention, but I thought it was clear that this was a C++/CX-specific post even without clicking on that link and I was wrong. (I guess I figured everyone could distinguish Standard from non-Standard headers on sight.)

    > Okay, did the title change to now include "C++/CX"?

    Yes, it was changed (not sure by who, wasn't me). We do listen. :->

  • To reiterate what STL said, we did update the title to more accurately reflect the changes described in the article itself.

    Our interns are a bright bunch, but they do follow the same process all of us follow before posting to this blog -- technical review. This standard holds for anyone who posts to this blog.

    By the way, we invite authors to submit ideas and articles for the Visual C++ blog. If you have ideas, send them to We are especially interested in best practices for bringing C++ 11 features into legacy applications :)

  • Stephan, I was confused too.  I knew it wasn't part of STL, but had no idea that it was part of C++/CX.  In fact, I'd never heard of the header before.

  • Need Visual Studio For Windows RT

  • more details of c++ click hear

Page 1 of 1 (11 items)