Re: [boost] Using Boost with C++/CLI?

From: Holger Grund (yahoo_at_[hidden])
Date: 2006-02-01 15:18:53

"Paul A Bristow" <pbristow_at_[hidden]> 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