Hi, I think I'll look into CLI. It looks hot, right? Any recommendation for resources like "CLI/C++ for intermediate C++ programmer"? Ciao, Imi. BTW: I've no background in Managed C++.

C++/CLI is a pretty horrid language to deal with, and unless you have a compelling requirement (i.e., you need to do advanced interoperation between native and managed code) there is no real reason to use it.

Quote:Original post by jpetrie
C++/CLI is a pretty horrid language to deal with

Why?

Ciao, Imi.

It is designed almost exclusively to serve the needs of interoperation between managed and native environments. Since those environments differ so widely, you end up having to work in something that resembles the lowest common denominator of the functional space those environments share -- and that is a very small space.

There are changes in the behavior of the "C++" aspect of the language (delete, how templates interact with types, how types are exposed outside the DLL, what types are present,...), and there are concepts missing from the "managed" aspect of the language (delegating constructors, many of the more advanced utility concepts,...) . There are things you flat-out cannot do, such as creating mixed-mode types, using templates (if you want Intellisense in your resulting assembly from a managed perspective). Et cetera.

Finally you need a pretty solid understanding of how both native and managed code environments function. You need to understand when it is appropriate to pin pointers or create GC root handles, when to use tracking references and when not to. How all the various interrelated aspects of the CLR and a native code domain play together (or not, as the case may be).

C++/CLI isn't designed to be a general purpose programming language. It is designed to do one thing well, and that one thing -- being nasty and complex by nature -- makes for a nasty and complex language (more complex than C++ alone, because it retains most of the dark corners of that language). The "use the best tool for the job" adage should apply here: unless you're building an interop layer, C++/CLI is not the best tool for the job. Even if you are, P/Invoke may be sufficient.

As for your original question... there are few/no books on the subject except the standard and the documentation on MSDN. There is also very limited toolchain support (only VS has real compiler support for it at the moment, afaik, and VS does not provide Intellisense support for C++/CLI in the newest version).

Quote:Original post by jpetrie
you end up having to work in something that resembles the lowest common denominator of the functional space those environments share -- and that is a very small space.

There are changes in the behavior of the "C++" aspect of the language (delete, how templates interact with types,

Hm.. I only read about how delete and garbage collecting works for managed objects in CLI. And I have to say, that it convinced me quite a lot. If I had to design a memory garbage collector for C++ and still want to keep the RAII-idiom (which I think is superiour to the try/finally approach advertised by other languages), then I would probably come out with exactly what C++/CLI did: Keeping the destructor that is guaranteed to be called (and as soon as possible) where I can free everything that I allocate. And the runtime take over the left-over memory part at any time in the future.

This may not suitable for applications where memory is just as scare as .. say.. file handles, but for the stuff I write so far, this would put less burden on the developer while still enables to write good and robust libraries.

So for me it did not look like the lowest common denominator but rather "the combined advantage of both worlds".

Said that, I haven't looked at anything else except the destructor semantic.


What is with the "how templates interact with types"? Does C++/CLI shun the C++ approach of using templates as a compile-time code generator engine and instead use the (IMHO inferiour) runtime code generation of C#?

Ciao, Imi.