Boost logo

Boost :

From: Holger Grund (yahoo_at_[hidden])
Date: 2005-04-03 09:11:32


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

-hg


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk