STL/CLR comparing to STL
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, https://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)
System::Console::Write("{0}", elem);
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, https://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, https://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:
#include <cliext\vector>
#include <cliext\algorithm>
using namespace System;
void PrintOutVectorElement(int iCur)
{
Console::WriteLine("{0}", iCur);
}
int main(array<System::String ^> ^args)
{
cliext::vector<int>^ myVect = gcnew cliext::vector<int>();
myVect->push_back(1);
myVect->push_back(2);
myVect->push_back(3);
myVect->push_back(4);
cliext::for_each(myVect->begin(), myVect->end(), &PrintOutVectorElement);
return 0;
}
Comments
Anonymous
May 22, 2007
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.Anonymous
May 23, 2007
Hi John, 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. Thanks, Nikola