OSDev.org

a) You've touched on the one thing about most GC systems that I am vehemently opposed to -- finalizers. Finalizers suck. They cause overhead, they make no guarantees about when your resources will be freed, etc. They are just a Bad Idea. I think the best mix is GC for memory only, and a scoped RAII-like idiom (or ref-counting) for managing non-memory resources (files, network connections, etc.). Java totally lacks this alternative -- at least C# has the using statement, and of course C++ has destructors and smart pointers.

Incidentally, this is pretty much how C++/CLI does things. For managed types, the destructor syntax is translated into an implementation of the IDisposable .NET interface, which is something that seems so obvious to me that it's amazing that none of the other current breed of GC languages has done it before. The using statement in C# is certainly useful but is somewhat lacking in that you can basically only use it in local scopes, whereas the destructor syntax can do automatic clean-up on an object-lifetime basis.

I am not sure I'd preach in favor of C++/CLI in general, though. I want to like the language, but there are certain things that just seem to be harder than they need to be, and to be perfectly honest Visual C++ produces some horrendous code for .NET applications (putting all the code in the header file, putting a public label in front of every single public method that the code generator adds, etc.).

There's also a serious lack of documentation (most Microsoft docs for .NET target VB and C#), and the Visual C++ team seems to be lagging behind the Visual C# team in supporting the features of .NET.

At this point, I think it's still an unfinished product, but it does seem like it satisfies Solar's a and b criteria.

Joel (not logged in) wrote:Incidentally, this is pretty much how C++/CLI does things.

Yep, I would have mentioned it, except for this:

I want to like the language, but there are certain things that just seem to be harder than they need to be

C++ is already a big kitchen sink. Adding all the %'s and ^'s to it isn't really helping matters. I like the ideas in it, but things have gotten so far out of hand that we need to start from scratch IMO.

I predict that a fan of "D" will post a reply shortly. ;D

C++ is already a big kitchen sink. Adding all the %'s and ^'s to it isn't really helping matters. I like the ideas in it, but things have gotten so far out of hand that we need to start from scratch IMO.

Although I would kind of agree that starting from scratch wouldn't be such a bad idea, it's not so much the addition of things like %'s and ^'s as it is some of the poor integration with the existing language. I think STL.NET is supposed to take care of a little bit of this, but it's lagging behind in release. I'd like to see them get it so that anything can be gcnew'ed and anything can be new'ed. Right now, there's too much separation between the two halves of the language. They also don't support const for .NET classes and don't seem to have any plans to add it (the forever problem with least common denominator support - because other languages lack const, they can't support it for C++/CLI).

One thing I do know is that when taking a Managed DirectX trivial spinning cube application from Visual C# to Visual C++. It was actually easier to take what I'd learned from Managed DirectX in C# and build the thing in native DirectX than what should have been a simple translation to Managed DirectX with C++/CLI, just because there were things that you don't have to deal with in C# that you have to deal with in C++/CLI. The real problem there is that these things aren't documented anywhere that I can find. All the docs for anything .NET seem to be for either VB or C#.