"Edward Diener" <eddielee@tropicsoft.com> wrote
I believe Microsoft will fix that bug in 2.0. The only disadvantage that it's not ready yet.
So, may be we should postpone this question until 2.0 released?
Anyway I don't think it's bad idea to do it with at least .NET 2.0.
The problem is that the .NET classes themselves do not support templates as classes or as public or protected member functions. So moving any of Boost to .NET essentially must drop the use of templates for the programmer using the implementation.
That's not quite correct. You can have templates of managed types. The C++ compiler will instantiate these as usual and create mangled names which many existing languages targetting the CLR can't access (they can still access methods via a base class). BTW: .NET 1.2 has never been released to the public and I think was the CLR version used for some very early alpha (I think when we first got the bits in July 2003, it shipped with a 1.2.30703 or something) VC++'s implementation of the C++/CLI language will enable you to compile almost all of your existing C++ code to managed code only. (the /clr:pure switch) That doesn't mean, however, that magically your code can be accessed from other languages targeting the CLR nor that it will take advantage of integrity/safety features of the GC memory system. If you want a verifiable executable you simply need to rewrite your code (and you can't use certain things in certain contexts like pointer arithmetic or managed references as members ..) The language design is obviously intended to keep our (and oc, MS's own) C++ assets. Just take your code compile with /clr and add new managed functionality with the extensions of the C++/CLI binding. So effectively, writing an implementation with the current structure and using .NET classes for file system access gets you a whole lot of nothing, I'm afraid. -hg