From: Edward Diener (eddielee_at_[hidden])
Date: 2005-04-02 16:15:39
Pavel Chikulaev wrote:
>> Dear all,
>> IMO in C++ .NET it's not good idea to use "windows.h"'s plain C
>> functions because someday Microsoft will call them all deprecated or
>> current implementation will not allow make client's code purely
>> managed. .NET implementation of boost::filesystem will make usage of
>> library more safe.
>> Plus, .NET implementaion will possibly work on other platforms than
>> where such classes are available. Actually I don't know any, but I
>> believe Microsoft or somebody else will find a way to do it.
>> So, may be add one more implementation?
>> Sooner or later it should be done.
Adding an implementation of any Boost library to .net means rewriting at
least some of that library in managed C++ for net 1.0 or 1.1 or for C++/CLI
for net 1.2 . I know that managed C++ has no template support ( and under an
NDA I can not disclose anything I know about .net 1.2 that is not public
knowledge ) so basically you are asking that the FileSystem library be
written completely without the use of templates.
Furthermore all C++ modules in net 1.0 and net 1.1 are subject to the DLL
initialization bug if those modules are created as a .NET assembly using
mixed mode C++. Mixed mode C++ involves any C++ code which uses the C++
standard library or the windows API. This bug can occur at any time and
crash the end-user's application and has nothing to do with the programmer's
code, thus essentially destroying all mixed-mode C++ programming of
assemblies for .net 1.0 and .net 1.1. Nor is there any sure workaround for
this bug. This is all well-documented by Microsoft. So the only real
alternative for C++ programmers writing assembles for .net 1.0 and .net 1.1
are to write pure mode managed C++, which is vastly different in many
respects from standard C++ which Boost promotes.
Given these truths it would be exceedingly foolish for Boost, or for the
Boost Filesystem, to be developed for .net as it now exists.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk