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:
Notice that it’s pretty easy to compare STL and STL/CLR, because they are based on the same (simplified) principles:
An important difference, though, is that STL is native code
On the other side, STL/CLR is a managed library, written entirely in C++/CLI, and all STL/CLR is verifiable code
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:
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
VC++ Libraries Team
[url=http://izztqnmu.com/nbfh/eres.html]My homepage[/url] | [url=http://ycbrlvxn.com/atsb/mqnb.html]Cool site[/url]
<a href="http://izztqnmu.com/nbfh/eres.html">My homepage</a> | <a href="http://ywljdtkb.com/jbpg/qmjo.html">Please visit</a>
http://izztqnmu.com/nbfh/eres.html | http://ynhbjroc.com/fxir/pcpf.html
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 http://archives.free.net.ph/message/20060614.141926.e7fb86ae.en.html