[Filesystem] Feature Request: One more implementation using .NET
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 Windows 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. Any thoughts? -- Pavel Chikulaev
http://www.mono-project.com A .NET multi-platform project On Apr 2, 2005, at 9:01 AM, 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 Windows 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.
Any thoughts?
-- Pavel Chikulaev _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 Windows 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.
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2n1vk$62e$1@sea.gmane.org...
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. You're absolutely right, but what about 2.0? It supports templates and 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. -- Pavel Chikulaev
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2n1vk$62e$1@sea.gmane.org...
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. You're absolutely right, but what about 2.0? It supports templates and 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. -- Pavel Chikulaev
Pavel Chikulaev wrote:
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2n1vk$62e$1@sea.gmane.org...
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. You're absolutely right, but what about 2.0? It supports templates and 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. Now you may feel that this is still useful, and I have done exactly that, although not for .NET, in my own Regular Expression Component Library using Boost regex++, but I do not think you can ask any of the Boost programmers to do that for you. If you decide to take a Boost library and create a .NET implementation for it for your own use or that of others, no one will object. But I think it is wrong to ask Boost implementors to work with an implementation that is not standard C++. After all Boost is about the C++ standard and creating advanced implementations which follow that standard as much as possible.
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2oo3n$4oq$1@sea.gmane.org...
Now you may feel that this is still useful, and I have done exactly that, although not for .NET, in my own Regular Expression Component Library using Boost regex++, but I do not think you can ask any of the Boost programmers to do that for you. If you decide to take a Boost library and create a .NET implementation for it for your own use or that of others, no one will object. I asked it, because I would like to do it by myself and because even in managed C++ I still want to use boost libraries(and iostreams). I just wanted to know does anybody else need it? But I think it is wrong to ask Boost implementors to work with an implementation that is not standard C++. After all Boost is about the C++ standard and creating advanced implementations which follow that standard as much as possible. What about Posix and Windows implementation?
-- Pavel Chikulaev
Pavel Chikulaev wrote:
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2oo3n$4oq$1@sea.gmane.org...
Now you may feel that this is still useful, and I have done exactly that, although not for .NET, in my own Regular Expression Component Library using Boost regex++, but I do not think you can ask any of the Boost programmers to do that for you. If you decide to take a Boost library and create a .NET implementation for it for your own use or that of others, no one will object. I asked it, because I would like to do it by myself and because even in managed C++ I still want to use boost libraries(and iostreams). I just wanted to know does anybody else need it?
The need may be minimal because once you target .NET you may be limiting yourself to a single OS and environment ( I am aware of Mono ). More importantly .NET already has a set of filesystem like classes, so you are competing against something that is already there. But if you feel it is worthwhile and useful for others, go for it ( that is what I did with my library ). Yu can even sell it if you like. There is nothing in Boost that limits you from using it in a commercial product just as long as you are not trying to sell a Boost implementation itself.
But I think it is wrong to ask Boost implementors to work with an implementation that is not standard C++. After all Boost is about the C++ standard and creating advanced implementations which follow that standard as much as possible. What about Posix and Windows implementation?
There is nothing about Posix or Windows API implementations that precludes the use of standard C++, although the windows.h header file makes it more difficult to use certain things, particularly macros, with conflict with it. The boost Filesystem library works in Linux/Unix and in Windows.
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2osgg$ep1$1@sea.gmane.org...
The need may be minimal because once you target .NET you may be limiting yourself to a single OS and environment ( I am aware of Mono ). More importantly .NET already has a set of filesystem like classes, so you are competing against something that is already there.
We also have Win32's CreateFile, but so what?
But if you feel it is worthwhile and useful for others, go for it ( that is what I did with my library ). Yu can even sell it if you like.
All I wanted is add to boost::filesystem one more implementation that filesystem's client code will be a bit more portable and safe in terms of Microsoft .NET. -- Pavel Chikulaev
From: "Pavel Chikulaev" <pavel.chikulaev@gmail.com> Pavel, I don't know what mail program you're using, but all of your messages are unreadable to me. Can you change your configuration, at least when sending to the Boost list? Alternatively, does anyone know what configuration change I need to make to my procmail recipes or to rmail in emacs to see these as intended? This is representative of what I see for each of your messages:
--===============0088448905== Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: base64
IkVkd2FyZCBEaWVuZXIiIDxlZGRpZWxlZUB0cm9waWNzb2Z0LmNvbT4gd3JvdGUgaW4gbWVzc2Fn ZSBuZXdzOmQyb28zbiQ0b3EkMUBzZWEuZ21hbmUub3JnLi4uDQo+IE5vdyB5b3UgbWF5IGZlZWwg dGhhdCB0aGlzIGlzIHN0aWxsIHVzZWZ1bCwgYW5kIEkgaGF2ZSBkb25lIGV4YWN0bHkgdGhhdCwN Cj4gYWx0aG91Z2ggbm90IGZvciAuTkVULCBpbiBteSBvd24gUmVndWxhciBFeHByZXNzaW9uIENv bXBvbmVudCBMaWJyYXJ5IHVzaW5nDQo+IEJvb3N0IHJlZ2V4KyssIGJ1dCBJIGRvIG5vdCB0aGlu ayB5b3UgY2FuIGFzayBhbnkgb2YgdGhlIEJvb3N0IHByb2dyYW1tZXJzDQo+IHRvIGRvIHRoYXQg Zm9yIHlvdS4gSWYgeW91IGRlY2lkZSB0byB0YWtlIGEgQm9vc3QgbGlicmFyeSBhbmQgY3JlYXRl IGEgLk5FVA0KPiBpbXBsZW1lbnRhdGlvbiBmb3IgaXQgZm9yIHlvdXIgb3duIHVzZSBvciB0aGF0 IG9mIG90aGVycywgbm8gb25lIHdpbGwNCj4gb2JqZWN0Lg0KSSBhc2tlZCBpdCwgYmVjYXVzZSBJ IHdvdWxkIGxpa2UgdG8gZG8gaXQgYnkgbXlzZWxmIGFuZCBiZWNhdXNlIGV2ZW4gaW4gbWFuYWdl ZCBDKysgDQpJIHN0aWxsIHdhbnQgdG8gdXNlIGJvb3N0IGxpYnJhcmllcyhhbmQgaW9zdHJlYW1z KS4NCkkganVzdCB3YW50ZWQgdG8ga25vdyBkb2VzIGFueWJvZHkgZWxzZSBuZWVkIGl0PyANCj4g QnV0IEkgdGhpbmsgaXQgaXMgd3JvbmcgdG8gYXNrIEJvb3N0IGltcGxlbWVudG9ycyB0byB3b3Jr IHdpdGggYW4NCj4gaW1wbGVtZW50YXRpb24gdGhhdCBpcyBub3Qgc3RhbmRhcmQgQysrLiBBZnRl ciBhbGwgQm9vc3QgaXMgYWJvdXQgdGhlIEMrKw0KPiBzdGFuZGFyZCBhbmQgY3JlYXRpbmcgYWR2 YW5jZWQgaW1wbGVtZW50YXRpb25zIHdoaWNoIGZvbGxvdyB0aGF0IHN0YW5kYXJkIGFzDQo+IG11 Y2ggYXMgcG9zc2libGUuDQpXaGF0IGFib3V0IFBvc2l4IGFuZCBXaW5kb3dzIGltcGxlbWVudGF0 aW9uPw0KDQotLQ0KUGF2ZWwgQ2hpa3VsYWV2DQo=
--===============0088448905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Rob Stewart" <stewart@sig.com> wrote in message news:200504051915.j35JF2X05314@vanzandt.balstatdev.susq.com...
From: "Pavel Chikulaev" <pavel.chikulaev@gmail.com>
Pavel,
I don't know what mail program you're using, but all of your messages are unreadable to me. Can you change your configuration, at least when sending to the Boost list? Alternatively, does anyone know what configuration change I need to make to my procmail recipes or to rmail in emacs to see these as intended?
This is representative of what I see for each of your messages: Thanks for letting me know, I've already changed message format. So know you should read all my new messages without trouble. But I can't repost previous posts, because it will be flood for everybody else. So If you still 'd like to look what is in them, use http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.devel It encodes them easily.
-- Pavel Chikulaev
From: "Pavel Chikulaev" <pavel.chikulaev@gmail.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200504051915.j35JF2X05314@vanzandt.balstatdev.susq.com...
From: "Pavel Chikulaev" <pavel.chikulaev@gmail.com>
Pavel,
I don't know what mail program you're using, but all of your messages are unreadable to me. Can you change your configuration, at least when sending to the Boost list? Alternatively, does anyone know what configuration change I need to make to my procmail recipes or to rmail in emacs to see these as intended?
This is representative of what I see for each of your messages: Thanks for letting me know, I've already changed message format. So know you should read all my new messages without trouble. But I can't repost previous posts, because it will be flood for everybody else. So If you still 'd like to look what is in them, use http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.devel It encodes them easily.
Yeah, I knew about that. I got most of the content from others' replies, anyway. Thanks for changing your format. I can read your messages now. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"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
"Holger Grund" <yahoo@ix-n.net> wrote in message news:d2ot1v$g4t$1@sea.gmane.org...
That's not quite correct. You can have templates of managed types. AFAIK in .NET 2.0 only, isn't it?
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.
You meant coverting std::string to .NET string, didn't you? -- Pavel Chikulaev
"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote
That's not quite correct. You can have templates of managed types. AFAIK in .NET 2.0 only, isn't it?
Templates are obviously a feature of the C++ compiler. VC++ 8 (which will ship with the .NET Framework 2.0) does support templates. VC 7.x do that to a very limited exent only (You can have certain function templates with managed signatures).
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.
You meant coverting std::string to .NET string, didn't you?
No. I meant adding a .NET implementations of the operations of filesystem. E.g. implement find_first_file/next_file/close in terms of System::IO::Directory::GetFiles() and not touching anything else. This can be compiled to managed code only (as can the current Windows implementation). I just don't think it does buy you anything. -hg
"Holger Grund" <yahoo@ix-n.net> wrote in message news:d2p46j$20q$1@sea.gmane.org...
Templates are obviously a feature of the C++ compiler. VC++ 8 (which will ship with the .NET Framework 2.0) does support templates. VC 7.x do that to a very limited exent only (You can have certain function templates with managed signatures). I meant C++ compiler.
No. I meant adding a .NET implementations of the operations of filesystem. E.g. implement find_first_file/next_file/close in terms of System::IO::Directory::GetFiles() and not touching anything else.
This can be compiled to managed code only (as can the current Windows implementation). I just don't think it does buy you anything. May be you right.
"Edward Diener" <eddielee@tropicsoft.com> wrote in message news:d2oo3n$4oq$1@sea.gmane.org...
... If you decide to take a Boost library and create a .NET implementation for it for your own use or that of others, no one will object. But I think it is wrong to ask Boost implementors to work with an implementation that is not standard C++. After all Boost is about the C++ standard and creating advanced implementations which follow that standard as much as possible.
Agreed. I have three priorities for Boost.Filesystem. To refine the i18n interface and associated Windows and POSIX implementations to the point they can be released, to propose the library to the C++ committee for standardization, and to react to bug reports, patches, and other user needs. That is all I can handle for the forseeable future. If someone else wants to contribute another implementation, that would be fine. But it might be best to wait until the i18n work is complete, and the LWG has had a chance to react to a standardization proposal. Otherwise an implementation would be trying to hit a moving target. While the overall design of the library has been stable for a long time now, i18n and standardization will cause lots of minor changes. --Beman
participants (2)
-
Beman Dawes -
Edward Diener -
Holger Grund -
Kon Lovett -
Pavel Chikulaev -
Rob Stewart