"Paul A Bristow" <pbristow@hetp.u-net.com> wrote

How much of Boost, if any, can be compiled and used with the /clr option in force?

Almost every valid C++ program is also a valid C++/CLI program. I doubt that you'll see real world code which would cause any problems.There are some valid C++ programs that won't work with /clr or exhibit different behavior. But these are really obscure cases, that you wouldn't write unless you wanted to break /clr compilation ;-) I believe the only one that ever came up in Microsofts own codebase was a #define interface struct which is used by MIDL generated files (interface struct is considered a single identifier here, therefore interface won't be replaced by struct during macro expansion) However, that doesn't mean things would work with managed types. But that really depends on what you're trying to do. For instance, I've used MPL to implement something along the lines of specialization of generics. But since it operates on types it's not too surprising. OTOH, things like boost::unordered_map<String^,String^> won't work for quite obvious reasons (at least with the current language standard)

Some advantages of C++/CLI are pretty obvious, but what are the gotchas?

While Microsoft did an excellent job on source-level compatibility with standard C++, I think they did very poor job on the "C++ culture". When you try to move some code from native to managed (and managed data - raw C++ with /clr yields MSIL code which does not operate on the garbage-collected heap) you'll quickly learn that C++ idioms just don't work very well. Some of the limitations result directly from requirements of the CLR's execution engine while others are just deliberate language design decisions. So the short story: if you only want to integrate some .NET functionality into your existing codebase, just throw /clr at it and you're fine (well, in theory at least ;-) ) Of course, you might want to isolate functionality which relies on the /clr switch. If you want to C++/CLI as a migration path for C++ expertise, then better think twice. It's probably still your best bet, but only because other options are worse :-( Of course, native code continues to work - at least for the forseeable future. Here's the somewhat longer story (which has little relation to Boost), why I feel C++/CLI just doesn't cut it. The are simply so many little and not so little oddities in the language design that developing with C++/CLI is a real pain. To list just some of my pet peeves: (where R,V,N are reference, value and native - standard C++ class - types). These only apply to the extensions. So long as you use standard C++ code, the standard C++ semantics are preserved. - overloaded operators apply to both pointer types (R^,V^) and class types (R,V). - constructor & destructor model tied to incompatible IDisposable model, so your code should expect that your destructor may be called on partially constructed objects and the destructor be called more than once - Support for types with reference semantics is fairly limited (no R% can have static or dynamic storage duration) - no support for const member functions, which makes working with const managed objects/references a pain. - Value types can't have special member functions - Type symmetry is broken for reference and value types. R^,R% act much like N* and N&. V^,V% have entirely different semantics. Which also causes taking the address of a V% or dereferencing a V^ to return a temporary. - Objects of managed class types can't have static storage duration. And these are only the things of the language design. Then there's also the .NET base class library. Designing a class library, especially of the size of the .NET BCL, is quite difficult. Apparently, Microsoft thought they could do better than others. Well, judge for yourself (one of my favorites is http://msdn2.microsoft.com/library/d312z50h(en-US,VS.80).aspx) I think it's one step forward and two steps back. I spent quite a bit of time on sorting out all kinds of ABI issues on Intel's XScale compiler. The ARM EABI is the most ambitious one I know of in terms of object-level compatibility, but still it doesn't even try to standardize things in presence of Standard C++ library functionality. That's were the CLR type system really shines. However, it also imposes serious restrictions on your code. Single-inheritance only, only weak construction & destruction guarantees, can't have leightweight managed pointer members. And if you care about compatibility with other managed languages you also can't use objects of class type or references to class types in your public interface or even free (namespace-scope non-member) functions. Just my two cents. -hg