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.
I continue introducing to STL/CLR. In this post I would like to describe what parts of STL library are implemented in STL/CLR.
STL/CLR provides an implementation of each container that is part of STL library. the list of STL containers may also be found here, http://msdn2.microsoft.com/en-us/library/1fe2x6kt(VS.80).aspx. And same list one may see in STL/CLR. Also all STL/CLR containers have same list of methods as their STL counterparts. If you used std::vector<>::push_back() you will see cliext::vector<>::push_back(). However STL/CLR containers may have some additional methods. For example, vector<T> has method to_array(), that can be used to create cli::array<T>. Something like this:
cliext::vector<int>^ v1 = gcnew cliext::vector<int>;
v1->push_back(1); v1->push_back(2); v1->push_back(3);
// copy the container to array
cli::array<int>^ arr = v1->to_array();
// print out array
for each (int elem in arr)
All STL/CLR containers have identical algorithmic complexity characteristics as their native STL counterparts. Supported types that can be stored in STL/CLR containers are:
- reference type (R), including generic versions
- handle to reference type (R^), including generic versions
- value type (V), including generic versions
- Built-in types, both native C++ and .Net classes, including System::String
Some requirements apply to elements stored in STL/CLR containers. Such for R, you need copy constructor and operator=. Destructor is optional, but it is called if it is present. For V, these requirements for a public copy constructor, public assignment operator, and a public destructor do not apply. Associative containers such as set and map must have a public comparison operator defined, which is operator< by default.
As I mentioned earlier, native classes and pointers cannot be stored in STL/CLR containers. If one tries, expect compiler error something along this lines
1>: error C3225: generic type argument for '_Value1_t' cannot be 'int *', it must be a value type or a handle to a reference type
I have tried compiling with int* as type to store as you may see.
STL/CLR provides same set iterators for each category of STL iterators, following list of STL iterators that may be found here, http://msdn2.microsoft.com/en-us/library/28f7db1d(VS.80).aspx. STL hierarchy of iterators is preserved. Increment/decrement operation of iterators has same meaning as in STL. Iterators are validation and range checked. However they are not "Checked iterators" in STL sense. Concept is the same but implementation is absolutely different.
And finally STL/CLR provides the same set of algorithms and utilities as it is in STL. All STL assumptions about algorithms still true for STL/CLR algorithms, http://msdn2.microsoft.com/en-us/library/wh15hsex(VS.80).aspx. STL/CLR algorithms can operate on STL/CLR and STL containers and iterators.
This is briefly on how STL/CLR compares to STL. In my next post I am going introduce parts of STL/CLR that are not in STL. To conclude here is a sample code snippet that used to work just fine with STL and now works with STL/CLR:
using namespace System;
void PrintOutVectorElement(int iCur)
int main(array<System::String ^> ^args)
cliext::vector<int>^ myVect = gcnew cliext::vector<int>();
cliext::for_each(myVect->begin(), myVect->end(), &PrintOutVectorElement);
cliext needs to support the stl string (ie basic_string) at a minimum for us poor guys having to do ports. stringstream's would be nice as well.
Could you please elaborate on why you need basic_string in STL/CLR? For example, leave in a comment a short sample of code in which you would see a benefit of this additioin to STL/CLR.