Advantages of managed c++ over c# and vb .net

[ajbharani]

What is the advantage in using MC++ over using C# .NET or vb .NET?

Bharani.

[darwen]

Not a lot : I prefer C# to C++/CLI.

It does have some nice features like :

1) Seemless interaction with native C++ : you can mix native C++ and managed code together and the compiler sorts out the interop.
2) You can have managed templated classes : but not across dll boundaries.
3) Allegedly it creates faster code by using C++ compiler techniques like inlining etc.
4) You can declare classes 'on the stack' and their dispose methods will be called automatically e.g.


ref class MyClass
{
~MyClass()
{
// implements IDisposable::Dispose
}
} ;

void exampleMethod()
{
MyClass myClass; // note no '^'
// blah blah
} // 'myClass' gets IDisposable::Dispose method called when it goes out of scope


It has some major drawbacks :

1) It takes a LOT longer to develop anything in C++/CLI than in C#. Much, much more typing, intellisense doesn't work properly etc.
2) Don't use it to write UI unless you like hitting your head with a hammer.

Darwen.

[_uj]

What is the advantage in using MC++ over using C# .NET or vb .NET?


The purpose of C++/CLI is to be a bridge between existing C++ code and .NET. so I don't think it's such a good idea to develop new .NET applications in C++/CLI unless you happen to like classic C++ of course and is willing to pay for the privilege of using it also in the world of managed code.

The biggest drawback with C++/CLI in my view is that it's hard to find information and example code. Coding in C++/CLI is a solitary experience and that's a pity because I think C++/CLI is a much better language than both C# and Java. C++/CLI deserves better. The technology is there. The compiler is amazing. What's needed is promotion.

[Jim_Auricman]

I agree that developing software in C# goes faster because Intellisense is a big help, etc. But if you want to have the project in managed C++, a company called Tangible Software Solutions makes conversion programs that convert, i.e. from a C# project to managed C++. I have tried the conversion program to convert to C++ from C#, and I am impressed how well it is done. It requires only minimal manual correction after the conversion has been done.

[JamesSchumacher]

I am going to quote myself from another thread. This deals with native C++ versus .NET --- However, just note that native C++ can be embedded in C++/CLI. This would be an obvious advantage of C++ over C# and/or VB.

And it's in reference to My CListBox (http://cid-f7d26664ce20e649.skydrive.live.com/self.aspx/Useful%20Code/test_listbox.exe) I implemented in native C++.

Imagine the managed heap trying to deal with that, that's not going to happen. :rolleyes:

Re: [RESOLVED] Why does this code leak memory?

--------------------------------------------------------------------------------

Quote:
Originally Posted by Hermit
That wasn't the point. The point is that:
- No one wants to deal with a list that has substantially more than 25-100 items.
- If they do, it had BETTER have search capabilities

And here we are still talking about list boxes. What about the container it uses, that you claim is comparable but superior to vector (i.e. a simple, contiguous, random access container)? Or have you built memory management right into your list box?


The default allocator in STL is essentially new([])/delete([]), and vectors are almost always mentioned in the context of replacing new[]/delete[]. What could possibly be your point, then?

Secondly, there is a huge difference between implementing a custom allocator and re-implementing vector. Not to mention that a custom allocator, if made properly, could be used by any type of container.



Search capabilities can be added to my CListBox with ease. You can access the container from the listbox. How do you think I am adding 250,000 strings when the button is clicked? Which means the search could be implemented in an interface member of the CListBox, or as an outside function working on the collection itself. This is not something that would be hard to accomplish. In fact, it's ironic that I was saying this myself just last night.

With a search function in a list box (you are right, I said that last night myself) it is even viable to search a list of over 10,000,000 names for example... And it would be single selection mode then, in which the data of that person would be displayed in other controls.

And it's not like you (whoever client is) are limited to a CListItem... It stores pointers for a reason... And the container itself has SetCapacity() AND SetBlockSize() members for dealing with reallocations. I have thought this out very well.

The CListBox::AddString just creates a CListItem to add to it, and when it does calls CListBox::AddItem.

And now maybe you will realize you are talking to an IT professional. (Even though I have had no paying experience.)

Or maybe you just want to hear more about how important these things are and that you want to hear more technical details. Let's just put it this way, as far as technical issues goes...

This is my REALITY TEST, to wake up Microsoft and others out there, that .NET is a mistake... And bloated code just stacked on top of other bloated code (a lot of open source projects, and Apple's stuff as well - not open source) is not a viable solution either.

This is what I meant by 'real world' Paul. Not knowing the innards of what makes STL successful in what it is good at (speed in general, because of iterators), handicaps you (people in general) Paul.

Now understand why I threw my 2 cents in.

There, the ISSUE has been closed.
__________________
TRX - My Game I Am Working On

--------------------------------------------------------------------------------
Last edited by JamesSchumacher : Today at 08:53 PM.

[Arjay]

I hate to be critical, but your sample list box application looks like it was created for Windows 3.1.

Seriously James, you need to check out some of the new frameworks.

[darwen]

This is my REALITY TEST, to wake up Microsoft and others out there, that .NET is a mistake


I don't think so. Anything which makes my software more reliable has got to be a good thing in my book. And .NET does just that.

Not to mention the easy to use unit testing frameworks (my preference is NUnit).

And speed of development.

And zero memory/resource leaks.

And very clean code.

And true cross platform support (with Mono)- this is even better than Java cross platform support from what I've heard.

And it's truly object oriented.

Darwen.