Libraries work in Orcas

Libraries work in Orcas

Rate This
  • Comments 18

Hi! My name is Ale Contenti. I'm a developer on the Visual C++ Libraries Team. I work on the CRT (C Run Time, i.e. strcpy() and printf(), like I always explain to my friends), SCL (Standard C++ Library, i.e. STL and streams), ATL and MFC. I also happen to work for Martyn, which blogged here a few weeks ago.


So, if you read Martyn's post, you already know what the Libraries Team is going to work on during Orcas. One of the area's that I'm working on is STL/CLR.  We're making good progress on this, too!  You can finally put your hands on a pre-release of STL/CLR in the next available CTP (it should be online in August). You can also find some cool postings on STL/CLR on Nikola's blog.


Ok, but what do I really do? During last product cycle I worked a lot on the Secure Libraries (i.e. strcpy_s() and checked iterators). During Orcas, I've been working on STL/CLR performance investigations for the last month or so.


STL/CLR is pretty cool. It is developed by Dinkumware. Here in VC++ we analyze and test the drops they give us, and we open bugs and give feedback on the design of some parts of the library. Recently, we've been focusing on improving the performance of some key scenarios.


We decided to compare STL/CLR perf against two other libraries:

  • STL, which works only on native types and use the native heap);
  • BCL, i.e. the collection library in the .Net Framework, basically the collections in System::Collections

Notice that it’s pretty easy to compare STL and STL/CLR, because they are based on the same (simplified) principles:

  • containers, which have member functions do add, remove and access elements;
  • algorithms, i.e. external functions which operates on ranges of values;
  • iterators, i.e. the glue between containers and algorithms.

An important difference, though, is that STL is native code

  • can be compiled /clr and /clr:pure;
  • cannot be compiled /clr:safe (i.e. the code is not verifiable, because it uses pointers and native storage);
  • works only with native types;
  • use native storage (i.e. new/delete).

On the other side, STL/CLR is a managed library, written entirely in C++/CLI, and all STL/CLR is verifiable code

  • can be compiler /clr, /clr:pure, /clr:safe
  • works only with managed types (and C++/CLI built-in type);
  • use garbage collected storage (i.e. gcnew/delete).

The result of our investigation is that STL/CLR is slower than STL most of the time. The advantage of native code, especially in code like this, is still pretty high. But STL/CLR is not order of magnitude slower… we’re still doing pretty well overall.


Comparing against BCL is more important for STL/CLR, since they both can store the same managed types. Some of the characteristics of BCL are:

  •  only have containers and enumerators;
  • based on generics (while STL/CLR is based on both templates and generics).

All the operations that STL/CLR usually implements separately as algorithms (like sort) are implemented as member functions of the BCL collections themselves. This gives the BCL collections a perf advantage, since their sort method knows about the internal implementation of the collection. On the other side, STL/CLR containers and algorithms are more versatile, and this gives STL/CLR an advantage when, for example, you need to sort with a custom operator<.


In our tests, we’ve seen this pattern: STL/CLR is more or less on par with BCL, and can be a little faster than BCL in some scenarios.


Notice that this performance work is not yet done! The STL/CLR you will see in the August CTP has some good overall performance, but it’s still an early preview! And it's important you try it out and tell us what scenario you care about most, how do you want to use it, etc. so that we can beef up our perf tests even more!


Let us know! And thanks again for all the feedback (not only on STL/CLR).


Next time I want to post some real code and some interesting things we found while playing around with this big C++/CLI templated library. Stay tuned! J


Ale Contenti


VC++ Libraries Team


  • Visual Studio 2005 ( no service pack applied...)

    I have recompiled all my C++ release build with _SECURE_SCL=0. I am getting access violations when iterating on a  std::set with a custom "Compare". I use various STL classes throughout my code and this access violation happens only on this std::set with the custom compare function ( and  _SECURE_SCL=0)

    The application passes QA with  _SECURE_SCL=1 in both Debug and Release mode. I can almost be 100% sure all my code that uses this set class has  _SECURE_SCL=0 defined as I wrap std::set in a thin layer in my own header where I can #error if  _SECURE_SCL!=0

  • The above bug is exactly the same as mine.  I'm using a library that's only available in 1 form.  I'm not sure whether _SECURE_SCL is 0 or 1 in the library, is there any way to tell?

    Either way, I'm getting internal errors in vectors, even those declared on the stack.

  • PingBack from

Page 2 of 2 (18 items) 12