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


Leave a Comment
  • Please add 7 and 5 and type the answer here:
  • Post
  • Would you consider providing an STL implementation optimised for speed? Even compilers as good as VC8 can't eliminate all the abstraction penalty; I've noticed that standard algorithms are often faster when passed pointers than vector iterators, for example.

    The checked iterators are a 'feature' which many people didn't want: most software runs solely in the context of an interactive user and has no remote connectivity, which somewhat mitigates the risk (and value) of the safety features (and of the software being attacked). Indeed, a lot of software deals exclusively with proprietary formats (unlikely to be targeted) or third-party libraries that aren't affected by the runtime linked to the host.

    Using other STL implementations can result in a 15% performance improvement over the VC2005 STL (in its default configuration) in applications I've worked on which are completely internal.

    I think it's fine that the SCL features exist (though I'd be surprised if you could cite three public examples of code where the STL was used in a way that caused a serious vulnerability) and I think it's absolutely correct that those features are enabled by default. All I want is a good library for my completely isolated, non-interactive, user-mode release builds.

    (Oh, and "On par" with the BCL makes the STL/CLR pretty worthless; once I've sacrificed the performance, I'd rather be more interoperable)
  • Anon, did you try to use the _SECURE_SCL=0 in your release build?
  • > Oh, and "On par" with the BCL makes
    > the STL/CLR pretty worthless; once
    > I've sacrificed the performance, I'd
    > rather be more interoperable)

    Probably the most important goal for STL/CLR is a migration of existing STL code to verifiable MSIL (so you don't have to rewrite everything using BCL classes). Maybe someone from VC team can comment on that.
  • Thanks for your comments, Anon & KiwiBlue!

    So, first about checked iterators. I'm happy we agree on the importance of having the checks on by default.

    A simple std::copy can turn into a buffer overrun pretty easily, especially if the destination is a C style array (i.e. just a pointer).

    Like KiwiBlue says, you can turn off checked iterators setting _SECURE_SCL=0.

    Also, every STL algorithm, internally, uses unchecked iterators. For example, when you call std::sort(v.begin(), v.end()), both v.begin() and v.end() are checked iterators. But std::sort immediately creates two unchecked iterators and uses them to actually sort the vector. And the unchecked version of a vector checked iterator is indeed a pointer, like Anon suggests!

    We're always very interested in improving the perf of our libraries! Do you have any example where you see the 15% perf degradation? It would be great to have them and work on them!
  • Now, about STL/CLR goals:
    1) easy migration of existing STL codebase to (like KiwiBlue said)
    2) leverage templates and the better inlining/optimization of the C++ compiler
    3) nice interop between STL/CLR <-> BCL
    4) introduce the STL abstractions for C++/CLI

    If you already have code which uses BCL, we're not expecting you to migrate it to STL/CLR.

    An example of (1) is that you can easily reuse your algorithms. Indeed, many of the STL/CLR algorithms are very similar to the STL ones.

    Also, we will provide iterator/container adapters for the BCL ICollection<T>, IList<T>, etc. so that you can use the BCL collections with your existing algorithms, too.

    About (2), it means that in some cases you have a specific perf advantage over the BCL, when you can leverage the better inlining capabilities exposed by templates (vs. generics).

    And with (3), you don't have to give up interop with the BCL: Every STL/CLR expose the corresponding BCL interfaces. When you have a vector<int>, you also have a IList<int>, and the same goes for map, hash_map (they implement IDictionary), etc.

    I'm not saying that STL/CLR is perfect, but it's definetely worth a try if you are in the C++ and C++/CLI world. Please let us know what we got wrong, what you think this would be useful for (or not useful), etc.

    For example, what's most important to you? interop between STL and STL/CLR or interop between BCL and STL/CLR?

    Thx again!
  • Ale is talking about his work on STL/CLR on VCBlog. You may find it here,
  • Just to mention this: I found a bug with _SECURE_SCL involving hash_map:

    the vc8.0 hash_map uses std::list for its buckets. The hash_map operator[] does a lookup and compares the resulting iterator with end(). The problem is that the std::list::iterator operator== checks that both iterator belong to the same std::list, which fails!

    My problem is that I find the checks useful, but it is not possible to selectively turn the check off for a single file because the std::list iterator implementation varies (in size, among other things) when _SECURE_SCL is 0 or 1, which lead to hard crash when two file compiled with different options are used together...
  • Did you ever compare STL that ships with VS2005 with Dinkumware/STLPORT (all unmanaged)? I was curious if these results are available anywhere. We are finding that STLPORT is better in performance compare to VS2005 STL. I am wondering if its because we are not using appropriate compiler switches.

  • About my comments of _SECURE_SCL vs. hash_map vs. std::list... I got feedback here internally that the problem only appears if one std::swap() two hash_maps. I've yet to confirm this, but it may point to something for you.
  • The Visual C++ team is pleased to announce that a public release of STL/CLR has been included in the...
  • Great work!

    [url=]My homepage[/url] | [url=]Cool site[/url]

  • Great work!

    <a href="">My homepage</a> | <a href="">Please visit</a>

  • Well done! |

  • Hi, My name is Andreea Isac and I’ve been a member of the Visual C++ Libraries team for one year and

  • When setting _SECURE_SCL=0, one must be careful to rebuild all (third party) libraries.

    Otherwise, the linked program may contain several definitions of the same functions; some using _SECURE_SCL=1, some _SECURE_SCL=0. The compiler/linker does not diagnose this. The resulting executable will contain undefined behavior, which obviously may lead to all sorts of interesting situations (e.g. crashes in our case).

    One more issue is that many vendors only provide their libraries compiled with one set of settings (either with _SECURE_SCL 0 or 1). You have to check which one, and if you have builds needing the other, build the library yourself and adjust your build settings to use the correct libraries.

    See also

Page 1 of 2 (18 items) 12