C++/CLI and Boost

Visual C++ Language

uj.

How do I best use common libraries with C++/CLI such as Boost and Loki. I'm going to use classic classes, both native and managed in my application.

My immediate need is smart pointers (like Boost.Smart_ptr). Are they avilable elsewhere in some library supplied with Visual C++ orchas beta1

Thank you.
Top

Re: Visual C++ Language C++/CLI and Boost

Alexander Stoyan

You can use the the same as before:

Code Snippet

#include

#pragma managed(push, off)

class UnmanagedClass

{

public:

...

};

#pragma managed(pop)

using namespace System;

void foo(Object^ any)

{

...

boost::shared_ptr ptr(new UnmanagedClass());

...

}

But unmanaged object can not be a part of managed:

Code Snippet

public ref class ManagedObject

{

boost::shared_ptr ptr; // C4368: mixed types are not supported

public:

};

Only pointer of unmanaged objects can be a part of managed object:

Code Snippet

public ref class ManagedObject

{

UnmanagedObject* ptr; // OK

public:

UnmanagedObject() : ptr(new UnmanagedObject())

{

}

~ManagedObject()

{

this->!ManagedObject();

}

!ManagedObject()

{

delete ptr;

}

};





Top

Re: Visual C++ Language C++/CLI and Boost

uj.

Thank you!

But what about managed classic classes

These cannot be created on the managed heap so I would need some kind of smart pointers for them too.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

Thank you!

But what about managed classic classes. Are there smart pointers available for them too somewhere

One option I guess would be to compile the Boost library with the /clr switch if that's possible.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

uj. wrote:

Thank you!

But what about managed classic classes. Are there smart pointers available for them too somewhere

One option I guess would be to compile the Boost library with the /clr switch if that's possible.



The smart pointers are header only libraries. You can use them in C++ classes, as opposed to CLR classes, in managed code doing mixed-mode C++/CLI development. Just include the appropriate Boost header file and use any header-only Boost library in C++ class managed code.

You can also build Boost non-header only libraries in C++ classes also.

You can not use the Boost shared_ptr to hold a CLR pointer. In general Boost code can not be used with CLR types. But you can certainly use any of Boost in C++ classes, even when compiling all code as managed. You can also pass C++ objects, including Boost objects, to non-CLR DLLs, just as you could have done if you were not using CLR and C++/CLI. Just make sure that any header files in those non-CLR DLLs specifically say __cdecl for all function declarations, else CLR will default to __clrcall by default, which is not what the DLL uses by default.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

So in principle I use a non-manged version of the Boost libraries (unless they're header-only). Wouldn't it be good to also have a managed version of those libraries How is the Standard C++ library handled Is there one managed and one non-managed version available

I'm asking this because I guess it's more efficient to use a managed library with managed code and a non-manage library with non-managed code. In the case of header-only libraries I've read somewhere that two versions are generate, one managed and one non-manged, and then the linker selects the appropriate one to match the code, so in this case one always gets the most efficient match.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

uj. wrote:

So in principle I use a non-manged version of the Boost libraries (unless they're header-only).



Yes, that is the idea.


uj. wrote:

Wouldn't it be good to also have a managed version of those libraries



It would still be native C++ classes ( and templates ).

The header file only Boost libraries are just header files. You would have to convince Boost developers to either build non-header file Boost libraries as CLR assemblies, or do it yourself.

uj. wrote:


How is the Standard C++ library handled Is there one managed and one non-managed version available



You need to ask Microsoft but I believe they supply a CLR assembly for their Standard C++ library. So it is managed code but with native C++ classes. They are supposedly working on a version of the Standard C++ library that will be CLR classes instead. See http://blogs.msdn.com/vcblog/archive/2006/12/22/an-update-to-stl-clr-is-complete.aspx
.
uj. wrote:


I'm asking this because I guess it's more efficient to use a managed library with managed code and a non-manage library with non-managed code. In the case of header-only libraries I've read somewhere that two versions are generate, one managed and one non-manged, and then the linker selects the appropriate one to match the code, so in this case one always gets the most efficient match.



Boost is involved with native C++. You would have to convince them to support CLR code for Boost, but I doubt they will do it directly. You can always try it yourself.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

I'm new to this so I'm just checking that I've got the principles right. I've been talking about classic C++ classes only, not the special classes of the CLI extension.

I've understood I can freely mix managed code with non-managed code found in libraries (such as Boost) but it's better if those libraries are also managed from the standpoint of interoperability (but I also realize that the managed form of a library still may be slower than the non-managed version). The problem is that one is largely on one's own to build these managed libraries.

Nobody has mentioned anything so I guess the Standard C++ library or other libraries avilable with Visual C++ doesn't sport smart pointers. It's quite funny that when smart pointers finally make it into the Standard C++ library in 2009 also GC will be introduced somewhat reducing the need for them.

Anyway thanks everybody. I'm really looking forward to using C++/CLI.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

GC has some big flaws to it, which Microsoft, Sun, and others who have used it in their systems just ignore. It leaves the manipulation of all resources other than GC memory up to the programmer to handle manually, which can easily lead to problems and errors. So I heavily doubt that smart pointers will go away once GC is introduced into the C++ standard.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

Well I don't think smart pointer will go away either.

Anyway regarding resource management in a GC environment I think C++/CLI has a quite reasonable solution whereby reference classes can be given stack semantics in functions so that their destructor gets called automatically when they go out of scope.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

uj. wrote:

Well I don't think smart pointer will go away either.

Anyway regarding resource management in a GC environment I think C++/CLI has a quite reasonable solution whereby reference classes can be given stack semantics in functions so that their destructor gets called automatically when they go out of scope.



That is a flawed general solution. It clearly does not work if one needs to pass around an object reference holding a resource to be used by other portions of a module, and one wants the last instance of those reference going out of scope to release the resource. You may claim that does not happen often, but whether or not it does occur often, when it does happen it is a problem which Boost's shared_ptr solves very nicely and GC systems like dotnet do not.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

Well if it was an attempt to provide a general solution it was flawed but it wasn't meant to be general. It's an implementation of the RAII pattern for shortlived objects (with the lifetime of the function where they're created). If you want RAII for longlived objects you need reference counting . You could implement the necessary smart pointers for CLI references, couldn't you, if it's not already done

So the problem isn't the existance of CG in .NET. The problem is that nobody has implemented smart managed pointers sporting reference counting. They couldn't be used to control memory deallocation because that's still the job of the GC but they could be used to deallocate other resources. They would be a general RAII solution.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

uj. wrote:

Well if it was an attempt to provide a general solution it was flawed but it wasn't meant to be general. It's an implementation of the RAII pattern for shortlived objects (with the lifetime of the function where they're created). If you want RAII for longlived objects you need reference counting . You could implement the necessary smart pointers for CLI references, couldn't you, if it's not already done

So the problem isn't the existance of CG in .NET. The problem is that nobody has implemented smart managed pointers sporting reference counting. They couldn't be used to control memory deallocation because that's still the job of the GC but they could be used to deallocate other resources. They would be a general RAII solution.



The problem in dotnet is that the smart pointers themselves would have to be generic value types with a copy constructor, assignment operator, and destructor, so that when the smart pointer is passed or goes out of scope, the reference count is increased or decreased accordingly in the appropriate member functions, ala Boost shared_ptr. If you look at value types in dotnet you immediately realize that this will not work because value types have no destructors. Also of course value types have no default constructors and, while this may be worked around, it is onerous to say the least.

Of course in some other GC systems, such as Java, there is no possibility of encapsulating a smart pointer in a value type since there is no possibility of a user-defined value type at all ! But even in dotnet the value type is so constrained as to be useless for doing so.

Even beyond that you are creating a dichotomy between how you work with objects which encapsulate non-memory resources and how you work with objects which only involve the releasing of GC memory. Ideally a good GC would automtically take care of both.

The flaw is a general one in GC systems, in the fact that non-memory resources which may need a deterministic destruction of an object at a particular time can not automatically be accomodated by GC systems which only involve the non-deterministic destruction of an object. GC systems work adequately in dealing with the one resource which programmers view the most important, memory, through non-deterministic destruction, but hardly work at all with all other types of resources. In the latter case only manual "destruction", ie. releasing, of objects will work but, as I have shown when passing such resource objects around, this is error prone.

The majority of people using GC and objects which encapsulate non-memory resources constrain themselves by simply not passing them around, but use them in one place and then immediately release their resource after that that one use, either manually or through, for example, the dotnet language construct you originally mentioned as a solution. While this may be acceptable for most it is not conducive to more complicated programming designs. This is a general flaw in current GC systems and Microsoft was just as remiss as Sun has been with Java to solve it. However if one does not encounter the situation, or accepts the constraint mentioned just above, one is not aware of this general flaw.

C++'s smart pointers, such as Boost shared_ptr, solve this problem but of course there are other problems, such as cross-referenced object pointers, which GC solves better. Therefore even if GC is added to C++ as an option for programmers to use in native C++ programming, I do not think that smart pointers will go away any time soon. In fact I hope to see in the near future Microsoft and Sun and Python, and other technologies which have embraced the GC non-deterministic destruction of objects methodology, also add support in their GC implementations for the deterministic destruction of objects in order to deal adequately with the type of RAII objects we have been discussing.


Top

Re: Visual C++ Language C++/CLI and Boost

uj.

I think you misunderstood what I was saying.

I said if you desperately wanted reference counting in a GC environment you can get it. You can implement reference counting in Java or C# if you want.


Top

Re: Visual C++ Language C++/CLI and Boost

eldiener

uj. wrote:

I think you misunderstood what I was saying.

I said if you desperately wanted reference counting in a GC environment you can get it. You can implement reference counting in Java or C# if you want.



I am not sure to whom the "you" refers, but my reply adequately shows that it is impossible for the end user to implement automatic reference counting in dotnet and Java the way they are designed at present. As for manual reference counting I have no doubt it can be done by the end user, similar to the way COM had AddRef and Release for COM interfaces, but that is the backward world from which we have come and I do not think it is the direction toward which anyone wants to go anymore in order to fix the inadequacy in GC systems which I have specified.

Instead, of course, systems like dotnet and Java should implement automatic deterministic destruction of objects for resource-holding types. However since both Sun and Microsoft are satisfied with their flawed GC systems, and since the computer programming world has accepted these flaws it with hardly a murmur, I am not holding my breath that either will do so in the immediate future.


Top