This blog is about developing Windows applications using Visual Studio. All postings on this weblog are provided "AS IS" with no warranties, and confer no rights. Use of any samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
Your host Nikola Dudar is a Program Manager in Windows division of Microsoft Corporation. He has been working on Windows Web Services API during Windows 7 and various additions to Visual C++ during VS2005 and VS2008. More details are in LinkedIn profile under Nikola's formal name Mykola Dudar.
If you are interested in program management and project management, check out my other blog at http://www.pmsnack.com/ where I collect best practices and other topics interesting to program and project managers.
To send feedback, comments or requests for new posts, please use the contact form.
STL/CLR, originally called STL.NET, is an implementation of Standard Template Library (STL) that can operate with objects of managed types. VC++ already has implementation of STL, however it is currently working only with native types. If you ever tried inserting an object of managed type in STL container, you would see an error like this one:
error C4439: 'std::xxxx' : function definition with a managed type in the signature must have a __clrcall calling convention
which basically says that compiler cannot instantiate a method from STL that would handle objects of managed types. It was decided not to play with existing implementation of STL to enable it storing objects of managed types so progress on this change does not impact all existing users of STL. STL/CLR has got its own set of headers, with names similar to STL implementation, and namespace – cliext.
Stan has written an introduction paper on STL/CLR published back in 2004. You may find it here. Most on material outline in that paper still apply, however there are some differences, which should not surprise anyone consider that implementation of this library has been changed several times during these two years. For example, name of the folder with all headers for STL/CLR is not cli, but cliext, so instead of doing #include <cli\vector>, one need to do #include <cliext\vector>. Namespace is cliext, not cli, so instead of cli::vector, one need to use cliext::vector. Also there are two sets of algorithms in the current implementation. STL/CLR algorithms and functions in <cliext\algorithm> and <cliext\numeric> is added to enable developers use STL/CLR containers and algorithms in verifiable code (/clr:safe). Stan is right about why we are working on this library. The intent behind STL/CLR is to enable C++ developers, who have many years experience of writing C++ code using STL, to keep using familiar STL-like programming paradigm for storing data in collections instead of switching to start using .Net collection types. With STL/CLR the following can be achieved:
· Use STL-like containers to store objects of managed types
· Use iterators to access elements stored in STL/CLR containers
· Use STL-like algorithms to operate on STL/CLR containers
· Use BCL generic and non-generic collection interfaces to operate on data in STL/CLR containers
· Use STL/CLR specific generic interfaces to operate on data in STL/CLR containers
STL/CLR containers are garbage collected, and the implementation is ‘verifiable’ allowing developers use these collections in Mixed (/clr), Pure (/clr:pure) and Safe (/clr:safe) modes. STL/CLR containers cannot be used to store objects of native types and native pointers. STL containers should be used for this task. STL/CLR algorithms can operate on STL/CLR and STL containers and iterators. I am going to fill out details and show how STL/CLR can be used in my post in future. For now, I think it is a good place for me to stop.