-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Holger Grund Subject: [boost] Re: [Filesystem] Feature Request:Onemoreimplementationusing.NET

"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.

[Brian Braatz Writes:] Forget Managed C++ Bad idea its going away (ugly too) The new CLI layer lets your code "be" C++ code and run in the dot net environment. You keep all the C++ performance by doing this. Only if you choose to expose something via the CLI mechanisms do you suffer performance issues with managed value\reference types Converesly, though what you gain is the ability to take your cpp code and selectively share out interfaces to it to other dot net libraries. Once you SHARE those things however you lose multiple inheritance and you cannot expose CPP templates. Additionally- the "sharing out" mechanism in CLI is akin to the PIMPL idiom (this is how CLI deals with you hooking the two worlds together) As Stan Lippman has said "C++ is multiparadigm. CLI is just another paradigm" The good news is you can use boost regex all day long. You can remain a CPP app , and you can share out functionality with dot net if you so choose.