RE: [boost] Re: [Filesystem] Feature Request:Onemoreimplementationusing.NET

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-04-03 12:21:26

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Holger Grund
> Subject: [boost] Re: [Filesystem] Feature
> Request:Onemoreimplementationusing.NET
> 
> "Edward Diener" <eddielee_at_[hidden]> 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.