(I have been reading this thread with interest. I elected to go back to the original post and respond to that) On 11/4/05 1:45 PM, "relative@gmx.net" <relative@gmx.net> wrote:
is there, or are there plans for, a boost c++/cli subproject?
i've played around with boost and the cli compiler, a lot of libraries work with unmanaged data types (with a lot of warnings, but work), others don't. none work with managed data types of course although that wouldn't be a big problem I suppose. (e.g. boost::tuple)
the spec is there, at least one compiler exists(mono?) and there is a STL called STL.NET by dinkumware(distributed by microsoft) for c++/cli. I haven't found anything on the website or the mailing list archives, is this beyond the scope of the boost project?
This would be easier for me to SEE what you are doing if you coded a sample. That would also give something concrete to talk about :) It SOUNDS like (please correct if I am wrong) that you wish to write some translation layer for the unmanaged types so they maybe used as parameters to boost templates? I am still having a hard time understanding where the problem you are seeking to address is. I.e. (From what LITTLE I understand about CLI) the normal thing in CLI for bridging the boundaries between managed and unmanaged types is to create a class (similar in concept to a PIMPL) and then embed the managed type inside that. // psuedo code struct outer { managed_type_here ^ ref_managed_object; void foobar() { // pass the foobar() call to the managed object ref_managed_object.foobar(); } }; This outer class has a pointer (Stan Lippman calls it a "hat") inside it to the CLI object. It then uses public member functions to expose stock C++ member functions which turn around and call into the managed object. Per (my understanding of) CLI, you are not generally supposed to pass a CLI object into a C++ function. (don't remember if it is even allowed) Using this mechanism would allow one to take the outer class and place it in, say a boost.tuple<>. Which would result in a "managed object" being inside boost.tuple. My Questions: is this along the lines of what you are thinking for a boost-cli library? If not- I suggest you mail the list some sample code. If SO, this is A LOT of work making these wrappers for everything in dotnet How does this fit into boost? This library would be VERY CLI specific (DUH! :) ) If you were REALLY wanting to do this, I suggest you use the reflection capabilities of CLR, dig into the type system- and generate code which implements the above for the Dot Net managed types This *might* be allowed into boost as a "tool" (though this remains *very* platform specific) The output of this tool would be fairly large This might be difficult to test I am *not* discouraging you in the least. Anything we can do to get more people using boost the better. My sour notes are simply based around trying to find a way to FIT this into boost. Even if most people do NOT believe this should go into boost, I believe there is a value to (what I think) you are proposing. Brian :)