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? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
Why would anyone want to use the c++/cli other than to torture themselves. I understand you are not suggesting boost in c# but boost based on C++ is superior to boost based on c#. I think it would be difficult to use .net with boost. .net doesn't have templates so structures have to be cast to go in and out of containers, consider the amount of boost libraries that would effect. Jan
Jan Stetka wrote:
Why would anyone want to use the c++/cli other than to torture themselves. I understand you are not suggesting boost in c# but boost based on C++ is superior to boost based on c#. I think it would be difficult to use .net with boost. .net doesn't have templates so structures have to be cast to go in and out of containers, consider the amount of boost libraries that would effect.
Jan
This is an uninformed view. C++/CLI supports templates in addition to generics. Don't be misled by earlier attempts to integrate C++ with .NET. If you formed your judgement by looking at the so-called Managed Extensions in VC7, then you should look with fresh eyes at C++/CLI. -- Eric Niebler Boost Consulting www.boost-consulting.com
So what benefits are we going to see from c++/cli for boost and what negative effects would it have? I would have thought it would use more memory. I've always found .net and COM for that matter virtually impossible to write readable code with. Making C++ more runtime is unneccesary. We (I think I speak for more than myself) don't want another layer between C++ and the operating system. We know what types were using and don't need the language to tell us. On the other hand Boost's future on the Microsoft platform would be ensured by this move as ms are stopping supporting (alledgedly) the win32 api. A number of boost libraries rely on win32 api. Jan
On 11/14/05, Jan Stetka <janpstetka@supanet.com> wrote:
So what benefits are we going to see from c++/cli for boost and what negative effects would it have? I would have thought it would use more memory. I've always found .net and COM for that matter virtually impossible to write readable code with. Making C++ more runtime is unneccesary. We (I think I speak for more than myself) don't want another layer between C++ and the operating system. We know what types were using and don't need the language to tell us. On the other hand Boost's future on the Microsoft platform would be ensured by this move as ms are stopping supporting (alledgedly) the win32 api. A number of boost libraries rely on win32 api.
Where's your source? I've heard nothing but "We plan to support WinAPI and WinFX, which relies heavily on WinAPI." I've also heard that they have no plans to force you to write managed code.
Jan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
I think you are getting winapi which is a .net thing mixed up with the native win32 api that boost uses. Sorry can't give you a source. Microsoft is keeping its cards close to its chest on that
Jan Stetka wrote:
I think you are getting winapi which is a .net thing mixed up with the native win32 api that boost uses. Sorry can't give you a source. Microsoft is keeping its cards close to its chest on that
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Isn't winapi just the non-32-bit specific name for win32, which isn't actually just for 32-bit? -- don't quote this
no. but I like the way your thinking there. I think mixing boost and .net code would be an interesting thing to do .net is popular in big business so would open up boost to new users.
(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 :)
.net users use .net for the whats already built into it which duplicated functionality in boost and they like the virtual machine which boost is really not designed for. its just boost and .net are aimed at 2 very different groups of people.
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 :)
I assume the OP wants to do things like: typedef boost::tuple<String^, Int> cli_tuple; Haven't looked in detail but I assume a new trait is_managed<T> is needed and the normal traits, is_const etc, need to work with ref types. For tuple specificly the access_traits need to handle ref types Somthing like: template <class T> struct access_traits<T^> { typedef T^ const_type; typedef T^ non_const_type; typedef T^ parameter_type; }; A more interesting question is what boost libraries should work with managed objects. Microsoft has an interesting view. They implement special CLI versions (with range checking etc) of the STL containers (STL.NET) to reuse built up STL knowledge. Using the same view with boost means that libraries like date_time, filesystem and regex could use the .Net framework as implementation while keeping the interface. Other boost libraries like tuple and multi_index might still have a legitimate use under CLI.
participants (1)
-
Brian Braatz -
Cory Nelson -
Eric Niebler -
Jan Stetka -
Martin -
relative＠gmx.net -
Simon Buchan