Orcas CTP now includes STL/CLR

The Visual C++ team is pleased to announce that a public release of STL/CLR has been included in the current Visual Studio Code Name “Orcas” September 2006 CTP.  STL/CLR is an implementation of the Standard Template Library (STL) that can be used for storing .Net types in STL-like containers. It also provides STL-like iterators and algorithms to operate on data stored in containers. As such, it brings the power and productivity of traditional development using STL to the .NET platform.  In addition, the library helps in organizing data exchange between native and managed code and helps in re-using existing customized algorithms that operate on STL iterators.

To learn more about STL/CLR please check documentation included with the CTP. You may also check a post on vcblog by Ale and series of posts on Nikola’s blog.

This version of the library provides core functionality ready for use in VC++ applications. Some areas of the library have not been implemented yet and we are currently working on these. Below you may find a brief summary of known issues in the version of the released STL/CLR library. The list does not enumerate all issues in the build, rather it lists major code defects or areas of missing functionality that are most likely to be hit while using this build.

Not implemented functionality

 

This version of the library does not provide adapters that facilitate data exchange between STL/CLR containers and objects of the .Net Collections classes (System::Collections or System::Collections::Generic). For the final release it is our plan to add adapters that can be used for this task. More details for this part of STL/CLR will be available in future previews of the library.

IDE Integration

–          On the initial run of Visual Studio IDE, if you try building a VC++ project that uses STL/CLR, you may see the following error:

> … : fatal error C1107: could not find assembly “Microsoft.VisualC.STLCLR.dll”: please specify the assembly search path using /AI or by setting the LIBPATH environment variable

If you get this error in your project, you need to save all your work, close Visual Studio IDE and open it again. Then you need to load your project back and build it again. You should not be seeing this error anymore.

–          Visualization of STL containers added in Visual Studio 2005 is not enabled for STL/CLR containers. We are working on enabling this feature for the next preview.

–          STL/CLR uses a .Net assembly Microsoft.VisualC.StlClr.dll. This assembly is installed into the GAC during installation of Visual Studio. Redistribution of this assembly is not supported in the CTP.

Known issues in containers

Below are known implementation defects that we are investigating and are expecting to fix in the next previews of the library.

–          Destructors of STL/CLR containers (for example, ~vector<R>() ) do not call the destructors ~R() for their elements.

–          cliext::pair<> is not available. You may use cliext::ref_pair<> instead for now.

–          For all containers, operator= does not take a handle to a container. For example, list<>::operator= does not take list<>^.  Thus, the following does not work:

list<int>^ myList = gcnew list<int>();

list<int>^ c2 = myList;

–   &nbs p;      cliext::stack<>, cliext::queue<>, and cliext::priority_queue<> cannot be constructed with a handle to a container of the same type. For example:

queue<int>^ myQueue = gcnew queue<int>();

queue<int>^ c1(myQueue);

–          Attempting to compile cliext headers without /clr gives not give clear errors. You may see errors similar to these:

..VCINCLUDEcliext/xutility(24) : error C2144: syntax error : ‘cliext::is_handle’ should be preceded by ‘;’

..VCINCLUDEcliext/xutility(24) : error C4430: missing type specifier – int assumed. Note: C++ does not support default-int

…VCINCLUDEcliext/xutility(24) : error C2143: syntax error : missing ‘;’ before ‘<end Parse>’

Known issues in algorithms

–          We are aware of several issues related to running STL/CLR algorithms on STL and STL/CLR containers. For example, there is an issue with passing std::vector to cliext::find_end, cliext::search, cliext::lower_bound, and cliext::stable_sort. Additionally, running cliext::copy on cliext::list gives compiler errors. However, we would still like you to report any issue you see in your code when try using STL/CLR algorithms.

–          Preincrement/predecriment operators are not implemented in iterators at this point. For example:

c1.insert( ++c1.begin( ), c2.begin( ),–c2.end( ) );

Known performance issues

Some performance issues can be observed with the version of the STL/CLR released in the CTP. We are working on addressing them. However, some differences may also exist later on because of the architecture differences between STL/CLR, STL and the .Net Collections classes. We encourage you report any performance issues you find with the current version of STL/CLR.

STL/CLR vs. STL

STL/CLR performance and STL performance are comparable for containers such as set, map, multiset, multimap and list. In contrast, STL/CLR vector is slower then its STL counterpart because of differences in the data storage used inside these containers. STL data is stored in a big chunk of memory allocated on the native heap. This is not possible to do on the managed heap. Instead, STL/CLR vector<> uses the cli::array<> type. STL can just increment/decrement pointers to the heap, while STL/CLR needs to perform more expensive operations using cli::array<>.

STL/CLR vs. .Net Collection Types

Overall STL/CLR is faster then the .Net Collection types from System::Collections and System::Collections::Generic except in some specific cases. Sorting elements in vector<> using STL/CLR algorithms may take more time then sorting System::Collection::Generic::List<> because of highly-optimized algorithms used by List<>. However random and sequential access of elements in vector<> is faster then in List<>. STL/CLR map is faster then System::Collection::Generic::SortedDictionary<> for most of operations. However STL/CLR hash_map tend to be slower than System::Collection::Generic::Dictionary<> on small value types. We are expecting to improve performance of hash_map in upcoming previews.

Supported types

Per design, STL/CLR containers support storing the following types:

–          reference type (R), including generic versions

–          handle to reference type (R^), including generic versions

–      &nbs p;   value type (V), including generic versions

–          Built-in types, both native C++ and .Net classes, including System::String^

Please let us know about cases when you get errors while using STL/CLR containers to store objects of types from the categories mentioned above.

Areas of feedback

Please feel free to submit any feedback on the STL/CLR library using the Connect website, http://connect.microsoft.com/VisualStudio/. You can also leave comments on the blog. Overall, please try using STL/CLR in your everyday programming in managed code. We would specifically like to hear your feedback in the following areas:

–          Usability of STL/CLR compared to STL. We would like to hear from you about what you like or don’t like about using STL/CLR compared to using STL.

–          Interoperability with managed code written using .Net classes in either C++ or C# or any other .Net language.

–          Any missing functionality that you would expect to be in STL/CLR.

–          Any performance issues you see with your application that uses STL/CLR.

 

I am looking forward to hearing from you!

 

Nikola Dudar

Program Manager

Visual C++ Libraries

Blog: http://blogs.msdn.com/nikolad/